Un SIEM ne devient pas utile parce qu’il collecte beaucoup de logs. Il devient utile lorsqu’il transforme des événements dispersés en informations fiables, en détections compréhensibles et en actions rapides. Elastic Security associe la puissance de recherche d’Elasticsearch, les visualisations de Kibana et des fonctions de sécurité conçues pour centraliser, analyser et corréler les données d’un système d’information.
Ce guide explique comment concevoir un SIEM Elastic réellement exploitable : quelles données collecter, comment les normaliser avec ECS, comment construire les détections, maîtriser la rétention et éviter les erreurs qui transforment trop souvent un projet SIEM en coûteux entrepôt de journaux.
Qu’est-ce qu’un SIEM Elastic ?
Un SIEM, ou Security Information and Event Management, centralise les événements de sécurité, facilite leur recherche, applique des règles de détection et aide les analystes à investiguer les alertes. Elastic Security ajoute ces usages de sécurité à la plateforme Elastic. Il ne faut donc pas réduire la solution à « Elasticsearch avec des logs » : l’objectif est de construire une chaîne complète allant de la collecte à la réponse.
Les composants essentiels
- Elasticsearch indexe, recherche, agrège et corrèle les événements.
- Kibana fournit les interfaces de recherche, tableaux de bord, alertes et investigations.
- Elastic Security apporte les règles de détection, alertes, timelines, cas et fonctions SOC.
- Elastic Agent et Fleet centralisent le déploiement des agents et des intégrations.
- Elastic Defend ajoute les fonctions de protection et de télémétrie endpoint.
- Logstash reste utile pour certains flux complexes, transformations ou architectures intermédiaires.
Elastic propose des déploiements gérés, Serverless et auto-hébergés. Le bon choix dépend des exigences de souveraineté, des compétences internes, du volume, de la disponibilité attendue et du modèle de coûts. La documentation officielle de démarrage Elastic Security détaille les options disponibles et les méthodes d’ingestion prises en charge.
À quoi sert concrètement le SIEM ?
Un SIEM Elastic bien conçu doit répondre à des questions opérationnelles :
- Quel compte vient de se connecter depuis un pays inhabituel ?
- Un poste exécute-t-il un processus rare après l’ouverture d’un document ?
- Plusieurs échecs d’authentification précèdent-ils une connexion réussie ?
- Un serveur communique-t-il avec une adresse associée à une menace connue ?
- Un administrateur modifie-t-il des contrôles de sécurité sans changement planifié ?
- Les sources indispensables à une investigation envoient-elles toujours leurs données ?
Architecture d’un SIEM Elastic
Une architecture logique peut se résumer en sept étapes :
- Produire les événements sur les postes, serveurs, équipements réseau, identités et services cloud.
- Collecter les données via Elastic Agent, une intégration, Syslog, API, Beats ou Logstash.
- Filtrer et enrichir les événements avec des pipelines d’ingestion.
- Normaliser les champs selon Elastic Common Schema.
- Stocker les événements dans des data streams adaptés.
- Détecter les comportements suspects avec des règles et modèles.
- Investiguer et répondre en documentant les décisions et les actions.
Cloud, Serverless ou auto-hébergé ?
Une offre gérée réduit la charge liée aux mises à jour, à la disponibilité et à l’exploitation du cluster. Un déploiement auto-hébergé donne davantage de contrôle mais exige des compétences Elasticsearch, des procédures de sauvegarde, une supervision dédiée et une gestion rigoureuse des montées de version. Serverless simplifie encore l’infrastructure, mais certaines fonctions de cycle de vie et de dimensionnement diffèrent d’un Elastic Stack versionné. Le choix doit être réalisé avant la collecte massive de données.
Sécuriser le SIEM lui-même
Le SIEM contient des informations très sensibles. Il doit donc être traité comme un actif critique :
- chiffrement TLS des communications ;
- authentification forte et rôles séparés pour l’administration, l’analyse et la lecture ;
- clés API limitées pour les agents et intégrations ;
- journalisation des actions administratives ;
- sauvegardes testées et dépôts de snapshots protégés ;
- segmentation réseau et limitation des interfaces exposées.
Quelles sources de logs collecter en priorité ?
La bonne question n’est pas « pouvons-nous collecter cette source ? », mais « quelle détection ou investigation rend-elle possible ? ». Une collecte progressive donne généralement de meilleurs résultats qu’un branchement simultané de toutes les sources.
Priorité 1 : identité et authentification
- Active Directory et contrôleurs de domaine ;
- Microsoft Entra ID ou autre fournisseur d’identité ;
- VPN, MFA, SSO et accès privilégiés ;
- création de comptes, changements de groupes et réinitialisations de mots de passe.
L’identité est au centre de nombreux scénarios : brute force, password spraying, vol de session, élévation de privilèges ou persistance par création de compte.
Priorité 2 : endpoints et serveurs
- télémétrie EDR et événements Elastic Defend ;
- journaux Windows, PowerShell, Sysmon et Linux auditd ;
- processus, services, tâches planifiées et modifications de registre ;
- événements liés aux fichiers sensibles et aux outils d’administration.
Priorité 3 : réseau, DNS et accès Internet
- pare-feu, IDS/IPS, WAF et concentrateurs VPN ;
- DNS, proxy web et passerelles de messagerie ;
- NetFlow ou autres métadonnées réseau lorsque leur usage est défini ;
- journaux des équipements d’administration et bastions.
Priorité 4 : cloud, SaaS et applications critiques
- journaux d’audit AWS, Azure et Google Cloud ;
- Microsoft 365, outils collaboratifs et services de partage ;
- applications métiers manipulant des données sensibles ;
- scanners de vulnérabilités et plateformes de threat intelligence.
Une matrice « source → cas d’usage → règle → responsable » aide à justifier chaque flux. Elle révèle aussi les angles morts. Pour découvrir mon expérience sur ces technologies, consultez la page Compétences en analyse de logs et EDR.
Ingestion et normalisation avec Elastic Common Schema
Elastic Agent et Fleet
Elastic Agent permet de collecter plusieurs types de télémétrie avec un agent unifié. Fleet centralise les politiques, intégrations et statuts. Les intégrations fournissent généralement des pipelines, mappings, data streams et tableaux de bord prêts à l’emploi. Elles accélèrent le démarrage, mais doivent être testées sur les formats et versions réellement présents dans l’environnement.
Quand utiliser Logstash ?
Logstash garde sa pertinence lorsqu’il faut :
- recevoir des flux depuis plusieurs protocoles ou files de messages ;
- réaliser des transformations complexes ;
- mettre en place du buffering entre producteurs et Elasticsearch ;
- dupliquer ou router les événements vers plusieurs destinations ;
- intégrer une source ancienne sans intégration Elastic adaptée.
Chaque composant supplémentaire augmente toutefois la surface opérationnelle. Une pipeline d’ingestion simple, observable et versionnée est souvent préférable à une chaîne très sophistiquée.
Pourquoi ECS est déterminant
Elastic Common Schema définit des noms et types de champs communs pour des données hétérogènes. Un même concept doit conserver le même champ, quelle que soit la source : utilisateur, adresse IP, processus, résultat d’authentification ou catégorie d’événement. Cette normalisation permet de réutiliser les requêtes, tableaux de bord et règles de détection.
Par exemple, une règle utilisant source.ip, user.name et
event.outcome peut fonctionner sur plusieurs technologies si leurs pipelines respectent ECS.
La référence officielle ECS
décrit les champs, types et conventions à utiliser.
Contrôler la qualité des données
Pour chaque intégration, vérifiez :
- la cohérence des horodatages et du fuseau horaire ;
- l’absence de conflits de mappings ;
- le taux d’événements rejetés ou placés dans un failure store ;
- la présence des champs ECS nécessaires aux règles ;
- la stabilité du volume et la détection des sources silencieuses ;
- la suppression ou le masquage des données qui ne doivent pas être centralisées.
Créer des règles de détection efficaces
Activer toutes les règles préconstruites sans préparation produit souvent un volume d’alertes difficile à absorber. Commencez par les techniques pertinentes pour l’environnement, vérifiez les données requises, puis adaptez les exceptions et seuils.
Les principaux types de règles Elastic Security
- Custom query avec KQL ou Lucene pour rechercher des motifs connus.
- Threshold lorsqu’un volume d’événements dépasse un seuil.
- Event correlation avec EQL pour une séquence d’événements dans le temps.
- ES|QL pour filtrer, transformer et agréger les données avant de produire les alertes.
- New terms pour détecter une valeur ou combinaison jamais observée dans la période de référence.
- Indicator match pour comparer la télémétrie à des indicateurs de menace.
- Machine learning pour certains écarts comportementaux difficiles à exprimer par un motif fixe.
Elastic publie un guide officiel pour choisir le type de règle selon le comportement recherché.
Exemple simplifié avec ES|QL
FROM logs-*
| WHERE event.category == "authentication" AND event.outcome == "failure"
| STATS attempts = COUNT(*) BY source.ip, user.name
| WHERE attempts >= 10Cette requête illustre une agrégation d’échecs d’authentification. En production, il faut limiter les data streams, définir une fenêtre temporelle, prendre en compte les systèmes légitimes et documenter la réponse attendue. Une règle sans procédure de triage ne constitue pas une détection opérationnelle.
Documenter chaque détection
Une règle mature devrait contenir :
- le scénario de menace et sa couverture MITRE ATT&CK ;
- les sources et champs indispensables ;
- la logique, les seuils et les exceptions ;
- les faux positifs connus ;
- les étapes de validation et d’investigation ;
- le responsable et la fréquence de révision ;
- des tests reproductibles permettant de confirmer son fonctionnement.
Investigation et réponse aux incidents
Une alerte doit permettre à l’analyste de répondre rapidement à quatre questions : que s’est-il passé, quels actifs sont concernés, quel est l’impact potentiel et quelle action faut-il engager ? Les fonctions de timeline, de recherche, de cas et de visualisation facilitent la corrélation des événements.
Contexte à enrichir
- criticité de l’actif et propriétaire métier ;
- identité, rôle et privilèges de l’utilisateur ;
- vulnérabilités présentes sur l’hôte ;
- réputation des adresses, domaines ou fichiers ;
- changements planifiés et fenêtres de maintenance ;
- alertes liées sur le même utilisateur, poste ou segment réseau.
Le SIEM doit aussi s’intégrer aux procédures de réponse : ticketing, notification, isolation d’un endpoint, blocage d’un indicateur ou collecte forensique. L’automatisation doit rester proportionnée à la confiance dans la détection. Une règle peu maîtrisée ne devrait pas déclencher une action destructive automatique.
Rétention, stockage et maîtrise des coûts
Le coût d’un SIEM dépend surtout du volume ingéré, de la durée de conservation, du niveau de réplication, des performances attendues et de la quantité de données réellement consultées. Avant le déploiement, mesurez le débit de chaque source pendant une période représentative.
Estimer le volume
Une première approximation peut utiliser la formule suivante :
volume quotidien ≈ événements par seconde × taille moyenne × 86 400Ajoutez ensuite la rétention, les réplicas, les snapshots et une marge de croissance. La compression et les mappings influencent la taille finale : une mesure sur des données réelles reste plus fiable qu’un ratio générique.
Data streams et cycle de vie
Les data streams sont adaptés aux journaux continus et séparent les données par type, dataset et namespace. Ils facilitent le rollover, les politiques de rétention et les permissions. Dans un Elastic Stack versionné, ILM peut déplacer les données entre les phases hot, warm, cold ou frozen, puis les supprimer. En Serverless, le mécanisme de data stream lifecycle remplit le rôle de gestion de la rétention.
La documentation ILM officielle explique les différences et les actions disponibles.
Réduire les coûts sans perdre la capacité d’enquête
- supprimer les événements sans valeur de sécurité démontrée ;
- filtrer les champs volumineux inutiles avant indexation ;
- adapter la rétention à la source et aux obligations ;
- conserver plus longtemps les données rares et critiques que les événements très répétitifs ;
- utiliser les tiers de données et snapshots lorsque l’architecture le permet ;
- surveiller les shards, mappings et pipelines pour éviter les dérives.
Comment déployer un SIEM Elastic par étapes ?
Phase 1 : cadrer les objectifs
- identifier les risques et actifs critiques ;
- définir dix à vingt cas d’usage prioritaires ;
- inventorier les sources nécessaires ;
- choisir le modèle de déploiement et la rétention initiale ;
- définir les rôles de l’équipe et le processus de traitement.
Phase 2 : réaliser un pilote
Connectez un périmètre représentatif : identité, quelques endpoints, pare-feu, DNS et un service cloud. Validez les pipelines ECS, mesurez le volume, activez un nombre limité de règles et simulez des scénarios. Le pilote doit prouver la valeur opérationnelle, pas uniquement le bon fonctionnement technique.
Phase 3 : industrialiser
- versionner les politiques, pipelines, règles et exceptions ;
- automatiser le déploiement des agents ;
- créer des tableaux de bord sur la santé de l’ingestion ;
- définir les sauvegardes, montées de version et tests de restauration ;
- former les analystes et responsables des sources.
Phase 4 : améliorer en continu
Révisez les règles après chaque incident, changement majeur ou apparition d’une nouvelle source. Mesurez la qualité des alertes et supprimez les détections qui ne débouchent jamais sur une décision utile. Un SIEM est un produit vivant, pas un projet terminé après la mise en production.
Les erreurs fréquentes d’un projet SIEM Elastic
Collecter tout, immédiatement
Cette approche augmente les coûts et le bruit avant même d’avoir défini les cas d’usage.
Négliger ECS et la qualité des pipelines
Des champs incohérents rendent les règles fragiles et les recherches difficiles à réutiliser.
Activer toutes les règles préconstruites
Les règles doivent correspondre aux technologies présentes et être réglées selon le contexte local.
Ignorer la santé de la collecte
Une absence d’alerte ne signifie rien si les journaux nécessaires ont cessé d’arriver.
Confondre conformité et détection
Conserver des logs pendant une durée imposée ne garantit ni leur qualité ni leur exploitation.
Oublier les procédures humaines
Sans propriétaire, délai de traitement et guide d’investigation, une alerte reste une simple notification.
Quels indicateurs suivre ?
- pourcentage des actifs critiques couverts par des sources fiables ;
- taux de sources silencieuses ou pipelines en erreur ;
- volume quotidien par dataset et évolution des coûts ;
- taux d’alertes clôturées comme faux positifs ;
- délai moyen de détection et de qualification ;
- nombre de règles testées récemment ;
- couverture des scénarios prioritaires et techniques MITRE ATT&CK ;
- actions d’amélioration réalisées après les incidents.
Questions fréquentes sur le SIEM Elastic
Elastic SIEM est-il gratuit ?
Certaines fonctions sont accessibles selon la distribution et le niveau de licence, tandis que d’autres capacités de sécurité avancées dépendent de l’offre choisie. Il faut vérifier la matrice de fonctionnalités et intégrer les coûts d’infrastructure, d’exploitation et de traitement des alertes.
Elastic peut-il remplacer un autre SIEM ?
Oui dans de nombreux contextes, à condition de migrer les sources, normaliser les données, reconstruire ou adapter les règles et valider les processus d’investigation. Une migration ne doit pas être réduite à la traduction automatique des requêtes existantes.
Faut-il utiliser Elastic Agent ou Logstash ?
Elastic Agent et les intégrations constituent généralement le point de départ le plus simple. Logstash est pertinent pour les flux complexes, les transformations avancées ou certains besoins de buffering et de routage. Les deux approches peuvent coexister.
Combien de temps conserver les logs ?
Il n’existe pas une durée unique. Elle dépend des cas d’usage, du temps moyen avant découverte d’un incident, des obligations applicables, du volume et du budget. Définissez une rétention par dataset plutôt qu’une règle globale identique pour toutes les données.
Un SIEM suffit-il pour protéger une entreprise ?
Non. Le SIEM améliore la visibilité, la détection et l’investigation. Il complète la gestion des identités, l’EDR, la segmentation, les correctifs, les sauvegardes, la sensibilisation et les procédures de réponse.
Conclusion
La réussite d’un SIEM Elastic repose moins sur la quantité de données que sur la cohérence de la chaîne : sources utiles, normalisation ECS, règles testées, analystes formés, rétention maîtrisée et amélioration continue. Un déploiement progressif centré sur les risques produit plus rapidement de la valeur et limite le bruit.
Cybergium accompagne la collecte des logs, l’intégration d’Elastic, la conception des détections et l’amélioration opérationnelle du SIEM. Découvrez l’offre Detection & Protection ou contactez-moi pour discuter de votre environnement.
SIEM Elastic : guide complet pour centraliser les logs et détecter les cybermenaces