SIEM open source ou commercial : Wazuh, Elastic, Splunk et Sentinel comparés
Le choix d'un SIEM se joue rarement sur les fonctionnalités. Il se joue sur le volume de journaux, la durée de conservation et l'équipe capable d'exploiter l'outil. Quatre solutions, huit critères identiques.
« Quel SIEM choisir ? » La question est presque toujours posée dans le mauvais ordre. On compare des listes de fonctionnalités, des captures d’écran de tableaux de bord, des promesses de détection par apprentissage automatique. Puis, six mois après la mise en service, on découvre que la facture dépend du volume de journaux, que les alertes s’accumulent sans être lues, et que personne n’a le temps d’écrire les règles. Ce comparatif part de l’autre bout : ce qu’il faut pour qu’un outil de gestion des informations et des événements de sécurité (SIEM) détecte vraiment, qu’il s’agisse d’un SIEM open source ou d’une solution commerciale.
Quatre solutions très répandues sont examinées sur les mêmes critères : Wazuh, Elastic Security, Splunk et Microsoft Sentinel. Aucune n’est éditée ni distribuée par DOSOBE. Les informations reflètent la documentation publique des éditeurs à la date de l’article ; les modèles de prix évoluant souvent, aucun tarif n’est cité.
Ce qu’un SIEM fait, et ce qu’il ne fait pas seul
Un SIEM collecte des journaux (serveurs, postes, pare-feu, annuaire, applications, services en nuage), les normalise, les corrèle avec des règles de détection, déclenche des alertes et conserve l’historique pour l’investigation. Il ne décide de rien. Une alerte non qualifiée est un bruit ; une règle non maintenue devient obsolète au premier changement d’infrastructure.
Les sources ne se valent pas. Pour une première mise en service, quelques-unes concentrent l’essentiel de la valeur de détection : l’annuaire (authentifications, création de comptes, changements de droits), la messagerie, l’accès distant (VPN, bastion), les outils de protection des postes et les journaux d’administration des services en nuage. Commencer par elles, avec des règles éprouvées, donne des résultats plus vite qu’une collecte exhaustive dont personne n’exploite la moitié.
D’où une règle de lecture pour tout le comparatif : la valeur d’un SIEM est le produit de trois facteurs, la qualité des sources collectées, la pertinence des règles et la capacité humaine à traiter les alertes. Si l’un des trois est nul, le résultat l’est aussi.
Quatre solutions, quatre modèles
Wazuh est une plateforme libre, issue du projet OSSEC, qui associe un agent installé sur les machines, un serveur d’analyse et un moteur d’indexation dérivé d’OpenSearch. Elle couvre la détection d’intrusion sur l’hôte, le contrôle d’intégrité des fichiers, l’évaluation de configuration, la détection de vulnérabilités et la corrélation de journaux. L’éditeur propose une offre hébergée et du support payant ; le logiciel lui-même est gratuit.
Elastic Security repose sur la pile Elastic (Elasticsearch, Kibana) et ajoute des règles de détection prêtes à l’emploi, publiées en source ouverte, un agent de protection des postes et des outils d’investigation. Une partie significative des fonctions de sécurité est disponible dans l’offre gratuite ; les fonctions avancées, comme la détection d’anomalies par apprentissage automatique, relèvent des abonnements payants. Après le passage à des licences non libres en 2021, l’éditeur a ajouté en 2024 l’AGPL aux licences proposées pour le code source.
Splunk est une plateforme commerciale de traitement de données machine, à laquelle s’ajoute l’application Enterprise Security pour les usages SIEM. Son langage de requête (SPL) et son catalogue d’applications et d’intégrations sont très riches, et beaucoup d’analystes de sécurité y ont été formés. Splunk appartient à Cisco depuis le rachat finalisé en 2024. Il s’installe sur site ou s’utilise en service hébergé.
Microsoft Sentinel est un SIEM en service sur Azure, adossé à un espace de travail Log Analytics et interrogé avec le langage KQL. Il s’intègre étroitement aux produits de sécurité de Microsoft (Defender, Entra ID, Microsoft 365) et automatise les réponses par des scénarios fondés sur Logic Apps. Il n’existe pas en version installable sur site.
Le comparatif, critère par critère
| Critère | Wazuh | Elastic Security | Splunk | Microsoft Sentinel |
|---|---|---|---|---|
| Licence | Libre (GPL v2) | Code source disponible, plusieurs licences dont AGPL ; fonctions avancées sous abonnement | Propriétaire | Service propriétaire |
| Hosting | Sur site, nuage de son choix ou offre hébergée de l’éditeur | Sur site, nuage de son choix ou offre hébergée de l’éditeur | Sur site ou service hébergé | Azure uniquement, région au choix |
| Collecte | Agent propre, syslog, intégrations nuage | Agent unifié, nombreuses intégrations | Transitaires (forwarders), catalogue d’intégrations très large | Connecteurs natifs Microsoft, agents et connecteurs tiers |
| Langage de détection | Règles et décodeurs au format XML | KQL, EQL, ES|QL ; règles publiées en source ouverte | SPL | KQL |
| Correspondance MITRE ATT&CK | Oui | Oui | Oui | Oui |
| Réponse automatisée | Réponse active sur l’agent | Actions et gestion de cas intégrées | Produit SOAR distinct | Scénarios automatisés (Logic Apps) |
| Modèle de coût | Infrastructure et temps humain ; support optionnel | Ressources consommées ou abonnement | Volume ingéré ou ressources consommées | Volume ingéré et conservé |
| Compétences requises | Élevées en administration et en écriture de règles | Élevées pour la pile auto-hébergée, moindres en service | Moyennes à élevées, vivier d’analystes formés | Moyennes, forte affinité avec l’écosystème Microsoft |
Aucune ligne ne départage seule. La correspondance avec le référentiel MITRE ATT&CK, par exemple, est offerte par les quatre : ce qui compte est le nombre de techniques réellement couvertes par vos règles actives, sur vos sources réelles.
Ce qui fait vraiment le coût
Trois postes dominent, quelle que soit la solution.
Le volume ingéré. Les journaux des pare-feu, des serveurs mandataires et des contrôleurs de domaine peuvent représenter l’essentiel du volume. Pour les solutions facturées au volume, c’est la variable principale ; pour les solutions auto-hébergées, elle se retrouve dans le stockage et la puissance de calcul. Filtrer à la source ce qui n’a aucune valeur de détection est la première économie.
La durée de conservation. Les investigations sur une compromission ancienne demandent des mois d’historique. Plusieurs solutions proposent un stockage « froid » moins coûteux mais plus lent à interroger. La durée doit être décidée à partir de vos obligations et de vos scénarios d’investigation, pas fixée par défaut.
Le temps humain. Écrire et ajuster les règles, qualifier les alertes, maintenir la collecte quand l’infrastructure change : c’est le poste le plus sous-estimé, et il ne disparaît avec aucune solution.
Comparer un SIEM gratuit à un SIEM payant sur le seul prix de licence fausse la décision. Un outil libre exploité par une équipe compétente peut coûter moins cher qu’une solution commerciale ; le même outil sans équipe coûte du temps perdu et donne une fausse impression de sécurité.
Open source ou commercial : le vrai arbitrage
- Pas de coût de licence lié au volume : on peut collecter largement
- Hébergement libre, y compris chez un hébergeur qualifié ou sur ses propres serveurs
- Code et règles inspectables, pas de dépendance à la feuille de route d’un éditeur
- Communauté active et règles partagées
- Installation, mise à jour et dimensionnement à votre charge
- Support communautaire, sauf contrat avec l’éditeur ou un intégrateur
- Compétences rares sur le marché, à garder dans la durée
- Intégrations parfois moins complètes avec certains services en nuage
Les solutions commerciales inversent cet équilibre : plus rapides à mettre en service, mieux intégrées à certains écosystèmes, soutenues par un éditeur, mais avec une dépendance plus forte et un coût qui croît avec le volume. Elastic se situe entre les deux, avec une offre gratuite étendue et des fonctions avancées payantes.
Quel choix selon votre situation
Votre environnement est majoritairement Microsoft 365 et Azure. Sentinel réduit fortement le travail de collecte et de corrélation sur ces sources. Vérifiez la région d’hébergement, la conservation et le coût des sources tierces volumineuses, qui peuvent changer l’équation.
Vous avez des exigences fortes de souveraineté ou d’hébergement sur site. Wazuh et Elastic auto-hébergés laissent le choix de l’infrastructure. En France, un prestataire de détection d’incidents qualifié par l’ANSSI peut exploiter ces outils pour vous.
Vous disposez déjà d’une équipe d’analystes formés et d’un volume important. Splunk et Elastic offrent la plus grande profondeur d’analyse. Le coût doit être modélisé sur trois ans, à volume croissant.
Vous êtes une organisation de taille moyenne, sans équipe de sécurité dédiée. Le premier choix n’est pas l’outil mais le mode d’exploitation : service managé ou prestataire de détection. L’outil suivra souvent la préférence de ce prestataire, ce qui doit être pesé au regard de la réversibilité.
Dans tous les cas, écrire ses cas d’usage de détection avant de choisir (quelles menaces, sur quelles sources, avec quelle réaction attendue), et les exprimer quand c’est possible au format ouvert Sigma, protège mieux de la dépendance que n’importe quelle clause contractuelle. Ce travail de cadrage relève de notre expertise cybersécurité et conformité ; pour les obligations qui l’encadrent, voir notre dossier NIS 2.
- Documentation publique de Wazuh (wazuh.com, documentation.wazuh.com).
- Documentation publique d’Elastic Security et dépôt public des règles de détection d’Elastic.
- Documentation publique de Splunk Enterprise Security.
- Documentation publique de Microsoft Sentinel (Microsoft Learn).
- MITRE, référentiel ATT&CK.
- Projet Sigma, format ouvert de règles de détection (SigmaHQ).
- ANSSI, référentiel d’exigences des prestataires de détection des incidents de sécurité (PDIS).
Questions fréquentes
Un SIEM open source est-il suffisant pour une organisation soumise à NIS 2 ?
Il peut l'être. NIS 2 impose des mesures de gestion des risques, dont la détection et la gestion des incidents, sans désigner d'outil. Un SIEM open source bien configuré, alimenté par les bonnes sources et exploité par une équipe compétente, répond à cette exigence. La question décisive est l'exploitation : qui surveille, qui qualifie les alertes, qui réagit.
Faut-il un SOC pour utiliser un SIEM ?
Il faut au minimum une organisation qui lit les alertes et agit, interne ou externalisée. Sans cela, le SIEM devient un entrepôt de journaux coûteux. Beaucoup d'organisations de taille moyenne s'appuient sur un prestataire de détection qui exploite l'outil pour elles.
Peut-on changer de SIEM facilement ?
La collecte se migre assez bien ; les règles de détection beaucoup moins, car chaque solution a son langage. Écrire ses règles au format Sigma, un format ouvert de description des détections convertible vers plusieurs langages, et documenter ses cas d'usage réduit nettement la dépendance.
Combien coûte un SIEM ?
Les modèles de prix diffèrent (volume ingéré, ressources consommées, nombre d'équipements, abonnement de support) et changent régulièrement : seul un devis sur votre volume réel est fiable. Pour comparer, il faut ajouter au coût de l'outil l'hébergement, le stockage sur la durée de conservation choisie et surtout le temps humain d'exploitation.