UNIVERSITÉ AUBE NOUVELLE

INSTITUT SUPÉRIEUR D’INFORMATIQUE ET DE GESTION

DÉPARTEMENT HIGH - TECH

MÉMOIRE EN VUE DE L’OBTENTION DU DIPLOME DE MASTER

DOMAINE : SCIENCES ET TECHNOLOGIE

OPTION : SECURITE INFORMATIQUE

THEME : ETUDE POUR LA REALISATION D’UN

SECURITY OPERATION CENTER (SOC) AU
PROFIT DE SUNU ASSURANCES IARD BURKINA
FASO
Présenté le 15 Juin 2023 par DENE Palmedé Ibrahim

Président du jury : Pr. SIE Oumarou

Membres :

1) Dr. YANOGO Jean K Hermann, Directeur de Mémoire, PhD en Cyber Sécurité

2) M. ALLAHISSEM Mrangaye, Maitre de stage, DSI de SUNU Assurances

3) Dr. BASSOLE Didier, Rapporteur, Enseignant-Chercheur en Informatique Université

Joseph KI-ZERBO

Juin 2023
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

DEDICACE

Nous dédions ce travail

A nos chers parents pour tous leurs sacrifices, leur amour, leur tendresse, leur soutien et leur
prière tout au long de mes études.
Merci d’être toujours là pour moi.

DENE PALMEDE IBRAHIM/U-AUBEN

I
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

REMERCIEMENTS

Ce présent rapport est le fruit de la contribution de plusieurs personnes. Qu’elles trouvent ici,
toute notre gratitude pour leurs soutiens, conseils et disponibilités. Nos sincères remerciements
vont particulièrement à l’endroit de :

Monsieur KINI Gnatan Isidore, Président Directeur Fondateur de l’université Aube

Nouvelle ;
Monsieur COMPAORE Mohamed, Directeur General de SUNU Assurances IARD
Burkina Faso pour m’avoir accepté au sein de son entreprise ;
Monsieur le président du jury ;
Notre Directeur de mémoire Dr. YANOGO Jean K Hermann, malgré ses multiples
occupations a accepté avec une approche très remarquable de nous accompagner lors de
la réalisation de ce document. Nous le remercions aussi pour sa disponibilité et nous en
profitons pour lui exprimer ici notre plus profonde gratitude ;
Monsieur ALLAHISSEM Mrangaye, Chef du service informatique. Votre accueil et
votre disponibilité ont été indispensables pour ma formation ;
L’ensemble du personnel administratif de L’université AUBE NOUVELLE ;
Tout le personnel de SUNU Assurances IARD Burkina Faso pour sa disponibilité et
pour son accompagnement ;
Toute ma famille : frères, sœurs, cousins, cousines, oncles et tantes pour leur soutien
moral et leurs bénédictions

DENE PALMEDE IBRAHIM/U-AUBEN

II
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

SOMMAIRE
DEDICACE .............................................................................................................................................. I
REMERCIEMENTS ............................................................................................................................... II
SOMMAIRE ......................................................................................................................................... III
LISTES DES TABLEAUX ET FIGURES ........................................................................................... IV
SIGLES ET ABREVIATIONS ............................................................................................................. VI
RESUME .............................................................................................................................................. VII
ABSTRACT ......................................................................................................................................... VII
INTRODUCTION GÉNÉRALE ............................................................................................................. 1
PROBLEMATIQUE ............................................................................................................................... 2
OBJECTIF PRINCIPAL ......................................................................................................................... 3
OBJECTIFS SPECIFIQUES ................................................................................................................... 3
HYPOTHESE.......................................................................................................................................... 3
METHODOLOGIE ................................................................................................................................. 4
PERTINENCE ET RETOMBEES ANTICIPEES .................................................................................. 4
CHAPITRE I : MISSIONS DU SOC/CSIRT, NORMES ET METHODOLOGIES .............................. 5
1.1. INTRODUCTION ................................................................................................................... 5
1.2. Concepts et fondamentaux sur les SOC .................................................................................. 5
1.3. Études comparatives sur les différentes solutions de gestion de la Sécurité SOC .................... 12
1.4. La gestion de la sécurité du réseau ........................................................................................ 17
1.5. La Gestion de Logs................................................................................................................ 20
1.6. L’équipe CIRT ...................................................................................................................... 22
1.7. Les solutions de supervisions de la sécurité réseau ............................................................... 23
1.8. Choix de la solution............................................................................................................... 28
Conclusion......................................................................................................................................... 30
CHAPITRE II : DEPLOIEMENT DE SECURITY ONION, MISE EN PLACE DE L’EQUIPE CIRT
ET TESTS ............................................................................................................................................. 31
4.1. Introduction ........................................................................................................................... 31
4.2. Architecture de Security Onion et déploiement .................................................................... 31
4.3. Installation du serveur et des sondes ..................................................................................... 36
4.4. Configuration de Security Onion........................................................................................... 49
4.5. Mise en place de l’équipe CIRT ............................................................................................ 57
4.6. Tests ...................................................................................................................................... 58
Conclusion......................................................................................................................................... 60
CONCLUSION GENERALE ............................................................................................................... 61
REFERENCES BIBLIOGRAPHIQUE.............................................................................................. VIII
TABLE DE MATIERES ....................................................................................................................... XI
ANNEXES ......................................................................................................................................... XIII

DENE PALMEDE IBRAHIM/U-AUBEN

III
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

LISTES DES TABLEAUX ET FIGURES

Liste des Tableaux
Tableau 1: Répartition des activités SOC/CSIRT .................................................................................. 8
Tableau 2 : Tableau Comparative des différentes solutions de SOC .................................................... 15
Tableau 3 : Tableau comparatif des différentes solutions testées Source [1] ........................................ 29

Liste des Figures

Figure 1: Les 4 grandes activités de la sécurité opérationnelle ............................................................... 6
Figure 2 : Chaîne de traitement d'un incident de sécurité ....................................................................... 6
Figure 3 : Processus de gestion des incidents ........................................................................................ 10
Figure 4 : Cycles d’une attaque informatique ....................................................................................... 17
Figure 5 : Cycle de sécurité de l’entreprise ........................................................................................... 18
Figure 6 : Couches d’une plateforme de SSR ....................................................................................... 19
Figure 7 : Architecture d'un système de gestion de logs type ............................................................... 22
Figure 8 : Architecture de Security Onion, source [31] ........................................................................ 31
Figure 9 : Vue synoptique du réseau de SUNU Assurances IARD....................................................... 33
Figure 10 : Les emplacements possibles pour les sondes...................................................................... 34
Figure 11 : Vue synoptique du réseau avec les sondes, les TAP et le serveur Security Onion ............. 35
Figure 12 : Choix de l’interface réseau Management ........................................................................... 36
Figure 13 : Résumé de la configuration réseau ..................................................................................... 37
Figure 14 : Lancement de la configuration de Security Onion.............................................................. 37
Figure 15 : Choix du cas d’utilisation ................................................................................................... 38
Figure 16 : Choix du mode de déploiement .......................................................................................... 38
Figure 17 : Choix du mode de configuration......................................................................................... 38
Figure 18 : Nom d’utilisateur/mot de passe pour Sguil, Squert et ELSA ............................................. 39
Figure 19 : Durée de garde des données................................................................................................ 39
Figure 20 : Choix du NIDS ................................................................................................................... 39
Figure 21 : Choix de la base de signature du NIDS Snort..................................................................... 40
Figure 22 : Saisie de l’Oinkcode ........................................................................................................... 40
Figure 23 : Choix d’activation de Salt................................................................................................... 41
Figure 24 : Choix d’activation d’ELSA ................................................................................................ 41
Figure 25 : Réservation d’espace disque pour les logs ELSA ............................................................... 41
Figure 26 : Résumé des paramètres d’installation du serveur ............................................................... 42
Figure 27 : Etat des services du serveur Security Onion ....................................................................... 42

DENE PALMEDE IBRAHIM/U-AUBEN

IV
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

Figure 28 : Console Sguil avec une alerte OSSEC détaillée ................................................................. 43

Figure 29 : Interface d’ELSA ................................................................................................................ 43
Figure 30 : Choix du mode de déploiement .......................................................................................... 44
Figure 31 : Demande de l’adresse IP du serveur ................................................................................... 44
Figure 32 : Nom d’utilisateur possédant les droits SU sur le serveur ................................................... 44
Figure 33 : Choix interface de sniffing ................................................................................................. 45
Figure 34 : Activation des IDS .............................................................................................................. 45
Figure 35 : : Activation de l’analyseur Bro ........................................................................................... 45
Figure 36 : Activation de l’extraction des exes par Bro ........................................................................ 46
Figure 37 : Activation d’Argus ............................................................................................................. 46
Figure 38 : Option Full packet capture .................................................................................................. 46
Figure 39 : : Espace disque à réserver ................................................................................................... 47
Figure 40 : Activation de Salt sur une sonde......................................................................................... 47
Figure 41 : Activation d’ELSA ............................................................................................................. 47
Figure 42 : Mise à jour du nœud serveur ............................................................................................... 48
Figure 43 : Résumé des paramètres d’installation de la sonde .............................................................. 48
Figure 44 : Une partie des résultats de la sostat redacted ...................................................................... 48
Figure 45 : Etat des services sur le serveur Security Onion (SO) ......................................................... 49
Figure 46 : Configuration de la durée d’archivage de Security Onion .................................................. 49
Figure 47 : Configuration des réseaux Snort ......................................................................................... 50
Figure 48 : Configuration des réseaux Bro............................................................................................ 50
Figure 49 : Statistique des règles Snort ................................................................................................. 52
Figure 50 : Un enregistrement dans un log d’une application non prise en charge............................... 53
Figure 51 : Décodeur et règle personnalisé OSSEC pour le log de la figure 50 ................................... 53
Figure 52 : Mise à jour de Security Onion avec soup ........................................................................... 54
Figure 53 : Aperçu d’un dossier journalier............................................................................................ 55
Figure 54 : Contenu du dossier des bases de données de MySQL ....................................................... 56
Figure 55 : Requête MySQL pour les espaces occupés source [6] ....................................................... 56
Figure 56 : Résultats d’un scan vu les NIDS dans la console Sguil ...................................................... 59
Figure 57 : Attaque par force brute détectée et stoppée par OSSEC .................................................... 60

DENE PALMEDE IBRAHIM/U-AUBEN

V
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

SIGLES ET ABREVIATIONS
API Application Programming Interface
CERT Computer Emergency Response Team
CIRT Computer Incident Response Team
CMDB Configuration Management Database
CNIL Commission Nationale de l’Informatique et des Libertés
COBIT Control Objectives for Information and Related Technology
CSIRT Computer Security Incident Response Team
ELK Elasticsearch Logstash Kibana
ELSA Enterprise Log Search and Archive
ENISA The European Union Agency for Cybersecurity
FAQ Frequently Asked Questions
HIDS Host-based Intrusion Detection System
HSRP Hot Standby Routing Protocol
IDS Intrusion Detection System
IoC Indicator of Compromise
IoT Internet of Things
IT Information Technology
ITIL Information Technology Infrastructure Library
LIDS Log-based Intrusion Detection System
MSSP Managed Security Services Provider
NAS Network Area Storage
NIDS Network Intrusion Detection System
NIPS Network Intrusion Prevention System
NSM Network Security Monitoring
OCS Open Computer and Software
OpenVAS Open Vulnerability Assesment System
OSSEC Open Source Security
OSSIM Open Source Security Information Management
PDCA Plan Do Check Act
QQOQCCP Quoi, Qui, Où, Quand, Comment, Combien, Pourquoi
RFC Requested For Comment
RADIUS Remote Authentication Dial In User System
RAID Redundant Array of Independent Disk
SIEM Security Information and Event Management
SI Système d’Information
SLA Service Level Management
SLO Service-Level Objectives
SO Security Onion
SOC Security Operations Center
SSH Secure Shell
VPN Virtual Private Network

DENE PALMEDE IBRAHIM/U-AUBEN

VI
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

RESUME
Dans ce projet, on s’intéresse à la mise en place d’une solution de gestion de la sécurité du
réseau de SUNU Assurances IARD Burkina Faso. Une telle solution est composée d’un tableau
de bord de sécurité du réseau, d’une solution de gestion de logs centralisées et d’une équipe
CIRT pour le pilotage de la solution. De ce fait, nous avons commencé d’abord par un audit de
vulnérabilité du réseau et du système informatique en passant un test d’intrusion. Ensuite
effectué une évaluation des risques en conformité avec l’audit réalisé. Enfin procéder à la mise
en place d’un tableau de bord de sécurité du réseau. Pour se faire, nous avons mis en place
l’outil Security Onion associé à d’autres outils pour avoir une vue globale sur la sécurité du
réseau. La seconde étape sera consacrée à la gestion des informations et événements de sécurité
provenant des logs. Dernièrement, nous avons procédé à la mise en place d’une équipe CIRT
pour le pilotage des différents outils mis en place afin d’assurer une meilleure gestion de
sécurité au sein de l’entreprise.
Mots clés : Tableau de bord, Security Onion, NSM, log, IDS, CIRT, vulnérabilité,
détection, intrusion.

ABSTRACT
In this project, we are interested in the implementation of a network security management
solution for SUNU Assurances IARD Burkina Faso. Such a solution is composed of a network
security dashboard, a centralized log management solution and a CIRT team to manage the
solution. Therefore, we first started with a vulnerability audit of the network and the computer
system by passing an intrusion test. Then carried out a risk assessment in accordance with the
audit carried out. Finally, proceed with the implementation of a network security dashboard. To
do this, we have implemented the Security Onion tool associated with other tools to have a
global view of network security. The second step will be devoted to the management of
information and security events from the logs. Recently, we set up a CIRT team to manage the
various tools put in place to ensure better security management within the company.
Key words: Dashboard, Security Onion, NSM, log, IDS, CIRT, vulnerability, detection,
intrusion.

DENE PALMEDE IBRAHIM/U-AUBEN

VII
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

INTRODUCTION GÉNÉRALE

Les systèmes d’informations informatisés sont désormais au cœur de l’activité des entreprises
et le moindre dysfonctionnement entraîne des risques cruciaux comme mécontentement des
clients, réputation négative, pertes de revenus, voire mise en péril de l’entreprise.
Les entreprises dépendent de plus en plus de l’informatique pour réaliser leurs objectifs. Elles
sont donc plus sensibles à la qualité des services informatiques fournis aux différentes
catégories d’utilisateurs et sont à la recherche de moyens et de ressources pour améliorer ces
services.
Tandis que les entreprises apprennent à mieux se protéger, les criminels élaborent dans le même
temps des techniques toujours plus sophistiquées pour franchir leurs murs de sécurité. Attirés
par les possibilités de gain sans précédent que les cyberattaques peuvent générer, les auteurs de
menaces toujours plus nombreux cherchent et ciblent activement les failles de sécurité
auparavant inconnues. De plus en plus de centres de supervision de la sécurité (SOC) sont mis
en place pour lutter contre les problèmes de sécurité à mesure qu'ils se présentent, fournissant
ainsi une réponse et une résolution dans les plus brefs délais.
Pour répondre à cet objectif, l’organisation est amenée à mettre en place des dispositifs
opérationnels et des dispositifs de pilotage. C’est dans cette optique que la société SUNU
Assurances IARD nous a soumis un projet portant sur « Etude pour la Réalisation d’un
Centre de Sécurité des Opérations (SOC) au profit de SUNU Assurances IARD ».
Notre travail sera structuré en quatre principaux chapitres : D’abord, dans un premier chapitre,
nous allons aborder les différents concepts sur les SOCS et les CSIRT et mener une étude des
différentes solutions et au choix de la solution. Et enfin le deuxième chapitre sera consacré au
déploiement de la solution suivi du test de sécurité.

DENE PALMEDE IBRAHIM/U-AUBEN

1
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

PROBLEMATIQUE
SUNU Assurances IARD Burkina Faso dispose d’agences à travers le Burkina Faso qui sont
interconnectées en temps réel aux infrastructures de SUNU Assurances IARD afin de saisir les
contrats d’assurances et de communiquer entre elles. SUNU Assurances IARD et SUNU
Assurances Vie d’une distance de 500 mètres sont également interconnectés à travers une
mutualisation des infrastructures techniques, à savoir les serveurs et les espaces de stockage et
la mise en place d’un plan de reprise informatique (PRI) en cas de besoin.

Avec le nombre croissant de failles de sécurité et la sophistication grandissante des

cyberattaques, les entreprises doivent aujourd'hui revoir leur approche de la cybersécurité.
En effet SUNU Assurances IARD Burkina Faso a été une fois victime d’une cyber-attaque de
type Ransomware rendant pendant un certain temps une indisponibilité du système. Il aura fallu
l’implémentation d’un plan de reprise informatique (PRI) pour assurer la continuité de service.
De ce fait Il est désormais nécessaire de basculer dans une approche où l'on va privilégier à la
fois une analyse complète des données à l’aide d’outils de supervision avancés. Franchir cette
étape est indispensable pour sécuriser les infrastructures informatiques existantes.

Durant nos premières semaines de stage, nous avons constaté des insuffisances relatives au
fonctionnement, à l’organisation et à la sécurité au niveau du système informatique de SUNU
Assurances. Parmi ces insuffisances, nous avons :
• Le manque de système centralisé pour la gestion de tous les incidents ;
• L’absence de la base de connaissances de tous les incidents traités ;
• La masse et la diversité des informations à traiter ;
• L’identification des évènements précurseurs d’alertes de sécurité ;
• L’appropriation du sujet et la réunion des compétences requises pour un projet
d’envergure.
Soucieux de ces différents problèmes et du maintien de la qualité du service, SUNU Assurances
se lance dans la quête d’une solution lui permettant de résoudre le plus rapidement ces
problèmes. C’est dans ce contexte que ce projet portant sur « L’Etude et la Réalisation du
Security Operation Center (SOC) » nous été soumis.

DENE PALMEDE IBRAHIM/U-AUBEN

2
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

OBJECTIF PRINCIPAL
L’objectif principal de notre étude est d’évaluer avec précision la capacité du système
d’information de SUNU Assurances à résister face aux attaques informatiques, à identifier les
failles et appliquer les actions correctives nécessaires en procédant à la mise en place du
Security Operation Center (SOC).

OBJECTIFS SPECIFIQUES
Pour améliorer le niveau de sécurité du système informatique de SUNU Assurances, nous nous
sommes fixés les objectifs spécifiques suivants :
➢ Garantir l’intégrité des données et le capital informationnel
➢ Concevoir un Système prêt à répondre à tout Cyber-Attaques
➢ Et de définir une Politique de Sécurité et de protection des données
Enfin, le SOC ne concerne pas seulement les équipements informatiques ; il touche aussi et
surtout chaque utilisateur. C’est la raison pour laquelle une formation sur les règles d’usage
sécuritaires doit être dispensée afin de mieux contrôler les pratiques de chaque collaborateur.

HYPOTHESE
Comme toute démarche d'un travail scientifique suppose une interprétation anticipée des faits
à étudier et à concevoir qui seront par la suite confrontés à la pratique qui les affirmera ou les
infirmera, dans nos recherches exploratoires, nous avons supposé que :
➢ La réalisation d’un centre de sécurité des opérations, permet d’obtenir une vision
complète et réaliste de la capacité de l’infrastructure analysée à résister aux attaques
de tous types et de toutes origines, pour obtenir un système plus performant, mieux
sécurisé et enfin, plus économique.
➢ La clé d’un système d’information performant et protégé au maximum de toutes
menaces est l’anticipation. Il convient également d’y avoir recours à intervalles
réguliers afin de faire face à l’évolution des attaques, mais également d’adapter son
infrastructure informatique en fonction des mises à jour nécessaires.
➢ Un centre de sécurité des opérations régulier permet de vérifier la productivité des
équipements du parc informatique, des systèmes d’exploitation et des logiciels, afin
d’apprécier l’adéquation de chaque poste avec les besoins actuels de l’utilisateur.

DENE PALMEDE IBRAHIM/U-AUBEN

3
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

➢ En adoptant régulièrement des actions correctrices, l’entreprise évite de perdre en

rapidité et efficacité et élimine les risques d’attaques imprévues, pouvant engendrer
des conséquences désastreuses (ralentissement de l’activité, pertes financières…).

METHODOLOGIE
Tout travail bien défini d’un système d’information nécessite une méthode de travail claire.
Cette méthode s’articulera autour des points suivants :
➢ Contexte du projet et présentation des structures de formation et d’accueil ;
➢ Une vue d’ensemble sur les systèmes d’information ;
➢ Mission, normes et méthodologies de sécurité des systèmes d’information ;
➢ Analyse et conception du projet ;
➢ L’analyse de l’existant qui consiste à critiquer le système actuel pour ressortir ses
limites
➢ Recommandation et proposition des solutions.

PERTINENCE ET RETOMBEES ANTICIPEES

En effet, la réalisation d’un centre de sécurité des opérations peut avoir plusieurs retombées et
du point de vue de plusieurs groupes d’utilisateurs.
Du point de vue gain l’organisme gagnera un temps considérable en cas d’audit informatique,
car l’audit permettra d’anticiper d’éventuels problèmes en rapport avec certaines erreurs
techniques et réagir ainsi de manière proactive. L’entreprise aura un état des lieux récent et
complet. Cela va permettre à l’organisme de se comparer avec ces concurrents. C’est également
un avantage pour effectuer des mises à jour d’applicatifs qui sont nécessaires, qui corrigent en
général les failles de sécurité.

DENE PALMEDE IBRAHIM/U-AUBEN

4
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

CHAPITRE I : MISSIONS DU SOC/CSIRT, NORMES ET

METHODOLOGIES
1.1. INTRODUCTION

Ce chapitre sera consacré à la sécurité des systèmes d’information. Dans un premier temps nous
allons introduire les concepts et fondamentaux sur les socs ; ensuite effectué un premier
parcours de l’ensemble du domaine, de ses aspects humains, techniques et organisationnels,
sans en donner de description technique. Et en deuxième lieu nous allons faires une étude sur
les différentes solutions de supervisions de la sécurité réseau.

1.2. Concepts et fondamentaux sur les SOC

Le “Security Operation Center” (SOC) est avant tout une équipe d’experts en sécurité chargée
de surveiller, détecter, analyser et qualifier les évènements de sécurité. Cette équipe assure le
pilotage des réactions appropriées aux incidents avérés de sécurité. Pour certaines
organisations, cette équipe administre et contrôle au quotidien des dispositifs et dispositions de
sécurité ; par exemple le « durcissement » de systèmes d’exploitation standards en vue de
renforcer leur sécurité, ou bien la gestion d’accréditations (droits d’accès à des ressources) voire
également la gestion du « patch management ».
En support direct du métier et en partenariat avec les services IT, un SOC a pour objectif de
réduire à la fois la durée et l’impact des incidents de sécurité qui tirent profit, perturbent,
empêchent, dégradent ou détruisent les systèmes dédiés aux opérations habituelles et standards.
Cet objectif est atteint grâce à une surveillance efficace et à un suivi des incidents de bout en
bout.

1.2.1. Principales différences entre le SOC et le CSIRT

Selon l’ENISA (The European Union Agency for Cybersecurity) , un CSIRT (Computer
Security Incident Response Team) est défini comme une équipe d’experts en sécurité
informatique ayant pour mission principale de répondre aux incidents en proposant les services
nécessaires au traitement des attaques et en aidant leurs parties prenantes à restaurer les
systèmes qui en ont fait l’objet.
La limite entre SOC et CSIRT n’est pas toujours évidente à tracer. Seul un modèle de
gouvernance et des responsabilités clairement établies permettent de partager détection,
réaction et suivi des incidents. Les adhérences entre le modèle de sécurité de l’Entreprise et
l’organisation de l’Entreprise peuvent constituer un frein supplémentaire au partage des tâches

DENE PALMEDE IBRAHIM/U-AUBEN

5
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

et responsabilités (il n’est pas rare que les fonctions/rôles des deux entités soient portés par les
mêmes personnes).

Figure 1: Les 4 grandes activités de la sécurité opérationnelle

Source : Forum des Compétences Supervision de la Sécurité du système d’information dans les secteurs
Banque et Assurance - Le Security Operation Center – SOC étude mené avec ATOS. Juin 2016 Page 9/38
Il est cependant communément admis que le SOC est responsable de la gestion des
vulnérabilités, de la détection et de la qualification des incidents de sécurité alors que le CSIRT
est responsable de la gestion de crise cyber (notion plus large que la réaction à un incident de
sécurité) et de la veille autour des cybermenaces (y compris les analyses forensics).

1.2.2. Synergies entre SOC et CSIRT

Si la limite entre les deux entités n’est pas clairement définie, les adhérences et interfaces n’en
sont que plus nombreuses. Ainsi, en considérant la chaîne plus détaillée présentée ci-dessous,
le curseur du partage des missions est laissé à l’appréciation de l’organisation. L’efficacité de
la sécurité dépend de la complétude de la chaine et non de la répartition des missions.

Figure 2 : Chaîne de traitement d'un incident de sécurité

Source : Forum des Compétences Supervision de la Sécurité du système d’information dans les secteurs
Banque et Assurance - Le Security Operation Center – SOC étude mené avec ATOS. Juin 2016 Page 9/38

En complément, il est primordial de bien organiser le ou les passages de témoins (a minima

qualité et quantité de l’information transmise et moyen de transmission) entre les différents
acteurs responsables des missions. Toutes les interactions entre les missions et activités doivent
être prises en compte et pas seulement les grandes interfaces.
Si le traitement et la veille sont généralement confiés au CSIRT, il faut noter que l’objectif est
que le SOC gagne en maturité et en efficacité au fur et à mesure du traitement des incidents. La
façon la plus simple d’atteindre cet objectif est de constituer des fiches de retours d’expériences

DENE PALMEDE IBRAHIM/U-AUBEN

6
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

(REX ou REEX) à l’issue de toute intervention du CSIRT. Ainsi, au fur et à mesure, si un

incident est enregistré à propos de technologies, produits ou attaques connues, et que celui-ci
fait l’objet d’une fiche ou procédure qui permet le traitement de l’incident, le SOC pourra
dérouler la chaine sans avoir à solliciter l’entité CSIRT. Selon ce modèle de maturité, le CSIRT
n’est alors sollicité (en escalade) qu’en cas de nouvelle attaque (inédite) nécessitant une
expertise spécifique. Le CSIRT pilote alors la résolution le temps de pouvoir industrialiser la
remédiation.

DENE PALMEDE IBRAHIM/U-AUBEN

7
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

Le tableau ci-dessous propose une répartition typique des activités. Comme précisé dans les paragraphes ci-dessus, chaque organisation est libre
d’adapter les missions des entités SOC et CSIRT du moment que la chaine de traitement est considérée de bout en bout.

Tableau 1: Répartition des activités SOC/CSIRT

Source : Forum des Compétences Supervision de la Sécurité du système d’information dans les secteurs Banque et Assurance - Le Security Operation Center – SOC
étude mené avec ATOS. Juin 2016 Page 10/3
SOC CSIRT
Gestion des vulnérabilités sur le périmètre Responsable Contribue (cf. Veille)
Collecte des événements sur le périmètre Responsable
Gestion des règles de corrélation d’évènements Responsable
Pondération des événements => émission d’alertes Responsable
Qualification de l’incident (instruction) Responsable/Contributeur Responsable/Contributeur

Responsable. Veille à
Pilotage de la remédiation Contributeur l’industrialisation de la
remédiation.
Acteur primaire Acteur sollicité sur escalade
Remédiation technique depuis N2 ou N3
(escalade N1 > N2 > N3)
Clôture de l’incident Responsable
Gestion de cybercrise Contributeur Responsable
Veille technologique / Veille menaces Responsable
Analyse post-mortem Responsable
Communication avec les autres CERT2 Responsable

DENE PALMEDE IBRAHIM/U-AUBEN

8
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

1.2.3. Journaux, événements, alertes et incidents

Pour éviter toute confusion dans la suite de ce document, les définitions des termes « journaux
/ enregistrements », « événements », « alerte » et « incident » sont proposées ci-dessous :

1.2.3.1. Journaux / Enregistrements

Les « journaux » ou « enregistrements » constituent la matière première (généralement à l’état
brut) que le SOC devra manipuler, analyser, corréler tout au long de la journée. Tout élément
d’un système d’information produit désormais des enregistrements agrégés en journaux. C’est
à partir de ces éléments que sont créés les premières métriques et rapports d’activités d’un SOC.
Constituant les logs d’un système actif, ces journaux sont généralement conservés à des fins
d’exploitation ou d’investigation.
1.2.3.2. Evénement
Selon la norme ITIL v3, un « événement » correspond à un changement d’état suffisamment
important pour être notifié à un gestionnaire du service. Ainsi, il peut s’agir d’un changement
d’état normal ou, au contraire, d’un changement pour un état anormal (ex. une défaillance). Un
événement peut être transcrit par un ou plusieurs enregistrements dans un journal.
Dans le cadre de ce document, nous préférerons la définition de la norme ISO 27000 (2.20) qui
précise qu’un événement de sécurité est une occurrence identifiée de l'état d'un service, d'un
système ou d'un réseau indiquant une faille possible dans la politique de sécurité de
l'information ou un échec des mesures de sécurité ou encore une situation inconnue jusqu'alors
et pouvant relever de la sécurité.
1.2.3.3. Alerte
Une alerte correspond à un événement ou à un groupe d’événements pondéré. Cette pondération
est particulièrement importante puisqu’elle permet de classer les événements et de ne retenir
que ceux qui atteignent ou dépassent un seuil de vigilance.
Les alertes peuvent être classées en différentes catégories :
- Faux positif : la pondération a été positionnée de façon inadaptée, rendant un événement
important à tort. Dans ce cas, le comportement du système est considéré défaillant à tort.
- Vrai positif : la détection a été correctement positionnée. Il s’agit d’une alerte qui correspond
réellement à un événement redouté ou à comportement anormal du système.
- Faux négatif : le mécanisme de détection n’a pas correctement fonctionné et un événement
qui aurait dû être identifié en tant qu’alerte n’a pas été repéré et classé. Le système est défaillant
et aucune alerte n’appuie ce statut.

DENE PALMEDE IBRAHIM/U-AUBEN

9
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

- Vrai négatif : le mécanisme de détection est adapté. Le comportement du système n’est pas
défaillant et aucun événement n’est identifié en tant qu’alerte à tort.

1.2.3.4. Incident
Toujours selon la norme ITIL, un incident est une interruption non planifiée d’un service, une
réduction de la qualité d’un service ou la défaillance d’un élément du système. Un incident est
associé à un impact négatif (perçu ou non) sur la qualité de service globalement perçue par les
utilisateurs du système.
Dans le contexte de la sécurité des systèmes d’information, la norme ISO 27000 (2.21) définit
un incident comme un ou plusieurs évènements liés à la sécurité de l'information indésirables
ou inattendus présentant une probabilité forte de compromettre les activités de l'organisation et
de menacer la sécurité de l'information.
La chronologie suivante peut être établie :

Figure 3 : Processus de gestion des incidents

[Source : Forum des Compétences Supervision de la Sécurité du système d’information dans les secteurs
Banque et Assurance - Le Security Operation Center – SOC étude mené avec ATOS. Juin 2016 Page 12/38]

Les incidents peuvent être catégorisés par le SOC ou le CSIRT, selon des critères propres à
l’organisation, pour permettre un reporting à plus haut niveau et, in fine, outiller le pilotage de
la sécurité des S.I. La catégorisation permet également de favoriser les comparaisons entre
pairs. La norme ISO 27014 et les documents de travail de l’ETSI3 établissent à cet effet, la
catégorisation/taxonomie des indicateurs/catégories d’incidents de sécurité.

1.2.4. Le SIEM
Les SIEM (Security Information and Event Management – système de gestion des informations
et des événements de sécurité) se sont imposés avec la démocratisation de la génération des
journaux et des traces que produisent les différents systèmes et plus particulièrement ceux de
sécurité. Il ne suffit plus, aujourd’hui, d’observer les traces produites par un composant de
sécurité pour s’assurer du bienfondé du comportement du système complet. Il faut, à minima,
considérer les traces des différentes briques essentielles du système.

DENE PALMEDE IBRAHIM/U-AUBEN

10
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

Les SIEM sont généralement complétés d’une solution de gestion de traces (dotée des
fonctionnalités d’archivage, de stockage, de protection et d’indexation).
Les SOC s’appuient systématiquement sur un ou plusieurs SIEM. Ce sont eux qui fournissent
les éléments de base du travail de tout analyste. Leur prétraitement permet aux analystes de se
débarrasser de la fastidieuse tâche de collecte et d’inventaire des événements sur tous les
périmètres concernés.

1.2.5. Le SOC dans la stratégie SSI

La sécurisation d’un système d’information doit être abordée selon les 4 volets suivants :
▪ Gouvernance : Définition et mise en place de la gouvernance, c’est-à-dire
identifier les acteurs, les rôles, les règles et les processus qui régissent la sécurité
du système d’information. Détermination de la cible de sécurité que l’entreprise se
choisit.
▪ Protection : Sélection puis mise en place des mesures de protection
organisationnelles et techniques nécessaires pour mitiger les risques afin que la
sécurité du SI ainsi implémentée soit conforme à la cible de sécurité que l’entreprise
s’est choisie et aux multiples exigences réglementaires auxquelles elle est soumise.
▪ Détection/Réaction : Sélection puis mise en place des mesures de sécurité relatives
à la surveillance des incidents de sécurité et à leur traitement.
▪ Remédiation/Reconstruction : Reconstruction de tout ou partie du SI après une
attaque réussie.
Les mesures de protections ne peuvent pas être 100% durablement efficaces. En effet, pour des
acteurs malveillants, les mesures de sécurité mises en oeuvre ne sont que des obstacles retardant
leurs progressions. Il est généralement admis que la probabilité de réussite d’une attaque dépend
directement de la volonté de l’attaquant, des moyens et du temps dont il dispose.

DENE PALMEDE IBRAHIM/U-AUBEN

11
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

1.3. Études comparatives sur les différentes solutions de gestion de

la Sécurité SOC
1.3.1. Le Centre Opérationnel de Sécurité (COS)
Le SOC s’adresse à des organisations qui désirent maîtriser leurs risques et augmenter le niveau
de sécurité de leur système d’information tout en contrôlant le coût correspondant. Pour ce faire,
l’objectif de l’organisation va être de répartir son effort sur les trois temps de la sécurité : la
prévention, la détection et la réaction.

1.3.2. Activités d’un SOC

La mission principale d’un SOC consiste à surveiller, détecter, analyser et qualifier les
évènements de sécurité. Elle se décline en 3 activités majeures pouvant être gérées
indépendamment :
✓ Activité #1 Supervision/Qualification/Alerting ;
✓ Activité #2 Pilotage des incidents de bout en bout ;
✓ Activité #3 (optionnelle) Traitement standardisé d’un incident.
En complément de cette mission principale, le SOC à la charge de conserver les journaux
d’activité (ou logs) qui lui sont remontés pour la durée qui a été définie.
Le SOC peut également se voir confier des missions additionnelles en fonction des
organisations, telles que :
• L’investigation sur incident également appelée forensique ou forensic ;
• La fourniture d’expertise ponctuelle sur la gestion de crise ;
• La gestion des vulnérabilités ;
• Un rôle de sécurité opérationnelle, à travers le paramétrage des équipements de
sécurité ;
• La Gestion des identités et habilitations ;
• Le traitement en profondeur des causes racines de l’incident ;
• La sensibilisation des utilisateurs et la communication de la sécurité.

1.3.3. Définition des missions d’un SOC

La définition des missions d’un SOC constitue le socle de tout SOC et doit être portée par le
plus haut niveau du management de l’Entreprise. Elle est généralement explicitée par un
document fondateur constitué d’une page portant le message du sponsor du projet et d’une
seconde page expliquant dans les grandes lignes ses missions.

DENE PALMEDE IBRAHIM/U-AUBEN

12
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

La définition de ses missions est la pierre angulaire qui permet d’assoir sa légitimité et
d’entamer l’amélioration continue en termes de qualité et d’efficacité. Une fois le socle des
missions défini, la monté en maturité permettant les transitions d’un modèle de SIEM SOC v1
vers un SOC v2. Ces gains de maturité sont soutenus par :
• L’accompagnement de spécialistes ;
• Le respect de normes ou de modèles IT.
Il convient de régulièrement revoir ces missions au regard de l’amélioration continue du SOC
tant au niveau de son efficience que de sa maturité, ainsi que de son adhérence avec le système
de gestion de la sécurité (ou SMSI). Cette revue doit obligatoirement tenir compte de la gestion
et de l’évolution des risques portés par l’Entreprise et doit intégrer la réduction de ces derniers
dans ses missions.

1.3.4. Classifications des SOC

La construction du SOC peut être lotie et suivre l’une des trois stratégies suivantes :
❖ 1ère possibilité : Faire appel à un SOC externe (MSSP) pour monter rapidement en
maturité ;
❖ 2ème possibilité : Opérer un SOC interne sur un petit périmètre critique métier.
❖ 3ème possibilité : Dans certains cas, les deux modèles peuvent être intégrés l’un à
l’autre pour produire un SOC hybride.

1.3.4.1. Le SOC dédié

Les SOC dédiés disposent de ressources humaines dédiées, organisées et en capacité de traiter
toutes les alarmes reçues par les outils de collecte. Installé dans les locaux de l'entreprise, il
fonctionne grâce à des équipes d'exploitation et des ressources IT internes. Le SOC dédié
consiste à placer un centre opérationnel de sécurité au sein de l'entreprise, géré par une équipe
dédiée avec des moyens techniques dédiés. Il fonctionne grâce aux ressources internes de
l'entreprise aussi bien en matière d'équipes IT et d'exploitation que de moyens techniques et de
locaux
1.3.4.2. Le SOC Externalisé ou Le MSSP
Le MSSP est un fournisseur tiers qui gère les opérations de sécurité quotidienne d’une
entreprise. Localisé chez un prestataire de sécurité informatique (MSSP : Managed Security
Service Provider), il est opéré grâce aux équipes informatiques de ce prestataire. Un MSSP
s’occupe de la sécurité plutôt qu’un Managed service Provider (MSP) standard qui s’occupe de
l’infrastructure, de la messagerie et des services cloud généraux.

DENE PALMEDE IBRAHIM/U-AUBEN

13
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

Le MSSP peut être le seul support informatique de l'entreprise, ou bien collaborer avec les
informaticiens de l'entreprise en matière de protection des données.
Les grandes entreprises font également appel à des MSSP pour le support du cloud. Comme de
plus en plus de personnes travaillent à domicile, les entreprises déplacent leur infrastructure
vers le cloud. Un MSSP sécurise l'environnement du cloud en mettant en œuvre des contrôles
de sécurité, la gestion des utilisateurs, les sauvegardes, les configurations et tout autre support
nécessaire à la migration vers le cloud.
1.3.4.3. Le SOC hybrides
Le partage entre les deux modèles est réalisé selon :
• Le périmètre de collecte : certains périmètre sensibles/confidentiels sont traités en
interne pendant que tous les autres périmètres sont laissés à la charge du MSSP. Dans
le cas de Groupes qui opèrent plusieurs entités quasi-autonomes sur un territoire
géographique important, certaines d’entre elles peuvent avoir fait le choix de faire appel
à un MSSP alors que d’autres continuent d’opérer le service SOC en interne.
• Le niveau de traitement : la qualification et le traitement des alarmes mineures peuvent
être déléguées à un MSSP tout en gardant les escalades de niveau 3 et l’investigation
sous la responsabilité d’une équipe interne.
Lors du choix d’un modèle de SOC, la pérennité du modèle pour l’Entreprise doit être étudiée
et largement commentée. En termes d’investissement, la mise en œuvre d’un SOC est un projet
d’envergure qui s’inscrit sur plusieurs années. Même si l’Entreprise choisi de faire appel à un
MSSP, elle se retrouve généralement engagée sur de longues périodes rendant ainsi compliquée
toute bascule vers un modèle internalisé. L’un des avantages essentiels de la création d’un SOC
interne est une visibilité et une réactivité maximale au niveau de l’ensemble du réseau. Une
équipe interne dédiée aura la capacité de surveiller l’environnement et ses applications,
fournissant ainsi une image complète au niveau du paysage des menaces.

DENE PALMEDE IBRAHIM/U-AUBEN

14
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

1.3.4.4. Tableau de comparaison

Tableau 2 : Tableau Comparative des différentes solutions de SOC

[Source : Personnel]

Avantages Inconvénients
Les SOC dédiés disposent de ressources humaines L’investissement financier initial est très important (pour
dédiées, organisées et en capacité de traiter toutes les mettre en œuvre l’outillage, recruter et former les ressources,
alarmes reçues par les outils de collecte conduire les études et exécuter la réalisation)
Les équipes du service connaissent mieux les De fait, la pression pour être en capacité de montrer le ROI
infrastructures et les applications supervisées et sont d’un tel service est également très importante.
donc à même de qualifier plus efficacement les alarmes
remontées.
Les solutions/outils dédiées sont plus flexibles et plus Le recrutement d’analyste SOC et d’expert en sécurité est un
SOC dédié facilement paramétrables. Les scénarios de menaces et véritable défi et peut prendre un certain temps.
les objectifs de sécurité sont considérés de façon
précise.
La communication (investigation) et l’escalade sont Le maintien en compétence et la gestion de carrière doivent
plus rapides (puisque utilisant les outils de être soigneusement considéré pour ne pas perdre rapidement
communication de l’Entreprise) toutes ses compétences internes.
Les journaux d’événements et tous les éléments de Les attaques large échelle, ciblant ou ayant ciblées, plusieurs
suivi des alarmes et incidents sont tous stockés en autres Entreprises ne seront sans doute pas perçues par un SOC
interne. focalisé sur la supervision d’un périmètre interne
L’investissement initial est plus raisonnable tant sur le Les opérateurs distants ne connaitront jamais aussi bien les
plan technique qu’humain infrastructures et applicatifs que des opérateurs agissant au sein
de l’Entreprise.

DENE PALMEDE IBRAHIM/U-AUBEN

15
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

Le service est généralement proposé à plusieurs acteurs L’externalisation d’un service de sécurité essentiel comme le
SOC externalisé du même domaine. Ceux-ci bénéficient de fait de SOC peut avoir un impact négatif sur le « moral » des
l’expertise des analystes pour le secteur d’activité personnels IT de l’Entreprise
concerné
La mutualisation des couts opérés par les acteurs Sans contrat spécifique, les ressources du MSSP peuvent être
MSSP leur permet de proposer des modèles de SOC mutualisées avec d’autres acteurs parfois concurrents
moins chers que les versions internalisées.
L’entente entre un acteur malveillant et un opérateur Les données internes de l’Entreprise sont envoyées à
du SOC est moins probable car ces derniers sont moins l’extérieur sans contrôle possible a priori. Une erreur de
exposés. manipulation est tout à fait probable.
Il n’y a pas de limite à la croissance forte et soutenue Toutes les données ne sont pas systématiquement archivées
du modèle (sous réserve de capacité du MSSP). (sauf cadre contractuel particulier)
Le MSSP met tout en œuvre pour se doter des La clause de réversibilité doit être étudiée avec soin pour
expertises les plus pointues sur les outils de collecte et permettre de changer d’acteurs/opérateur en cours ou en fin de
de traitement. contrat
Certains périmètre sensibles/confidentiels sont traités
en interne pendant que tous les autres périmètres sont
laissés à la charge du MSSP.
SOC Hybride Dans le cas de Groupes qui opèrent plusieurs entités La qualification et le traitement des alarmes mineures peuvent
quasi-autonomes sur un territoire géographique être déléguées à un MSSP tout en gardant les escalades de
important, certaines d’entre elles peuvent avoir fait le niveau 3 et l’investigation sous la responsabilité d’une équipe
choix de faire appel à un MSSP alors que d’autres interne.
continuent d’opérer le service SOC en interne.

DENE PALMEDE IBRAHIM/U-AUBEN

16
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

1.4. La gestion de la sécurité du réseau

De nos jours, les attaques deviennent de plus en plus sophistiquées. Les hackers sont de
sérieux adversaires, redoutables et implacables. Bien que le domaine de la sécurité informatique
ait beaucoup évolué ces dernières années, outrepasser un firewall ou un IDS (Intrusion
Detection System) est devenu une gymnastique pour les hackers expérimentés.
La méthode la plus efficace d’y parvenir est l’utilisation une solution de gestion de la
sécurité. Une solution de gestion de la sécurité est l’ensemble des outils et des moyens utilisés
pour superviser la sécurité du réseau, gérer les événements et incidents issus de la supervision.

Figure 4 : Cycle d’une attaque informatique

[Source [6]: R. Bejtlich, The Pratice of Network Security Monitoring, San Francisco: No Starch
press, 2013.

Également permettre de répondre aux principes de la traçabilité et de l’intégrité de la sécurité

informatique, autrement dit, permettre de garder intactes toutes traces d’activités normales ou
suspectes dans le réseau et les systèmes.
Le tout (supervision et gestion) est intégré dans le cycle de la sécurité au sein de l’entreprise
[6]. Les tâches normales des responsables de la sécurité sont les deux premières phases du Cycle
de Réponse d’un Incident de Bejtlich, c’est-à-dire Planifier et Résister [6]. Les deux autres
revenants à l’équipe CIRT.

DENE PALMEDE IBRAHIM/U-AUBEN

17
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

Figure 5 : Cycle de sécurité de l’entreprise

[Source [6]: R. Bejtlich, The Pratice of Network Security Monitoring, San Francisco: No Starch
press, 2013.

Ce principe met en avant les activités de surveillance des réseaux et des systèmes. Ces activités
permettront de détecter des signes d’une intrusion en cours de préparation ou en cours
d’évolution. Ainsi, les responsables de la sécurité, l’équipe CIRT où les administrateurs du
réseau pourront prendre des mesures adéquates afin d’arrêter la progression de l’attaque et de
défaire l’attaquant, en ajoutant ou en modifiant des règles au niveau des pare-feu.

1.4.1. La supervision de la sécurité réseau

La Supervision de la Sécurité du Réseau (SSR) ou Network Security Monitoring (NSM)

en anglais, est : « la collecte, l’analyse et l’escalade des signes et des alertes pour détecter et
répondre aux intrusions. » [6]. La supervision de la sécurité du réseau peut être vue comme une
méthodologie, et non pas une simple action. Une fois correctement mis en place, elle permet
aux responsables de la sécurité, notamment l’équipe CIRT, de détecter et de mettre fin à une
attaque avant qu’elle ne cause de dégât
La SSR trouve mieux sa place dans une solution de gestion de la sécurité du réseau. En
effet la SSR est requis pour fournir une solution de gestion de la sécurité du réseau et des
systèmes, ce qui permet d’avoir un contrôle plus global sur le réseau et des analyses plus
précises [10].

DENE PALMEDE IBRAHIM/U-AUBEN

18
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

1.4.2. Architecture d’une plateforme de Supervision de la Sécurité Réseau

Une plateforme de supervision de la sécurité réseau est constituée des éléments suivants :
outils de collecte de données, outils de distributions de données et d’outils de présentation de
données. Ces outils sont organisés en suivant une architecture en couches.
• La couche outils de collecte de données, est l’ensemble des outils qui permettent de
directement collecter les données à partir du réseau ou à travers les logs. Ces données
sont ensuite envoyées aux outils de présentation ou d’analyse de données via la couche
de distribution. Parmi ces outils, on trouve : les systèmes de détection d’intrusion, les
analyseurs ; ici la source de données se réfère à un équipement réseau ou le log d’une
application.
• La couche outils de distribution de données, c’est la couche intermédiaire. Elle met en
relation la couche de collecte et la couche de présentation des données. Autrement dit,
elle est constituée d’outils qui permettent à la couche présentation de mieux exploiter
les données collectées par la couche de collecte de données.
• La couche outils de présentation de données permet d’exposer les données collectées
aux analystes et aux experts du CIRT à des fins d’analyse et de prise de décision. Au
niveau de cette couche, on trouve plusieurs catégories d’outils, certains avec des
interfaces graphiques et d’autres en ligne de commande. Les outils que la couche
comprend sont entre autres : moteur de corrélation, gestion des alertes, investigation et
escalade d’événements, etc.

Figure 6 : Couches d’une plateforme de SSR

Source: Cymbel, “The Big Picture of the Security Incident Cycle, » 10 Octobre 2010.

DENE PALMEDE IBRAHIM/U-AUBEN

19
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

1.4.3. Les types de données collectées

Un superviseur de la sécurité réseau collecte plusieurs types de données à différents
niveaux et différents endroits. Selon [11], [6] et [3] les principaux types de données collectés
par un superviseur de la sécurité réseau sont suivants : données à contenues intégrales, données
statistiques, données de sessions, données d’alertes et les logs.
• Les données à contenues intégrales : C’est lorsque l’intégralité du trafic est capturée
et stockée à des fins d’analyse. Celles-ci (données capturées) comprennent les en-têtes
(headers) et les contenus (payloads).
• Les données statistiques : « Une donnée statistique est l’organisation, l’analyse,
l’interprétation et la présentation d’autres types de données » [3]. Autrement dit, ces
données permettent à un analyste de voir d’autres informations liées à une activité sur
le réseau. Parmi les informations qui peuvent en sortir, on peut citer : nombre de paquets
transmis et reçus, nombre de paquets par seconde, nombre de datagrammes UDP,
pourcentage de segment TCP, statistiques relatives à un protocole, etc.
• Les données de sessions : Les données de sessions présentent un résumé des
communications passées entre deux interlocuteurs, en occurrence deux machines. De
petite taille, elles sont très faciles à exploiter et leur stockage long duré ne pose pas de
problème. Les consoles de corrélation analysent en temps réel et en continue les données
provenant de la couche distribution (cf. section précédente) et déclenchent une alerte
dès qu’une donnée présente une anomalie par rapport aux règles, signatures ou toutes
autres bases d’information.
• Les données de log : Ces données sont généralement des données brutes en provenance
des équipements, des systèmes ou des applications. Ceux-ci peuvent être des données
de journaux d’événements Windows, SYSLOG, données spécifiques à une application
(ex. MySQL, apache, etc…), un pare-feu, un routeur, log d’authentification (RADIUS,
VPN, etc..), etc.

1.5. La Gestion de Logs

Un log est un registre dans lequel est enregistré tout événement provenant du réseau ou
des systèmes dans une entreprise. La gestion des logs est également partie intégrante d’une
solution de gestion de la sécurité. La gestion des logs peut être définie comme toute activité liée
à la collecte, la centralisation, l’analyse et l’archivage des logs générés par les différentes entités
du réseau et des systèmes. Ces entités peuvent être : pare-feu, routeurs, switch, serveurs
(applications et systèmes), ordinateurs PC, etc

DENE PALMEDE IBRAHIM/U-AUBEN

20
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

La gestion de log permet aux administrateurs de la sécurité des entreprises d’assurer le

stockage des informations détaillées sur les événements des réseaux et des systèmes,
notamment les événements de sécurité informatique.

1.5.1. Architecture d’un système de gestion de log

Le guide de gestion de log de la sécurité informatique du NIST [13] décrit un système de gestion
de log comme étant l’ensemble du matériel, du réseau, des logiciels et supports utilisés pour
générer, transmettre, stocker, analyser et de disposer des données de log. Selon le même guide,
un système de gestion de logs est constitué de trois (3) grandes parties qui sont :
• La partie génération de logs est constituée des équipements et des hôtes
responsables de la génération des données de log.
• Les logs sont souvent transférés aux nœuds de traitement en temps réel. La partie
analyse de log et stockage est composée des serveurs et des nœuds de traitements
des logs. Selon [12] les éléments de cette partie sont appelés collecteurs et
agrégateurs.
• Le monitoring de logs, la troisième partie, contient les outils qui seront utilisés
pour superviser, pour revoir les données de logs et les résultats des différentes
analyses. Le monitoring de logs comprend un tableau de bord, des outils de
génération de rapports, des outils de recherche dans les logs et surtout des outils
de corrélation de logs.

1.5.2. Fonctions d’un système de gestion de logs

Les fonctions attendues d’un système de gestion de logs sont entre autres la collecte, l’analyse,
le stockage et l’évacuation (supprimer). Ces fonctions doivent être réalisées sans altérer ou
modifier de quel que ce soit les données des logs. Selon [13] elles (fonctions) se divisent en
quatre grands groupes. Ce sont les suivants :
• Général ;
• Stockage ;
• Analyse ;
• Disposition.
Les fonctions générales incluent la conversion de logs, le filtrage des événements, et
l’agrégation des événements. La conversion de logs ou log parsing en anglais est le fait
d’uniformiser tous les logs en un format unique et facilement compréhensible par les humains.

DENE PALMEDE IBRAHIM/U-AUBEN

21
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

Le filtrage des événements est la suppression des entrées de logs jugées inutiles parce qu’elles
contiennent des informations qui ne nous intéressent pas.
Les informations ainsi éliminées ne sont pas utiles pour l’analyse. L’agrégation
d’événements consiste à faire une consolidation d’un nombre d’entrées de logs similaires. Par
exemple, dix (10) lignes concernant l’authentification échouée d’un compte utilisateur peuvent
être résumées en une seule ligne « Tentative multiple d’authentification échouée pour le compte
utilisateur admin sur le serveur mail. » Les fonctions stockage regroupent les fonctions telles
que la rotation de logs, la compression et l’archivage de logs, la normalisation de logs et la
vérification de l’intégrité des logs.
Syslog Syslog Routeur SyslogPare-feu Syslog RSyslog Serveur Central Syslog-NG Tableau de
bord Analyse, Correlation et alerte Archivage et stockage sécurisé log log loglog

Figure 7 : Architecture d'un système de gestion de logs

[Source : Tidiane SYLLA, Etude et mise en place d’une Solution de Gestion de la Sécurité du Réseau :
CAS D’AFRIBONE MALI, Mali, Master 2, Mémoire de fin de Cycle, Université de Carthage
Département Informatique, 2017]

1.6. L’équipe CIRT

Une CIRT (Computer Incident Response Team) encore appelée CERT (Computer
Emergency Response Team) est une équipe ou département au sein d’une entreprise, chargé
des questions relatives aux problèmes de sécurité de l’information, du réseau et des systèmes.
D’après [14] : « Une CERT est une organisation ou un département au sein d’une organisation
chargé d’étudier la sécurité de l’Internet, découvrir les vulnérabilités et fournir l’assistance
sécuritaire relative à une communauté identifiée. ». Ainsi, une CIRT surveille activement les

DENE PALMEDE IBRAHIM/U-AUBEN

22
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

activités du réseau et des systèmes, à la recherche d’éventuels intrusions ou signes d’intrusion.

Pour ce faire, une CIRT doit être dotée d’outils lui permettant de collecter, d’analyser et de
générer des alertes dès qu’il y’a une anomalie. Au sein d’une CIRT, on trouve : le responsable
en chef, l’assistant au responsable en chef, des analystes, et des superviseurs.

1.7. Les solutions de supervisions de la sécurité réseau

Une solution de supervision de la sécurité réseau rentre dans la catégorie des SIEM
(Security Information and Event Management). En effet, un SIEM encore appelé SIM (Security
Information Management) est un outil qui permet d’avoir une vue unique sur tous les
événements liés à la sécurité du réseau et des systèmes. Il comprend l’analyse et la corrélation
de logs, de gestion des incidents et le reporting basé sur l’analyse d’événements. Un SIEM
analyse d’autres données en plus des logs, mais la source de données primaire est le log [12].
Un SIEM agrège les données provenant des périphériques de sécurité, de réseau, des systèmes
et des applications. Les données ainsi agrégées sont normalisées. Alors, un événement
apparaissant plusieurs fois dans plusieurs sources différentes peut être corrélé. En plus des
points cités plus haut, un SIEM fournit la capacité d’investigation (Forensic) à l’équipe CIRT.
Cette dernière pourra entreprendre des mesures, escaladée l’incident ou simplement de le
documenter.
Quelques avantages d’un SIEM :
• Gestion de logs centralisée ;
• Corrélation de logs et mise en relation « cause à effet » ;
• Agrégation des événements de sécurité en une liste que l’on peut facilement
gérer : classifié, catégorisé, etc.
• Permet de prévenir des dommages sur les ressources informatiques de
l’entreprise ;
• Permet d’avoir un tableau de bord pour la gestion de la sécurité, l’assurance
de conformité avec les politiques de sécurité, etc. ;
Il est important de savoir qu’il existe deux formes de supervision de la sécurité. La
supervision de la sécurité de réseau proactive et la supervision de la sécurité de réseau réactive.
La supervision de la sécurité réseau proactive consiste à rechercher des vulnérabilités, des
failles, des certificats invalides ou expirés, etc. La supervision de la sécurité réseau réactive est
la forme la plus utilisée. Elle consiste à la recherche d’incidents, à apporter une réponse aux
incidents et à l’investigation de réseau.

DENE PALMEDE IBRAHIM/U-AUBEN

23
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

1.7.1. Security Onion

Security Onion est une distribution Linux pour la détection d’intrusion, la supervision de la
sécurité réseau et la gestion de logs [15]. Elle a été créée par Doug Burks. Sa dernière version
est basée sur Ubuntu 16.04. Elle contient Snort, Suricata, Bro, OSSEC, Sguil, Squert, ELSA
(Enterprise Log Search and Archive), Xplico, NetworkMiner et plusieurs autres outils de
sécurité [15]. Elle est totalement Open Source et est régulièrement maintenue à jour par Doug
Burks et d’autres contributeurs. Security Onion est une grande distribution qui facilite la mise
en relation et l’intégration de plusieurs d’éléments. Ce qui fait d’elle, l’un des outils NSM les
plus rapides à déployer à appréhender.

1.7.1.1. Snort
Snort est un système de détection et de prévention d’intrusion réseau (NIDS/NIPS) open
source [16]. Il a été développé par Sourcefire, racheté par Cisco. Aujourd’hui, il est maintenu
par Cisco [16]. C’est le NIDS/NIPS le plus déployé à nos jours [17]. Snort utilise la signature
des règles, des protocoles et des anomalies comme techniques de détection d’intrusion. Il
analyse le trafic en temps réel. En plus d’être un NIDS, il supporte d’autres modes de
fonctionnement [18]. Ce sont le mode Sniffer, le mode Packet Logger. Snort analyse en continu
le trafic du réseau et génère des alertes d’intrusion à la moindre anomalie. Avec Security Onion,
Snort est utilisé avec PF_RING pour avoir plus de capacité d’analyse [19]. Les règles sont
régulièrement téléchargées à partir des bases de signatures de Snort. Il est également possible
d’écrire ses propres règles.
1.7.1.2. Suricata
A l’instar de Snort, Suricata est un également un système de détection et de prévention
d’intrusion réseau basé sur les règles. Il est open source. Il est développé et maintenu depuis
2008 par Open Information Security Foundation (OISF), une organisation à but non lucratif
[20]. Sa licence est distribuée sous GNU GPL. Comme Snort, il peut fonctionner en d’autres
modes (sniff et capture de paquets). Il télécharge les règles à partir des bases de signatures, mais
il est également possible d’écrire ses propres règles pour la détection des menaces les plus
complexes.
1.7.1.3. Bro
Bro IDS est un système de détection d’intrusion réseau à base d’analyse. C’est une
plateforme d’analyse réseau puissante développée et maintenue par International Computer
Science Institute à l’Université de Berkeley, en Californie [21]. La plateforme Bro est supportée
(financièrement) par la National Science Foundation. Contrairement aux NIDS à base de règle,

DENE PALMEDE IBRAHIM/U-AUBEN

24
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

Bro effectue une analyse complète du trafic réseau, classifie le trafic, et génère les alertes en
cas d’anomalie. Bro surveille le trafic, journalise toutes les connexions, tous les certificats SSL,
toutes les requêtes DNS, http, ftp, ssh, etc., mais également les activités Syslog qu’il voit [15].
Ainsi, Bro arrive à détecter le trafic contenant un cheval de Troie, un fichier exécutable
malicieux, etc., en temps réel. Il effectue également une corrélation temps réel des activités du
réseau en utilisant les bases de renseignements sur les menaces [15]. Cela lui permet d’alerter
l’utilisateur sur l’utilisation d’adresse IP malicieuses ou douteuses et des domaines douteux.

1.7.1.4. OSSEC
OSSEC (Open Source Security) est un HIDS (Host Intrusion Detection System) créé
par Daniel Cid. OSSEC possède un puissant moteur de corrélation et d’analyse, qui intègre la
vérification de l’intégrité des fichiers, la vérification du registre Windows, une politique de
sécurité centralisée [22]. Il permet également la détection de Rootkit, l’alerte temps réel et un
système de réponse active [23]. OSSEC est classé dans la catégorie des LIDS (Log-based
Intrusion Detection System) [24]. OSSEC supporte plusieurs modes de fonctionnement : local,
serveur, agent et hybride. En mode serveur, les agents OSSEC remontent de manière sûre les
résultats d’analyses vers le serveur, qui effectuera la corrélation. Ils vérifient l’intégrité des
fichiers système en plus des fichiers spécifiés par l’utilisateur. Ils monitorent les logs de
plusieurs applications, en comparant leurs contenus à des règles (prédéfinies ou personnalisées)
et en faisant une corrélation par rapport à d’autres événements. A la moindre anomalie, OSSEC
génère alors une alerte (SMS, email). Chaque alerte possède un niveau. Les niveaux varient de
0 à 15. Une alerte de niveau 0 est ignorée, tandis qu’une alerte de niveau 14 nécessite un
traitement, car elle indique une compromission. OSSEC convertit les logs suivant des
décodeurs et fait l’analyse et la corrélation des événements en utilisant des règles. La plupart
des règles sont préinstallées à l’installation d’OSSEC. Ces règles sont très souvent basées sur
les indicateurs de compromissions [25] (IOC : Indicators of Compromise) et sur les bases de
renseignements des menaces et des vulnérabilités actualisées.

1.7.1.5. Sguil
Sguil est une application de type desktop spécialement conçu pour la réception et
l’affichage des alertes. Pour cela, elle est connectée à une base de données centrale hébergée
sur MySQL. Elle a été créée par Bamm Vischer. Elle est maintenue comme open source, et sa
dernière version à l’édition de ce document est 0.9.0.

DENE PALMEDE IBRAHIM/U-AUBEN

25
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

1.7.1.6. Squert
Squert est l’équivalent web de Sguil. Autrement dit, Squert permet de visualiser et
d’effectuer des recherches sur les alertes enregistrées dans la base de données de Sguil.
L’interface de Squert permet d’effectuer la chasse aux événements, en plus, elle permet
d’effectuer des actions supplémentaires, comme vérifier la signature d’une alerte par rapport à
la base à jour de menaces.

1.7.1.7. ELSA
On ne peut pas présenter un SSR sans parler de gestionnaire de log. Enterprise Log
Search and Archive (ELSA) est une plateforme de gestion de log centralisée à base de syslog.
Elle est basée sur Syslog-NG, MySQL et Sphinx. Elle supporte des recherches de type full text
sur un grand nombre de données. Son intégration avec Security Onion permet aux analystes de
recherche dans les logs les événements liés par exemple aux alertes générées par les IDS ou les
analyseurs réseaux, etc.

1.7.1.8. ELK
ELK (Elasticsearch Logstash Kibana) est une plateforme de gestion centralisée de log
qui intègre plusieurs technologies ensemble dans le but de faciliter encore plus la recherche de
log, la classification et bien d’autres choses. Son intégration dans Security Onion est en cours
de test et devra à terme remplacer ELSA. C’est également une plateforme disponible en mode
haute disponibilité et en mode distribué pour permettre une gestion ultra performante de très
grandes quantités de logs.
1.7.2. OSSIM (Open Source Security Information Management)
OSSIM est un outil de supervision de la sécurité réseau également très populaire. C’est
une solution pleinement fonctionnelle. Il a été créé en 2003 par AlienVault. Il est Open Source
et continue à être maintenu par AlienVault. AlienVault développe une version payante de ce
superviseur, c’est AlienVault USM (Unified Security Management) et elle coûte très chère.
OSSIM est basé sur la distribution Debian (une distribution Linux). Elle comporte beaucoup
d’outils : OSSEC, OpenVAS, OCS Inventory, Evaluation de risque (Risk Assesment), Nagios
Availability Monitor, Nmap, etc.

1.7.2.1. OSSEC
Nous avons décrit OSSEC dans une section précédente. Comme Security Onion,
OSSIM déploie OSSEC comme HIDS à cause de ses qualités et son architecture agent/serveur.

DENE PALMEDE IBRAHIM/U-AUBEN

26
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

1.7.2.2. Snort, Suricata

Les NDIS Snort et Suricata ont été décrits dans des sections précédentes. Ils sont présents dans
OSSIM à l’instar de Security Onion.

1.7.2.3. OpenVAS
OpenVAS (Open Vulnerability Assesment System) est une plateforme qui intègre
plusieurs outils et services qui permettent d’avoir un puissant scanneur de vulnérabilité [26].
En effet, OpenVAS permet d’analyser la vulnérabilité d’un quelconque système en effectuant
toute une batterie de test. La plateforme OpenVAS est la version open source (libre) de
Greenbone Networks (payante). OSSIM intègre OpenVAS dans le but de fournir une
plateforme d’évaluation de la vulnérabilité couplée à un SIEM.

1.7.2.4. Risk Assesment :

La fonctionnalité Risk Assesment ou évaluation du risque en français, permet d’évaluer
le risque lié à un événement. Cette évaluation se base sur la priorité affecter à l’hôte concerné,
la menace détectée et la probabilité d’occurrence de l’événement [27].

1.7.2.5. OCS Inventory

OCS Inventory (Open Computer and Software) est une plateforme qui permet de
réaliser l’inventaire du parc informatique (matériel et logiciel) de manière automatique [28].
Elle est très puissante et elle utilise une faible bande passante. Elle existe en deux versions, une
version open source et une version payante. Sa dernière version est OCS Inventory NG 2.3.1.
Elle supporte toutes les plateformes informatiques connues : Windows, MAC OS, Linux,
Android, IOS. OSSIM intègre OCS Inventory pour lui permettre de découvrir automatiquement
toutes les machines et services activés sur le réseau. Ainsi, dès l’installation d’OSSIM, vous
avez la possibilité de découvrir tous les ordinateurs et composants informatiques disponibles
sur votre réseau, ce qui est très avantageux quand on est en face d’un réseau de plus de 1000
ordinateurs par exemple.
1.7.2.6. Nagios
Nagios est l’outil de supervision de réseau à ne plus décrire, tant qu’il a fait ses preuves.
C’est un outil de supervision de réseau open source. Sa première version date de 1996 [29]. Il
est intégré à OSSIM afin de permettre de gérer la disponibilité de machines configurées sur
celle- ci (plateforme OSSIM).
1.7.3. ArcSight
ArcSight est une solution entreprise payante développée par Hewlett-Packard (HP),
dans le but de fournir une solution de gestion de sécurité aux entreprises. Elle possède toutes

DENE PALMEDE IBRAHIM/U-AUBEN

27
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

les fonctionnalités d’un SSR. Sa licence coûte très chère. ArcSight est disponible en plusieurs
versions, toutes payantes. ArcSight Enterprise Security Manager (ESM) a été conçu pour des
sociétés de grandes étendues (plusieurs milliers d’actifs à gérer) [30], tandis qu’ArcSight
Express a été conçu pour les PME.

1.7.4. Splunk
Splunk à l’instar des autres SIEM et SSR monitore et gère les logs [30]. Splunk existe
en deux versions. Une version gratuite limitée à 500 Mo de données à traiter et version payante
au-delà des 500 Mo. Le prix devient rapidement exorbitant en fonction de la quantité de données
à traiter. Splunk propose plusieurs produits selon le budget des entreprises. Parmi ceux-ci, on
trouve Splunk Enterprise, Splunk Cloud, etc.

1.7.5. Graylog2
Graylog2 est une solution open source de gestion log développée en java et basée sur
Elastic-Search. Grâce à son système de plugin, on peut y ajouter beaucoup de plugins. Cela
permet de l’exécuter comme un NSM, mais aussi en un SIEM.

1.8. Choix de la solution

Comme nous l’avons évoqué dans notre méthodologie, nous travaillerons dans ce projet avec
des outils open source. Cela s’intègre également dans la vision de l’entreprise qui est de réaliser
un SOC dédié et robuste. De ce fait, nous avons étudié et testé trois solutions open source, à
savoir : Security Onion, OSSIM et Graylog2. Les résultats des tests effectués sont répertoriés
dans le tableau ci-dessous.

DENE PALMEDE IBRAHIM/U-AUBEN

28
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

Tableau 3 : Tableau comparatif des différentes solutions testées

[Source : Personnel]
Rubrique Elastic Stack Alien Vault OSSIM Splunk Security Onion
Open Source ✓ x ✓ ✓
NSM x x ✓
SIEM ✓ ✓ ✓ ✓
Gestion et intégrité des Logs ✓ x ✓ ✓
Intégration avec l’existant ✓ ✓ ✓ ✓
Documentation ✓ ✓ ✓ ✓
Mise à jours régulière ✓ ✓ ✓ ✓
Configuration matérielle ✓ x ✓ ✓
NIDS snort/Suricata ✓ ✓ x ✓
HIDS OSSEC ✓ ✓ ✓ ✓
Tableau de Bord ✓ ✓ ✓ ✓
Network Miner ✓ x ✓
CapMe x x ✓
Wireshark ✓ ✓ x ✓
OpenVas ✓ ✓ x ✓
Nagios ✓ ✓ ✓
Support de Elasticsearch Logstash Kibana ✓ x ✓

Légende : ✓ : Caractéristique disponible à part entière

x : Caractéristique disponible en partie

DENE PALMEDE IBRAHIM/U-AUBEN

29
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

1.8.1. Critères de choix des solutions SIEM

• Le choix de l'outil SIEM s'articule autour de trois critères principaux : le budget,
l'effectif requis et la pertinence face aux menaces.
• Le budget est un paramètre important car toute entreprise a besoin d'avoir des
perspectives claires en matière d'outils de gestion de la sécurité informatique. L'idéal est
d'accéder à un outil dont la licence est simple, offrant un compromis entre l'efficacité et
le coût.
• Il sera également important d'évaluer le nombre de personnes nécessaires à exploitation
de l'outil choisi.
• Cette réponse aux menaces constitue d'ailleurs le troisième critère de choix d'un SIEM.
Par ailleurs, un SIEM efficace doit posséder un module de tableau de bord et de rapports
complets afin de pouvoir communiquer facilement auprès de la direction et des auditeurs.

1.8.2. Choix de la solution et justification

Les résultats nous démontrent la richesse de Security Onion par rapport aux autres solutions.
En plus d’être un NSM puissant, il est totalement open source et présentent plusieurs outils pour
l’investigation et les enquêtes poussées dont une équipe CIRT a besoin. Cela répond
parfaitement au besoin et à la politique de SUNU Assurances IARD Burkina Faso. Security
Onion est très bien documenté. Il possède une grande communauté d’utilisateurs et un support
même étant gratuit. Il nous permet aussi, si l’on veut utiliser un autre gestionnaire de log
qu’ELSA, par exemple ELK, de le désactiver. Security Onion comprend un groupe de produits
qui est d’autant plus utilisé par une multitude de grandes entreprises comme LinkedIn, Netflix,
Uber et StackOverflow.
Avec le responsable du service informatique de SUNU Assurance IARD, nous avons choisi
Security Onion.

Conclusion
Dans ce chapitre, nous avons effectué une étude détaillée des solutions de gestion de sécurité.
Nous avons également choisi les composants de la solution à déployer. Le prochain chapitre
sera consacré au choix de la solution, à son déploiement et aux différentes configurations.

DENE PALMEDE IBRAHIM/U-AUBEN

30
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

CHAPITRE II : DEPLOIEMENT DE SECURITY ONION,

MISE EN PLACE DE L’EQUIPE CIRT ET TESTS
4.1. Introduction
Cette partie sera consacrée à l’architecture et au déploiement de la solution que nous avons
choisie, c’est-à-dire Security Onion. Security Onion permettra de répondre aux questions que
nous nous sommes posées au début de ce travail.
4.2. Architecture de Security Onion et déploiement
4.2.1. Architecture de Security Onion

Figure 8 : Architecture de Security Onion

Source : L. Wes et D. Burks, « Architecture – Security Onion Solution, » 29 Septembre 2017.

DENE PALMEDE IBRAHIM/U-AUBEN

31
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

Nous avons décrit les principaux composants de Security Onion dans le chapitre précédent.
L’interaction entre ces différents composants est présentée dans la figure 8. Les composants
sont repartis en collecteur, distributeurs et en consoles de visualisation. Ces différentes couches
ont été décrites dans la section 3.5.1 du chapitre 3. Nous remarquons également que les
composants sont regroupés à deux niveaux distincts : Sensor (sonde) et Master server (serveur).
Security Onion est une solution fondée sur le modèle distribuée client/serveur. Une sonde
Security Onion est une machine sur laquelle sont installés plusieurs outils pour la collecte et
l’analyse du trafic, c’est la machine cliente. Parmi ces outils, nous avons principalement : NIDS
(Snort ou Surricata), l’analyseur de réseau Bro et OSSEC. Ces éléments ont été décrits dans le
chapitre précédent. Les sondes remonteront leurs informations vers le serveur de Security
Onion. Un serveur Security Onion est une machine sur laquelle sont installées les consoles
d’administration et de supervision de la sécurité du réseau. C’est à partir du serveur que l’équipe
CIRT pourra mener les différentes opérations voir et gérer les incidents.

4.2.2. Architecture du réseau cible

La figure 9 présente une vue synoptique de l’architecture du réseau dans lequel nous allons
installer Security Onion. Pour des raisons de confidentialité, certains détails ont été
volontairement masqués, afin de ne pas divulguer des informations qui pourront compromettre
la sécurité de l’entreprise.

DENE PALMEDE IBRAHIM/U-AUBEN

32
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

Figure 9 : Vue synoptique du réseau de SUNU Assurances IARD

Source : SUNU Assurances IARD

4.2.3. Modes de déploiement de Security Onion

Security Onion dispose de trois (3) modes de déploiement. Il s’agit du mode standalone ou
intégré, du mode distribué et du mode hybride [15].

4.2.3.1. Mode serveur/sonde intégré (Standalone)

Dans ce mode de déploiement, une seule machine physique ou virtuelle est utilisée pour
l’exécution du serveur et des composants de la sonde. Ladite machine peut avoir plusieurs
interfaces, pour superviser plusieurs LAN. Ce mode de déploiement est utilisé pour les réseaux
de petite taille.

4.2.3.2. Mode distribué

Ce mode déploiement consiste à utiliser une seule machine comme serveur, et plusieurs autres
comme sondes. Il est recommandé en milieu fortement distribué, au niveau des réseaux de
grande taille. Les analystes se connectent sur les consoles présentent sur le serveur.

4.2.3.3. Mode hybride

Le mode hybride permet d’avoir une machine standalone et des sondes remontant des
informations vers le composant serveur de la machine standalone.

DENE PALMEDE IBRAHIM/U-AUBEN

33
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

4.2.3.4. Mode de déploiement choisit

Dans ce projet, nous avons choisi le mode distribué. En effet, le réseau de SUNU Assurances
IARD a une taille conséquente, et supporte un grand trafic.

4.2.4. Emplacements des sondes et du serveur

À partir de l’architecture du réseau (figure 9), nous remarquons qu’il faut plusieurs sondes pour
avoir une vue globale sur tout le trafic qui entre et sort du réseau. Partant de là, il faut alors
choisir les emplacements des différentes sondes. Le choix des emplacements des différentes
sondes est crucial pour la réussite du déploiement. En effet, l’analyse continue du trafic réseau,
représente l’un des nerfs de la solution à mettre en place. Les NIDS, analyseurs de réseau et de
comportement, fonctionnent en capturant et en analysant le trafic en temps réel. La question qui
se pose à ce moment est la suivante : comment capturer le trafic en continue sans influer sur
celui-ci ?
La réponse est la suivante : Il existe deux principaux moyens pour accomplir cette tâche, c’est
à dire, la recopie des ports au niveau des switches et l’utilisation d’enregistreur de trafic réseau
Network TAP.

Figure 10 : Les emplacements possibles pour les sondes

Source : SUNU Assurances IARD et Personnel

DENE PALMEDE IBRAHIM/U-AUBEN

34
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

La recopie des ports a plusieurs noms dans le jargon, selon les fabricants. Pour certains, c’est
le port spanning (Cisco) pour d’autres c’est le port mirroring (dell). Cela consiste à recopier
tout le trafic des ports indiqués vers un port spécifique du switch. C’est une fonction qui est
disponible seulement sur les switches de classes entreprises. Un enregistreur de trafic réseau
plus connu sous Network Tap est un équipement spécialement conçu pour recopier tout le trafic
qu’il reçoit vers un port. Il est généralement placé sur le lien agrégé (entre switch et routeur ou
pare-feu). Son emplacement ne cause pas de problème en cas de panne, le trafic continuera à
fluer, seul l’enregistrement sera arrêté. Dans notre projet, nous avons choisi d’utiliser le TAP.
Sur la figure 11, nous avons les emplacements suivants à partir des quels on peut positionner
les différentes sondes.
L’emplacement A situé entre le routeur de bord et le pare-feu nous permet de voir l’intégralité
du trafic provenant du réseau local et des DMZ, mais le NAT (Network Address Translation)
masque les adresses provenant des réseaux situés derrière le pare-feu. Donc, l’emplacement A
ne sera pas utilisé. Les emplacements B, C et D sont parfaits pour nos sondes, car on peut voir
passer tous les trafics provenant des différents sous réseaux. L’emplacement E nous permettra
de voir le trafic à destination des clients, là aussi c’est un emplacement parfait pour voir le trafic
des clients.
Pour des raisons juridiques, nous n’avons pas été autorisés à placer de sonde à ce niveau. Pour
finir, la configuration matérielle des sondes a également jouée sur l’emplacement des
différentes sondes. Une sonde doit avoir une configuration matérielle proportionnelle au trafic
supervisé. Le serveur sera mis dans le LAN afin de le protéger contre les agressions venant de
l’extérieur du réseau.

Figure 11 : Vue synoptique du réseau avec les sondes, les TAP et le serveur Security Onion
Source : SUNU Assurances IARD et Personnel

DENE PALMEDE IBRAHIM/U-AUBEN

35
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

4.3. Installation du serveur et des sondes

4.3.1. Configuration matérielle
Les caractéristiques typiques des machines qui seront utilisées pour bien mener à terme les
tâches de NSM sont les suivantes [32] :
• Processeur : 4 cœurs de processeur par interface de monitoring.
• Mémoire RAM : Au minimum 16Go, avec 1 Go supplémentaire pour chaque interface
monitorée connecté à un port SPAN ou un TAP pour par exemple un trafic de 200 Mb/s.
Si le volume de trafic est très important, alors il faut augmenter en mémoire RAM,
jusqu’à 256 Go ou plus, et cela en fonction de la taille de l’organisation.
• Disque dur : Grande capacité de stockage, avec comme système de stockage le RAID.
Il faut noter que les données de supervision et les trafics associés sont sauvegardés sur
le disque.
• Carte réseau : au moins deux cartes réseaux par sonde.

4.3.2. Installation du serveur

La procédure d’installation de la distribution Security Onion est la même selon que la machine
est en mode standalone, serveur ou sonde. Une fois cette installation terminée, il faut configurer
la distribution. Cela se fait en cliquant sur le bouton Setup, à partir du bureau. Une fois le Setup
lancé, un menu se présente à nous pour la configuration des cartes réseaux, c’est- à-dire la carte
de gestion Management et la carte Sniffing. On fixe alors l’adresse IP de la carte Management,
la carte Sniffing sera sans adresse IP (figure 12). Nous avons alors suivi toutes les étapes, en
fournissant les informations comme l’adresse IP, le masque de sous réseau, la passerelle par
défaut et les serveurs DNS.

Figure 12 : Choix de l’interface réseau Management

[Source : personnelle]

Une fois ces étapes effectuées, nous obtenons cela (figure 13).

DENE PALMEDE IBRAHIM/U-AUBEN

36
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

Figure 13 : Résumé de la configuration réseau

[Source : personnelle]

Après avoir validé cette configuration, la machine redémarre et nous lançons Setup encore une
fois pour la configuration (figure 14).

Figure 14 : Lancement de la configuration de Security Onion

[Source : personnelle]

Lorsque nous avons cliqué sur « Yes, Continue ! », le choix du cas d’utilisation se présente
dans la fenêtre qui s’affiche. Nous choisissons Production Mode (figure 15). Après avoir validé
le choix sur Production Mode, la fenêtre suivante nous affiche le choix du mode du
déploiement, c’est-à-dire Standalone, Serveur ou Sonde. Nous sommes en train d’installer le
serveur, nous choisissons alors Serveur (figure 16).

DENE PALMEDE IBRAHIM/U-AUBEN

37
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

Figure 15 : Choix du cas d’utilisation

[Source : personnelle]

Figure 16 : Choix du mode de déploiement

[Source : personnelle]

Une fois le choix du mode de déploiement effectué, Security Onion nous demande de choisir
le mode configuration (figure 17). Nous avons le choix entre « Best pratices » et Custom. Nous
choisissons « Custom » afin de complètement personnaliser notre installation.

Figure 17 : Choix du mode de configuration

[Source : personnelle]

DENE PALMEDE IBRAHIM/U-AUBEN

38
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

Puisque nous sommes en train d’installer le serveur, nous devons configurer Sguil, Squert et
ELSA. Pour cela, Security Onion nous demande de fournir un nom d’utilisateur et un mot de
passe qui permet d’accéder à ses éléments (figure 18).

Figure 18 : Nom d’utilisateur/mot de passe pour Sguil, Squert et ELSA

[Source : personnelle]

Après le nom d’utilisateur/mot de passe, vient la configuration de la durée de sauvegarde des

données d’alertes d’IDS, des événements et des données de session (figure 19).

Figure 19 : Durée de garde des données

[Source : personnelle]

La fenêtre suivante nous propose deux NIDS parmi lesquels il faut choisir. Les NIDS proposés
sont ceux de la distribution de Security Onion, c’est-à-dire Snort et Surricata. Nous avons choisi
d’utiliser Snort (figure 20). Snort est le NIDS open source le plus utilisé, de plus il est très bien
documenté.

Figure 20 : Choix du NIDS

[Source : personnelle]

DENE PALMEDE IBRAHIM/U-AUBEN

39
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

Une fois le NIDS choisit, nous devons choisir la base de signature de ce dernier. Nous avons
choisi la dernière option « Snort Subscriber (Talos) ruleset only and set a Snort Subscriber
policy ». En effet, cette option permet à Snort d’aller chercher les signatures (ruleset) tous les
jours au niveau des bases Snort couvrant la majeure partie des nouvelles menaces, et il nécessite
d’avoir un Oinkcode. Un Oinkcode est un code unique associé à un compte utilisateur Snort
(figure 21).

Figure 21 : Choix de la base de signature du NIDS Snort

[Source : personnelle]

Il faut à présent saisir l’Oinkcode que nous avons obtenu après notre enregistrement auprès de
Snort (figure 22). Il faut noter que cet enregistrement se fait gratuitement.
Ensuite, il nous ait proposé de choisir d’activer Salt ou non. Salt permettra à notre serveur de
plus facilement gérer les comptes d’utilisateurs des machines sondes, les clés SSH, etc.
autrement dit, Salt permet au serveur de communiquer en sécurité avec les sondes. Nous
choisissons de l’activer (figure 23).

Figure 22 : Saisie de l’Oinkcode

[Source : personnelle]

DENE PALMEDE IBRAHIM/U-AUBEN

40
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

Figure 23 : Choix d’activation de Salt

[Source : personnelle]

L’étape suivante nous demande si l’on veut activer ELSA ou non. ELSA a été décrite dans le
chapitre précédent. Si nous souhaitons utiliser une autre plateforme de gestion de logs autre
qu’ELSA, nous le désactivons. Dans ce cas, nous avons d’utilisé ELSA (figure 24).

Figure 24 : Choix d’activation d’ELSA

[Source : personnelle]

Lorsqu’on choisit d’utiliser ELSA comme plateforme de gestion de logs, Security Onion
demande de réserver de l’espace disque pour les logs (figure 25). Nous avons choisi 10Go pour
un départ.

Figure 25 : Réservation d’espace disque pour les logs ELSA

[Source : personnelle]

DENE PALMEDE IBRAHIM/U-AUBEN

41
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

Le résumé de l’installation à effectuer s’affiche et il faut cliquer sur valider pour démarrer
l’installation et appliquer les réglages que nous avons choisi.

Figure 26 : Résumé des paramètres d’installation du serveur

[Source : personnelle]

Une fois l’installation terminée, nous avons exécuté la commande sudo service nsm restart pour
redémarrer les services et avoir leurs statuts (figure 3-20).

Figure 27 : Etat des services du serveur Security Onion

[Source : personnelle]

On peut tester la console Sguil (figure 28) et l’interface de Squert (figure 29).

DENE PALMEDE IBRAHIM/U-AUBEN

42
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

Figure 28 : Console Sguil avec une alerte OSSEC détaillée

[Source : personnelle]

Figure 29 : Interface de squert

[Source : personnelle]

4.3.3. Installation des sondes

La procédure d’installation d’une sonde Security Onion est presque la même que celle d’un
serveur. Une fois l’installation de la distribution terminée, on procède par le lancement du
Setup. Les premières étapes consistent à configurer les paramètres réseaux de la machine.

DENE PALMEDE IBRAHIM/U-AUBEN

43
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

Quand les paramètres réseaux de la machine sont correctement configurés, on passe à l’étape
d’installation des éléments de la distribution (figure 30).

Figure 30 : Choix du mode de déploiement

[Source : personnelle]

Comme nous sommes en train d’installer une sonde, nous optons pour deuxième choix. Une
fois le monde sonde choisi, Security Onion nous demande de fournir l’adresse IP du serveur
maître. Dans notre cas, l’adresse IP du serveur est le 192.168.10.50 (figure 31).

Figure 31 : Demande de l’adresse IP du serveur

[Source : personnelle]

Après avoir choisi l’adresse IP du serveur, nous devons indiquer un compte utilisateur qui
possède les privilèges super utilisateur sur le serveur et qui peut y accéder en SSH (figure 32).

Figure 32 : Nom d’utilisateur possédant les droits SU sur le serveur

[Source : personnelle]

DENE PALMEDE IBRAHIM/U-AUBEN

44
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

Une fois ces informations fournies, nous devons également configurer l’interface de sniffing.
Nous avons configuré en amont l’interface eth0 comme interface de management. Nous
choisirons l’interface eth1 comme interface de sniffing (figure 33).

Figure 33 : Choix interface de sniffing

[Source : personnelle]

A présent nous devons choisir les modules que nous souhaitons activer. Security Onion nous
propose d’activer ou non les NIDS. Nous choisissons Oui (figure 34).

Figure 34 : Activation des IDS

[Source : personnelle]

Lorsque nous avons activé les IDS, Security Onion nous a demandé de choisir un paramètre
concernant les homes networks, c’est-à-dire les réseaux locaux. Nous laissons les valeurs par
défauts à ce niveau (Classes d’adresses IP privées RFC 1918) : 192.168.0.0/24, 10.0.0.0/8,
172.16.0.0/16. Ensuite SO nous demande si l’on souhaite, d’activer l’analyseur Bro. Nous
choisissons d’activer Bro, car il sera l’œil de notre réseau en plus des NDIS et HIDS (figure 3-
28).

Figure 35 : : Activation de l’analyseur Bro

[Source : personnelle]

DENE PALMEDE IBRAHIM/U-AUBEN

45
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

L’analyseur Bro possède la capacité d’extraire tous les fichiers exécutables, et peut les stocker
dans un emplacement à partir duquel on peut y accéder. Cette fonctionnalité est très intéressante
dans le cadre d’une investigation en cas de présence d’un fichier malicieux ou suspect sur le
réseau (figure 36).

Figure 36 : Activation de l’extraction des exes par Bro

[Source : personnelle]

Security Onion embarque Argus. Argus surveille le trafic réseau et log toutes les données de
session vers le serveur. Ceci est particulièrement intéressant lorsqu’un analyste souhaite voir
toutes les activités en rapport avec une session [33] (figure 37).

Figure 37 : Activation d’Argus

[Source : personnelle]

Après avoir effectué toutes ces étapes, la configuration de notre sonde n’est pas encore
terminée. Nous devons choisir le mode de surveillance du trafic du réseau. Pour cela, Security
Onion nous offre deux possibilités : Sauvegarde complète du trafic ou sauvegarde simple des
trafics relatifs aux différents événements d’alertes (figure 38).

Figure 38 : Option Full packet capture

[Source : personnelle]

DENE PALMEDE IBRAHIM/U-AUBEN

46
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

L’option full packet capture est très intéressante dans la mesure où elle va permettre la revue
de l’entièreté des données capturées à partir du réseau. Son inconvénient est qu’il prend
beaucoup d’espace disque. Ensuite Security Onion nous demande de fournir l’espace disque à
remplir pour déclencher une purge des logs. Par défaut nous laissons cette à 90 pourcents (figure
39).

Figure 39 : : Espace disque à réserver

[Source : personnelle]

Une ceci effectué, SO nous demande si l’on souhaite activer Salt. Nous choisissons l’option
activer Salt. Nous avons déjà activé Salt sur le serveur (figure 40).

Figure 40 : Activation de Salt sur une sonde

[Source : personnelle]

Dans l’étape suivante nous devons activer ELSA (figure 41).

Figure 41 : Activation d’ELSA

[Source : personnelle]

DENE PALMEDE IBRAHIM/U-AUBEN

47
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

Après avoir activé ELSA comme un nœud sur la sonde, l’étape suivante demande de mettre à
jour ELSA sur le serveur (figure 42).

Figure 42 : Mise à jour du nœud serveur

[Source : personnelle]

Pour procéder à l’installation et appliquer les choix que nous avons faits, nous cliquons sur le
bouton « Yes, proceed with the changes ! » (figure 43).

Figure 43 : Résumé des paramètres d’installation de la sonde

[Source : personnelle]

Après l’installation, nous avons exécuté la commande sostat redacted pour vérifier l’état des
services.

Figure 44 : Une partie des résultats de la sostat redacted

[Source : personnelle]

DENE PALMEDE IBRAHIM/U-AUBEN

48
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

Dans la partie ci-avant, nous avons réalisé le gros du travail, c’est-à-dire, le choix de
l’emplacement des sondes et le déploiement de la solution de supervision de la sécurité du
réseau. Nous avons également effectué les configurations initiales. La suite sera consacrée aux
configurations avancées, aux personnalisations, la mise en place de l’équipe CIRT et les tests.
Ensuite à la configuration des nœuds de Security Onion, c’est-à-dire le serveur et les sondes.
Nous avons précédemment décrit l’architecture du déploiement et nous avons effectué
l’installation et les configurations initiales du serveur et des sondes.

4.4. Configuration de Security Onion

Les fichiers relatifs à la configuration de SO sont localisés dans le répertoire /etc/nsm, et cela
quel que soit la machine sur laquelle on se trouve serveur/sonde). Dans ce répertoire, on trouve
les configurations de tous les outils.
4.4.1. Configuration du serveur
Pour vérifier que tous les services activés sur le serveur fonctionnent normalement, nous
exécutons la commande service nsm status. Le résultat de cette commande devra afficher cela
(figure 45).

Figure 45 : Etat des services sur le serveur Security Onion (SO)

[Source : personnelle]

Sur le serveur, il est possible de configurer la durée de sauvegarde des archives avant leurs
suppressions. Cette configuration se fait dans le fichier /etc/nsm/securityonion.conf. Dans ce
fichier, on fixe la valeur de la variable DAYSTOKEEP. Par défaut, cette valeur est fixée à 30,
mais nous avons choisi 365 jours.

Figure 46 : Configuration de la durée d’archivage de Security Onion

[Source : personnelle]

DENE PALMEDE IBRAHIM/U-AUBEN

49
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

4.4.2. Configuration des sondes

4.4.2.1. Généralités
L’une des tâches les plus importantes d’une sonde est la fonction d’IDS. Ainsi, après
l’installation, il est possible de configurer les réseaux surveillés par l’IDS installé, s’ils sont
différents des réseaux du RFC 1918. Les configurations relatives à une sonde se font dans le
/etc/nsm/$HOSTNAME-INTERFACE/. $HOSYNAME correspond au nom d’hôte de la
sonde INTERFACE correspond à l’interface monitorée. Une fois dans ce répertoire, on
modifie soit snort.conf ou suricata.yaml, dépendant de l’IDS installé.
Sur la figure 47, la variable HOME_NET permet de configurer les réseaux internes à surveiller.
HOME_NET est configurée avec les réseaux de classe privée du RFC 1918. On remarque que
la variable EXTERNAL_NET, avec comme valeur any, cela permet de s’intéresser à tous les
réseaux provenant de l’extérieur.

Figure 47 : Configuration des réseaux Snort

[Source : personnelle]

La configuration des réseaux à surveiller par l’analyseur Bro se fait dans le fichier
/opt/bro/etc/networks.cfg.

Figure 48 : Configuration des réseaux Bro

[Source : personnelle]

Comme avec Snort, les réseaux configurer par défaut sont les réseaux de classes privées du
RFC 1918. En plus des règles prédéfinies, des règles téléchargées, Snort nous permet d’écrire

DENE PALMEDE IBRAHIM/U-AUBEN

50
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

nos propres règles. L’ensemble de ces règles se trouve dans le répertoire etc/nsm/rules. Dans
règles spécifiques à une sonde se trouvent dans le ficher /etc/nsm/$HOSTNAME-
INTERFACE/rules/local.rules.
Les alertes de Snort sont configurées pour être envoyées au format baynard2. « baynard2 » est
configuré pour transcrire les sorties de Snort vers la base de Sguil.

4.4.2.2. Règles personnalisées

L’une des puissances de Snort est qu’il nous donne la possibilité d’écrire nos propres règles.
Une règle Snort se découpe en deux parties : l’entête de la règle, et les options de la règle.
L’entête de la règle contient les actions à entreprendre, le protocole auquel la règle s’applique,
et les ports sources et de destinations. Les options de la règle nous permettent de spécifier un
message descriptif à associer à la règle, mais les vérifications d’autres champs des paquets.
Elles correspondent au corps de la règle.
La syntaxe d’une règle Snort est la suivante : action proto src_port direction dst_ip dst_port
(options) [34].
• Action : correspond à l’action à entreprendre au cas ou un paquet correspond à la règle.
Snort comporte plusieurs actions intégrées. On peut citer par exemple log, alert,
activate, pass. Il est possible d’écrire sa propre action à comprendre.
• Proto : correspond au protocole à analyser. Ils sont au nombre de quatre (4) : tcp, udp,
ip et icmp. Src_ip et dst_ip correspondent aux adresses IP source et de destination à
regarder.
En général, pour une règle dont la direction est de l’extérieur vers l’intérieur, le champ src_ip
est mis à la chaine any. Il est possible d’utiliser la notation CIDR pour définir un réseau de
destination au lieu d’une seule adresse de destination.
• Les champs src_port et src_dst sont pour les ports sources et destinations. Ils peuvent
prendre la valeur any.
Etant donné le nombre très important de règles disponibles et téléchargées par Snort, il est très
rare de voir un analyste écrire ses propres règles. La figure 49 montre le nombre de règles
disponibles pour notre IDS Snort dans SO. La commande sostat | less nous permet d’avoir cette
information.

DENE PALMEDE IBRAHIM/U-AUBEN

51
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

Figure 49 : Statistique des règles Snort

[Source : personnelle]

Nous remarquons qu’à partir de ces statistiques, qu’il y’a 32 509 règles au total dont 9336 règles
sont actifs.
Exemple: alert tcp any any – > any any (flags : SF, 12; msg : “Scan possible en cours’;)
Cette règle demande à Snort d’inspecter tous les paquets entrants et sortant, n’importe quelle
adresse source et destination, n’importe quel port source et destination. Il va chercher si les
drapeaux SYN et FIN sont activés cela permet de savoir s’il s’agit d’un type de scan de port.
S’il trouve des paquets avec les FLAGS TCP fixé à SF, il génère une alerte avec le message
« Scan possible en cours »

4.4.3. Configuration des LIDS

4.4.3.1. Généralités
D’autres configurations sont disponibles, notamment celles des HIDS/LIDS. Les
agents/serveurs OSSEC prennent en charge cette fonction.
La configuration d’OSSEC se fait dans le fichier /var/ossec/etc/ossec.conf. Ce fichier contient
beaucoup de section de configuration [24].
OSSEC surveille les logs en se basant sur les règles bien définies. S’il détecte une anomalie par
rapport aux règles, OSSEC envoie des alertes dans le fichier /var/ossec/alerts/alerts.log.
L’agent OSSEC intégré au serveur SO lit les alertes, les retranscrit puis les envoient à la base
de Sguil. Ainsi, on peut se référer à [35] pour les éléments à surveiller lors d’écriture des règles
de corrélation. OSSEC peut être configuré pour envoyer des alertes d’un certain niveau par
email.

4.4.3.2. Règles personnalisées

OSSEC possède ses propres parseurs de logs et règles de corrélation. Il comporte des règles
pour la plupart des applications et systèmes connus. Si on dispose d’une application qui n’est
pas supportée par OSSEC, par exemple une application développée en interne, on peut écrire
ses propres règles et parseurs pour la prise en charge de cette application.

DENE PALMEDE IBRAHIM/U-AUBEN

52
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

Les fichiers de log à surveiller sont configurés dans la section localfile du ficher de
configuration d’OSSEC.
Les règles et les décodeurs d’OSSEC sont écrits au format xml. Les décodeurs sont localisés
dans les fichiers /var/ossec/etc/decoders.xml et /var/ossec/rules/*.xml.
Exemple : Décodage et règle pour un log spécifique à une application non prise en charge par
OSSEC.

Figure 50 : Un enregistrement dans un log d’une application non prise en charge

[Source : personnelle]

Figure 51 : Décodeur et règle personnalisés OSSEC pour le log de la figure 50

[Source : personnelle]

4.4.4. Maintenance de Security Onion

L’installation et les configurations initiales du serveur et des sondes Security Onion ne sont que
les débuts de l’aventure. Les composants installés ont besoin d’être régulièrement mise à jour.
Les espaces de stockage que demandent ces différents services sont grands et doivent être
régulièrement surveillés.

4.4.4.1. Mise à jour

La plateforme NSM de Security Onion s’exécute sur une distribution Linux, et a besoin d’être
régulièrement mise à jour. Un système qui n’est pas régulièrement mise à jour tournera
certainement avec beaucoup de failles et de vulnérabilités.
SO tourne sur Ubuntu, donc nous permet alors d’effectuer des mises à jour à travers le
gestionnaire de paquets apt. Cela peut se faire soit en mode graphique u en mode ligne de
commande.

DENE PALMEDE IBRAHIM/U-AUBEN

53
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

En cliquant sur le bouton « Install Now », le système télécharge et installe les mises à jour
directement en mode graphique. Il faut également noter que les mise à jour en mode graphique
(sont recherchées et proposées automatiquement.
En mode console, on utilise la commande apt-get update et apt-upgrade. La première
commande permet de rechercher les mises à jour génériques pour la plupart des applications
out daté, et propose de leur mettre à jour. L’upgrade concerne les applications ou les paquets
de version inférieure par rapport à la version à jour.
Les mises à jour mentionnées ci-dessus sont pour le système, les packages et les applications
installées. SO dispose d’un outil pour les mises à jour qui lui est spécifiques. A travers cette
plateforme, SO met à jour les différents composants et outils qu’il intègre. Il s’agit de l’outil
soup.
Comme notre déploiement est distribué, soup est combiné à salt pour la mise à jour des sondes
[36]. La procédure à suivre est d’abord de mettre à jour le serveur. Pour cela, on exécute la
commande soup sur le serveur (figure 52).

Figure 52 : Mise à jour de Security Onion avec soup

[Source : personnelle]

DENE PALMEDE IBRAHIM/U-AUBEN

54
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

4.4.4.2. Limiter les accès

Le serveur doit être protégé contre les accès non autorisé. Pour cela, nous ouvrons seulement
les ports autorisés à savoir : 514 pour syslog, 22 pour SSH, 1514 pour OSSEC et 443 pour
l’accès HTTPS.
UFW (Uncomplicated Firewall) est l’utilitaire qui sert de pare-feu pour la distribution SO. Pour
contrôler l’état des ports ouverts au niveau du pare-feu, on utilise la commande ufw status.

4.4.4.3. Gérer les espaces disques

Aussitôt bien installé et configuré, les outils Security Onion commencent à sniffer le Traffic du
réseau en direct. Si la fonction full packer capture est activée, alors les sondes et le serveur
sauvegarde tout le trafic sniffer. Cela demande une disponibilité de grands espaces de stockage
pour le court et le moyen terme. Cette fonction est réalisée par l’outils netsniff-ng. Netsniff-ng
est capable de sniffer un lien jusqu’à 10Gb/s.
Les outils NSM qu’embarque SO commencent alors à collecter, à interpréter et à analyser les
données en lice du réseau. Les données collectées par ces outils sont de divers types (cf. chapitre
3). Ces données sont ensuite enregistrées dans divers emplacements au niveau du disque. Selon
[6], parmi ces emplacements, deux sont les plus importants :
- /nsm répertoire dans lequel sont stockés tous les logs et les données capturées ;
- /var/lib/MySQL répertoire de stockage des bases de données MySQL.
Le répertoire /var/lib/Mysql utilise moins d’espace que /nsm. Les données de SO sont stockées
dans le répertoire /nsm/sensor_dat/nomsonde-interface/dailylogs/YYYY-MM-DD.
Nomsonde correspond au nom d’hôte de la machine sonde. Le nom du fichier que ce dossier
contient est Snort suivi du timestamp (au format Unix) auquel le fichier a été modifié. Le
contenu du fichier est au format pcap.

Figure 53 : Aperçu d’un dossier journalier

[Source : personnelle]

DENE PALMEDE IBRAHIM/U-AUBEN

55
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

Figure 54 : Contenu du dossier des bases de données de MySQL

[Source : personnelle]

La Figure 54 nous montre le contenu du dossier des bases de données de MySQL. On y

remarque que les bases de données créées sont : elsa_web, syslog, syslog_data. Les autres sont
les bases spécifiques à MySQL.
L’un des principaux avantages de SO est le fait qu’il dispose de plusieurs scripts qui vérifient
régulièrement l’utilisation de l’espace disque. Si l’espace disque utilisé atteint le seuil fixé, les
scipts effacent automatiquement les anciennes données capturées (pcap). Par defaut, ce seuil
est fixé à 90% de l’espace disque.
Les bases de données Sguil, Syslog et ELSA enregistrées sur MySQL occupent beaucoup
d’espace disque. Pour vérifier l’espace disque occupé par ces différentes bases, l’utilisateur doit
simplement se connecter au serveur MySQL et exécuter la requête suivante :

Figure 55 : Requête MySQL pour les espaces occupés source [6]

[Source : personnelle]

Security Onion embarque également un script pour le nettoyage de la base de données de Sguil.
Lors de l’installation du serveur, nous avons configuré une variable DAYSTOKEEP. Cette
variable se trouve dans le fichier /etc/nsm/securityonion.conf. Le scipt sguil-db-purge vérifie
les données enregistrées dans la base de données de Sguil. Il supprime les données dont l’âge a

DENE PALMEDE IBRAHIM/U-AUBEN

56
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

dépassé la valeur de la variable DAYSTOKEEP. Si par exemple la valeur de DAYSTOKEEP

est de 365, sguil-purge-db supprimera toutes les données datant de 366 jours ou plus.
La surveillance de l’espace de disque occupé par les logs est aussi nécessaire. Ainsi, si les logs
sont stockés plus d’un an par exemple, l’administrateur de la sécurité devra alors les exporter
vers un autre stockage.
En plus de la surveillance des espaces occupé par les outils individuels, nous pouvons surveiller
l’espace disque globale disponible et utilisé. La commande df -h permet de voir l’espace libre
et occupé sur les partitions du système.

4.5. Mise en place de l’équipe CIRT

4.5.1. Généralités
Le déploiement d’une solution de gestion de la sécurité n’est pas complet s’il n’y a pas au sein
de l’entreprise, de l’organisation une équipe CIRT. L’équipe CIRT est chargée de piloter et de
mener les opérations de supervision de la sécurité de réseau. Travailler avec un SSR permet à
une équipe CIRT de prendre de meilleures décisions et d’agir beaucoup plus rapidement.

4.5.2. Constitution de l’équipe

Selon |6], l’équipe CIRT devra composer de trois sections, dirigée par un responsable. Toujours
selon la même source, les sections devront être réparties comme suit :
• Détection et réponse aux incidents ;
• Renseignement appliqué sur les menaces (Threat Intelligence) ;
• Infrastructure et développement.

4.5.2.1. Responsable de l’équipe

Le rôle du responsable de l’équipe CIRT est chargé d’organiser, de former et mener l’équipe à
bien réussir ses opérations. La décision finale à appliquer, lui revient. Il se repose sur les
informations remontées par les différents responsables de sections, notamment la section
Détection et Réponse aux incidents et Renseignement sur les menaces. Le responsable
Technique de ‘l’entreprise aura cette tâche.

4.5.2.2. Détection et réponse aux incidents

Cette section devra être constituée d’un Analyste principal et un technicien chargé de la
surveillance des évènements. [6] décrit cette section comme étant responsable du suivi
journalier et de l’escalade des incidents de sécurité.

DENE PALMEDE IBRAHIM/U-AUBEN

57
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

L’analyste principal devra être un expérimenté de la sécurité informatique. Il devra également

avoir les facultés de chasseur d’évènements. Il forme le technicien de la surveillance des
évènements, et ce dernier lui remonte les évènements suspects. Le Technicien lui est chargé de
surveiller la sécurité du réseau 24h/24, et cela mem étant dehors des locaux de l’entreprise.
L’analyste principal sera un ingénieur expérimenté du service technique. Le Technicien sera un
technicien en réseau, formé pour utiliser un NSM.

4.5.2.3. Renseignement sur les menaces

Cette section est la plus difficile à former. En effet, elle est chargée de suivre et de se renseigner
sur les menaces inhérentes aux activités numériques. Elle est également chargée de suivre
l’audit du réseau interne. Selon [6], cette section devra être chargée de faire des tests de
simulation d’adversaires et des tests de pénétrations. La section renseignement sur les menaces
est constituée d’un ingénieur chargé du renseignement, et d’ingénieurs chargés de simuler les
équipes bleues1 ou Blue team et les équipes rouges ou Red team2 .
L’ingénieur chargé du renseignement informe régulièrement la section détection et réponse
aux incidents sur les menaces actuelles et les actions à entreprendre pour les contrer.

4.5.2.4. Infrastructure et développement

La section infrastructure et développement fournie aux deux autres sections des outils pour
leurs permettre de bien mener leurs opérations. Elle veille également à la mise en place de
nouveaux outils et techniques de détection.
Elle devra être constituée d’un développeur et d’un administrateur système.

4.6. Tests
Pour tester que la solution mise en place fonctionne très bien, nous procéderons à plusieurs
tests, selon plusieurs cas de figure.

1
Blue team : une équipe chargée d’agir en interne comme des consultants. Elle est chargée de mettre en place les mesures pour sécuriser
l’entreprise de l’intérieur
2
Red team2 : Une équipe chargée d’agir comme des pirates informatiques. Elle est chargée de simuler les attaques et les menaces à la
recherche constante de failles dans la protection mise en place par la Blue Team
58
DENE PALMEDE IBRAHIM/U-AUBEN
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

4.6.1. Cas de figure 1 : Scan d’une machine sur le réseau

Figure 56 : Résultats d’un scan vu les NIDS dans la console Sguil

[Source : personnelle]

La méthode la plus simple pour vérifier le bon fonctionnement d’un NIDS est de procéder par
un scan. L’outil le plus utilisé pour les scans est nmap. Nmap étant installé sur Kali Linux,
nous l’avons utilisé pour scanner le réseau. Le résultat ne s’est pas fait attendre. Instantanément,
les alertes ont été envoyées vers Sgui, qui les affiche aussitôt (figure 4-12). Lorsque nous
cochons l’option « Show Packet Data », nous remarquons que seul le drapeau SYN est
positionné. Cela renseigne sur le type de scan effectué, dans ce cas c’est le scan SYN.

4.6.2. Cas de figure 2 : Tentative d’attaque par force brute

Pour tester le HIDS OSSEC installé sur les hôtes, nous avons essayé de faire une
authentification SSH par force brute. Pour ce faire, nous avons utilisé l’outil medusa disponible
dans la distribution Kali Linux.
Durant nos configurations, nous avons activé l’option active d’OSSEC pour qu’il bloque les
tentatives multiples. Sur la figure 4-13, Sguil affiche les alertes d’OSSEC concernant une
authentification échouée. Il précise que c’est une authentification SSH échoué, ensuite indique
qu’il y’a plusieurs tentatives avec un mot de passe erroné. En analysant les détails de la dernière
alerte, l’on voit qu’OSSEC a bloqué la machine responsable de ces tentatives multiples. Nous

DENE PALMEDE IBRAHIM/U-AUBEN

59
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

également examiné le temps d’entre chaque tentative. Il y’a eu 9 tentatives en 15 secondes, ce

qui laisse voir qu’il y’a eu une attaque par force brute mais elle à échoué.

Figure 57 : Attaque par force brute détectée et stoppée par OSSEC

[Source : personnelle]

Conclusion
Dans ce chapitre, nous avons effectué des configurations plus poussées sur Security Onion.
Nous avons vu comment maintenir SO. Nous avons également procédé à la mise en place de
l’équipe CIRT au sein de l’entreprise. Pour finir, nous avons procédé à des tests.

DENE PALMEDE IBRAHIM/U-AUBEN

60
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

CONCLUSION GENERALE
Au terme de ce projet, et compte tenu tout ce qui précède, il est de toute évidence que les
problèmes qui ont été soulevés au départ à savoir entre autres l’étude et la mise en place d’une
solution de gestion de la sécurité ont été résolus. A travers cette solution SUNU Assurance
IARD fera une gestion efficace de la sécurité de son réseau. Cette solution lui permettra aussi
de protéger ses clients de la plupart des menaces en provenance d’internet et contribuera à la
sécurité de son interconnexion avec les différentes agences annexes.
En effet, dans ce projet, nous avons pu mettre en place une solution composée d’un Network
Security Monitoring en l’occurrence Security Onion composé d’un gestionnaire centralisé de
logs, en l’occurrence ELSA. Nous avons également mis en place l’équipe CIRT qui pourra
valablement s’appuyer sur la solution déployée pour mener à bien ses missions. Avec cette
solution, les équipes Techniques de SUNU Assurances IARD verront les intrusions et pourront
prendre les mesures nécessaires pour les arrêter (Snort, OSSEC, Sguil, Squert). Ces outils
(CapMe, Network Miner, Xplico, Wireshark) leurs permettront de mener des investigations
poussées pour tirer des conclusions plus adaptées après des évènements de sécurité. Les traces
ainsi obtenues pourront être utilisées comme preuve contre un attaquant.
Ce projet nous a également permis la maitrise de techniques d’audit de la sécurité des réseaux
et des systèmes. Nous avons proposé des recommandations afin d’avoir un réseau et des
systèmes sécurisés avant le déploiement de toute solution de gestion de la sécurité.
Ce projet a été l’occasion pour en tant que professionnel des réseaux et des télécommunications
de mettre en pratique les connaissances théoriques de la sécurité des réseaux. Cette formation
théorique s’est révélée particulièrement adaptée aux compétences souhaitées et m’a permis de
relever le défi posé. En outre, elle m’a permis de me diversifier et d’aborder le monde très prisé
des professionnels de la sécurité informatique.
Ce travail pourra être compléter par l’intégration d’un SIEM open source avec Security Onion.
Cela renforcera le dispositif de supervision et enrichira le tableau de bord.
Dans l’avenir, nous souhaiterons apporter notre contribution à la sécurité dans l’Internet des
Objets (IoT). Nous essayerons de mener des études approfondies afin de proposer des outils
pour la gestion de sécurité des objets connectés, afin d’aboutir à une évolution beaucoup plus
sûre des réseaux IoT à grande échelle, et permettrons de résoudre une partie du problème de la
sécurité de la vie privée des utilisateurs dans l’IoT.

DENE PALMEDE IBRAHIM/U-AUBEN

61
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

REFERENCES BIBLIOGRAPHIQUE

[1] Tidiane SYLLA, Etude et mise en place d’une Solution de Gestion de la Sécurité du
Réseau : CAS D’AFRIBONE MALI, Mali, Master 2, Mémoire de fin de Cycle, Université de
Carthage Département Informatique, 2017

[2] ADOUM Mahamat Youssouf, Réalisation d’Audit de Sécurité d’un Réseau local : cas de
TALENTYS, Master 2, Mémoire de fin de Cycle, Université Aube Nouvelle, Décembre 2022
[3] ACISSI, Sécurité informatique – Ethical Hacking, Apprendre l’attaque pour mieux se
défendre, Herblain, France : Editions ENI, 2013 pp. 12-14.
[4] RSA EMC Corporation, « Hacker Tactics, Techniques and Procedures, »2015.
[5] Helps Net Security, « Hackers changing tactics, techniques and procedures, » 24 Octobre
2022.
[6] R. Bejtlich, The Pratice of Network Security Monitoring, San Francisco : No Starch press,
2013.
[7] Cymbel, “The Big Picture of the Security Incident Cycle, » 10 Octobre 2010. [En ligne]
Available : https://www.cymbel.com/security-compliance/the -big-picture-of-the-security-
incident-cycle/. [Accès le 12 Décembre 2022].
[8] G. Smith, « Log Analysis with the ELK stack (Elasticsearch, Logtsash and Kibana), » 2016.
[9] Sysdream IT Security Services, « Certification PCI DSS,» 2017 [En ligne]. Available :
https://sysdream.com/pci-dss/certification/. [Accès le 12 Novembre 2022].
[10] R. Heenan et M. Naghmeh, « Introduction to Security Onion, » The First Post Graduate
Cyber Security Symposium, pp. 1-4, Mai 2016.
[11] L.C.S, The principle of Network Security Monitoring [MSN], 2.15, p. 60.
[12] S. Gupta et L. D. Kees, «Logging and Monitoring to Detect Network Intrusion and
Compliance Violations in the Environment, » SANS Institute InfoSec Reading Room, p. 44,
2012.
[13] K. Kent et M. Souppaya, Guide to Computer Security Log Management, Graithersburg:
National Institute of Standards and Technology, 2006.
[14] M. K. K. A. R. O. M. N. Peter MUIA, « Emergency Response Team (CERT) for the
NREN Community – The case of KENET CERT, » UbuntuNet Alliance annual conference,
n°%18, pp. 158-167, 2015.
[15] D. Burks, « Introduction To Security Onion,» 16 Mars 2017. [En ligne]. Available :
https://github.com/security-onion-solutions/security-
onion/wiki/IntroductionToSecurityOnion. [Accès le 21 Novembre 2022]
[16] Cisco, « Snort official documentation, » [En ligne]. Available :
https://wwsnort.org/document#OfficialDocumentation. [Accès le 21 Novembre 2022].

DENE PALMEDE IBRAHIM/U-AUBEN

VIII
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

[17] Cisco, « Snort The World’s Most Widely Deployed IPS Technology, » 11 Novembre
2022 [En ligne]. Available
https://www.cisco.com/c/en/us/products/collateral/security/brief_c17-733286.html. [Accès le
21 Novembre 2022].
[18] Cisco, « Snort | Getting Started, » [En ligne]. Available : https://manual-snort-org.s3-
website-us-east-1.amazonaws.com/node3.html. [Accès le 21 Novembre 2022]
[19] D. Burks, « Snort, » 18 Février 2017. [En ligne]. Available : https://githu.com/security-
onion-solutions/security-onion/wifi/snort. [Accès le 21 Novembre 20222].
[20] Suricata, « Suricata, Open source IDS/IPS/NSM engine, » [En ligne]. Available :
https://www.suricata-ids.org/. [Accès le 21 Novembre 2022].
[21] Bro, « The Bro Network Security Monitor, » 2017. [En ligne]. Available :
https://www.bro.org/. [Accès le 22 Novembre 2022].
[22] OSSEC, « About OSSEC, » OSSEC Project Team, 2017. [En Ligne]. Available :
https://ossec .github.io/about.html. [Acès le 23 Novembre 2022]
[23] A. Hay, D. Cid et B. Rory, OSSEC Host-Based Intrusion Detection, Burlington :
Synergress Publishing, Inc, 2008.
[24] D. Cid, log Analysis using OSSE, 2007 p.46.
[25] D. Cid, « Server Security : Indicators of Compromised Behavior with OSSEC, » 17 Mars
2016. [En ligne] Available : https://blg.sucuri.net/2016/03/server-security-anomaly-
behaviour-with-ossec.html. [Accès le 24 Novembre 2022]
[26] OpenVas , « OpenVas – Open Vulnérability Assesment System, » 2017. [En ligne]
Available : https://www.openvas.org/. [Accès le 25 Novembre 2022].
[27] D. Karg, J. D. Munoz, D. Cil, F. Ospitia, S. Gonzales et J. Casal, Open Source Security
Information Management, 2003.
[28] OCS INVENTORY NG, « Projet OCS Inventory, » 2017. [En ligne]. Available :
https://www.ocsinventory-ng-org/fr/. [Accès le 25 Novembre 2022].
[29] Nagios, « History of Nagios, » [En ligne]. Available :
https://www.nagios.org/about/history/. [Accès le 26 Novembre 2022].
[30] S. Lawton, « A guide to Security Information and Event Management, » 16 Février 2015.
[En ligne]. Available : https://www.tomsitpro.com/articles/siem-solution-guide, 2-864-2.html.
[Accès le 27 Novembre 2022]
[31] L. Wes et D. Burks, « Architecture – Security Onion Solution, » 29 Septembre 2017. [En
ligne] Available : https://github.com/security-onion-solution/security-onion/wiki/architecture.
[Accès le 27 Novembre 2022]
[32] D. Burks, « Hardware requirements, » 15 Février 2017. [En ligne]. Available
https://github.com/Security-Onion-Solution/security-onion/Hardware [Accès le 28 Novembre
2022].

DENE PALMEDE IBRAHIM/U-AUBEN

IX
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

[33] QOSien, LLC, « Argus – Auditing Network Activity – Getting Started, » 17 Avril 2012
[En ligne]. Available : https://qosient.com/argus/gettingstarted.shtml. [Accès le 03 Décembre
2022].
[34] O’Reilly, « Write Your Own Snort Rules, » [EN ligne]. Available :
https://archive.oreilly.com/pub/h/1393. [Accès le 05 Décembre 2022].
[35] A. Chuvakin et L. Zelster, « Critical Log Review Checklist for Security Incidents, » 2017.
[En ligne]. Available : https://zeltser.com/security-incident-log-review-checcklist/. [Accès le
04 Décembre 2022].
[36] D. Burks, « Upgrade, » 14 Mars 2017. [En ligne]. Available : https://github.com/security-
Onion-Solutions/security-onion/wiki/Upgrade. [Accès le 08 Décembre 2022].
[37] Forum des Compétences Supervision de la Sécurité du système d’information dans les
secteurs Banque et Assurance - Le Security Operation Center – SOC étude mené avec ATOS.
[38] DJIBRINE Agadji Kaou, Etude et mise en œuvre d’un centre de services (Service Desk)
pour la gestion des incidents informatiques au profit de E-SERVICES, Master 2, Mémoire de
fin de Cycle, Université Aube Nouvelle, Avril 2022

DENE PALMEDE IBRAHIM/U-AUBEN

X
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

TABLE DE MATIERES
DEDICACE .............................................................................................................................................. I
REMERCIEMENTS ............................................................................................................................... II
SOMMAIRE ......................................................................................................................................... III
LISTES DES TABLEAUX ET FIGURES ........................................................................................... IV
SIGLES ET ABREVIATIONS ............................................................................................................. VI
RESUME .............................................................................................................................................. VII
ABSTRACT ......................................................................................................................................... VII
INTRODUCTION GÉNÉRALE ............................................................................................................. 1
PROBLEMATIQUE ............................................................................................................................... 2
OBJECTIF PRINCIPAL ......................................................................................................................... 3
OBJECTIFS SPECIFIQUES ................................................................................................................... 3
HYPOTHESE.......................................................................................................................................... 3
METHODOLOGIE ................................................................................................................................. 4
PERTINENCE ET RETOMBEES ANTICIPEES .................................................................................. 4
CHAPITRE I : MISSIONS DU SOC/CSIRT, NORMES ET METHODOLOGIES .............................. 5
1.1. INTRODUCTION ................................................................................................................... 5
1.2. Concepts et fondamentaux sur les SOC .................................................................................. 5
1.2.1. Principales différences entre le SOC et le CSIRT ........................................................... 5
1.2.2. Synergies entre SOC et CSIRT ....................................................................................... 6
1.2.3. Journaux, événements, alertes et incidents ...................................................................... 9
1.2.4. Le SIEM ........................................................................................................................ 10
1.2.5. Le SOC dans la stratégie SSI......................................................................................... 11
1.3. Études comparatives sur les différentes solutions de gestion de la Sécurité SOC .................... 12
1.3.1. Le Centre Opérationnel de Sécurité (COS) ................................................................... 12
1.3.2. Activités d’un SOC ....................................................................................................... 12
1.3.3. Définition des missions d’un SOC ................................................................................ 12
1.3.4. Classifications des SOC ................................................................................................ 13
1.4. La gestion de la sécurité du réseau ........................................................................................ 17
1.4.1. La supervision de la sécurité réseau .............................................................................. 18
1.4.2. Architecture d’une plateforme de Supervision de la Sécurité Réseau ........................... 19
1.4.3. Les types de données collectées .................................................................................... 20
1.5. La Gestion de Logs................................................................................................................ 20
1.5.1. Architecture d’un système de gestion de log ................................................................. 21
1.5.2. Fonctions d’un système de gestion de logs ................................................................... 21
1.6. L’équipe CIRT ...................................................................................................................... 22
1.7. Les solutions de supervisions de la sécurité réseau ............................................................... 23

DENE PALMEDE IBRAHIM/U-AUBEN

XI
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

1.7.1. Security Onion............................................................................................................... 24

1.7.2. OSSIM (Open Source Security Information Management) .......................................... 26
1.7.3. ArcSight......................................................................................................................... 27
1.7.4. Splunk............................................................................................................................ 28
1.7.5. Graylog2 ........................................................................................................................ 28
1.8. Choix de la solution............................................................................................................... 28
1.8.1. Critères de choix des solutions SIEM ............................................................................ 30
1.8.2. Choix de la solution et justification ............................................................................... 30
Conclusion......................................................................................................................................... 30
CHAPITRE II : DEPLOIEMENT DE SECURITY ONION, MISE EN PLACE DE L’EQUIPE CIRT
ET TESTS ............................................................................................................................................. 31
4.1. Introduction ........................................................................................................................... 31
4.2. Architecture de Security Onion et déploiement .................................................................... 31
4.2.1. Architecture de Security Onion ..................................................................................... 31
4.2.2. Architecture du réseau cible .......................................................................................... 32
4.2.3. Modes de déploiement de Security Onion..................................................................... 33
4.2.4. Emplacements des sondes et du serveur ........................................................................ 34
4.3. Installation du serveur et des sondes ..................................................................................... 36
4.3.1. Configuration matérielle ............................................................................................... 36
4.3.2. Installation du serveur................................................................................................... 36
4.3.3. Installation des sondes ................................................................................................... 43
4.4. Configuration de Security Onion........................................................................................... 49
4.4.1. Configuration du serveur .............................................................................................. 49
4.4.2. Configuration des sondes .............................................................................................. 50
4.4.3. Configuration des LIDS................................................................................................. 52
4.4.4. Maintenance de Security Onion .................................................................................... 53
4.5. Mise en place de l’équipe CIRT ............................................................................................ 57
4.5.1. Généralités ..................................................................................................................... 57
4.5.2. Constitution de l’équipe ................................................................................................ 57
4.6. Tests ...................................................................................................................................... 58
4.6.1. Cas de figure 1 : Scan d’une machine sur le réseau ...................................................... 59
4.6.2. Cas de figure 2 : Tentative d’attaque par force brute ................................................... 59
Conclusion......................................................................................................................................... 60
CONCLUSION GENERALE ............................................................................................................... 61
REFERENCES BIBLIOGRAPHIQUE.............................................................................................. VIII
TABLE DE MATIERES ....................................................................................................................... XI
ANNEXES ......................................................................................................................................... XIII

DENE PALMEDE IBRAHIM/U-AUBEN

XII
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

ANNEXES

ANNEXES 1 : Indicateurs et tableaux de bord

Nous donnons ici une liste d’indicateurs et de leur utilité. Cette liste est donnée à titre d’exemple.

Indicateur d’activité du SOC

Indicateur Type d’indicateur Commentaire
Nombre d’équipements surveillés Activité du SOC Base de référence pour les taux qui suivent
Nombre d’événements collectés
Nombre d’alertes déclenchées Efficacité du SOC suivant le paramétrage des Si les ratios sont trop élevés, le SOC est mal
Nombre de faux positifs outils ajusté. Il faut revoir le paramétrage des outils.

Nombre d’incidents de sécurité

Indicateur des risques du SOC

Indicateur Type d’indicateur Commentaire
Ex : Risque de non déclenchement d’alertes
sensibles
Nombre de risques identifiés Proposition d’amélioration du SOC
Pic d’alertes sur certaines vulnérabilités

DENE PALMEDE IBRAHIM/U-AUBEN

XIII
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

Indicateur des risques du SOC

Indicateur Type d’indicateur Commentaire
Efficacité de la détection des incidents de Rapport des incidents détectés par le SOC sur
sécurité par le SOC sur son périmètre de le total des incidents de sécu.
Détection d’incidents de sécurité
surveillance

Capacité de l’équipe SOC à traiter les Nombre d’incidents traités sur le total
incidents d’incidents déclarés Indicateurs
Taux de clôture des incidents sur le mois

Indicateur des risques du SOC

Indicateur Type d’indicateur Commentaire
Pourcentage des alertes récurrentes sur une durée
Surveillance Qualité de la détection
définie, identifiées comme faux positif.
Respect du délai de fourniture du rapport
Demandes d’investigation Mesure des engagements de délais
d’investigation
Nombre d’incidents mal qualifiés / total des incidents
Incidents Taux d’incidents mal qualifiés
de sécurité
Tenue des délais de changement et amélioration
Changements Tenue des délais
continue

Gouvernance Reporting sécurité Livré dans les délais

DENE PALMEDE IBRAHIM/U-AUBEN

XIV
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

Annexe 2 : Exercices et audits

Le fait qu’une alerte ne se déclenche jamais n’est pas le signe de sa non-pertinence. Il convient
donc d’imaginer des scénarios d’attaques exceptionnels et de les soumettre au SOC pour
évaluer sa réaction. Il est souhaitable que ces scénarios ne soient pas imaginés par l’équipe
SOC. Il faut donc faire appel à une équipe autre (une red team) ou alors à un prestataire externe
spécialisé dans ce type de scénario. Il est d’ailleurs aussi souhaitable de ne pas prévenir les
équipes du SOC tout en prenant les précautions nécessaires pour que cette attaque simulée ne
dégénère pas.

Annexe 3 : Améliorer et étoffer le projet

Le SOC est opérationnel et donne satisfaction globalement à l’entreprise. Sa maturité va évoluer
au fur et à mesure du temps et de son activité. Il est alors possible d’aller de l’avant en étendant
le périmètre du SOC à de nouveaux SI par exemple et/ou prendre en compte de nouveaux agents
comme les applications. Il est aussi possible de définir de nouvelles alertes, de modifier les
rapports, en fait de réajuster tout ce qui ne convient pas dans le périmètre initial. Plus
généralement, il convient de mettre en place un référentiel de maturité et d’évaluer et de mesurer
les axes d’amélioration par rapport à ce référentiel. On voit alors se superposer une nouvelle
étape de BUILD pendant que le RUN continue. C’est pourquoi, il est nécessaire dans les
tableaux récapitulatifs de bien lister les deux actions. En cas de contractualisation avec un ou
des partenaires, il est utile de définir tout ce qui peut changer dans le projet et les impacts sur
les coûts du projet, afin de ne pas avoir de mauvaises surprises.

DENE PALMEDE IBRAHIM/U-AUBEN

XV
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

Annexe 4 : Les aspects juridiques de la mise en œuvre d’un SOC

Lorsqu’une entreprise souhaite mettre en place un SOC, de nombreux enjeux juridiques doivent

être anticipés, qu’ils soient internalisés ou externalisés.

a) Les enjeux juridiques du SOC externalisé et internalisé

Il est possible que les prérogatives du SOC entrent en conflit avec les normes internes à
l’entreprise. Ainsi, certains changements internes devront être effectués afin de permettre la
mise en œuvre des missions de sécurité du SOC (règlement intérieur, charte informatique, etc.).
Cependant, de tels changements peuvent nécessiter l’information et/ou la consultation du
comité d’entreprise/des délégués du personnel. Cette procédure pourrait aussi être mise en
œuvre lorsque la mise en œuvre du SOC est susceptible d’entrainer un contrôle de l’activité du
salarié.

b) Les enjeux juridiques de l’externalisation du SOC

Quels sont les enjeux soulevés par l’externalisation d’un SOC ? De prime abord,
l’externalisation d’un service suppose une contractualisation entre l’entreprise et le prestataire.
Sont exposés ci-dessous les principaux enjeux contractuels. En premier lieu, il est nécessaire
de prévoir le périmètre des prestations relatives à la mise en place du SOC, puis à l’exécution
du contrat. Le prestataire devra-t-il seulement détecter les incidents ? Devra-t-il prendre le
contrôle du système d’information pour faire face à ces incidents ? Quels acteurs le SOC devra-
t-il alerter dans l’hypothèse d’une violation de données à caractère personnel ? Ce périmètre
doit impérativement être intégré au contrat, afin d’éviter tout problème d’ingérence durant les
situations de crise. Il conviendra également de préciser les modalités d’accès au système
d’information par le prestataire. L’entreprise devra ainsi délimiter les éléments à externaliser,
afin de minimiser l’ouverture des données tout en garantissant l’efficacité de la prestation. Pour
sécuriser la confidentialité des données contenues dans le système d’information ou dans les
données transférées en général, il est préférable d’inclure dans le contrat une clause de
confidentialité vis-à-vis du prestataire. En outre, il est conseillé d’insérer dans le contrat des
mesures d’évaluation de la prestation, permettant éventuellement de le résilier en cas de non-
respect de la part du prestataire. Il s’agira notamment de préciser les délais d’intervention (de
réaction aux incidents, par exemple) tel qu’indiqué dans la section V.3.5. Les SLA, indicateurs
et reporting. Des pénalités de retard peuvent être appliquées à certaines de ces clauses.
Toute entreprise choisissant d’externaliser un SOC devrait également songer à mettre en œuvre
des procédures de contrôle. Pour cela, l’insertion d’une clause d’audit dans le contrat est

DENE PALMEDE IBRAHIM/U-AUBEN

XVI
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

fortement conseillée. Ceci permet de fixer concrètement le cadre du service et les prestations
attendues. Une attention particulière doit être portée à la clause relative à la responsabilité du
prestataire (dommages couverts, plafond de responsabilité, etc.). Le contrat pourra également
comporter une clause d’assurance, par exemple, garantissant la réparation des dommages le cas
échéant. Il faudra veiller à définir précisément dans le contrat les aspects liés aux durées de
conservation des données chez le prestataire. En dernier lieu, il convient de prévoir l’après
contrat, notamment en vue d’assurer la continuité du service.

c) La protection des données personnelles dans le cadre d’un SOC

Dans le cadre d’un SOC, la conformité à la législation relative à la protection des données
personnelles doit être assurée. En effet, la loi Informatique et Libertés du 6 janvier 1978 et le
règlement européen 2016/679 (entré en vigueur le 24 mai 2016 et applicable à partir du 25 mai
2018), fixent un cadre juridique de protection des données à caractère personnel. Dans
l’hypothèse où l’entreprise faisant appel aux services d’un SOC collecte des données à caractère
personnel, elle sera caractérisée, a priori, comme « responsable de traitement ». À ce titre, le
Règlement Général de Protection des Données impose au responsable de traitement de prendre
des mesures techniques et organisationnelles appropriées, telles que la pseudonymisation et le
chiffrement des données. Si le SOC est externalisé, le prestataire en charge de la sécurité du
système d’information, sera susceptible de traiter ces données afin de mener à bien sa mission.
Dès lors, il sera a priori caractérisé comme un « sous-traitant », au sens des dispositions
législatives. Le Règlement Général de Protection des Données prévoit une évolution sur ce
point puisque le sous-traitant pourra faire l’objet de sanctions en cas de non-respect des
obligations qui lui sont imposées quant à la protection des données personnelles qu’il traite.
L’article 34 de la loi Informatique et Libertés dispose que « Le responsable de traitement est
tenu de prendre toutes les précautions utiles (…) pour préserver la sécurité des données ». De
plus, l’article 35 de la loi Informatique et Libertés dispose que « les données à caractère
personnel ne peuvent faire l’objet d’une opération de traitement de la part d’un sous-traitant
(…) que sur instruction du responsable de traitement ». Il est donc bon de s’assurer que le SOC
ne traite pas les données à caractère personnel en dehors des missions qui lui sont confiées.
Pour rappel, en l’état actuel de la réglementation, seul le responsable de traitement peut être
sanctionné par la CNIL. Se pose en outre la question de la localisation du SOC extérieur à
l’entreprise. En effet, le transfert de données à caractère personnel hors de l’Union européenne
est strictement encadré.

DENE PALMEDE IBRAHIM/U-AUBEN

XVII
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

Il faut alors que cet État soit considéré comme assurant un niveau de protection suffisant, ou
qu’il soit inséré dans les contrats entre l’entreprise et le prestataire des clauses type dictées par
la Commission européenne, assurant une protection adéquate des données.

d) Les textes à anticiper dans la mise en œuvre d’un SOC

Après trois ans de négociations, le Parlement européen et le Conseil de l’Union européenne ont
adopté le 6 juillet 2016 la directive concernant les mesures destinées à assurer un niveau élevé
commun de sécurité des réseaux et des systèmes d’information dans l’Union, ou plus
simplement « directive NIS » (Network and Information Security). S’agissant d’une directive
et non d’un règlement, sa transposition dans les droits nationaux de chaque État membre devra
intervenir avant le 9 mai 2018. La directive NIS se propose de renforcer la cyber-sécurité des
États membres et leur coopération en matière de sécurité informatique. Les SOC sont
concernés, en tant qu’acteurs de premier plan pour ce qui est de la cyber-sécurité.

Annexe 5 : Politique de log

Les logs ou traces (aussi appelés événements de sécurité) sont la matière première pour la
surveillance de la sécurité d’un SI. Que ce soit les postes de travail, les serveurs, les
applications, les équipements de sécurité tels que les pares-feux ou les IDS (liste non
exhaustive), tous génèrent des traces dans le but d’être exploitées ou d’identifier les
comportements à risque. Toutefois, par défaut les systèmes génèrent peu ou pas de traces et
souvent les informations nécessaires pour la supervision de la sécurité d’un SI sont manquantes.
Il est donc important dans un premier temps de réviser la politique de logs par défaut des
différents systèmes (serveurs, applications, équipements réseaux,) afin de s’assurer que les
scénarios d’attaque préalablement retenus seront correctement détectés. Il faudra le cas échéant
procéder par itérations des scénarios d’attaque et affiner les politiques de logs en conséquence
pour s’assurer de l’exhaustivité de la détection. La politique de logs doit prendre en compte :
❖ Les besoins de conformités réglementaires ;
❖ Les informations nécessaires pour l’investigation en cas d’incident de sécurité
❖ Les informations nécessaires aux équipes IT ou métiers suivant l’usage prévue de la
solution de collecte et de centralisation des logs.
❖ Les capacités de traçage des équipements.
❖ La volumétrie et la capacité de traitement de la solution de collecte et de centralisation
des logs.

DENE PALMEDE IBRAHIM/U-AUBEN

XVIII
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

En fonction du périmètre de supervision et de l’importance de l’équipement ou des assets de la

zone, un type d’équipement peut avoir une politique de log différente. Par exemple, un parefeu
de bordure Internet ne trace pas toutes les connexions rejetées de l’Internet vers le réseau interne
car il est souvent attaqué et cela générerait trop de logs inutiles. Par contre un pare-feu
protégeant des actifs critiques doit tracer toute les connexions ou tentatives de connexions pour
les besoins d’investigation en cas d’incident. La politique de logs d’un équipement doit prendre
en compte à minima les catégories suivantes :
❖ Authentification ;
❖ Gestion des utilisateurs ;
❖ Gestions des groupes d’utilisateurs ou rôles ou profils ;
❖ Changements de configuration ;
❖ Erreurs de fonctionnement ;
❖ Alertes de sécurité ;
❖ Actions métiers essentielles.
Il convient également de limiter la redondance d’information. En particulier dans le cas de logs
réseau il est possible de trouver la même communication sur plusieurs équipements surveillés.
La politique devra définir en fonction des traces à obtenir quel est l’équipement le plus judicieux
pour produire les logs.

DENE PALMEDE IBRAHIM/U-AUBEN

XIX
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

Annexe 6 : COUT DE LA REALISATION DU SOC

REF. DÉSIGNATION QTÉ PRIX UNIT. MONTANT

Serveur HPE ProLiant DL380 Gen9 (32 Go de RAM, 4 To de disque
1 3 000 000 3 000 000
dur) avec prise Schuko

Dualcomm ETAP-2205 dual-Link Network TAP 6 325 000 1 950 000

EQUIPEMEN Rack 28 U - profondeur 110 cm + accessoires (serre-câbles, passe-
T RESEAU 1 480 000 480 000
câbles, prise électrique 1U)
SERVEUR
Cordon de brassage FTP cat6 - 50cm/1m Legrand 8 3 500 28 000
SECURITY
ONION
FTP cat6 - câble 3m Legrand 8 5 000 40 000

Alimentation centrale EATON - 15 kVa pour 220V 1 3 500 000 3 500 000

Câble - CAT 6 (1000 pieds) Legrand 1 160 000 160 000

Panneau de brassage FTP Cat6 24 ports 1U Legrand 1 170 000 170 000

Prises RJ45 Legrand 8 13 000 104 000

Prise électrique de conduit Legrand 8 10 000 80 000

Boîte de Conduite Électrique Flex Legrand 8 1 000 8 000

DENE PALMEDE IBRAHIM/U-AUBEN

VIII
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

Ordinateur de bureau HP pavillon 24 (écran 24 pouces, i5, ssd256, 8go

3 800 000 2 400 000
de ram, antivirus 3 ans, Windows 10, combo clavier/souris français)

Coût d'installation (montage des conduits, câblage réseau et électrique,

POSTES 3 11 500 000 34 500 000
raccordement réseau.)
DE
TRAVAIL Mise en place et configuration des infrastructures 1 3 500 000 3 500 000

Ordinateur portable LENOVO Thinkpad E14 pouces, i5, ssd256, 8 go

ram, antivirus 3 ans, édition bureautique maison et étudiant, clavier 1 800 000 800 000
français intégré, Windows 10

Onduleur Eaton 800VA 3 75 000 225 000

Câble HDMI pour vidéoprojecteur (30m, avec répéteur) 3 35 000 105 000

AV Souris sans fil - Clavier sans fils Gamer 3 80 000 240 000
EQUIPMEN
Smart TV LED 55 pouces 4 450 000 1 800 000
MONITORING
Support mural TV (compatible avec TV ci-dessus) 3 20 000 60 000

Multiport HDMI 4 port 1 22 500 22 500

Technicien de supervision 1 250 000 250 000

Ingénieur de Supervision 1 350 000 350 000

DENE PALMEDE IBRAHIM/U-AUBEN

IX
 ETUDE POUR LA REALISATION D’UN CENTRE DE SECURITE DES OPERATIONS AU PROFIT DE SUNU ASSURANCES

Equipe
CSIRT Ingénieur en Sécurité Informatique 1 350 000 350 000

Ingénieur de Conception en Sécurité Informatique 1 450 000 450 000

Responsable Informatique 1 800 000 800 000

Main d'Œuvre
Mise en place et Formations 1 2 000 000 2 000 000
Arrêté la présente proforma à la somme de : Cinquante-sept millions trois cent Total HT 57 372 500
soixante-douze mille cinq cents (57 372 500) francs CFA.
Net à Payer 57 372 500

DENE PALMEDE IBRAHIM/U-AUBEN

X