Un SIEM centralise, normalise, recherche et corrèle des événements de sécurité afin d’aider à détecter et investiguer des menaces. Il ne devient opérationnel que lorsque les sources sont fiables, les règles sont reliées à des scénarios et chaque alerte mène à une décision documentée.
année de la nouvelle référence NIST de réponse à incident
La SP 800-61 Rev. 3, publiée en avril 2025, intègre la réponse à incident dans l’ensemble de la gestion du risque CSF 2.0, au lieu de la traiter comme une phase isolée.
NIST — SP 800-61 Rev. 3Ce que fait un SIEM — et ce qu’il ne fait pas
Le SIEM rassemble les traces d’identité, endpoint, réseau, cloud et applications pour permettre une recherche et une corrélation communes. Il accélère une investigation lorsque l’analyste peut passer d’un signal à l’utilisateur, l’actif et l’historique associés.
Il ne crée pas de visibilité à partir de journaux absents et ne remplace ni l’EDR ni l’équipe de réponse. Une licence importante avec une collecte mal gouvernée produit surtout du coût et du bruit.
L’architecture minimale à décider
Cartographiez les producteurs, les collecteurs, le transport, la normalisation, le stockage chaud ou froid et les consommateurs. Pour chaque source, définissez propriétaire, fuseau horaire, rétention, champs critiques, contrôles d’accès et comportement en cas d’interruption.
Le modèle de données compte davantage que le nombre de connecteurs. Des identifiants stables pour utilisateurs, hôtes et applications permettent de relier les événements sans reconstruire chaque fois les correspondances.
Prioriser les cas d’usage
Commencez par les scénarios qui combinent impact, plausibilité et télémétrie disponible. Pour chacun, formulez le comportement, la logique, les exceptions, le triage, le propriétaire et la méthode de test. Une règle sans action suivante est une requête, pas un cas d’usage opérationnel.
- Scénario de menace et actif concerné
- Sources et champs obligatoires
- Logique et seuils
- Contexte fourni à l’analyste
- Action, escalade et test
Mesurer la qualité plutôt que le volume
Suivez la disponibilité des sources, la couverture testée, le délai de qualification, les faux positifs coûteux et les incidents détectés par d’autres canaux. Ces métriques montrent où la chaîne échoue.
Le nombre de règles et le nombre d’événements ingérés peuvent aider à piloter la capacité, mais ils ne démontrent pas que le SOC voit plus tôt ou décide mieux.
Matrice de décision opérationnelle
| Étape | Question à résoudre | Résultat attendu |
|---|---|---|
| Collecter | Choisir les sources selon les scénarios de menace. | Mesurer la couverture |
| Normaliser | Préserver temps, identité, actif et action. | Rendre les événements comparables |
| Détecter | Corréler un comportement avec son contexte. | Produire un signal qualifiable |
Critère d’architecture
Le volume ingéré n’est pas le résultat. La métrique utile est la capacité à prendre une décision fiable dans un délai adapté au risque.
Le bon niveau de contrôle dépend du contexte, des actifs exposés et de l’impact métier : documentez les hypothèses, mesurez le résultat et réévaluez après chaque changement significatif.
Questions fréquentes
Quelle différence entre SIEM et EDR ?
L’EDR observe et agit sur les endpoints ; le SIEM corrèle des sources multiples pour une vue transversale. Ils sont complémentaires.
Toutes les logs doivent-elles aller dans le SIEM ?
Non. La collecte doit répondre à des usages de détection, d’investigation, de conformité ou de conservation clairement définis.
Par où commencer un projet SIEM ?
Par les scénarios prioritaires, les sources indispensables et les décisions attendues, avant le catalogue de connecteurs.
Sources officielles
Achraf Hachimi
Ingénieur SOC Senior / CSIRT certifié CISSP, spécialisé en Incident Response, Threat Hunting et Detection Engineering. Huit ans d’expérience en environnements critiques avec Splunk ES, Microsoft Defender XDR, SentinelOne et Cybereason.