C'est quoi un SIEM

Page concept

Cette page explique les grands principes du SIEM — de quoi parler avant d’écrire une règle ou de comparer deux outils. La mise en œuvre pas à pas commence avec l’introduction de l’Acte 2. Les ressources en fin de page sont votre point de départ pour aller plus loin par vous-même.

Le concept en une phrase

Un SIEM n’est pas un produit qu’on achète mais ce qu’on fait de ses logs — collecter large, corréler, détecter, alerter, enquêter.

Une base australe a déjà instrumenté ses systèmes pour l’observabilité : elle voit ses métriques, ses logs, ses traces. Le SIEM (Security Information and Event Management) pose une question différente sur ces mêmes données : non plus « est-ce que ça marche ? » mais « qui me veut du mal ? ». Rien n’oblige à racheter une plateforme dédiée pour se poser cette question — c’est un choix, pas une fatalité.

---

Les grands principes

1. De l’observabilité à la détection — mêmes logs, autre question

L’Acte 1 a construit la vue : Alloy collecte, Loki stocke, Grafana affiche. Ces logs contiennent déjà tout ce qu’il faut pour détecter une intrusion — une connexion depuis une IP inhabituelle, un compte de service qui lit un fichier qu’il ne lit jamais, une requête SQL hors norme. Rien de nouveau à instrumenter : on change la lentille, pas l’infrastructure.

flowchart LR
    L[Logs collectés\nAlloy → Loki] -->|"Ça va bien ?"| O[Observabilité\nActe 1]
    L -->|"Qui me veut du mal ?"| D[Détection\nActe 2]

C’est le même flux de données qui sert les deux questions — voir Observabilité, les trois piliers pour la fondation.

2. Les 4 fonctions d’un SIEM

Peu importe l’outil, un SIEM fait toujours quatre choses :

1. Collecte — rapatrier les logs de toutes les sources (systèmes, réseau, applicatif).
2. Normalisation — ramener des formats hétérogènes à une structure exploitable (champs, horodatage cohérent).
3. Détection / corrélation — appliquer des règles pour repérer un événement suspect, seul ou en chaîne avec d’autres.
4. Alerting — notifier un humain quand une règle matche, avec assez de contexte pour agir.

Un outil qui ne fait que l’une de ces quatre choses n’est pas un SIEM — c’est un maillon.

3. SIEM-pratique vs SIEM-produit — un choix pédagogique assumé

• Le SIEM-produit — une plateforme qui fait les quatre fonctions pour vous, dans une interface propriétaire. Rapide à démarrer, mais on clique dans une UI sans toujours comprendre ce qui se passe derrière.
• Le SIEM-pratique — les quatre fonctions assemblées à la main, avec les briques de l’Acte 1. C’est le choix de TAAF : SOC Grafana-natif — Sigma pour écrire les règles, LogQL pour les exécuter dans Loki, Grafana Alerting pour notifier.

TAAF met le SOC Grafana-natif au centre du tronc commun : vous comprenez chaque brique parce que vous l’avez posée vous-même. Wazuh, lui, est traité comme un bonus clé-en-main — utile pour voir à quoi ressemble un SIEM-produit, jamais présenté comme « le » SIEM de la formation.

4. Le SOC, ce sont des humains derrière l’outil

Aucune règle ne clôt un incident toute seule. Une alerte qui tombe doit être triée (vrai signal ou bruit ?), enquêtée (que s’est-il passé, sur quel périmètre ?), puis escaladée si nécessaire. Le SIEM produit la matière première ; le SOC — les analystes — transforme cette matière en décision. Un outil sans équipe qui le regarde n’est qu’un entrepôt de logs qui clignote dans le vide.

5. Faux positifs, faux négatifs — le compromis permanent

Une règle trop large alerte sur tout, y compris du trafic légitime (faux positif) — à force, l’équipe ignore les alertes (alert fatigue). Une règle trop stricte rate l’attaque qui varie légèrement du motif prévu (faux négatif) — le pire des deux cas, une intrusion invisible. Écrire une détection, c’est choisir un point sur cette balance, et l’ajuster avec le temps : voir Détection-as-code — Sigma pour le cycle de vie d’une règle.

---

Où ça sert dans TAAF

• Introduction de l’Acte 2 — SIEM — le module qui pose le SOC Grafana-natif par-dessus la stack de l’Acte 1.
• TP Bonus — Wazuh, SIEM clé-en-main — la comparaison SOC Grafana-natif vs Wazuh est le TP : un même incident vu par les deux approches.
• Le fil rouge — l’incident rejoué au jour J (phishing julie.moreau → accès svc_backup → exfiltration de genetic_samples) est le cas d’usage qui traverse tout l’Acte 2.

---

Ressources associées

Ces liens sont des points de départ pour vos propres recherches — voir la bibliothèque complète sur la page Ressources, section Détection & SIEM.

À chercher par vous-même : « what is a SIEM », « SIEM vs log management », « alert fatigue SOC », « detection engineering lifecycle ».