Doublons de logs : distinguer retransmission et action répétée

Périmètre des intégrations : Seculogik utilise une architecture indépendante des sources pour ingérer les alertes et événements de sécurité via son propre modèle de données. Wazuh et OpenSearch sont les premières intégrations. Les autres sources citées correspondent à des connecteurs prévus ; leur disponibilité doit être confirmée pour chaque évaluation.

Après une reprise de collecte, plusieurs lignes semblent raconter la même connexion. Faut-il compter plusieurs tentatives ou une seule ? Supprimer les lignes ressemblantes peut rendre un tableau de bord plus lisible, tout en effaçant des actions réellement distinctes. Les conserver sans explication peut, à l’inverse, gonfler une alerte fondée sur un seuil.

La question utile n’est donc pas seulement « ces lignes se ressemblent-elles ? », mais « représentent-elles la même occurrence, selon une identité dont nous connaissons les garanties ? ». Voici une méthode indépendante des outils pour enquêter sur les doublons, tester une correction et documenter son effet. Elle ne suppose aucune capacité d’intégration Seculogik disponible.

1. Séparer l’action, l’événement et sa livraison

Notre recommandation : commencer avec trois niveaux. Une action est ce qui s’est produit dans le système examiné. Un événement est l’enregistrement qu’une source en produit. Une livraison est une arrivée de cet enregistrement dans votre chaîne de collecte. Plusieurs livraisons peuvent correspondre à un événement ; plusieurs événements peuvent également décrire des aspects différents d’une action.

Une authentification vue par un fournisseur d’identité et par une application ne devient pas automatiquement un doublon. Les deux observations peuvent apporter des informations différentes. À l’inverse, deux arrivées d’un même événement source ne prouvent pas deux authentifications. Corréler des observations et supprimer une retransmission sont deux décisions distinctes.

Délimitez la source, l’organisation, le flux et la période touchés. Relevez où la multiplication apparaît : export source, collecteur, transformation, stockage ou requête d’affichage. Conservez quelques références consultables avant de modifier le traitement. N’exportez pas tous les logs par défaut, et gardez les éléments sensibles dans leurs emplacements autorisés.

2. Vérifier ce que garantit réellement l’identifiant

CloudEvents 1.0.2 définit l’identité d’un événement par la combinaison source et id. Une retransmission peut garder cette combinaison ; un consommateur peut alors la traiter comme un doublon. Cette garantie appartient au contrat CloudEvents et à sa mise en œuvre, pas à n’importe quel champ appelé « identifiant ». Source : spécification CloudEvents

Notre recommandation : retrouver la documentation de la source et suivre un échantillon de bout en bout. Qui attribue l’identifiant ? Désigne-t-il une occurrence, un type d’événement, une transaction ou une ligne nouvellement créée à l’arrivée ? Est-il conservé pendant une reprise ? Dans quel périmètre est-il unique ? Un identifiant ajouté à chaque ingestion ne permet pas, à lui seul, de reconnaître une livraison précédente.

OpenTelemetry décrit également log.record.uid comme un identifiant distinguant les enregistrements ; sa convention suppose des valeurs différentes pour des enregistrements distincts. Cette convention est facultative et affichée au stade de développement dans la documentation consultée. Ne supposez donc ni sa présence ni le respect de ce contrat par tous vos producteurs. Source : OpenTelemetry

Si l’identité source n’est pas assez documentée, gardez la conclusion « doublon présumé ». Une clé de rapprochement proposée par votre équipe reste une hypothèse à tester. Vérifiez notamment les changements d’instance, les remises à zéro et les collisions entre organisations avant d’autoriser une suppression.

3. Comparer les livraisons sans confondre ressemblance et identité

Elastic ECS distingue notamment event.id, event.hash et event.ingested : identité de l’événement, empreinte du contenu brut et heure d’arrivée dans le stockage central. Ces champs ont des fonctions différentes ; leur nom ne dispense pas de contrôler comment votre chaîne les renseigne. Source : Elastic ECS, champs d’événement

Nous recommandons de comparer, pour chaque paire candidate, l’identité source documentée, la provenance, les éléments significatifs du contenu, les heures disponibles et le chemin de collecte. Une arrivée plus tardive peut être compatible avec une reprise, sans en constituer à elle seule la preuve. Recherchez aussi les opérations de relance ou de relecture connues de l’équipe de collecte.

Une empreinte identique établit une égalité de contenu selon la représentation et l’algorithme choisis, sous leurs limites ; elle n’établit pas automatiquement l’unicité d’une action. Deux opérations distinctes peuvent produire le même texte. À l’inverse, un enrichissement ajouté à l’arrivée peut modifier le contenu d’une retransmission. Documentez ce qui entre dans la comparaison et ce qui en est exclu.

Évitez surtout une clé fondée uniquement sur le compte, le résultat et une heure arrondie. Elle peut fusionner plusieurs tentatives rapprochées. Si deux enregistrements portant la même identité documentée ont un contenu significatif contradictoire, conservez les deux et faites examiner l’anomalie. Ne choisissez pas silencieusement le plus récent.

4. Tester la déduplication avant de retirer des éléments

Notre recommandation : commencer par marquer les doublons candidats dans un environnement de test ou une vue parallèle. Comparez les résultats avec la vue non dédupliquée, sans effacer les sources nécessaires à la vérification. Définissez le périmètre, la durée de conservation de l’état de déduplication et le comportement attendu lorsqu’un enregistrement arrive tardivement.

Préparez des données synthétiques sans secret et au moins ces situations :

• Le même événement source est livré plusieurs fois avec son identité conservée.
• Deux événements distincts ont un texte identique et des identités différentes.
• Des producteurs ou organisations distincts utilisent le même identifiant local.
• Une livraison arrive après la fenêtre de rapprochement retenue.
• Un identifiant manque, ou deux contenus contradictoires partagent une identité.
• Une relecture autorisée traverse le traitement une nouvelle fois.

Pour chaque situation, écrivez le résultat attendu avant le test. Vérifiez les occurrences conservées, les références vers les livraisons regroupées et le traitement des anomalies. Une baisse du volume affiché ne suffit pas à démontrer que la correction fonctionne. Vérifiez aussi qu’une répétition réelle reste visible et que les frontières entre organisations sont respectées.

Exemple entièrement fictif : deux tentatives de connexion distinctes ont le même compte, le même résultat et la même seconde affichée, mais des identités source différentes. Chacune est ensuite livrée une deuxième fois. Sous un contrat d’identité vérifié, la vue dédupliquée doit conserver les deux occurrences, avec la trace de leurs retransmissions. Elle ne doit les réduire ni à une seule tentative, ni les présenter comme quatre actions indépendantes.

5. Contrôler les conséquences sur les détections et les dossiers

Une modification de déduplication change potentiellement ce que comptent les requêtes en aval. Notre recommandation : identifier les détections à seuil, les tableaux de bord et les dossiers qui utilisent le flux concerné. Pour chacun, préciser si le chiffre attendu représente des livraisons, des événements source distincts ou des actions corroborées. Ces unités ne sont pas interchangeables.

Rejouez les scénarios synthétiques sur les détections pertinentes. Une séquence réellement répétée doit encore atteindre le résultat attendu ; une retransmission seule ne doit pas fabriquer cette séquence lorsque la règle compte des événements distincts. Conservez la version du traitement et de la règle utilisées pour comparer les résultats. Ne réécrivez pas les conclusions d’anciens dossiers sans examen de leur périmètre.

Dans un dossier déjà ouvert, expliquez la correction : quelles lignes ont été regroupées, selon quelle identité, quelles occurrences restent distinctes et quelle incertitude demeure. Si la visibilité historique ne permet pas de reconstituer les livraisons, dites-le. La disparition d’une alerte après modification du comptage ne prouve pas que l’activité sous-jacente était bénigne.

6. Définir une preuve de reprise durable

Avant la mise en service, nommez le responsable du traitement, le critère de succès et la procédure de retour à la version précédente. Surveillez ensuite les identifiants manquants, les collisions de contenu, les arrivées hors fenêtre et les reprises connues. Les seuils utiles dépendent de votre flux ; il n’existe pas ici de durée universelle de déduplication à appliquer à toutes les sources.

Le résultat attendu est une décision explicable : ce qui est compté, ce qui a été regroupé, pourquoi et avec quelle limite. Pour prolonger cette vérification, consultez notre guide sur la reprise d’une collecte SIEM interrompue. Une collecte revenue et un comptage fiable demandent chacun leur propre vérification.