Un SIEM (Security Information and Event Management) est une plateforme qui collecte les journaux d’événements produits par un système d’information, les centralise dans un référentiel unique, les normalise dans un format commun, puis les corrèle afin de détecter des comportements suspects et de générer des alertes. Chaque équipement conserve par défaut ses propres traces dans son coin ; le SIEM les rassemble et les met en relation. Une authentification réussie à trois heures du matin ne dit pas grand-chose isolément. Rapprochée d’une connexion VPN depuis un pays inhabituel puis d’un accès à un partage de fichiers sensible, elle devient un signal exploitable.
Dans le secteur bancaire et financier, cet outil constitue la matière première du centre opérationnel de sécurité (SOC), qui s’appuie sur ses alertes pour surveiller le système d’information en continu. Encore faut-il l’alimenter et l’entretenir : une plateforme mal raccordée aux bonnes sources, ou dont les règles de détection ne sont plus maintenues, perd rapidement son utilité, quelle que soit la technologie retenue.
Les sources de données collectées
La couverture d’un SIEM se mesure à la variété des journaux qu’il reçoit. Les sources habituelles comprennent :
- les systèmes d’exploitation des serveurs et des postes de travail, qui tracent les authentifications, la création de processus ou les modifications de configuration ;
- les applications métier, dont les journaux enregistrent les opérations sensibles — dans une banque, un virement, un changement de bénéficiaire ou une consultation de compte laissent une trace applicative ;
- les équipements réseau et de sécurité : pare-feu, proxys, sondes de détection d’intrusion, relais de messagerie ;
- les environnements cloud et SaaS, dont les journaux d’audit ont leurs propres formats et modes de collecte — la galaxie Microsoft 365 illustre bien le sujet, avec des dizaines de services produisant chacun leur télémétrie ;
- l’annuaire d’entreprise, Active Directory le plus souvent, dont les événements de création de comptes, d’élévation de privilèges ou de modification de groupes intéressent directement la détection.
D’autres briques de sécurité viennent enrichir cette collecte. Les solutions de gestion des comptes à privilèges (PAM) journalisent les sessions des administrateurs, une population particulièrement surveillée du système d’information. Les outils de prévention des fuites de données (DLP) remontent quant à eux les tentatives d’envoi de documents vers l’extérieur, un type d’événement que le SIEM peut croiser avec les journaux d’accès aux serveurs de fichiers.
Règles de corrélation : le réglage ne s’arrête jamais
Une règle de corrélation décrit un scénario que l’on souhaite détecter : une série d’échecs d’authentification suivie d’un succès, un compte de service qui ouvre une session interactive, un volume de données sortant anormal sur une plage horaire donnée. Beaucoup d’éditeurs livrent des catalogues de règles alignés sur des référentiels de techniques d’attaque comme MITRE ATT&CK ; ces catalogues fournissent un point de départ qu’il reste à adapter au contexte de chaque établissement.
Le problème central reste le faux positif. Une règle écrite trop largement noie les analystes sous des alertes sans intérêt. La resserrer réduit le bruit, au risque cette fois de laisser passer des variantes d’attaque pourtant proches du scénario visé. Le réglage est donc une activité continue : chaque alerte traitée nourrit un ajustement de seuil, une liste d’exclusion documentée ou la retraite pure et simple d’une règle devenue inutile. L’enrichissement automatique aide à trier — une adresse IP signalée par la threat intelligence ou une machine porteuse d’une vulnérabilité critique non corrigée justifient de prioriser l’alerte correspondante.
La journalisation, un prérequis d’architecture
Collecter des journaux suppose qu’ils existent, qu’ils soient exploitables et qu’un attaquant ne puisse pas les effacer. Ce prérequis est moins trivial qu’il n’y paraît : des horloges non synchronisées rendent toute chronologie d’incident douteuse, des journaux conservés uniquement sur la machine compromise disparaissent avec elle, et un niveau de verbosité mal choisi produit soit du bruit, soit des trous.
L’ANSSI a publié des recommandations de sécurité pour l’architecture d’un système de journalisation, qui traitent notamment de la centralisation des événements sur une infrastructure dédiée, de la protection de cette infrastructure et de la synchronisation horaire. La lecture de ce document avant tout projet SIEM évite un écueil classique : investir dans une plateforme de corrélation alors que la chaîne de production des journaux, en amont, n’est pas maîtrisée.
SIEM, EDR, XDR : des périmètres différents
La confusion entre ces sigles est entretenue par un marché où chaque éditeur étend son discours au-delà de son produit. Le SIEM travaille sur des journaux : il reçoit des événements déjà produits par d’autres, les corrèle et conserve un historique transverse couvrant potentiellement tout le système d’information, des applications métier aux équipements réseau. L’EDR, lui, s’installe sur le poste de travail ou le serveur et observe le comportement du système en direct — processus lancés, appels système, modifications de la base de registre — avec une capacité de blocage immédiat que le SIEM n’a pas. Son analyse de l’hôte est bien plus fine que ce que permettent des journaux, mais son champ de vision s’arrête aux machines équipées de l’agent.
Le XDR prolonge cette logique en croisant la télémétrie des postes avec celle de la messagerie, des identités ou du cloud, généralement au sein de l’écosystème d’un même éditeur. L’ambition de corrélation le rapproche du SIEM, mais son périmètre reste borné aux sources qu’il sait nativement ingérer. En pratique, les deux approches coexistent dans la plupart des grandes organisations financières : l’EDR ou le XDR détecte et bloque au plus près de la menace, le SIEM assure la vision d’ensemble, l’historique long et la couverture des sources que les outils de détection managés ignorent. Les différences entre ces familles d’outils sont détaillées dans notre article consacré à l’EDR et au XDR.
Ce que le SOC en fait, et avec qui
La plateforme se contente de produire des alertes ; leur exploitation quotidienne revient aux équipes du SOC : qualification, écartement des faux positifs, investigation des cas sérieux, escalade lorsque l’incident est avéré. C’est à ce moment qu’intervient le CSIRT, chargé de la réponse — confinement, analyse approfondie, remédiation — selon un partage des rôles précisé dans notre article sur la différence entre CSIRT, CERT et SOC.
La circulation de l’information fonctionne dans les deux sens. Les équipes de renseignement sur la menace fournissent au SOC des indicateurs de compromission qui deviennent des règles de détection dans le SIEM ; les investigations du CSIRT révèlent des modes opératoires qui alimentent en retour ces mêmes équipes. Certains établissements poussent cette intégration jusqu’au modèle du cyber fusion center, qui réunit détection, réponse, renseignement et lutte contre la fraude sur un plateau commun.
Conservation des journaux et cadre réglementaire
La durée de conservation des événements collectés soulève des questions juridiques autant que techniques. Une durée trop courte prive les investigateurs d’historique lorsqu’une intrusion ancienne est découverte tardivement. Une conservation prolongée pose un autre problème : les journaux forment un stock de données personnelles dont la détention doit se justifier. La CNIL a adopté une recommandation relative aux mesures de journalisation qui aborde les durées de conservation et la protection des journaux eux-mêmes, ces derniers contenant fréquemment des identifiants et des traces d’activité individuelles.
Pour les établissements financiers s’ajoute une dimension sectorielle. Le règlement européen DORA (règlement (UE) 2022/2554) impose aux entités financières des mécanismes de détection des activités anormales et une gestion structurée des incidents liés aux technologies de l’information et de la communication, ce qui suppose une capacité de journalisation et de supervision à la hauteur. Les politiques de conservation méritent d’être définies avec les fonctions juridique et conformité, en distinguant les journaux techniques de courte durée de vie de ceux qui documentent des opérations soumises à des exigences de traçabilité propres au secteur. Le SIEM se trouve à l’intersection de ces contraintes : outil de détection pour le SOC, il est aussi, de fait, l’archive dans laquelle l’établissement puisera le jour où il devra reconstituer le déroulement d’un incident devant son autorité de supervision.
