Lors d’une intrusion, la première question que se pose l’équipe de réponse n’est presque jamais comment l’attaquant est entré, mais qu’a-t-il fait une fois à l’intérieur. Répondre exige des traces : des journaux d’authentification, des journaux réseau, des journaux applicatifs, horodatés et conservés. Quand ces traces n’existent pas, ou qu’elles dorment éparpillées sur des centaines de machines sans personne pour les regarder, l’attaque se déroule en silence et l’analyse après coup devient impossible. C’est précisément le vide que comble la journalisation centralisée, dont le SIEM est l’outil de référence.
Cet article décrit ce qu’est réellement un SIEM, ce qu’il faut lui donner pour qu’il serve à quelque chose, et la méthode pour construire une capacité de détection utile plutôt qu’un simple entrepôt de logs coûteux. Il s’appuie sur les ressources publiques de l’ANSSI, le référentiel d’attaques MITRE ATT&CK et le guide de gestion des journaux du NIST.
Pourquoi la journalisation est le socle de la détection
La sécurité défensive repose sur une chaîne simple : pour réagir à une attaque, il faut la détecter ; pour la détecter, il faut l’observer ; pour l’observer, il faut des journaux. Cette dépendance est si fondamentale qu’une organisation sans journalisation maîtrisée n’a, à proprement parler, aucune capacité de détection. Elle attend que le mal soit visible, c’est-à-dire que le rançongiciel chiffre les fichiers ou que les données apparaissent en vente, pour découvrir qu’elle a été compromise.
Le décalage entre l’intrusion et la découverte
Une caractéristique récurrente des compromissions est le délai entre l’accès initial et la détection. Un attaquant entre, élève ses privilèges, se déplace latéralement, exfiltre des données, et reste souvent des semaines avant de déclencher l’action visible. Pendant cette période, dite de présence silencieuse, seuls les journaux gardent la mémoire de ses actions. Si la rétention est trop courte ou la collecte inexistante, la fenêtre d’observation se referme avant même que l’on cherche à regarder.
Le problème de la dispersion
Chaque équipement produit des journaux dans son coin : le contrôleur de domaine, le pare-feu, le serveur web, la solution de messagerie, le poste de travail. Tant que ces journaux restent locaux, deux problèmes les rendent inexploitables. D’abord, personne ne les consulte au quotidien, faute de temps et de point d’accès unique. Ensuite, un attaquant qui prend le contrôle d’une machine efface les journaux locaux pour couvrir ses traces. La centralisation répond aux deux : elle rassemble les journaux en un point de visibilité unique et les met hors de portée d’un attaquant qui n’aurait compromis qu’une machine.
Détecter, mais aussi prouver
La journalisation ne sert pas qu’à détecter. Elle sert à comprendre la portée d’un incident, à reconstituer la chronologie des actions de l’attaquant, et à démontrer aux autorités, aux assureurs et aux clients comment l’organisation a réagi. Cette dimension probatoire prend de l’importance avec les obligations de notification d’incident, notamment dans le cadre de la directive NIS2, comme le détaille notre guide complet de la directive NIS2. Sans journaux, on ne peut ni détecter, ni analyser, ni prouver.
Ce qu’est un SIEM, concrètement
Le sigle SIEM signifie Security Information and Event Management. Derrière ce terme se cache une plateforme qui assure quatre fonctions enchaînées : collecter les journaux, les normaliser, les corréler, et alerter. Comprendre ces quatre étapes évite le malentendu le plus courant, qui consiste à croire qu’un SIEM détecte les attaques tout seul une fois installé.
La collecte
La collecte rassemble les journaux des sources vers la plateforme centrale, par des agents installés sur les machines, par l’envoi de flux syslog, ou par des connecteurs vers des interfaces de programmation. La difficulté n’est pas technique mais organisationnelle : il faut décider quelles sources brancher, dans quel ordre, et s’assurer que chaque source émet effectivement les bons journaux. Beaucoup de projets échouent ici, en cherchant à tout collecter immédiatement, ce qui sature la plateforme et noie le signal.
La normalisation
Les journaux arrivent dans des formats hétérogènes. Un événement d’authentification ne s’écrit pas de la même façon sur un annuaire Windows, un serveur Linux et une passerelle VPN. La normalisation traduit ces formats disparates vers un schéma commun, où le champ utilisateur, le champ adresse source ou le champ résultat portent toujours le même nom. Sans cette étape, impossible de poser une requête unique du type quels échecs d’authentification sur l’ensemble du parc. La qualité de la normalisation conditionne directement la qualité de la détection.
La corrélation
C’est le cœur de la valeur. La corrélation rapproche des événements provenant de sources différentes pour faire émerger un scénario qu’aucune source ne révèle seule. Une multitude d’échecs d’authentification suivie d’un succès, puis d’une création de compte à privilèges, puis d’une connexion sortante inhabituelle : chacun de ces événements est banal isolément, mais leur enchaînement décrit une attaque. La corrélation est ce qui transforme un amas de journaux en récit de sécurité.
L’alerte et la restitution
Enfin, lorsque la corrélation déclenche un scénario, le SIEM émet une alerte destinée à un analyste, et offre une interface pour investiguer : rechercher dans l’historique, pivoter d’un indicateur à l’autre, reconstituer la chronologie. Cette restitution rejoint le travail d’un centre opérationnel de sécurité, qu’il soit interne ou confié à un prestataire, sujet que nous développons dans notre article sur le SOC externalisé et le modèle MSSP.
Les conditions d’un SIEM utile
Un SIEM mal alimenté ou mal réglé ne produit aucune sécurité, seulement une facture de stockage et un flot d’alertes ignorées. Plusieurs conditions concrètes séparent un projet utile d’un échec coûteux.
Choisir les sources par valeur de détection
L’erreur fondatrice consiste à brancher d’abord les sources les plus volumineuses ou les plus faciles, en se disant qu’on triera ensuite. La bonne logique est inverse : on commence par les sources à plus forte valeur de détection. En pratique, l’annuaire d’authentification vient presque toujours en tête, car la quasi-totalité des attaques modernes passe par des authentifications, légitimes en apparence et détournées en réalité. Viennent ensuite les pare-feu et la passerelle Internet pour la visibilité des flux, les serveurs critiques et contrôleurs de domaine, les solutions de protection des postes, et les accès distants. Cette priorisation évite de saturer la plateforme et concentre l’attention là où elle compte.
Garantir la qualité et l’horodatage des journaux
Une corrélation suppose de comparer des événements dans le temps. Si les horloges des sources ne sont pas synchronisées, la chronologie reconstituée est fausse et le scénario d’attaque devient illisible. La synchronisation horaire par un service de temps fiable, en pratique le protocole NTP appuyé sur une source de référence commune, est donc un prérequis non négociable. De même, un journal incomplet, tronqué ou émis avec un niveau de verbosité insuffisant ne sert à rien. Vérifier que chaque source émet les événements attendus, dans le bon format et avec un horodatage cohérent, est un travail ingrat mais déterminant.
Écrire des cas d’usage de détection
Un SIEM ne détecte que ce qu’on lui a appris à reconnaître. Un cas d’usage est une règle de détection qui décrit un scénario d’attaque et la combinaison d’événements qui le trahit. Écrire de bons cas d’usage suppose de partir de scénarios réels plutôt que d’inventer des règles dans le vide. Le référentiel MITRE ATT&CK, qui cartographie les techniques d’attaque observées dans la nature, fournit une base méthodique pour couvrir les comportements pertinents : accès initial, persistance, élévation de privilèges, déplacement latéral, exfiltration. Plutôt que de viser une couverture exhaustive d’emblée, on construit progressivement un catalogue de détections aligné sur les menaces qui pèsent réellement sur l’organisation.
Accepter le travail continu sur les faux positifs
Aucune règle ne naît parfaite. Une détection trop large génère des alertes sur des comportements légitimes, et un analyste noyé sous les faux positifs finit par tout ignorer, y compris la vraie alerte. L’ajustement des règles, l’exclusion des comportements normaux propres à l’organisation, et la mesure du taux de pertinence des alertes constituent un travail permanent, pas une phase de mise en route. Un SIEM est un service vivant qui se règle dans la durée, pas un produit que l’on installe et que l’on oublie.
Construire la démarche par étapes
Un projet de journalisation et de SIEM réussit lorsqu’il avance par paliers maîtrisés, chacun apportant une valeur tangible avant de passer au suivant.
Définir la politique de journalisation
Avant tout outil, il faut une politique : quelles sources journaliser, quels événements collecter, combien de temps les conserver, et qui y a accès. L’ANSSI publie sur ce point un guide de journalisation dédié, qui constitue une référence pour fixer le périmètre et les durées de rétention adaptés au contexte français. Cette politique articule deux contraintes parfois opposées : la valeur de détection et d’analyse, qui pousse à conserver longtemps, et le respect du RGPD, qui impose de justifier la conservation des journaux contenant des données personnelles. Une politique écrite tranche ces arbitrages explicitement.
Centraliser avant de corréler
La première brique technique est la centralisation pure : rassembler les journaux des sources prioritaires en un point unique, fiable et sécurisé, indépendamment de toute capacité de détection. Cette étape a déjà une valeur, car elle rend l’investigation possible après incident. On y ajoute la synchronisation horaire et le contrôle de complétude. Ce n’est qu’une fois cette base saine que l’on bâtit la corrélation et les cas d’usage, sous peine de construire la détection sur des fondations instables.
Définir le modèle d’exploitation
Une plateforme de détection sans personne pour traiter ses alertes ne sert à rien. Il faut décider qui qualifie les alertes, selon quel processus, et avec quelle disponibilité. Trois modèles existent : l’internalisation complète, qui exige une équipe dédiée et disponible en continu ; l’externalisation auprès d’un prestataire de détection ; et le modèle hybride, où l’exploitation est déléguée tout en gardant la maîtrise des priorités. Ce choix dépend de la maturité et des effectifs, et conditionne la valeur réelle de l’investissement bien plus que le choix du produit.
Relier la détection à la réponse
Détecter sans savoir réagir laisse l’organisation paralysée au pire moment. Les alertes issues du SIEM doivent alimenter un processus de réponse à incident défini à l’avance, avec des rôles, des procédures d’escalade et des décisions préparées. Cette articulation entre détection et réaction est au cœur de la préparation à la crise cyber, que nous traitons dans notre article sur la gestion de crise cyber, le PCA et le PRA. Un SIEM n’a de sens que comme premier maillon d’une chaîne qui va jusqu’à la remédiation.
Le SIEM dans l’écosystème de détection
Le SIEM n’agit pas seul. Il s’insère dans un ensemble d’outils dont il devient souvent le point d’agrégation et de corrélation.
Complémentarité avec l’EDR
L’EDR observe finement le comportement d’une machine, là où le SIEM raisonne à l’échelle du système d’information. Les deux se complètent : l’EDR détecte une charge malveillante locale, le SIEM relie cet événement à des authentifications, des flux réseau et des actions sur l’annuaire pour reconstituer la chaîne complète. De nombreuses architectures envoient d’ailleurs les alertes de l’EDR vers le SIEM comme source de corrélation de haute valeur. Pour situer ces briques les unes par rapport aux autres, notre comparatif EDR, MDR et XDR précise les périmètres respectifs et les modèles de service associés.
Articulation avec la réponse au rançongiciel
La détection précoce est l’un des rares leviers efficaces contre le rançongiciel, dont l’action visible n’arrive qu’au terme d’une longue phase silencieuse. Un SIEM correctement réglé peut repérer les signaux avant-coureurs, comme une reconnaissance de l’annuaire, une création de comptes ou une désactivation de protections, et déclencher une réaction avant le chiffrement. Les vecteurs et la cinématique de ces attaques sont détaillés dans notre analyse des vecteurs d’attaque du rançongiciel en 2026, qui montre pourquoi la fenêtre de détection précoce est si déterminante.
Vers la détection augmentée
Les volumes de journaux dépassent depuis longtemps la capacité d’analyse manuelle, et les approches récentes ajoutent des méthodes d’analyse comportementale et d’apprentissage automatique pour repérer les anomalies que des règles fixes ne couvrent pas. Ces approches ne remplacent pas les cas d’usage écrits, mais les complètent en signalant des écarts par rapport à un comportement de référence. Elles déplacent une partie de l’effort de l’écriture de règles vers la qualification des anomalies, sans supprimer le besoin d’analystes ni de journaux fiables en entrée.
Erreurs fréquentes et points de vigilance
Quelques écueils reviennent dans la plupart des projets et méritent une vigilance explicite.
Confondre volume ingéré et capacité de détection
Un tableau de bord qui affiche des milliards d’événements par jour impressionne, mais ne mesure rien de la sécurité réelle. La valeur d’un SIEM se mesure au nombre et à la pertinence des cas d’usage actifs, à la qualité des sources, et au taux d’alertes vraies. Un grand volume mal exploité coûte cher et ne détecte rien.
Oublier la sécurité de la plateforme elle-même
Le SIEM concentre les journaux de tout le système d’information : il devient une cible de choix. Un attaquant qui le compromet efface ses traces et neutralise la détection. La plateforme doit donc être durcie, ses accès strictement contrôlés, et l’intégrité des journaux protégée. Conserver une copie des journaux à l’écart, en stockage non modifiable, garantit qu’ils survivent même à une compromission de la plateforme principale.
Négliger la maintenance des sources
Une source qui cesse d’émettre, à la suite d’une mise à jour, d’un changement de configuration ou d’un incident, crée un angle mort silencieux. Sans contrôle régulier de la complétude des sources, le SIEM continue de fonctionner en donnant l’illusion d’une couverture qu’il n’a plus. Surveiller la santé des sources fait partie intégrante de l’exploitation.
Démarrer sans modèle d’exploitation
Déployer la technologie avant d’avoir décidé qui traite les alertes condamne le projet. Les alertes s’accumulent, personne ne les qualifie, et la plateforme devient un coût sans contrepartie. Le modèle d’exploitation, interne, externalisé ou hybride, doit être arrêté avant la mise en service, pas après.
Conclusion
La journalisation centralisée est le socle invisible de toute capacité de détection. Sans journaux collectés, fiables et conservés, une intrusion se déroule sans témoin et l’analyse après incident devient impossible. Le SIEM est l’outil qui transforme ce socle en détection active, à condition de comprendre qu’il ne s’agit pas d’un produit que l’on allume, mais d’un service que l’on construit et que l’on entretient. Sa valeur ne vient ni du volume de journaux ingérés, ni du produit choisi, mais de la pertinence des sources, de la qualité de l’horodatage, des cas d’usage de détection écrits à la main et du modèle humain qui qualifie les alertes. Une organisation qui aborde la journalisation comme un projet par étapes, en commençant par les sources à plus forte valeur et en reliant la détection à la réponse, se dote d’une capacité réelle. Une organisation qui achète un SIEM en espérant qu’il fasse le travail seul hérite d’un entrepôt de logs coûteux et muet.
Sources et références
[1] ANSSI, recommandations et guides de sécurité (dont la journalisation), https://www.ssi.gouv.fr/ [2] CERT-FR, avis et alertes de l’ANSSI, https://www.cert.ssi.gouv.fr/ [3] MITRE ATT&CK, base de connaissance des techniques d’attaque, https://attack.mitre.org/ [4] ENISA, agence de l’Union européenne pour la cybersécurité, https://www.enisa.europa.eu/ [5] NIST SP 800-92, Guide to Computer Security Log Management, https://csrc.nist.gov/pubs/sp/800/92/final