SIEM (Security Information and Event Management)

Ce que fait un SIEM

Un SIEM répond à un problème concret : les données de sécurité de votre entreprise sont dispersées dans des dizaines de systèmes différents. Le firewall génère ses logs, le serveur mail les siens, Active Directory enregistre les authentifications, chaque application cloud a son propre journal d’audit. Aucun de ces systèmes, pris isolément, ne montre le tableau complet.

Le SIEM collecte tous ces logs dans une plateforme unique, les normalise dans un format commun et les corrèle entre eux pour détecter des schémas d’attaque qu’aucune source individuelle ne pourrait révéler.

Exemple concret : un employé reçoit un email de phishing et saisit ses identifiants sur une fausse page de connexion. Pris séparément, les événements semblent anodins :

• La passerelle email a livré un email (des milliers passent chaque jour)
• Un clic sur un lien externe (banal)
• Une connexion à Microsoft 365 depuis une adresse IP en Europe de l’Est (un seul événement dans des millions de logs)
• Un accès à SharePoint et un téléchargement massif de fichiers (qui regarde les logs SharePoint ?)

Le SIEM, lui, corrèle ces quatre événements en séquence et déclenche une alerte : email suspect → clic → connexion anormale → exfiltration probable. Un analyste du SOC peut alors intervenir en quelques minutes au lieu de découvrir l’incident des semaines plus tard.

Comment fonctionne un SIEM

Le traitement des données dans un SIEM suit quatre étapes séquentielles.

Étape 1 : Collecte des logs

Le SIEM ingère les données de sécurité depuis toutes les sources connectées. Les méthodes de collecte varient :

• Agents installés sur les serveurs et postes de travail (collecte des événements système, logs applicatifs)
• Syslog pour les équipements réseau (firewalls, switchs, routeurs)
• API pour les services cloud (Microsoft 365, Google Workspace, AWS, Azure)
• Connecteurs natifs pour les outils de sécurité (EDR, passerelle email, proxy web)

Le volume de logs est considérable. Une PME de 100 postes avec Microsoft 365, un firewall et un EDR génère facilement 5 à 20 Go de logs par jour. Un SIEM doit pouvoir ingérer et indexer ce volume en temps réel.

Étape 2 : Normalisation

Chaque source de logs utilise un format différent. Le firewall Fortinet n’enregistre pas les événements comme le firewall Palo Alto. Les logs Active Directory n’ont rien à voir avec les logs Microsoft 365.

Le SIEM normalise tous ces formats dans un modèle de données commun. Un événement de connexion, qu’il provienne d’Active Directory, de Microsoft 365 ou du VPN, est transformé en un format unifié contenant : l’identité de l’utilisateur, l’adresse IP source, l’horodatage, le résultat (succès/échec) et le service concerné.

Cette normalisation est ce qui rend la corrélation possible. Sans elle, comparer un log de firewall avec un log Active Directory serait comme comparer un texte en français avec un texte en chinois — les deux contiennent l’information, mais il faut un traducteur commun.

Étape 3 : Corrélation et détection

La corrélation est le mécanisme central du SIEM. Des règles de corrélation analysent les événements normalisés en temps réel et déclenchent des alertes quand un schéma suspect est détecté.

Quelques exemples de règles de corrélation typiques :

Scénario	Événements corrélés	Alerte
Brute force	10+ échecs d’authentification sur le même compte en 5 minutes	Tentative de brute force
Compte compromis	Connexion VPN depuis la France à 9h, puis connexion Microsoft 365 depuis le Brésil à 9h15 (impossible travel)	Compte potentiellement compromis
Phishing suivi d’exfiltration	Email suspect reçu + clic sur lien + connexion anormale + téléchargement massif dans l’heure	Chaîne d’attaque phishing en cours
Mouvement latéral	Compte utilisateur accède à un serveur auquel il n’a jamais accédé + élévation de privilèges	Mouvement latéral post-compromission
Ransomware	Chiffrement massif de fichiers sur un partage réseau + suppression des shadow copies	Ransomware en cours de déploiement

Les SIEM modernes complètent les règles statiques avec du machine learning pour détecter les anomalies comportementales (UEBA — User and Entity Behavior Analytics). Le système apprend le comportement normal de chaque utilisateur et de chaque machine, et alerte quand un écart significatif est observé.

Étape 4 : Alertes et investigation

Quand une règle de corrélation se déclenche, le SIEM génère une alerte avec un niveau de sévérité (critique, haute, moyenne, basse). L’alerte contient :

• La description du scénario détecté
• Les événements bruts qui ont déclenché la règle
• Les entités impliquées (utilisateur, machine, adresse IP)
• Le contexte enrichi (l’IP source est-elle connue comme malveillante ? Le domaine du lien est-il récent ?)

L’analyste du SOC utilise ensuite le SIEM comme outil d’investigation : il peut rechercher dans les logs historiques, tracer l’activité d’un utilisateur ou d’une machine sur une période donnée, et reconstruire la chronologie complète d’un incident.

Quels logs collecter en priorité

Tout connecter d’un coup au SIEM est contre-productif : trop de logs = trop de bruit = des analystes noyés sous les faux positifs. L’approche pragmatique est de commencer par les sources à plus forte valeur.

Priorité 1 : les sources liées au phishing et à l’identité

Le phishing est le vecteur d’entrée principal. Selon le Verizon DBIR 2024, 36 % des compromissions initiales commencent par un email de phishing ou du social engineering. Les logs à connecter en premier :

Passerelle email (Microsoft Defender for Office 365, Proofpoint, Barracuda, etc.) — Chaque email reçu, livré, bloqué ou mis en quarantaine. Les métadonnées des emails (expéditeur, domaine, présence de pièce jointe, résultat de l’analyse) permettent de détecter les campagnes de phishing.

Active Directory / Azure AD — Chaque authentification, chaque modification de groupe, chaque création ou suppression de compte. C’est la source qui révèle les comptes compromis (connexions impossibles, élévations de privilèges anormales, comptes de service utilisés de manière inhabituelle).

Microsoft 365 / Google Workspace — Les logs d’audit des applications cloud : qui accède à quoi, depuis où, quels fichiers sont partagés ou téléchargés. Un compte 365 compromis donne accès à l’email, à SharePoint, à Teams et à OneDrive — soit la quasi-totalité des données de l’entreprise.

Priorité 2 : réseau et accès distant

Firewall — Les flux réseau autorisés et bloqués, les connexions vers des destinations suspectes, les tentatives d’accès depuis des adresses IP malveillantes.

VPN — Les connexions distantes : qui se connecte, depuis quelle adresse IP, à quelle heure. Une connexion VPN à 3h du matin depuis un pays où l’entreprise n’a aucun collaborateur est un signal fort.

Priorité 3 : endpoints

EDR — Les événements sur les postes de travail et serveurs : exécution de processus, modifications du registre, comportements suspects (chiffrement massif de fichiers, tentative de désactivation de l’antivirus). L’EDR détecte le malware qui arrive sur le poste après un clic sur un lien de phishing.

Ce que les six sources couvrent

Vecteur d’attaque	Sources de détection
Email de phishing	Passerelle email + EDR
Vol d’identifiants (credential phishing)	Active Directory + M365/GWS + VPN
Malware après clic	EDR + firewall
Mouvement latéral	Active Directory + EDR
Exfiltration de données	M365/GWS + firewall
Ransomware	EDR + Active Directory

Avec ces six sources, une PME couvre les scénarios d’attaque les plus fréquents. D’autres sources (proxy web, DNS, applications métier) peuvent être ajoutées ensuite selon les besoins.

SIEM et détection du phishing

Le SIEM est un outil de détection post-livraison. Il ne remplace pas le filtre email (qui bloque les emails malveillants connus avant qu’ils n’atteignent la boîte de réception) ni la simulation de phishing (qui entraîne les employés à reconnaître et signaler les emails suspects). Mais il détecte ce qui passe entre les mailles du filet.

Les règles de détection phishing dans un SIEM

Un SIEM correctement configuré détecte les indices suivants :

Indicateurs dans les logs email :

• Email provenant d’un domaine créé il y a moins de 30 jours (domaine jetable, souvent utilisé pour le phishing)
• Email avec un objet contenant des mots-clés de social engineering (“urgent”, “paiement”, “validation requise”) envoyé depuis un domaine externe
• Volume anormal d’emails similaires envoyés à plusieurs employés en peu de temps (campagne de phishing de masse)

Indicateurs dans les logs d’authentification :

• Connexion à Microsoft 365 depuis une adresse IP inhabituelle dans les minutes suivant la réception d’un email suspect → probable vol d’identifiants
• Connexion à des horaires inhabituels ou depuis un pays où l’entreprise n’opère pas → « impossible travel »
• Création d’une règle de transfert email dans la boîte d’un utilisateur juste après une connexion suspecte → technique classique des attaquants de type BEC pour intercepter les emails

Indicateurs dans les logs endpoint :

• Exécution d’un script PowerShell ou d’une macro Office après l’ouverture d’une pièce jointe email
• Connexion réseau sortante vers un domaine jamais vu dans l’entreprise, déclenchée par un processus inhabituel
• Téléchargement d’un exécutable depuis un lien contenu dans un email

Limites de la détection SIEM seule

Le SIEM détecte les attaques après qu’elles ont atteint l’utilisateur. Il ne bloque pas l’email de phishing en amont. La chaîne de défense complète contre le phishing comprend :

1. Authentification email (SPF, DKIM, DMARC) → empêche l’usurpation de votre domaine
2. Filtrage email → bloque les emails malveillants connus
3. Sensibilisation et simulation → entraîne les employés à détecter et signaler
4. SIEM + SOC → détecte les attaques qui passent les trois premières couches
5. EDR → bloque l’exécution du payload sur le poste

Options SIEM pour les PME

SIEM cloud

Les SIEM cloud ont radicalement changé l’accessibilité pour les PME. Plus besoin d’acheter des serveurs ni de gérer l’infrastructure de stockage.

Microsoft Sentinel — Intégré à la suite Azure/Microsoft 365. Si votre entreprise est sur Microsoft 365, Sentinel bénéficie de connecteurs natifs pour ingérer les logs sans configuration complexe. Facturation à la consommation (par Go ingéré), ce qui peut surprendre si le volume n’est pas anticipé.

Elastic Security — Solution open-source avec une offre cloud (Elastic Cloud). Bonne flexibilité, large communauté, mais nécessite de l’expertise pour configurer les règles de détection.

Wazuh — Plateforme open-source qui combine SIEM et capacités d’EDR basique. Option à faible coût pour les PME avec de l’expertise technique interne, mais la gestion et l’optimisation restent à la charge de l’entreprise.

Alternatives au SIEM pour les PME

Pour beaucoup de PME, un SIEM dédié n’est pas la bonne entrée. Deux alternatives méritent considération :

XDR (Extended Detection and Response) — Les plateformes XDR intègrent la corrélation de logs (fonction SIEM), la détection endpoint (fonction EDR) et parfois la réponse automatisée (fonction SOAR) en un seul produit. Pour une PME qui n’a pas d’analyste SIEM en interne, un XDR managé est souvent plus efficace qu’un SIEM seul.

MDR (Managed Detection and Response) — Un service MDR inclut l’outil de détection ET l’équipe d’analystes. Le fournisseur gère le SIEM/XDR, écrit les règles de détection, traite les alertes et vous appelle quand un incident réel est détecté. C’est l’option “clé en main” pour les PME sans expertise sécurité interne.

Guide de choix

Besoin	Solution recommandée	Budget mensuel (PME 100 postes)
Visibilité de base sur les endpoints	EDR managé seul	300 - 1 500 €
Détection avec corrélation de sources	SIEM cloud ou XDR	500 - 3 000 €
Détection + réponse sans expertise interne	MDR	2 000 - 5 000 €
SOC complet externalisé	SOC-as-a-Service	2 000 - 5 000 €

Déployer un SIEM : les erreurs à éviter

Erreur 1 : tout connecter dès le départ

Connecter 30 sources de logs le premier jour produit un déluge d’alertes impossibles à gérer. Commencez par 3 à 5 sources prioritaires (passerelle email, Active Directory, Microsoft 365, firewall, EDR) et ajoutez les sources suivantes une fois que les premières sont correctement calibrées.

Erreur 2 : ne pas calibrer les règles

Les règles de détection par défaut d’un SIEM génèrent un volume élevé de faux positifs. Un analyste SOC noyé sous les faux positifs finit par ignorer les alertes — y compris les vraies. Prenez le temps de calibrer chaque règle sur votre environnement : quelles sont les adresses IP légitimes, les plages horaires normales, les comportements attendus de chaque service ?

Erreur 3 : déployer un SIEM sans personne pour lire les alertes

Un SIEM sans analyste est un outil inutile. Si vous n’avez personne en interne pour surveiller et investiguer les alertes, choisissez un service managé (MDR ou SOC externalisé) plutôt qu’un SIEM que vous opérez vous-même. L’outil est la moindre partie — c’est l’expertise humaine qui transforme des logs en détection d’attaques.

Erreur 4 : ignorer la rétention des logs

En cas d’incident, l’investigation forensique nécessite des logs historiques. Si votre SIEM ne conserve que 30 jours de données, vous ne pourrez pas retracer une attaque dont la phase de mouvement latéral a duré deux mois. L’ANSSI recommande une rétention minimale de 6 mois pour les logs de sécurité, et 12 mois pour les logs d’authentification.

Avant de déployer un SIEM, vérifiez que votre configuration email ne génère pas de bruit inutile. Un domaine sans DMARC en p=reject laisse passer des emails usurpés qui encombrent vos logs et compliquent la détection. Testez votre configuration avec notre vérificateur de sécurité email.

Le concept de SIEM est normalisé par les bonnes pratiques du NIST Cybersecurity Framework (fonction “Detect”) et les recommandations de l’ANSSI sur la journalisation et la détection d’incidents.