Collecter et fiabiliser les logs de sécurité

Collecter et fiabiliser les logs de sécurité

La détection ne commence pas dans un SIEM (Security Information and Event Management), elle commence dans les journaux produits par les systèmes. Sans collecte exhaustive, horodatage fiable et schéma cohérent, une règle de détection ne protège rien : elle interroge seulement un récit incomplet, parfois inventé par des champs mal mappés.

Explication de la marmotte

Gérer des événements de sécurité ressemble à rassembler les témoignages après un accident : si chacun raconte l’heure, le lieu et les faits dans un format différent, personne ne peut reconstruire ce qui s’est passé. Le but est d’obtenir des informations comparables avant de chercher un responsable.

→ Lire l’explication complète de la marmotte

La qualité des événements avant le choix du SIEM

Le compromis central est brutal : normaliser coûte du temps d’ingénierie continu, des compétences métier et une discipline de changement ; ne pas normaliser coûte des détections aveugles, des enquêtes interminables et des faux positifs impossibles à expliquer. Le second coût reste souvent invisible jusqu’à l’incident. Le premier apparaît immédiatement dans un budget, donc il perd fréquemment contre une licence présentée sur une slide avec trois graphiques bleus.

La recommandation est nette : financer une plateforme de données de sécurité avant d’étendre le catalogue de détections ou de changer de SIEM. Cette position vaut dès qu’au moins trois familles de sources produisent des événements, par exemple pare-feu, applications et environnement cloud. En dessous, un schéma maison minimal peut suffire. Au-delà, traiter chaque connecteur comme un projet isolé fabrique une dette technique qui se cache dans les règles de corrélation.

Une donnée exploitable porte au minimum : l’heure de l’événement, l’heure de réception, la source émettrice, l’identité concernée, l’action observée, le résultat, la cible et un identifiant stable permettant de retrouver le message brut. Les champs absents doivent rester explicitement absents. Inventer success=true parce qu’une source ne fournit pas le résultat transforme une hypothèse en fait de sécurité. C’est efficace pour améliorer les tableaux de bord, beaucoup moins pour comprendre une compromission.

Le schéma OCSF (Open Cybersecurity Schema Framework) fournit des classes d’événements et une sémantique interopérable. Il réduit le coût de rapprochement entre produits, surtout pour les authentifications, activités réseau et changements de configuration. Il ne remplace pas la modélisation : les extensions fabricant, les conventions de nommage et les événements propres au métier doivent conserver une gouvernance. Un schéma maison est acceptable s’il est versionné, documenté et testé comme une interface publique. Sans cela, ce n’est pas un schéma, c’est une collection de suppositions en JSON (JavaScript Object Notation).

Les sujets de détection réseau et de réponse opérationnelle restent détaillés dans les menaces réseau. La collecte de flux, elle, dépend aussi des décisions prises dans l’architecture réseau et les services cloud.

Collecte des logs, buffers et horodatage

Chaque source doit disposer d’un chemin de collecte identifié : émission locale, agent, relais, file persistante, stockage brut et index de recherche. Le chemin doit survivre à une indisponibilité du SIEM. Envoyer directement un pare-feu ou une application vers un indexeur central sans tampon durable fait dépendre la preuve d’un incident de la disponibilité d’un seul composant. C’est une architecture optimiste. L’optimisme est une stratégie de sauvegarde étonnamment peu populaire après un incident.

Un buffer mémoire absorbe une pointe, pas une panne. Sa capacité doit être calculée à partir du débit maximal observé, de la durée d’interruption admissible et d’une marge pour les rafales. Une file persistante sur disque doit disposer de seuils d’alerte sur son occupation, son âge maximal et son taux de rejet. Lorsqu’elle sature, le comportement doit être connu : bloquer l’émetteur, perdre les messages récents ou évincer les anciens. Aucun de ces choix n’est neutre. Pour l’audit et l’investigation, évincer les anciens est généralement le pire choix, car il détruit le début de la séquence.

L’heure doit être produite par la source et préservée sans réécriture. Chaque événement doit aussi recevoir une heure de réception à l’entrée de la plateforme. Synchroniser les équipements avec NTP (Network Time Protocol), en UTC (temps universel coordonné), est un prérequis de détection, pas une préférence d’exploitation. Une dérive de quelques minutes entre un contrôleur d’identité, un poste et un pare-feu peut inverser une chaîne causale : la connexion paraît suivre l’action qu’elle a déclenchée.

Les sources doivent déclarer leur fuseau horaire, leur précision et leur comportement lors des changements d’heure. Une application qui émet une date locale sans décalage rend deux heures indistinguables lors du passage à l’heure d’hiver. Une corrélation temporelle ne peut pas réparer une ambiguïté absente du message initial.

La collecte cloud mérite la même sévérité. Les interfaces programmatiques des fournisseurs imposent des quotas, livrent parfois les événements avec retard et peuvent échouer partiellement. Conserver un curseur de lecture persistant, relire avec recouvrement temporel et dédupliquer avec un identifiant d’événement sont obligatoires. Une interrogation périodique sans curseur robuste crée soit des trous, soit des doublons. Les deux finissent par polluer les détections, chacun à sa manière.

Normalisation, mapping et conservation du brut

La normalisation traduit un événement natif vers un contrat commun. Elle ne consiste pas à renommer src_ip en source.ip et à déclarer la mission accomplie. Il faut définir la signification de chaque champ : une adresse source peut désigner un client, un relais, un conteneur ou une adresse traduite. Les quatre valeurs peuvent être présentes dans le même événement et elles ne sont pas interchangeables.

Un mapping doit séparer les faits observés, les enrichissements et les inférences. L’adresse privée d’un actif, le pays déduit d’une adresse publique et le niveau de criticité issu d’un inventaire n’ont pas la même provenance ni la même stabilité. Écraser l’adresse native par une valeur enrichie empêche de rejouer l’analyse lorsque l’inventaire change. Conserver le message brut, son empreinte cryptographique et la version du parseur permet de prouver comment un champ a été obtenu.

Chaque règle de mapping doit être versionnée et associée à des jeux d’événements de référence. Modifier le sens d’un champ est une rupture de contrat : les règles de détection, tableaux de bord et recherches historiques doivent être évalués avant le déploiement. Un champ user.name qui reçoit tantôt un identifiant technique, tantôt une adresse de messagerie, casse silencieusement les jointures. Les moteurs de recherche ne protestent pas, ils trouvent autre chose avec un aplomb admirable.

Le format commun ne garantit pas l’exhaustivité. Un EDR (Endpoint Detection and Response) voit les processus et certains fichiers, pas nécessairement la requête applicative qui a initié l’action. Un pare-feu voit un flux, pas l’utilisateur réel derrière une traduction d’adresse. La reconstitution exige donc des sources complémentaires, une gestion d’identité cohérente et des journaux applicatifs. Les mécanismes d’authentification et de traçabilité associés sont liés aux choix décrits dans les architectures d’identité.

Exemple de mapping contrôlé d’un événement de pare-feu

Un test de mapping doit échouer lorsqu’un champ critique est absent ou ambigu. L’exemple suivant transforme un événement JSON minimal en structure commune et refuse un résultat de connexion inconnu. Il nécessite jq, un fichier local et aucune dépendance réseau.

# Créer un événement brut représentatif, conservé ensuite comme jeu de test.
cat > firewall-event.json <<'EOF'
{
  "timestamp": "2026-09-22T08:15:04Z",
  "device_name": "fw-edge-01",
  "src_ip": "198.51.100.24",
  "dst_ip": "10.20.4.18",
  "dst_port": 443,
  "action": "allow"
}
EOF

# Produire un événement normalisé et échouer si l'action est inconnue.
jq -e '
  if (.action | IN("allow", "deny")) then
    {
      time: .timestamp,
      observer: { name: .device_name },
      source: { ip: .src_ip },
      destination: { ip: .dst_ip, port: .dst_port },
      activity: "network-connection",
      status: (if .action == "allow" then "success" else "failure" end)
    }
  else error("action pare-feu non mappée")
  end
' firewall-event.json

Ce test ne valide pas le comportement du pare-feu, seulement le contrat de transformation. Ajouter ensuite des cas de refus, de champ manquant, d’adresse IPv6, de traduction d’adresse et d’horodatage invalide. Le test doit être exécuté à chaque modification du parseur et avant toute mise à jour de connecteur.

Surface d’attaque et exploitation de la plateforme de données

Les journaux sont une cible. Un attaquant cherche à désactiver l’audit, saturer un collecteur, modifier une configuration de rétention ou injecter des événements trompeurs. Une source compromise peut aussi fabriquer des événements valides en apparence. La normalisation augmente la comparabilité, elle n’établit pas la véracité du fait.

Protéger les flux entre sources, relais et stockage par authentification mutuelle, contrôle d’accès minimal et chiffrement en transit. Séparer les identités d’écriture, de lecture et d’administration. Un compte capable de supprimer les journaux et de modifier la rétention ne doit jamais être utilisé par un collecteur. Les accès d’investigation doivent être journalisés dans un domaine distinct, sinon l’effacement des traces devient circulaire, ce qui est presque poétique et totalement inexploitable.

La conservation brute doit être immuable pendant la durée décidée par la politique de sécurité. L’immuabilité n’empêche pas la suppression à l’expiration, elle empêche une modification discrète avant cette échéance. La rétention, la localisation des données et les informations personnelles relèvent d’une gouvernance documentée, pas d’une promesse de conformité magique. Pour cadrer les responsabilités et les arbitrages d’architecture, consulter la gouvernance de la sécurité.

Superviser la chaîne elle-même : taux reçu par source, taux rejeté par parseur, retard d’ingestion, profondeur des files, dérive d’horloge, proportion de champs nuls et volume quotidien par type d’événement. Une baisse brutale de volume est souvent plus grave qu’une hausse. Elle peut signaler un collecteur mort, une règle de filtrage trop large ou un attaquant qui a trouvé le bouton d’arrêt.

La reprise exige des sauvegardes du schéma, des parseurs, des configurations de collecte, des identités de service et des métadonnées de curseur. Restaurer seulement les index sans restaurer les versions de mapping produit une archive lisible mais sémantiquement douteuse. Conserver les secrets de collecte dans un gestionnaire dédié, les faire tourner et tester leur remplacement. Une clé expirée qui coupe la remontée de journaux ne fait pas de bruit ; elle laisse juste un trou parfaitement silencieux.

🐝 Ce qui arrive si on s’en passe

Sans normalisation ni contrôle de collecte, la ruche reste ouverte sur des points que les règles de détection ne montrent jamais. La recherche rétrospective devient impraticable : un indicateur publié après coup ne peut pas être confronté à des mois d’événements dont les champs portent des noms et des sens variables selon la source. La couverture cesse d’être mesurable, car rien ne relie une source à la détection qu’elle alimente, et l’arrêt d’un connecteur passe pour un calme opérationnel. Les archives perdent leur valeur probatoire lorsque le message brut, son empreinte et la version du parseur manquent, puisque l’origine d’un champ n’est plus démontrable. Enfin, tout changement d’outil impose de réécrire le sens des données au lieu de le transporter.

🦫 Explication de la marmotte 🍫

Les équipements et logiciels produisent des traces lorsqu’une personne se connecte, qu’un programme démarre, qu’une connexion réseau est autorisée ou qu’un réglage change. Ces traces arrivent sous des formes différentes. La première étape consiste à les récupérer sans perte, même lorsqu’un service central tombe temporairement. Des files stockées sur disque gardent les messages en attente, mais elles doivent être surveillées : lorsqu’elles sont pleines, des informations disparaissent.

Chaque trace doit contenir l’heure où le fait s’est produit et l’heure où elle a été reçue. Les machines doivent partager une horloge réglée de façon cohérente. Sinon, une enquête peut placer une action avant sa cause.

Ensuite, un programme transforme les messages pour utiliser les mêmes noms et les mêmes significations. Une adresse, un compte ou un résultat doivent toujours vouloir dire la même chose. Le message original est conservé, car une transformation peut contenir une erreur. Des tests vérifient qu’un changement ne casse pas les recherches existantes.

Cette préparation permet de relier plusieurs traces pendant une enquête. Elle ne garantit pas qu’une trace est vraie, ni qu’aucune source ne manque. Il faut donc protéger les accès, surveiller les retards et les pertes, garder des copies des réglages et tester la reprise. Si la collecte s’arrête ou si un champ est mal traduit, les outils d’alerte continuent parfois à fonctionner, mais leurs réponses deviennent fausses.

À lire aussi

• 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.
• SIEM open source coûte-t-il vraiment moins cherLe 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.
• 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.
• SOC centre des opérations de sécurité : rôle, organisation, mesureCe qu'est un SOC (centre des opérations de sécurité), comment il s'organise, quel modèle choisir et comment juger s'il détecte vraiment les attaques.

Pages voisines

La citent

• EDR : fonctionnement, angles morts et contournements
• AI Act : journalisation automatique d'une IA à haut risque (articles 12, 19 et 26)
• Le journal que personne ne lit

Collecter et fiabiliser les logs de sécurité

Elle cite

• Normaliser les logs avec OCSF, ECS ou CIM
• Architecture de journalisation d’audit immuable centralisée
• Sécuriser NTP contre le spoofing et la dérive d’horloge