Log Stitching : pourquoi corréler les logs change tout en détection avancée

Introduction

Dans la plupart des environnements modernes, la sécurité repose sur une multitude de sources de logs : EDR, pare-feu, Active Directory, VPN, proxy, outils cloud, etc. Individuellement, ces logs racontent une partie de l’histoire. Mais isolés, ils restent souvent incomplets, voire trompeurs.

C’est ici qu’intervient le log stitching :  une technique avancée qui consiste à relier des événements provenant de différentes sources pour reconstruire une séquence d’attaque cohérente.

Ce sujet est crucial pour les SOC, équipes DFIR, architectes XDR et responsables cybersécurité, car sans corrélation intelligente, les attaques modernes passent facilement sous le radar.

Dans cet article, nous allons :

• Définir précisément le log stitching,
• Expliquer pourquoi il est indispensable en détection moderne,
• Détailler comment il fonctionne concrètement,
• Illustrer son impact avec un exemple chiffré,
• Donner des conseils pratiques pour l’implémenter efficacement.

Qu’est-ce que le Log Stitching et pourquoi est-ce important ?

Le log stitching consiste à relier des événements isolés à travers différentes sources de logs afin de reconstruire une chronologie complète d’un incident.

Au lieu d’analyser :

• un login suspect,
• puis une exécution PowerShell,
• puis une connexion réseau inhabituelle,

Le log stitching permet de comprendre : qu’il s’agit de la même session utilisateur, sur la même machine, dans une même fenêtre temporelle, avec une intention malveillante cohérente.

' Sans stitching, chaque événement semble bénin. Avec stitching, ils forment une attaque.’

Pourquoi c’est essentiel :

• Les attaques modernes sont fragmentées
• Les adversaires exploitent le bruit
• Les outils isolés génèrent des alertes faibles
• Les faux positifs explosent sans corrélation

Le log stitching transforme un volume d’événements en narratif de compromission.

1.   Comment fonctionne le Log Stitching :

Étape 1 — Collecte multi sources :

Les sources typiques incluent :

• EDR (processus, hash, parent-child)
• Active Directory (logon events)
• Pare-feu (connexions sortantes)
• VPN
• Logs cloud (Azure AD, M365)
• DNS

Chaque source possède :

• son propre format,
• son propre timestamp,
• ses propres identifiants.

Étape 2 — Normalisation des données :

Avant de corréler, il faut normaliser :

• utilisateur → UPN unique
• hostname → format standardisé
• timestamps → UTC
• IP internes vs externes

Sans normalisation, le stitching échoue..

Étape 3 — Corrélation par identités communes :

Le stitching repose sur des pivots communs :

• User ID
• Session ID
• Hostname
• IP
• Process GUID
• Hash de fichier

Exemple simple :

1. 08:01 — Login VPN (User A)
2. 08:03 — Logon Windows (User A)
3. 08:05 — PowerShell execution (User A)
4. 08:07 — Connexion vers IP suspecte

Individuellement : faible criticité
Corrélés : scénario d’intrusion cohérent.

Étape 4 — Construction d’une timeline unifiée

Le résultat final est :

Login → Execution → Persistence → Beaconing → Lateral movement

Le log stitching produit une chaîne causale, pas une simple liste d’événements.

Exemple : impact sur la détection

Imaginons une entreprise recevant :

• 50 000 événements par jour
• 500 alertes faibles
• 10 incidents réels

Sans stitching :

• Chaque alerte est traitée individuellement
• 90 % sont ignorées
• Temps moyen d’investigation : 30 min par alerte

Charge SOC : 500×30=15000 minutes = 250 heures par jour

Avec stitching :

Les 500 alertes sont regroupées en :

• 25 séquences cohérentes
• Dont 10 réellement malveillantes

Nouvelle charge : 25×30=750 minutes = 12,5 heures par jour

s = 250 heures par jour

12,5 heures

Résultat :  Réduction massive du bruit et concentration sur les vraies chaînes d’attaque

Conseils pratiques pour implémenter le Log Stitching

·       Centraliser les logs (SIEM ou XDR)

·       Uniformiser les identifiants utilisateur et machine

·       Utiliser des corrélations temporelles dynamiques (ex : événements liés dans une fenêtre de 5 à 15 minutes)

·       Exploiter les graphes d’entités (User ↔ Host ↔ Process ↔ IP)

·       Mesurer le taux de réduction d’alertes après corrélation

Le log stitching est une discipline, pas une simple règle SIEM.