SECURITE DES RESEAUX ET DES COMMUNICATIONS

CHAPITRE IV : OUTILS DE GESTION ET DE TRAITEMENT DES INCIDENTS DE

SECURITE EN ENTREPRISE
I. Préambule :

Dans ce chapitre nous allons voir les équipements ou les outils que les entreprises
utilisent afin de non seulement assurer la sécurité de l'entreprise, la gestion des incidents ou
des alertes de sécurité mais aussi la façon dont les équipes de sécurité les utilisent. Nous
allons aussi étudier et traiter quelques exemples réels d'incidents de sécurité (la création d'un
incident, les recommandations, le suivi de bout en bout du traitement, etc.).

Avant d'entrer dans le vif du sujet nous allons tout d'abord voir comment est la
structure interne d'une entreprise, comment les équipes de sécurité sont divisées et la façon
dont elles travaillent ensemble.

A noter que chaque entreprise a sa propre organisation et cette dernière repose sur la
taille de l'entreprise.

1. Les différentes équipes de sécurité en entreprise:

Nous avons principalement deux grandes équipes de sécurité en entreprise: le CERT et

le SOC.

Le CERT (Computer Emergency Response Team):

Le CERT est composé d'une équipe d'experts en sécurité informatique dans différents
domaines (malwares, test d’intrusion, veille, lutte contre la cybercriminalité, forensics, etc.).
Les experts sont chargés de réagir et de prendre en main les incidents de sécurité majeurs. Ils
sont aussi chargés de procéder au "reverse engineering" des codes malicieux afin d'identifier
et de corriger les failles de sécurité en entreprise ainsi que de développer les solutions
adéquates pour éradiquer le risque.

Le CERT assure une veille de sécurité, ce qui signifie qu'ils sont à jours en terme de
nouvelles attaques, nouveaux logiciels malveillants, les dernière vulnérabilités et les
technologies touchées par ces vulnérabilités, ils communiquent ensuite les informations en
interne et/ou en externe avec d'autres entreprises (mise en garde) et avec la communauté de
sécurité informatique en général.

M. OLE SO’ONO Georges Léa Page 1

 SECURITE DES RESEAUX ET DES COMMUNICATIONS

Le CERT peut être une équipe interne au sein de l'entreprise ou une équipe externe
(prestataire) dont l'entreprise peut faire appel pour ses services (offres de veille, réponse à
incidents, forensics, etc.).

Des plateformes existent et permettent aux différentes équipes CERT d'échanger leurs
expériences, de partager de l'information et des bonnes pratiques (exemple de plateforme ou
organisme: TF-CSIRT, FIRST).

Le SOC (Security Operations Center):

Le SOC est considéré comme une tour de contrôle ou de supervision et

d'administration de la sécurité du parc informatique de l'entreprise. Sa responsabilité est
généralement partagée entre trois équipes: les analystes de sécurité, l'équipe SIEM et l'équipe
des outils de ticketing.

a. L'équipe SIEM:

Elle est composée de deux sous équipes : RUN et BUILD qui ont des rôles différents
dans le cycle de vie du système SIEM:

1. Responsabilités : L'équipe BUILD est responsable de la conception, de

l'installation, de la configuration initiale et de la personnalisation du SIEM, tandis que l'équipe
RUN est responsable de la gestion opérationnelle et de la maintenance continue du SIEM, y
compris la gestion des logs et leur intégration dans le SIEM pour une surveillance et une
analyse efficaces des événements de sécurité.

2. Phase de cycle de vie : L'équipe BUILD est impliquée dans la phase initiale de
mise en œuvre du SIEM, tandis que l'équipe RUN intervient après le déploiement du système
pour en assurer le bon fonctionnement et la gestion quotidienne.

3. Compétences requises : L'équipe BUILD doit posséder des compétences en

matière de conception, d'architecture système, d'intégration logicielle et de configuration. Elle
doit être capable de planifier et de mettre en place une infrastructure technologique répondant
aux besoins de l'entreprise. L'équipe RUN, quant à elle, a besoin de compétences en matière
de surveillance, de gestion des incidents, de maintenance et d'optimisation des systèmes. Elle
doit être capable de réagir rapidement aux événements de sécurité, de résoudre les problèmes
et d'assurer le bon fonctionnement du système.

M. OLE SO’ONO Georges Léa Page 2

 SECURITE DES RESEAUX ET DES COMMUNICATIONS

4. Objectifs : L'objectif principal de l'équipe BUILD est de mettre en place un

système fonctionnel qui réponde aux exigences de l'entreprise tout en respectant les normes
de sécurité et de conformité. L'objectif de l'équipe RUN est d'assurer le bon fonctionnement
du système en surveillant les événements, en gérant les incidents, en maintenant la conformité
et en optimisant les performances du système.

5. Implication : L'équipe BUILD est généralement impliquée dans les projets de

déploiement ou de mise à niveau du système et travaille en étroite collaboration avec l'équipe
de développement, les fournisseurs et les partenaires. L'équipe RUN fonctionne en continu,
surveillant et gérant le système au jour le jour.

6. Évolution des rôles : Une fois le système construit et déployé, l'équipe BUILD peut
passer à d'autres projets, tandis que l'équipe RUN continue à gérer et à maintenir le système à
long terme, en s'adaptant aux nouvelles menaces, aux changements technologiques et à
l'évolution des besoins de l'entreprise.

En résumé, l'équipe BUILD se concentre sur la conception et la mise en œuvre initiale

du système, tandis que l'équipe RUN est responsable de la gestion opérationnelle, de la
surveillance, de la maintenance et de l'optimisation du système après son déploiement.

b. L'équipe analystes sécurité:

Le rôle de l'équipe d'analystes en cybersécurité est crucial pour protéger les systèmes,
les réseaux et les données d'une organisation contre les cybermenaces et pour garantir la
posture de sécurité globale. Les analystes sécurité sont chargés non seulement de surveiller et
de détecter les incidents de sécurité, mais aussi de les traiter et d'y répondre correctement et
efficacement. Ils sont chargés de détecter les anomalies et les violations et de définir les
réponses appropriées aux alertes.

Les analystes utilisent le SIEM pour collecter, corréler et analyser les journaux
d'événements (logs) de sécurité provenant de différentes sources. En fonction des besoins de
l'entreprise, ils peuvent être répartis en trois niveaux : N1, N2 et N3. Voici un exemple des
tâches assignées à chaque équipe d'analystes de sécurité :

M. OLE SO’ONO Georges Léa Page 3

 SECURITE DES RESEAUX ET DES COMMUNICATIONS

b. L'équipe des systèmes de ticketing:

Cette équipe n'est pas chargée de la sécurité de l'outil mais travaille en étroite
collaboration avec les analystes afin de leur facilité la création et le traitement des incidents de
sécurité. Ils sont donc responsables de l'outil permettant la gestion et le traçage des incidents.

Le SOC et le CERT travaillent et communiquent ensemble. En résumé, le SOC peut

être considéré comme la tour de contrôle de la sécurité informatique de l’entreprise et le
CERT son allié pour prendre en charge et traiter les menaces avérées. II. Les outils de gestion
et de traitement des incidents de sécurité en entreprise

Nous avons vu dans les cours précédents les différents outils ou solutions utilisé(e)s en
entreprise pour la prévention des menaces de sécurité et la protection contre les attaques.
Nous avons également vu comment on peut filtrer des adresses IPs niveau FW et des
signatures niveau IPS. Ci-après un exemple d'outils permettant la détection des menaces:

M. OLE SO’ONO Georges Léa Page 4

 SECURITE DES RESEAUX ET DES COMMUNICATIONS

Dans cette partie nous allons voir les outils permettant le déclenchement des alertes , la
gestion, la réaction et le traitement des incidents de sécurité. Mais avant d'aller plus loin, il
faut tout d'abord comprendre une notion importante : les logs.

Définition de log: les logs (journalisation en français) sont des enregistrements de

toutes actions faites dans un système informatique (ordinateur, serveur, routeur, FW, AV,
IPS/IDS, proxy, etc.) y compris les événements (exemple: login, connexions vers un site
externe, suppression d'un fichier, branchement clé USB, etc.). Le log fournit une trace
historique des activités qui peut être utilisée pour comprendre le comportement du système,
suivre les actions des utilisateurs, identifier les incidents de sécurité et enquêter sur les
violations potentielles. Toutes ces métadonnées sont enregistrées dans des fichiers appelés
"fichiers logs" et peuvent être transmises et centralisées dans l'outil SIEM.

Objectifs de la collecte de log: La collecte de logs permet aux équipes de sécurité de

surveiller ce qui se passe dans l'infrastructure informatique de l'entreprise et d'identifier les
anomalies et les risques du système. Ils servent à de multiples fins, notamment au
troubleshooting, à l'audit, à la conformité, à la réponse aux incidents et au forensic.

M. OLE SO’ONO Georges Léa Page 5

 SECURITE DES RESEAUX ET DES COMMUNICATIONS

Ça facilite également le travail des analystes en cybersécurité en centralisant tous les

logs dans un seul outil (SIEM), ce qui facilite l'investigation des événements en cas
d'incidents de sécurité. Par conséquent, une gestion et une analyse efficaces des logs est
importante pour une détection efficace des menaces. Outre, les organisations s'appuient sur les
logs pour maintenir un environnement informatique sûr et performant.

Anatomie d'un log: Un log contient au minimum les informations sur le temps dont
une action a été réalisée sur un système informatique appelé "Timestamp", les informations
sur l'utilisateur ou la machine (nom de l'utilisateur ou l'adresse IP de la machine) et l'action
entreprise par le système/utilisateur en question.

Tout dépend du système qui génère des logs, d'autres informations peuvent être
incluses dans le fichier log. Le proxy peut par exemple fournir d'autres logs comme: le site
web visité, le domaine du site web, le UserAgent, l'IP de destination, le port de destination,
l'action du proxy en question, etc. Exemple de log antivirus:

Types de logs (journaux): Chaque technologie génère un type de données différent et

chaque technologie collecte ces données dans son propre fichier logs (journal). Pour cette
raison, il existe de nombreux types de logs (journaux), notamment :

événements importants au sein d'un système, tels que le démarrage/l'arrêt du système, la

connexion/la déconnexion de l'utilisateur, les tentatives de connexion, les échecs de
connexion et les événements liés une application.

des
activités liées à un serveur spécifique au cours d'une période donnée.

M. OLE SO’ONO Georges Léa Page 6

 SECURITE DES RESEAUX ET DES COMMUNICATIONS

système d'exploitation. Il comprend les activités du système telles que les modifications du
système, les arrêts inattendus, les erreurs et les avertissements, ainsi que d'autres processus
importants. Windows, Linux et macOS génèrent tous des syslogs.

robots ayant accès à certaines applications ou à certains fichiers.

application ou à un fichier.

fonctionnement et la disponibilité du système.

connectivité et les limites de capacité.

incidents de sécurité. Ils comprennent les logs des pare-feu, IPS/IDS, AV et autres outils de
sécurité. Ces journaux permettent de détecter et d'enquêter sur les menaces et les violations
potentielles.

eau,
telles que le flux de trafic, les connexions et les erreurs. Ces logs peuvent aider à
troubleshooter les problèmes de réseau, à détecter les comportements suspects et à surveiller
l'utilisation de la bande passante.

Nous avons parlé d'une centralisation de logs sur un seul outil afin de faciliter
l'investigation des analystes, cet outil est le plus indispensable pour le traitement des
incidents, on parle de SIEM.

1. Le SIEM (Security information and event management):

Définition: Il s'agit d'une plateforme utilisée pour centraliser les journaux (logs) et
générer des alertes. Elle recueille, analyse et met en corrélation les données relatives aux
événements de sécurité provenant de diverses sources au sein d'un environnement
informatique afin de fournir aux organisations une vue centralisée de leur situation en matière
de sécurité. Le SIEM est la plateforme qui génère le plus d'alertes.

M. OLE SO’ONO Georges Léa Page 7

 SECURITE DES RESEAUX ET DES COMMUNICATIONS

Les composants SIEM les plus importants pour la gestion des logs:

a) La phase de collecte des logs: dans cette phase nous devons mettre en place une
infrastructure capable de collecter les différentes technologies générant des logs. Nous
pouvons les collecter à partir des AVs, FWs, SEs, équipements réseau, IPS/IDS, etc. à partir
de n'importe quel système générant des logs (ou événements) en centralisant les différents
systèmes dans le SIEM. C'est dans cette phase que nous effectuons la normalisation, la
standardisation, l'agrégation, le filtrage, et parfois même la compression.

b) Après cette phase vient la phase du "correlation engine" où on définit les UsesCase
selon les besoins de l'entreprise. Par exemple ce qu'elle veut couvrir comme risque qui n'a pas
encore été pris en compte. Nous définissons donc une ou plusieurs UsesCases pour ne plus
être aveugle à un risque bien défini. Nous procédons également aux Tuning des règles de
sécurité au cours de cette phase pour éviter les incidents de type FP (faux positif) ou flood.

c) La phase de stockage ou d'archivage et la réponse aux incidents: lors de la phase de

collecte, nous allons évidemment filtrer nos recherches. Cependant, même avec ce filtrage,
nous allons chercher dans une base de données avec des milliers voire des millions de logs.
Cela a poussé la plupart des entreprises à diviser les logs, par exemple, en stockant les logs de
3 à 6 mois dans un serveur, et les logs d'un an dans un autre serveur appelé "Archiver". La
réponse aux incidents provient lorsque l'environnement avec ses UseCases est assez mature et
fonctionnelle de façon correcte et efficace.

Les principales fonctionnalités de la phase de collecte:

a) La normalisation et le parsing : La normalisation est le processus qui consiste à

obtenir, par exemple, l'IP source, le nom d'hôte, l'heure de la connexion, etc. à partir des
événements bruts, et le parsing est le processus qui consiste à faire correspondre les logs à des
règles pour déterminer quelles chaînes de texte doivent être mappées à des champs de base de
données.

b) le filtrage des événements pour choisir uniquement les événements qui nous
intéressent au niveau la technologie générant les logs et de transférer cet événement au SIEM.
Sans filtrage, nous collectons tous les logs, même ceux qui ne doivent pas être utilisés, ce qui

M. OLE SO’ONO Georges Léa Page 8

 SECURITE DES RESEAUX ET DES COMMUNICATIONS

sera problématique. Il est important d'avoir cette fonctionnalité combinée avec la

fonctionnalité d'agrégation pour améliorer les performances de notre SIEM et la phase de
collecte des données.

c) La mise en cache : lorsque la connectivité entre le collecteur du SIEM et la

destination échoue pour une raison quelconque, ou si nous procédons à plus d'événements en
entrée et qui ne peuvent être délivrés en sortie, le collecteur du SIEM pousse les logs dans le
cache et reprend le transfert de ces logs lorsque la connexion est établie (nous devons assurer
un espace suffisant au niveau du cache).

d) L'agrégation : la fonctionnalité principale ici est quand nous avons les mêmes
événements qui se répètent et qui arrivent dans une fenêtre de temps spécifique. Au lieu
d'envoyer le même événement plusieurs fois, nous allons envoyer une seule fois l'événement
avec le nombre d'occurrence de ce dernier, ce qui permettra de réduire la taille de stockage et
l'utilisation de la bande passante.

e) Compression et cryptage : Les deux fonctionnalités sont nécessaires pour

compresser les logs et les crypter entre la source et la destination pour éviter d'envoyer les
logs en clair car les logs contiennent des informations sensibles et il est important de crypter
les trafics.

f) Contexte du client : il est important de connaître le scope de la collecte, ce que le

client souhaite collecter, s'il y a une qualification de la criticité des machines. En général,
nous devons nous assurer que dans un premier temps, les règles de sécurité des appareils les
plus critiques sont intégrée dans le SIEM (ce que nous appelons la priorisation). Nous devons
établir des priorités et voir quels dispositifs sont critiques, tels que : les FW, IPS, AV, les
systèmes d'authentification, les logs AD, les logs VPN, les Proxy, etc. Nous collectons par la
suite les logs selon cette priorisation car si nous collectons tous les logs en une seule fois,
nous aurons des problèmes vu la taille gigantesque des logs. Autres informations à savoir du
client : Nous devons savoir comment le réseau est construit, où sont hébergées les données, si
le client a d'autres applications que nous devons prendre en compte comme la gestion des
vulnérabilités. Avec qui communiquer si nécessaire ?

Exemples de SIEM: QRadar, Splunk, Exabeam, Sentinel, Arcsight, Netwitness, etc.

Les logs centralisés dans le SIEM peuvent constituer la première ligne de défense pour
déterminer la portée d'une attaque ou identifier une anomalie.

M. OLE SO’ONO Georges Léa Page 9

 SECURITE DES RESEAUX ET DES COMMUNICATIONS

2. Les systèmes de ticketing:

Cet outil est utilisé non seulement par les analystes sécurité et le CERT mais aussi par
le support IT. Dans cette partie du cours nous allons nous concentrer sur son utilisation pour
la réponse aux incidents de sécurité de façon générale.

Un système de ticketing est un logiciel d'assistance (ou une interface) utilisé pour créer
des incidents de sécurité, les traiter, les gérer et suivre leur résolution de bout en bout de
manière efficace. Cela permet de s'assurer que les incidents sont correctement traités et que
rien ne passe à travers les mailles du filet.

Il est également utilisé par les analystes de la sécurité non seulement pour
communiquer entre eux en laissant des notes, des commentaires et des mises à jour dans le
ticket, ce qui permet le partage des connaissances, mais aussi pour communiquer avec les
utilisateurs impliqués dans l'incident de sécurité (l'utilisateur pour lequel l'alerte a été
déclenchée). Cela permet de garantir la traçabilité de toutes les communications et de la
résolution de l'incident.

Un incident de sécurité interne est une information strictement confidentielle qui ne

doit jamais être rendue publique. Un outil de ticketing avec ses classifications pourrait
garantir la confidentialité des incidents de sécurité.

En centralisant tous les incidents dans un seul outil, les analystes de sécurité peuvent
gagner du temps, avoir une visibilité sur ce qui se passe dans l'entreprise et fournir des
indicateurs de sécurité de manière efficace et correcte.

L'équipe de ticketing peut personnaliser l'interface de l'outil en fonction des besoins

des analystes de sécurité, avec la validation du client final. De cette manière, ils peuvent créer
des tableaux de bord avec une priorisation des incidents à traiter, le nombre d'incidents traités
par analyste, le nombre d'incidents traités par jour par le SOC, les règles de sécurité qui se
déclenchent le plus, permettant aux analystes d'enquêter sur les causes, les vulnérabilités et de
mettre en œuvre des solutions.

Exemples des outils de ticketing: Archer, ServiceNow, Resilient, Jira, etc.

3. Le SOAR (security orchestration automation and response)

M. OLE SO’ONO Georges Léa Page 10

 SECURITE DES RESEAUX ET DES COMMUNICATIONS

Le SOAR est un "add-on" qui peut être ajouté au SIEM, qui va répondre aux besoins
les plus classiques du SOC et qui va vous permettre d’automatiser l’investigation et la
réaction sans assistance humaine.

On prend un exemple parmi les cas les plus basique qui est le cas des mails de
phishing. Ces derniers sont généralement traités manuellement. Où l'analyste passait
beaucoup de temps à analyser l’adresse source de ce mail, chaque lien, chaque pdf, les liens
cachés dans un pdf où derrière une image. Ensuite l'analyste devrait regrouper toutes ces
informations et essaie de formuler une réponse unique pour chaque utilisateur.

Le but avec une solution SOAR c’est d’automatiser toutes ces étapes, avec la
possibilité de faire des actions à distance sur ces mails de phishing. Par exemple: supprimer
tous les mails avec une pièce jointe malicieuse attachée reçus dans le parc informatique de
l'entreprise, interdire l’accès au site malveillant reçu par mail et éventuellement supprimer un
fichier malveillant présent dans toutes les stations de travail. Toutes ces actions peuvent être
effectuées à l’aide de la conception de playbook, et bien sûr avec l’accord en amont du client
final.

Donc pour l'exemple de mails de phishing on est non seulement sur l’automatisation
de la réponse mais aussi sur l’automatisation de l'investigation. Cette investigation est définit
par les analystes sécurité en mettant en place des Playbook.

Définition d'un Playbook:

Un playbook est l'ensemble de processus par lesquels un incident douteux doit passer
pour confirmer sa légitimité ou pas. Il définit les étapes à suivre depuis la réception de
l'incident jusqu'à son traitement.

Mettre en place des playbook est un projet qui prend du temps. Avant de mettre en
place une solution SOAR il faut d’abord commencer par la détection car sans cette dernière ça
sert à rien d'avoir la partie réponse. Néanmoins, une solution SOAR vient souvent avec des
playbooks de base mais qui nécessite une personnalisation pour être efficace. Pour le
playbook de phishing par exemple ou pour les actions les plus basique comme bloquer un port
ou autre ça ne va pas prendre beaucoup de temps, par contre pour d’autres actions ça peut
prendre quelques jours (ça peut aller de quelques heures à quelques jours). Mais avant tout il
faut vraiment avoir une bonne maturité côté détection avant de se lancer dans un projet de
playbook. Exemples de solutions SOAR: Exabeam, Cortex, Phantom, Resilient, etc.

M. OLE SO’ONO Georges Léa Page 11

 SECURITE DES RESEAUX ET DES COMMUNICATIONS

III. Création des alertes de sécurité niveau SIEM (UCs):

Avant la création des Usecases, les analystes sécurité ainsi que l'équipe intégration
(l'équipe RUN de l'outil SIEM) doivent mettre en place une réunion avec le métier demandant
la création des usecases.

Durant cette réunion, ils discutent de la faisabilité et des besoins du métier. Une fois
cette étape faite, l'équipe intégration se charge de récupérer les logs de la technologie en
question et de mettre en place la usecase. Cette dernière doit être implémentée sur la pré-
production du SIEM pendant environ 15 jours afin d'éviter les faux positifs et les bruits.

Pendant ces 15 jours c'est un analyste de sécurité qui suit et surveille les
déclenchements éventuels de la usecase et le bon fonctionnement de cette dernière. Une fois
les 15 jours passés et que la usecase est correctement opérationnelle, l'équipe intégration passe
la usecase en production sur le SIEM.

La création de Usecases sur le SIEM permet de détecter et d'identifier le plus en amont

possible une tentative d’attaque, une exfiltration de données, un comportement anormal sur le
réseau, sur une machine utilisateur, sur un serveur, etc. Ensuite, répondre en étant préparé à
réagir en cas d’incident de sécurité (attaque virale, DDoS, phishing, etc.) à travers un
processus de gestion et de réponse à incident prédéfini.

Exemple de règle (Usecase) sur le SIEM QRadar:

Une fois les conditions de la règle sont atteintes, une alerte se déclenche sur le SIEM
et l'analyste de sécurité devrait investiguer et traiter l'incident de sécurité.

IV. Le traitement des incidents de sécurité par les analystes en entreprise

Après avoir vu comment les analystes de sécurité peuvent créer les usescases sur le
SIEM et le passage en production, dans cette partie du cours nous allons voir comment les
analystes les traitent de bout en bout.

M. OLE SO’ONO Georges Léa Page 12