Cartographier les logs disponibles : le problème du corpus pour l'anonymisation
Cartographier les logs disponibles : le problème du corpus pour l’anonymisation
Entraîner un agent d’anonymisation pose un problème paradoxal : les données les plus utiles à l’entraînement sont précisément celles que personne ne partage. Les logs réels de production contiennent exactement les entités sensibles qu’on cherche à détecter — et c’est pour ça qu’ils restent dans les datacenters.
Cette contrainte a des conséquences directes sur la qualité des modèles. Cet article recense les corpus disponibles, leur niveau de sanitisation, leur densité en entités sensibles, et la façon dont on peut les compléter par des données synthétiques.
Le prérequis : des logs non sanitisés
La recherche sur l’analyse de logs a longtemps fonctionné avec des jeux de données “propres” — anomaly detection, parsing, clustering — où les données sensibles étaient déjà masquées. Pour l’anonymisation, c’est l’inverse : on a besoin de voir les données brutes pour apprendre à les détecter.
Critères d’un bon corpus pour l’entraînement d’un agent d’anonymisation :
- Non sanitisé — les entités sensibles (IPs, comptes, hostnames) sont présentes à l’état brut
- Varié — plusieurs systèmes, plusieurs formats (syslog, CEF, JSON, .evtx)
- Annoté ou annoatable — soit des labels existent, soit le format permet l’annotation automatique
LogHub : la référence fondamentale
LogHub s’impose comme le corpus de référence pour la recherche sur les logs système. Il maintient une collection de logs provenant de systèmes réels ou de laboratoires, explicitement non sanitisés dans la mesure du possible. Plus de 450 organisations de recherche l’utilisent.
| Dataset | Système | Durée | Taille | Lignes | Entités sensibles |
|---|---|---|---|---|---|
| HDFS_v1 | Fichiers distribués | 38,7 h | 1,47 GiB | 11,2 M | IDs de blocs (quasi-identifiants) |
| BGL | Supercalculateur | 214,7 j | 708 MiB | 4,7 M | Nœuds de calcul, PIDs |
| Thunderbird | Supercalculateur | 244 j | 29,6 GiB | 211 M | Hostnames, IPs, comptes |
| Windows | OS | 226,7 j | 26 GiB | 114 M | SIDs, noms d’utilisateurs, Event IDs |
| Linux | OS | 263,9 j | 2,25 MiB | 25 K | Hostnames, IPs, services, paths |
| Apache | Serveur Web | 263,9 j | 4,90 MiB | 56 K | IPs clients, paths, user-agents |
| OpenSSH | Authentification | 28,4 j | 70 MiB | 655 K | IPs, usernames, ports, clés |
Pour le cas d’usage “logs éditeurs”, les datasets prioritaires sont OpenSSH et Linux : dense en IPs, hostnames, comptes de service — exactement les entités qu’un ingénieur support ne devrait pas voir.
Les logs HDFS illustrent un piège classique : leurs identifiants de blocs (blk_-1234567890123) sont des quasi-identifiants techniques. Les masquer casse la cohérence logique du log — l’ingénieur ne peut plus suivre le cycle de vie d’un bloc. Les conserver permet une attaque par liaison de données. Ce dilemme — utilité vs confidentialité — revient dans chaque corpus.
Les corpus de sécurité : densité maximale en PII
SecRepo et logs de compromission
SecRepo fournit des échantillons de logs provenant de systèmes réels, parfois issus de compromissions. La densité en données sensibles y est maximale :
- 86 000 lignes d’
auth.log— tentatives SSH avec IPs sources, noms d’utilisateurs ciblés, timestamps précis - Logs de pot de miel (honeypot) en JSON — payloads d’attaques avec IPs d’attaquants, patterns d’exploitation
- Journaux Squid (~200 Mo) — URLs visitées, IPs clients, user-agents
Ces logs sont particulièrement utiles pour entraîner la détection des entités à haute densité : un seul fichier auth.log peut contenir plusieurs milliers d’adresses IP sources et des centaines de noms d’utilisateurs tentés en force brute.
CIC-IDS2017 et CSE-CIC-IDS2018
Les jeux de données du Canadian Institute for Cybersecurity combinent logs de trafic réseau (PCAP) et logs d’événements machine, générés dans une infrastructure simulant une entreprise réelle : 420 PC, 30 serveurs, 7 scénarios d’attaque.
Pour un agent d’anonymisation, ces données testent des scénarios difficiles :
- Infiltration réseau : noms d’utilisateurs et structures de répertoires exposés via SMB ou RDP
- Attaques DoS : volumes massifs de logs avec des IPs sources variées — test de passage à l’échelle
- Botnets : domaines de commande et contrôle (C2) et patterns de communication — quasi-identifiants d’infrastructure
LANL Unified Host and Network Dataset
Le Los Alamos National Laboratory a publié un dataset couvrant 90 jours d’activité réseau et hôte (bien que partiellement dé-identifié). Plusieurs centaines de millions d’événements d’authentification utilisateur-ordinateur.
Son intérêt principal pour l’évaluation : tester la résistance aux attaques par corrélation temporelle. Un utilisateur dont les horaires de connexion sont réguliers peut être ré-identifié en analysant les motifs d’authentification sur une longue période — même si son nom a été remplacé par un token. Le dataset LANL reproduit exactement ce scénario à grande échelle.
Le benchmark SDLog : apprentissage supervisé
L’étude SDLog (Aghili et al., 2025) a introduit le premier benchmark annoté spécifiquement pour la détection de données sensibles dans les logs logiciels : 32 000 entrées annotées, couvrant 16 systèmes différents.
| Système | % d’entrées sensibles | Réseau (IP/MAC) | Chemins fichier | Identifiants | URL/Config |
|---|---|---|---|---|---|
| HDFS | 100,0% | 71,4% | 14,3% | 100,0% | 0,0% |
| Apache | 66,7% | 16,7% | 33,3% | 33,3% | 0,0% |
| Hadoop | 58,8% | 14,0% | 5,3% | 42,1% | 7,1% |
| BGL | 22,5% | 6,7% | 12,5% | 3,3% | 0,0% |
| Android | 10,2% | 0,0% | 0,6% | 9,6% | 0,0% |
| HealthApp | 0,0% | 0,0% | 0,0% | 0,0% | 0,0% |
Deux constats frappants :
HDFS à 100% — chaque entrée contient au moins un identifiant sensible. C’est le corpus d’entraînement le plus dense, mais aussi le plus délicat : masquer les identifiants de blocs casse la corrélation entre événements.
HealthApp à 0% — une application peut générer des logs techniques sans aucune donnée sensible. L’agent doit apprendre à ne pas sur-anonymiser.
SDLog utilise CodeBERT comme backbone : son score F1 atteint 98,4% avec seulement 100 exemples de fine-tuning, ce qui confirme la puissance des modèles pré-entraînés sur du code pour comprendre la structure des logs.
La complexité des formats
Windows Event Log (.evtx)
Les journaux Windows utilisent un format binaire propriétaire encapsulant du XML structuré. Avant tout traitement NLP, une étape de décodage est nécessaire.
Les Event IDs critiques pour l’anonymisation :
| Event ID | Événement | Données sensibles |
|---|---|---|
| 4624 / 4625 | Connexion réussie / échouée | Nom d’utilisateur, domaine, IP source |
| 4688 | Création de processus | Ligne de commande complète — peut contenir mots de passe et clés API |
| 7045 | Installation de service | Compte de service, chemin d’exécution |
L’Event ID 4688 est particulièrement à risque : il enregistre la commande complète du processus créé, ce qui peut inclure des paramètres sensibles passés en arguments.
Outils d’extraction :
Get-WinEvent(PowerShell) — export XML structuréEvtxECmd— export CSV/JSON, colonnesPayloadDataannotablesWELM(NSA) — définitions de messages pour tous les Event IDs sans avoir à rencontrer d’instance réelle
Linux : la variabilité des formats
Sous Linux, les logs sont en texte brut — avantage NLP. Mais la variabilité des formats produits par les différents démons (Apache, OpenSSH, Postfix, journald) nécessite une capacité de généralisation élevée.
| Source | Format | Entités sensibles |
|---|---|---|
/var/log/auth.log |
Syslog RFC 3164 | IP, username, méthode PAM, clé SSH |
/var/log/apache2/error.log |
Apache HTTPD | IP client, chemin système, user-agent |
/var/log/kern.log |
Syslog kernel | Adresses mémoire, identifiants matériels |
journald (JSON) |
JSON structuré | Tout + métadonnées système |
Données synthétiques : compléter les lacunes
Quand les logs réels ne couvrent pas suffisamment de cas de figure, ou que leur utilisation pose des problèmes éthiques, la génération synthétique comble les lacunes.
| Outil | Mécanisme | Force | Licence |
|---|---|---|---|
| Log-synth | Schémas JSON | Génère des millions de lignes de logs serveur Web | Apache-2.0 |
| Synthcity | GAN / VAE | Préserve l’intégrité statistique, métriques de privacy intégrées | Apache-2.0 |
| Greenmask | Transformation déterministe | Maintient l’intégrité référentielle entre colonnes | Apache-2.0 |
L’avantage clé du synthétique pour l’évaluation : on sait exactement où se trouvent les entités sensibles. On peut mesurer le rappel (recall) de l’agent avec précision, ce qu’un corpus annoté imparfaitement ne permet pas.
Notre pipeline utilise également un LLM (Claude, Phi-3.5-mini) pour générer des exemples annotés à partir de logs bruts — voir l’article suivant sur le fine-tuning spaCy.
Quel corpus pour quel objectif
| Objectif | Corpus recommandé | Raison |
|---|---|---|
| Entraîner la détection NER de base | LogHub OpenSSH + Linux | Dense, non sanitisé, formats classiques |
| Tester la robustesse multi-système | SDLog (32K annotations) | 16 systèmes, labels standardisés |
| Valider sur des scénarios d’attaque | CIC-IDS2017 | Logs d’attaque réels avec IPs, comptes |
| Tester la corrélation temporelle | LANL Dataset | 90 jours, millions d’authentifications |
| Combler des cas de figure rares | Log-synth + Synthcity | Génération contrôlée, recall mesurable |
| Logs Windows spécifiques | EVTX-ATTACK-SAMPLES | Scénarios de mouvement latéral |
Le problème du corpus pour l’anonymisation est structurellement difficile : les meilleures données restent privées. L’état de l’art combine corpus académiques (LogHub, SDLog), corpus de sécurité (SecRepo, CIC-IDS), et génération synthétique contrôlée. Cette combinaison — avec un LLM pour l’annotation automatique — est précisément la stratégie adoptée pour constituer notre dataset d’entraînement NER sécurité.
Ressources :