SIEM : définition, fonctionnement et obligations de journalisation en Europe

Un SIEM (Security Information and Event Management), ou système de gestion des informations et des événements de sécurité, est un outil de supervision qui centralise les journaux produits par les pare-feux, les serveurs, les postes de travail, les annuaires, les applications et les services cloud, les met en corrélation pour repérer en temps quasi réel les comportements suspects, lève des alertes et conserve l’historique nécessaire aux enquêtes après incident et aux rapports de conformité. Il sert d’outil de travail aux équipes d’un centre opérationnel de sécurité (SOC), qu’il soit interne ou confié à un prestataire.

Un SIEM ne détecte rien par lui-même : sa valeur dépend des sources qu’on lui confie, des règles de détection qu’on y écrit et des analystes qui traitent ses alertes. Les agences de cybersécurité australienne et américaine le résument dans leur guide commun de mai 2025 : ni un SIEM ni un SOAR ne sont des outils que l’on installe puis oublie, et leur mise en œuvre est un travail continu qui demande un personnel très qualifié.

La première version de cet article, publiée en janvier 2023, reprenait la présentation commerciale des éditeurs. Cette version, réécrite le 20 octobre 2026 à partir des guides de l’ANSSI, de la CNIL et des agences australienne et américaine, ainsi que des textes européens, explique le fonctionnement d’un SIEM et ses limites, situe les outils voisins, puis détaille les obligations de journalisation et de notification qu’il aide à remplir.

Du serveur de journaux au SIEM

Le terme réunit deux fonctions apparues séparément. La gestion des informations de sécurité (SIM) collecte, stocke et restitue les journaux sur la durée, pour les rapports et les enquêtes ; la gestion des événements de sécurité (SEM) analyse ces événements au fil de l’eau pour les corréler et alerter. Un simple serveur qui centralise les journaux remplit la première fonction ; un SIEM y ajoute la normalisation des données, la corrélation, l’alerte et les outils d’investigation.

La centralisation reste la condition de départ. Le guide de l’ANSSI sur l’architecture d’un système de journalisation (version 2.0 du 28 janvier 2022) recommande que les journaux de l’ensemble des équipements du système d’information soient collectés puis transférés sur un ou plusieurs serveurs centraux dédiés, et insiste sur la synchronisation de tous les équipements sur une même source de temps : sans horodatage cohérent, il devient impossible de reconstituer l’enchaînement d’une attaque à partir de journaux venus de dizaines de machines.

Le fonctionnement d’un SIEM, de la collecte à l’alerte

Collecter et normaliser les journaux

Les journaux arrivent par plusieurs canaux : des agents installés sur les serveurs et les postes, le protocole syslog (normalisé par la RFC 5424 en 2009) pour les équipements réseau et les systèmes Unix, et les interfaces de programmation des services cloud. Le guide des agences australienne et américaine sur les journaux à intégrer en priorité recommande d’augmenter progressivement le nombre et les types de sources plutôt que de les ajouter toutes d’un coup. Il les classe dans un ordre indicatif de priorité, en tête duquel figurent les journaux des outils de détection et de réponse sur les postes (EDR), ceux des équipements réseau, puis ceux des contrôleurs de domaine et de l’annuaire Active Directory ; pour les services cloud, il place en premier les systèmes critiques, les services exposés à Internet et les comptes qui administrent ces services.

Chaque source a son propre format, et le SIEM doit les traduire dans un schéma commun pour pouvoir comparer un échec de connexion sur un pare-feu et sur un annuaire. Des schémas ouverts, comme OCSF (Open Cybersecurity Schema Framework), proposent un schéma de sécurité central indépendant des éditeurs, ce qui facilite l’échange de données entre outils.

Corréler et détecter

La corrélation rapproche des événements isolés, anodins pris un par un, pour faire apparaître un scénario : une série d’échecs d’authentification suivie d’une connexion réussie depuis un pays inhabituel, puis de la création d’un compte administrateur, par exemple. Les règles de détection peuvent s’écrire dans le format ouvert Sigma, conçu pour décrire des détections dans les journaux de façon simple et partageable, puis être traduites pour le SIEM utilisé. Elles s’organisent souvent selon la base MITRE ATT&CK, qui recense les tactiques et techniques des attaquants à partir d’observations réelles, ce qui permet de mesurer quelles techniques l’organisation sait effectivement détecter. Le SIEM peut aussi intégrer des flux de renseignement sur les menaces (adresses, domaines ou empreintes de fichiers malveillants) pour les confronter aux journaux.

Alerter, enquêter et conserver

Lorsqu’une règle se déclenche, le SIEM crée une alerte que les analystes qualifient : incident réel, fausse alerte ou événement à surveiller. La première difficulté technique relevée par le guide australien et américain se situe ici : obtenir que le SIEM produise des alertes lorsque des incidents se produisent, et n’en produise pas dans le cas contraire. L’historique conservé sert ensuite aux enquêtes de criminalistique numérique, pour reconstituer le chemin d’un attaquant plusieurs semaines après son intrusion. Les journaux centralisés doivent eux-mêmes être protégés contre la modification et la suppression, car effacer ses traces fait partie des techniques des attaquants.

SOAR, EDR et XDR : des outils complémentaires

Un SOAR (Security Orchestration, Automation and Response) automatise la réponse à une activité anormale en appliquant des scénarios prédéfinis, ou playbooks : isoler un poste, désactiver un compte, enrichir une alerte avec des informations externes. Selon le guide des agences australienne et américaine, certains SOAR collectent et analysent eux-mêmes les journaux, d’autres s’appuient sur un SIEM existant, et ces actions automatiques complètent les équipes de réponse sans les remplacer.

Un EDR (Endpoint Detection and Response) surveille les postes de travail et les serveurs, détecte les comportements malveillants sur la machine et permet d’y répondre, par exemple en isolant le poste du réseau. Un XDR (Extended Detection and Response) étend cette détection et cette réponse à plusieurs couches du système d’information. La première version de cet article réduisait le XDR à la détection, alors que la réponse en fait partie, comme son nom l’indique. Les frontières entre ces catégories s’estompent, le guide australien et américain notant par exemple que certains SOAR intègrent leur propre SIEM ; le SIEM garde l’avantage d’accepter des journaux de toute provenance, y compris des applications métier, ce qui reste indispensable pour les obligations de journalisation présentées plus bas.

Un marché recomposé depuis 2023

Deux opérations ont modifié l’offre depuis la publication de la première version de cet article. Cisco a finalisé le rachat de Splunk, que l’article citait comme éditeur indépendant de SIEM et de SOAR, le 18 mars 2024. Le 15 mai 2024, IBM et Palo Alto Networks ont annoncé la cession à ce dernier d’une partie des actifs de QRadar en mode SaaS, l’outil d’IBM dont l’article reproduisait une capture d’écran ; Palo Alto Networks a annoncé la finalisation de l’opération le 4 septembre 2024, et IBM a indiqué que les clients de QRadar sur site continueraient d’être pris en charge.

Les assistants d’IA générative se sont aussi installés dans ces outils : celui de Microsoft, présenté dans notre article sur Security Copilot, est disponible depuis le 1er avril 2024 sous le nom de Copilot for Security. Ces évolutions rappellent qu’un SIEM s’inscrit dans la durée : la possibilité d’exporter ses journaux et ses règles de détection dans des formats ouverts, comme Sigma, compte autant dans le choix d’un outil que ses fonctions du moment.

Les obligations qui supposent journalisation et détection

Aucun des textes présentés ci-dessous n’impose d’acheter un SIEM, mais tous exigent de journaliser, de détecter les incidents et de les déclarer dans des délais courts, ce qui est difficile à tenir sans un outil qui centralise et corrèle les journaux.

NIS 2 et ses mesures d’exécution

La directive (UE) 2022/2555, dite NIS 2, range la gestion des incidents parmi les mesures minimales de gestion des risques que les entités essentielles et importantes doivent prendre (article 21). Son article 23 fixe un calendrier de notification des incidents importants : une alerte précoce dans les 24 heures après en avoir eu connaissance, une notification d’incident dans les 72 heures, puis un rapport final au plus tard un mois après cette notification.

Pour certains fournisseurs numériques (DNS, informatique en nuage, centres de données, réseaux de diffusion de contenu, services gérés et services de sécurité gérés, places de marché, moteurs de recherche, réseaux sociaux, services de confiance), le règlement d’exécution (UE) 2024/2690 du 17 octobre 2024 précise ces mesures. Son annexe leur demande d’utiliser des outils pour surveiller et journaliser les activités sur leurs réseaux et leurs systèmes, de conserver les journaux pendant une période prédéfinie, de disposer d’horloges synchronisées et de mettre en place une procédure de corrélation et d’analyse des journaux.

Les États membres devaient transposer la directive au plus tard le 17 octobre 2024. En France, le projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité a été adopté par le Sénat le 12 mars 2025, et la commission spéciale de l’Assemblée nationale a établi son texte le 10 septembre 2025 ; à la date du 20 octobre 2026, le dossier législatif ne mentionne pas d’adoption en séance publique à l’Assemblée.

DORA pour le secteur financier

Le règlement (UE) 2022/2554, dit DORA, s’applique depuis le 17 janvier 2025 aux entités financières. Il leur impose des mécanismes permettant de détecter rapidement les activités anormales (article 10), un processus de gestion des incidents liés aux technologies de l’information et de la communication (TIC) pour les détecter, les gérer et les notifier (article 17), et la déclaration des incidents majeurs à l’autorité compétente (article 19). Le règlement délégué (UE) 2025/301 fixe les délais : notification initiale dans les quatre heures suivant la classification de l’incident comme majeur et au plus tard 24 heures après en avoir eu connaissance, rapport intermédiaire dans les 72 heures suivant la notification initiale, rapport final un mois après le rapport intermédiaire.

Le règlement délégué (UE) 2024/1774 consacre son article 12 à la journalisation : l’entité financière documente et met en œuvre des procédures, protocoles et outils de journalisation, choisit les événements enregistrés et la durée de conservation des journaux, protège ceux-ci contre la manipulation, la suppression et les accès non autorisés, et synchronise les horloges de ses systèmes sur une horloge de référence fiable et documentée.

RGPD et recommandation de la CNIL

Le RGPD impose des mesures de sécurité adaptées au risque (article 32) et la notification d’une violation de données personnelles à l’autorité de contrôle dans les meilleurs délais et, si possible, 72 heures au plus tard après en avoir pris connaissance (article 33). Dans sa recommandation sur la journalisation (délibération n° 2021-122 du 14 octobre 2021), la CNIL recommande de conserver les journaux des applications qui portent un traitement de données personnelles pendant six mois à un an, en précisant que la journalisation dite périmétrique, celle des équipements informatiques spécifiques dotés de logiciels embarqués, répond à une logique différente.

Un SIEM est lui-même un traitement de données personnelles : les journaux contiennent des identifiants, des adresses IP et des traces d’activité des collaborateurs. Sa finalité de sécurité doit être documentée, l’accès aux journaux réservé aux personnes habilitées, et la durée de conservation fixée et appliquée.

Opérateurs d’importance vitale et autres référentiels

Pour les opérateurs d’importance vitale, les règles de sécurité prises en application du code de la défense, citées par l’ANSSI dans son guide, imposent que les événements de leurs systèmes d’information d’importance vitale soient horodatés à partir de sources de temps synchronisées, centralisés et archivés au moins six mois, et accompagnés d’un système de corrélation et d’analyse. L’ANSSI qualifie par ailleurs des prestataires de détection des incidents de sécurité (PDIS) selon un référentiel publié en 2017, utile à une organisation qui confie sa supervision à un tiers. La première version de cet article citait aussi PCI DSS, la norme de sécurité des données de cartes de paiement, ainsi que les lois américaines HIPAA et SOX, qui ne concernent que les organisations soumises à ces régimes.

Les limites d’un SIEM

Le coût est la première. Le guide des agences australienne et américaine souligne que la mise en œuvre d’un SIEM ou d’un SOAR entraîne des coûts importants : licences ou volumes de données, recrutement et fidélisation de spécialistes, intégration. Lorsque la licence ne plafonne pas l’ingestion, les coûts peuvent devenir très élevés si l’intégration des journaux n’est pas maîtrisée, et certains paramètres par défaut tendent à augmenter les volumes ingérés.

Le bruit est la deuxième. Des règles trop larges noient les analystes sous des fausses alertes, au risque qu’ils manquent la véritable ; des règles trop étroites laissent passer les attaques. Le réglage est un travail permanent, à reprendre chaque fois que le système d’information ou les techniques des attaquants évoluent. Enfin, un SIEM ne voit que ce qu’on lui envoie : une application métier, un service cloud ou un équipement industriel qui ne lui transmet pas ses journaux reste un angle mort, quelle que soit la qualité des règles.

Construire la détection par étapes

La démarche part des risques et des obligations plutôt que de l’outil. Une organisation commence par établir quels textes la concernent (NIS 2, DORA, statut d’opérateur d’importance vitale, traitements de données personnelles à risque) et quels scénarios d’attaque elle redoute le plus, ce qui détermine les journaux à collecter en priorité et les durées de conservation à appliquer. Elle synchronise ensuite les horloges de ses équipements et centralise les journaux de ces sources prioritaires, avant d’en ajouter d’autres par étapes, comme le recommandent les agences australienne et américaine.

Les règles de détection viennent après, rattachées aux techniques de MITRE ATT&CK qui correspondent aux scénarios retenus, et testées en reproduisant ces techniques dans un environnement maîtrisé pour vérifier qu’elles déclenchent bien une alerte. La procédure de gestion des incidents se cale sur les délais légaux applicables (24 heures pour l’alerte précoce de NIS 2, quatre heures après classification pour DORA, 72 heures pour la CNIL) et désigne qui qualifie un incident et qui notifie. Le choix entre une équipe interne et un prestataire, qualifié PDIS ou non, se fait enfin à partir des compétences disponibles et du coût d’une surveillance continue, en conservant dans tous les cas la maîtrise des journaux et des règles. Notre article sur la gestion de la sécurité des données replace cette supervision parmi les autres mesures de protection.

Sources et références 24 sources

Textes de l'Union européenne

1. [1] Directive (UE) 2022/2555 (NIS 2)
2. [2] Règlement d'exécution (UE) 2024/2690 du 17 octobre 2024 (exigences techniques et méthodologiques NIS 2)
3. [3] Règlement (UE) 2022/2554 (DORA)
4. [4] Règlement délégué (UE) 2024/1774 (cadre de gestion du risque lié aux TIC)
5. [5] Règlement délégué (UE) 2025/301 (contenu et délais de notification des incidents majeurs)
6. [6] Règlement (UE) 2016/679 (RGPD)

France

1. [7] CNIL - Recommandation relative aux mesures de journalisation (délibération n° 2021-122 du 14 octobre 2021)
2. [8] ANSSI - Recommandations de sécurité pour l'architecture d'un système de journalisation, version 2.0 (28 janvier 2022)
3. [9] ANSSI - Prestataires de détection des incidents de sécurité (PDIS)
4. [10] Assemblée nationale - Dossier législatif du projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité

Guides et référentiels techniques

1. [11] ASD's ACSC et CISA - Implementing SIEM and SOAR platforms: Executive guidance (mai 2025)
2. [12] ASD's ACSC et CISA - Implementing SIEM and SOAR platforms: Practitioner guidance (mai 2025)
3. [13] ASD's ACSC et CISA - Priority logs for SIEM ingestion: Practitioner guidance (mai 2025)
4. [14] CISA - Guidance for SIEM and SOAR implementation
5. [15] NIST SP 800-61 Rev. 3 - Incident Response Recommendations and Considerations for Cybersecurity Risk Management (avril 2025)
6. [16] NIST SP 800-92 - Guide to Computer Security Log Management (2006 ; révision 1 à l'état de projet)
7. [17] RFC 5424 - The Syslog Protocol
8. [18] MITRE ATT&CK
9. [19] Sigma - format de règles de détection
10. [20] Open Cybersecurity Schema Framework (OCSF)

Annonces des éditeurs

1. [21] Cisco - Cisco completes acquisition of Splunk (18 mars 2024)
2. [22] IBM - IBM and Palo Alto Networks to jointly provide AI-powered security offerings (mai 2024)
3. [23] Palo Alto Networks - Closes acquisition of IBM's QRadar SaaS assets (4 septembre 2024)
4. [24] Microsoft - Copilot for Security generally available on April 1, 2024