SIEM open source coûte-t-il vraiment moins cher

Éditorial

Le coût réel d’un SIEM open source se trouve dans la normalisation des journaux, l’entretien des détections et les compétences d’exploitation, rarement dans sa licence.

~11 min de lecture7 sections

SIEM open source coûte-t-il vraiment moins cher

En septembre 2026, le constat ne varie plus : un SIEM (Security Information and Event Management) open source ne remplace pas une licence par zéro euro, il remplace une dépense visible par une charge d’ingénierie continue. Le compromis central est brutal : on gagne la maîtrise du pipeline et des données, on paie des spécialistes capables de maintenir cette maîtrise quand les formats, les attaques et les systèmes changent.

Explication de la marmotte

Choisir une solution gratuite pour surveiller une entreprise ressemble à acheter un atelier vide plutôt qu’à louer un service clé en main. Le bâtiment ne coûte presque rien, mais il faut des personnes pour installer les machines, régler les outils et repérer ce qui cloche avant que la fumée sorte par le toit.

→ Lire l’explication complète de la marmotte

La licence absente ne supprime pas le coût du SIEM

Un SIEM collecte des événements, les rend comparables, recherche des comportements suspects et déclenche une réponse humaine ou automatisée. Les projets open source couvrent correctement le stockage, l’indexation, la recherche et parfois des règles prêtes à l’emploi. Ce sont les briques les plus visibles, donc celles que les comparatifs de prix adorent compter. Elles ne sont pas celles qui absorbent le plus d’heures.

Le coût réel se décompose ainsi :

coût total = plateforme + ingestion + normalisation + détection + investigation + exploitation + rétention

La plateforme comprend les nœuds, le stockage, le réseau, les sauvegardes et les mises à niveau. L’ingestion comprend les agents, les files d’attente et les connecteurs. Ces deux postes existent aussi chez un éditeur, mais le contrat commercial transfère une partie de la responsabilité technique. Avec l’open source, la responsabilité reste interne, même lorsque le logiciel est hébergé chez un fournisseur de cloud.

La normalisation est le premier gouffre discret. Un événement de connexion provenant d’un pare-feu, d’un annuaire, d’une application métier ou d’un service cloud ne porte ni les mêmes champs, ni la même heure, ni la même identité. Une règle qui cherche source.ip, user.name et event.outcome ne détecte rien si le connecteur produit client_address, login et status=OK. Le tableau de bord reste vert. La compromission aussi.

Les schémas communs, tels que Elastic Common Schema ou Open Cybersecurity Schema Framework, réduisent le problème sans le supprimer. Ils donnent une cible de données, pas une traduction fiable. Il faut décider si une adresse observée est l’origine réseau réelle ou celle d’un proxy, si un compte de service représente une personne, si un refus applicatif est un échec d’authentification, et si l’horodatage provient du producteur ou du collecteur. Ce travail relève de l’architecture, pas du copier-coller de pipeline.

La conservation des journaux précède donc le choix d’outil. Sans inventaire des sources, des propriétaires, des champs disponibles et des obligations de rétention, un SIEM open source devient un lac de données où chaque enquête commence par une pelle et finit par une facture d’astreinte.

Normalisation des logs : la dette qui ne dort jamais

Un pipeline d’ingestion fiable doit rejeter explicitement les événements incomplets, conserver la charge utile brute pendant une durée définie et produire des métriques de qualité. Accepter silencieusement un champ absent est une faute de conception : l’absence d’alerte peut alors signifier « aucune attaque » ou « parseur cassé ». Ces deux états ne doivent jamais partager le même silence.

La règle opérationnelle est simple : chaque source critique doit avoir un contrat de données versionné. Ce contrat définit les champs obligatoires, les valeurs autorisées, le fuseau horaire, l’identifiant de corrélation, le propriétaire et le test de non-régression. Lorsqu’un éditeur renomme un champ dans une mise à jour, le test doit échouer avant que la détection ne disparaisse. Les journaux applicatifs ont une passion historique pour les changements non documentés, probablement parce que les incidents ont besoin de loisirs créatifs.

Exemple de normalisation vérifiable avec jq

L’exemple suivant transforme un événement de connexion Amazon Web Services (AWS) en document cohérent. Il nécessite jq et un fichier JSON valide. Le résultat n’est pas un pipeline complet, mais il montre ce qui doit être testé : un résultat de connexion, une identité, une adresse source et un horodatage.

# Créer un événement de test minimal.
cat > cloudtrail-login.json <<'JSON'
{
  "eventTime": "2026-09-22T08:30:00Z",
  "eventName": "ConsoleLogin",
  "sourceIPAddress": "198.51.100.42",
  "userIdentity": { "arn": "arn:aws:iam::123456789012:user/alice" },
  "responseElements": { "ConsoleLogin": "Success" }
}
JSON

# Normaliser vers des champs de détection stables.
jq -c '
  select(.eventName == "ConsoleLogin") |
  {
    "@timestamp": .eventTime,
    event: {
      kind: "event",
      category: ["authentication"],
      type: ["start"],
      outcome: (
        if .responseElements.ConsoleLogin == "Success"
        then "success"
        else "failure"
        end
      )
    },
    user: { name: .userIdentity.arn },
    source: { ip: .sourceIPAddress }
  }
' cloudtrail-login.json

Le test doit aussi couvrir les échecs, les valeurs nulles, les identités fédérées, les adresses absentes et les événements hors format. Une transformation qui ne traite que le cas heureux est une démonstration commerciale avec des accolades.

La normalisation ne garantit pas l’intégrité de la source. Un attaquant ayant pris le contrôle d’un hôte peut modifier, couper ou noyer ses journaux avant leur collecte. Il faut donc envoyer les événements critiques vers un collecteur distant authentifié, restreindre les droits d’écriture, surveiller les trous temporels et horodater les reçus côté collecteur. La cryptographie protège le transport et l’accès aux archives, elle ne rend pas véridique un poste déjà compromis. Les mécanismes de clés et de rotation décrits dans Cryptographie restent nécessaires, mais ne remplacent pas une source digne de confiance.

Règles de détection : le produit gratuit livre des alertes, pas une défense

Une règle de détection est une hypothèse sur un comportement hostile, exprimée sur des données dont la sémantique doit rester stable. Importer un catalogue de règles au format Sigma, langage générique de détection, donne un point de départ. Ce n’est pas un centre opérationnel de sécurité emballé sous vide.

Chaque règle doit être validée contre trois jeux d’événements : activité normale représentative, attaque simulée ou trace publique fiable, puis données dégradées. Sans ce troisième jeu, une règle peut sembler excellente tout en échouant dès qu’un agent redémarre ou qu’un champ devient vide. Le taux de faux positifs ne mesure pas seul la qualité : une règle silencieuse parce qu’elle ne voit plus rien a un taux de faux positifs parfait. C’est une performance assez facile à vendre à un poisson rouge.

L’entretien permanent comprend au minimum :

• associer chaque règle à une source, un propriétaire et une technique adversaire documentée ;
• tester sa compilation après chaque changement de schéma ou de moteur ;
• revoir les exceptions, car une exception sans échéance est une désactivation avec un joli nom ;
• mesurer le délai entre l’événement brut, l’indexation et l’alerte ;
• supprimer les règles sans source fiable ni décision de réponse.

Le SIEM ne garantit ni l’investigation ni le confinement. Une alerte indiquant une élévation de privilège ne dit pas si le compte doit être suspendu, si une session active doit être révoquée, ni comment préserver les preuves. Ces décisions viennent des procédures de réponse, des droits d’administration séparés et d’une architecture d’identités cohérente. L’architecture cyber doit définir ces frontières avant de brancher des automatisations. Sinon, un connecteur d’action transforme une détection approximative en incident automatisé. Le robot zélé reste un robot zélé.

Compétence rare, exploitation banale et facture certaine

L’exploitation exige trois compétences rarement réunies dans un poste unique : ingénierie de données, détection d’intrusion et connaissance des systèmes surveillés. Savoir écrire une requête ne suffit pas à interpréter une authentification Kerberos, un appel d’interface de programmation applicative ou une séquence de déploiement continue. Savoir administrer une plateforme ne suffit pas à distinguer un comportement d’attaquant d’un comportement de sauvegarde.

Cette rareté inverse l’économie annoncée. Une licence commerciale chère peut coûter moins qu’un poste spécialisé mobilisé pour corriger les parseurs, enrichir les événements, répondre aux alertes et maintenir l’infrastructure. Le raisonnement doit comparer le coût annuel complet, y compris les absences, les astreintes, la formation, la supervision de la plateforme et le risque de dépendre d’une seule personne. L’open source réduit la dépendance à un éditeur, mais peut créer une dépendance à un opérateur irremplaçable. Ce n’est pas de la souveraineté, c’est une clé SSH avec une retraite à venir.

La supervision du SIEM doit porter sur le SIEM lui-même : volume entrant par source, retard de collecte, taux d’échec de parsing, événements rejetés, pression mémoire, saturation du stockage, échec de sauvegarde et temps de restauration mesuré. Les sauvegardes doivent inclure les configurations, les règles, les tableaux de bord, les dictionnaires d’enrichissement et les secrets de connecteurs. Restaurer seulement les index sans restaurer les règles revient à récupérer une bibliothèque après avoir brûlé le catalogue.

Les secrets d’ingestion exigent des comptes dédiés, des privilèges minimaux, une rotation documentée et une alerte lors d’échec d’authentification. Un jeton partagé entre tous les collecteurs rend impossible l’attribution d’un abus et transforme la révocation en coupure générale. Les connecteurs doivent accepter un recouvrement contrôlé de jetons pendant la rotation, sinon la sécurité se négocie à chaque renouvellement avec un arrêt de collecte en prime.

Le cas précis où l’open source devient rationnel

Le calcul s’inverse dans un cas étroit : l’organisation possède déjà une équipe durable de détection et d’ingénierie de données, exploite un volume de journaux dont la licence commerciale augmente plus vite que les coûts d’infrastructure, et doit conserver une maîtrise forte des schémas, des règles et de l’hébergement. Il faut aussi que cette équipe ait un mandat explicite pour maintenir le produit, pas seulement pour le déployer.

Dans cette situation, le SIEM open source devient une plateforme interne. Les connecteurs sont industrialisés, les contrats de données sont testés, les règles sont versionnées, les changements passent par intégration continue et les investigations alimentent le backlog de détection. Le gain ne vient pas de la gratuité du logiciel. Il vient de la réutilisation d’une compétence déjà financée et d’une échelle suffisante pour amortir l’effort.

La plupart des organisations ne sont pas dans ce cas. Elles disposent d’une équipe infrastructure, parfois d’une équipe sécurité, mais pas d’une capacité de détection disponible en continu. Elles choisissent l’open source au moment où la licence paraît excessive, puis découvrent que les alertes nécessitent une sémantique des données, que cette sémantique nécessite des propriétaires, et que les propriétaires ont d’autres priorités. La recommandation est donc nette : choisir un service commercial ou managé lorsque l’objectif est de réduire le temps de détection sans financer une équipe produit dédiée. Choisir l’open source seulement lorsque cette équipe existe déjà, que son financement est pérenne et que la gouvernance des données est prête. La gouvernance n’est pas un supplément administratif : c’est la condition qui évite de confondre autonomie et abandon.

🐝 Ce qui arrive si on s’en passe

Sans contrat de données ni entretien des détections, la porte de la ruche reste ouverte sur des angles morts silencieux. Les événements continuent d’arriver, mais leur chronologie devient inexploitable : horodatages hétérogènes et identités non réconciliées empêchent de reconstituer l’enchaînement d’une intrusion, donc d’en déterminer le point d’entrée et la portée. Les journaux conservés perdent alors leur valeur probatoire lors d’un contrôle ou d’une demande d’assurance, puisqu’on ne peut démontrer ni leur complétude ni leur intégrité de bout en bout. L’investigation est reportée sur un prestataire externe, au tarif d’urgence, qui recommence la normalisation pendant que l’accès de l’attaquant persiste. Enfin, une collecte interrompue ne laisse aucune trace visible : la rétention réglementaire paraît respectée alors que des périodes entières manquent, et l’absence sera constatée le jour où il faudra prouver le contraire.

🦫 Explication de la marmotte 🍫

Un système de surveillance de sécurité reçoit des traces laissées par les connexions, les serveurs, les applications et les services en ligne. Ces traces arrivent sous des formes différentes. Avant de pouvoir chercher une activité dangereuse, il faut les traduire dans un vocabulaire commun : même nom pour une adresse, même nom pour une identité, même manière d’indiquer un succès ou un échec. Si cette traduction se trompe ou s’arrête, les recherches peuvent ne plus voir une attaque.

Un logiciel gratuit peut faire une grande partie du stockage et de la recherche. Il ne décide pas seul du sens des données, ne vérifie pas que les traces reçues sont complètes, et ne sait pas quelles alertes sont normales dans une organisation donnée. Des personnes doivent écrire les règles de surveillance, les tester avec des activités légitimes et des attaques connues, puis les corriger lorsque les logiciels surveillés changent.

Il faut aussi surveiller l’outil de surveillance : une panne de collecte, un disque plein ou un identifiant expiré peut créer un angle mort. Les accès utilisés pour envoyer les traces doivent être limités et renouvelés. Les réglages et les données doivent être sauvegardés puis restaurés lors de tests.

Le choix gratuit devient rentable seulement lorsqu’une équipe compétente existe déjà pour faire ce travail durablement. Sans cette équipe, le prix évité sur la licence réapparaît en temps de spécialistes, en alertes mal réglées et en incidents détectés trop tard.

À lire aussi

• Collecter et fiabiliser les logs de sécuritéCollecter, horodater, normaliser et contrôler les événements de sécurité conditionne la détection autant que le choix du SIEM.
• Comment calibrer les alertes d’un SIEM sans noyer le SOCLa théorie de la détection explique pourquoi un SIEM trop bavard épuise les analystes, tandis qu’un SIEM silencieux masque les menaces réelles.
• Réduire la fatigue d’alerte dans un SOCConcevoir la priorisation, la corrélation et le tiering d’un SOC pour réduire la fatigue d’alerte sans masquer les incidents réels.
• Configurer une détection open source avec WazuhGuide pratique pour centraliser les journaux, installer Wazuh et détecter les premières tentatives d’accès suspectes sans SIEM commercial.

Pages voisines

La citent

• Le journal que personne ne lit
• Configurer une détection open source avec Wazuh
• SOC centre des opérations de sécurité : rôle, organisation, mesure

SIEM open source coûte-t-il vraiment moins cher

Elle cite

• Ce qu'on garde
• Comment structurer un mentorat technique sans dogme
• Réagir aux premières minutes d’un incident suspecté