SIEM : définition, usages réels et limites en cybersécurité

Niveau : débutant. Il est utile de connaître la différence entre une adresse IP, un compte utilisateur, un serveur et une application. Une première familiarité avec les journaux système facilite la lecture, mais aucun produit SIEM particulier n'est requis.

L'objectif est de comprendre un mécanisme de défense, pas d'apprendre une interface commerciale. Les noms des menus, les langages de requête et les modèles de licence changent selon les solutions. Le raisonnement reste toutefois stable : savoir quelles traces existent, les transporter, les normaliser, les enrichir, puis décider ce qui mérite une enquête.

Le NIST définit un outil SIEM comme une application capable de rassembler les données de sécurité issues des composants d'un système d'information et de les présenter sous une forme exploitable dans une interface unique. Deux fonctions sont donc essentielles : regrouper les événements et les rendre exploitables.

Dans une organisation, les traces sont dispersées. Un contrôleur de domaine enregistre des authentifications. Un pare-feu observe des connexions réseau. Un service cloud conserve des actions d'administration. Un antivirus ou un EDR signale un comportement sur un poste. Une application web journalise des erreurs et des accès. Examiner chaque console séparément ralentit l'analyse et masque les relations entre événements.

Le SIEM offre donc plusieurs usages complémentaires :

1. Centraliser les journaux. Les agents, collecteurs ou API acheminent les événements vers une plateforme commune.
2. Conserver et rechercher. L'analyste peut retrouver les événements associés à un compte, une machine ou une période.
3. Normaliser. Des formats différents sont ramenés vers des champs comparables, par exemple source_ip, user, action ou timestamp.
4. Enrichir. La plateforme peut ajouter le rôle d'un actif, son propriétaire, sa criticité ou des informations de renseignement sur une adresse.
5. Corréler. Une règle relie plusieurs signaux faibles pour faire émerger une situation plus significative.
6. Alerter et documenter. Une alerte ou un dossier d'investigation est créé, priorisé puis confié à un analyste ou à l'équipe chargée de la réponse.
7. Produire des tableaux de bord. Les équipes suivent la couverture des sources, les volumes, les délais et les tendances.

Ces fonctions servent aussi aux recherches rétrospectives après incident, si les traces pertinentes ont été collectées et conservées.

Cette définition peut être vérifiée dans le glossaire SIEM du NIST. Le guide NIST SP 800-92 détaille les principes de gestion des journaux qui alimentent ces plateformes.

Imaginons trois événements concernant le même compte : cinq échecs de connexion, une réussite depuis une nouvelle adresse IP, puis l'ajout du compte à un groupe privilégié. Pris séparément, chacun peut avoir une explication légitime. Rapprochés dans une fenêtre de dix minutes, ils méritent une vérification.

1. Production et collecte

Le SIEM ne crée pas les événements à la place des systèmes sources. Il reçoit ce que les hôtes, applications et équipements savent journaliser. La première décision consiste donc à choisir les sources utiles et à activer une journalisation adaptée. Un événement absent à la source restera invisible en aval.

La collecte peut employer un agent installé sur l'hôte, un transfert standard comme syslog, un collecteur intermédiaire ou une API. Elle doit être surveillée : un connecteur silencieusement interrompu crée un angle mort.

2. Horodatage, analyse et normalisation

Le temps est essentiel pour reconstruire une séquence. Des horloges désynchronisées peuvent inverser l'ordre apparent des actions. Après réception, un parseur extrait les champs du message brut. La normalisation permet ensuite d'interroger ensemble des produits qui nomment différemment la même notion.

Le message original doit rester accessible. Un parseur peut remplir le mauvais champ ou perdre une information. La normalisation accélère la recherche sans remplacer la trace brute.

3. Enrichissement et corrélation

Une adresse IP seule dit peu de choses. Si l'inventaire indique qu'elle appartient à un serveur critique, l'événement prend un autre poids. De même, une connexion inhabituelle sur un compte de test n'a pas nécessairement la même priorité que sur un compte d'administration.

Une règle de corrélation peut exprimer : « plusieurs échecs, suivis d'une réussite, puis d'une action privilégiée pour le même utilisateur dans un intervalle court ». D'autres détections reposent sur une statistique, un écart à une base habituelle ou une règle prédéfinie par le fournisseur. Chacune repose sur une hypothèse que l'analyste doit vérifier.

4. Qualification humaine

L'alerte n'est pas un verdict. L'analyste contrôle l'identité, l'actif, la chronologie, les changements prévus et les autres traces disponibles. Il peut conclure à une activité légitime, demander des informations, ajuster la priorité ou déclencher une procédure de réponse. Une alerte bien conçue fournit assez de contexte pour rendre cette décision plus rapide et reproductible.

Les recommandations de la CISA sur la journalisation et la détection insistent sur la qualité, la centralisation et l’exploitation des événements, pas seulement sur leur collecte.

Un SIEM n'est pas un bouclier autonome. Plusieurs confusions sont fréquentes.

Il ne remplace pas les sources de télémétrie. Sans journal d'authentification, trace DNS, événement EDR ou audit cloud, la plateforme ne peut pas inventer la donnée manquante.

Il ne garantit pas une détection exhaustive. Une règle couvre un comportement défini. Un attaquant peut agir autrement, une règle peut être désactivée, ou un champ nécessaire peut ne pas être correctement extrait.

Il ne bloque pas nécessairement l'action. Le SIEM détecte et organise l'information. Le blocage relève souvent d'un pare-feu, d'un EDR, d'un fournisseur d'identité ou d'une automatisation explicitement autorisée. Une réponse automatique mal bornée peut d'ailleurs interrompre une activité légitime.

Il ne transforme pas une alerte en preuve certaine. Une corrélation indique qu'une hypothèse mérite examen. Elle peut produire de faux positifs. À l'inverse, une activité mal couverte peut ne déclencher aucune alerte, ce qui constitue un faux négatif.

Il ne résout pas seul la réponse à incident. Il peut soutenir la chronologie et le triage, mais les rôles, procédures, sauvegardes, communications et décisions doivent être préparés ailleurs.

La présentation de Microsoft Sentinel illustre les fonctions d’un produit concret, mais ne remplace pas la définition des besoins, des sources et des règles propres à l’organisation.

Cet exercice reste entièrement local et utilise des données inventées. Il ne cible aucun système tiers.

Crée un fichier events.jsonl contenant une ligne JSON par événement :

{"time":"2026-09-14T09:00:00Z","user":"lea","action":"login_failed","source_ip":"192.0.2.10"}
{"time":"2026-09-14T09:01:00Z","user":"lea","action":"login_failed","source_ip":"192.0.2.10"}
{"time":"2026-09-14T09:02:00Z","user":"lea","action":"login_failed","source_ip":"192.0.2.10"}
{"time":"2026-09-14T09:04:00Z","user":"lea","action":"login_success","source_ip":"192.0.2.10"}
{"time":"2026-09-14T09:07:00Z","user":"lea","action":"group_admin_added","source_ip":"192.0.2.10"}
{"time":"2026-09-14T09:15:00Z","user":"sam","action":"login_success","source_ip":"192.0.2.20"}

Les adresses du bloc 192.0.2.0/24 sont réservées à la documentation. Importe ce fichier dans un outil de journalisation de laboratoire, ou examine-le simplement avec un éditeur. Formule une règle en langage naturel : pour un même utilisateur et une même adresse, au moins trois échecs sont suivis d'une réussite puis d'un ajout au groupe administrateur en moins de dix minutes.

Rédige ensuite une fiche d'alerte avec : le compte concerné, le début et la fin de la séquence, les événements observés, l'hypothèse, deux vérifications à effectuer et une raison possible de faux positif. N'automatise aucun blocage dans cet exercice.

Critère de réussite

L'exercice est réussi si tu isoles la séquence de lea, restitues ses cinq événements dans l'ordre, expliques pourquoi l'événement de sam n'entre pas dans la corrélation et distingues clairement fait observé et hypothèse. Un bon résultat mentionne aussi que la règle ne prouve ni un vol de compte ni une compromission.

• Collecter tout sans objectif. Le volume augmente les coûts et le bruit. Commence par les scénarios de détection et les obligations de conservation.
• Confondre réception et couverture. Voir des événements arriver ne prouve pas que tous les types nécessaires sont présents.
• Ignorer la santé des collecteurs. Mesure les retards, ruptures et baisses anormales de volume.
• Créer une règle sans procédure. Une alerte doit préciser son propriétaire, sa priorité, les données de contexte et les premières vérifications.
• Copier des règles sans les adapter. Les comptes, actifs, horaires et pratiques normales diffèrent selon l'environnement.
• Négliger l'accès aux journaux. Les journaux peuvent contenir des données personnelles ou sensibles. Les droits, durées de conservation et consultations doivent être maîtrisés.
• Mesurer seulement le nombre d'alertes. Une file abondante peut signaler du bruit plutôt qu'une bonne détection. La qualité du triage et la couverture sont plus instructives.