Recollect & Rank : quand un LLM désanonymise vos logs

Une opération d’anonymisation réussie au sens technique — toutes les IPs masquées, tous les comptes remplacés par des tokens — peut échouer au sens de la confidentialité si le contexte restant permet de reconstruire ce qui a été masqué. Ce n’est pas une hypothèse théorique. Les outils pour y parvenir sont disponibles publiquement.

Le problème des quasi-identifiants

La définition classique du PII (Personally Identifiable Information) couvre les données directement identifiantes : nom, numéro de sécurité sociale, adresse email. L’anonymisation standard se concentre sur ces données.

Les quasi-identifiants sont différents : pris isolément, ils n’identifient personne. Combinés, ils peuvent devenir uniquement identifiants.

La démonstration de Narayanan et Shmatikov (2008) sur la base Netflix reste la référence : 99% des utilisateurs pouvaient être identifiés avec seulement 8 évaluations de films et leurs dates approximatives. Les données étaient “anonymisées” — les noms supprimés, les identifiants remplacés par des nombres aléatoires. Le contexte résiduel a suffi.

Dans les logs de sécurité, les quasi-identifiants prolifèrent :

Aucun de ces éléments n’est une IP, un nom de compte, ou un hostname. Pourtant leur combinaison peut suffire à identifier une machine ou un utilisateur dans un environnement connu.

La méthode Recollect & Rank (R.R.)

L’attaque formalisée par Chen et al. (2025) dans “R.R.: Unveiling LLM Training Privacy through Recollection and Ranking” donne un cadre précis à ce que les attaquants peuvent faire avec des LLMs modernes.

Principe : soumettre les logs anonymisés à un LLM en lui demandant de reconstruire les données masquées depuis le contexte.

Log anonymisé :
  Mar 4 09:14:22 [HOSTNAME_001] sshd[3847]: Failed password for [USER_001]
  from [IP_001] port 52341 ssh2

Prompt attaquant :
  "Ce log provient d'un serveur Linux. Basé sur le port 52341,
   le service sshd, et le pattern d'échec, donne une liste
   de noms d'utilisateurs plausibles pour [USER_001] dans
   un contexte d'entreprise francophone."

LLM retourne :
  1. svc_admin, svc_splunk, svc_backup (comptes de service courants)
  2. j.dupont, p.martin (patterns nominatifs courants)
  3. root, admin (comptes génériques SSH)

La méthode est en deux temps :

1. Recollect — le LLM génère une liste de candidats plausibles pour la valeur masquée
2. Rank — les candidats sont classés par vraisemblance selon le contexte disponible

Condition de succès : le contexte résiduel dans le log anonymisé est “bavard” — il contient des informations qui contraignent l’espace des valeurs possibles.

Quand le contexte trahit le masque

Prenons un log d’authentification Windows après anonymisation :

Event ID 4624 — Successful Logon
Account Name: [USER_001]
Account Domain: [DOMAIN_001]
Logon Type: 3
Source Network Address: [IP_001]
Source Port: 49152
Workstation Name: [HOST_001]
Logon Process: NtLmSsp
Authentication Package: NTLM

Ce qui reste visible après anonymisation :

• Logon Type 3 → connexion réseau (pas locale, pas RDP, pas service)
• Port 49152 → port éphémère Windows, connexion sortante depuis le client
• NtLmSsp + NTLM → authentification NTLM (pas Kerberos → domaine absent ou accès crossdomaine)
• Event ID 4624 → connexion réussie

Un analyste ou un LLM bien prompté peut inférer : connexion réseau NTLM réussie depuis un poste Windows vers ce serveur, probablement un partage SMB ou une connexion WMI. Les candidats pour [USER_001] sont des comptes avec accès réseau NTLM sur cette machine. L’espace de recherche se réduit considérablement.

k-anonymité et l-diversité : métriques de résistance

La k-anonymité fournit une garantie formelle contre la ré-identification : un enregistrement satisfait la k-anonymité si au moins k-1 autres enregistrements lui sont indiscernables sur tous les quasi-identifiants.

En pratique : si [USER_001] apparaît dans au moins k logs avec des contextes différents (Logon Types différents, heures différentes, machines différentes), l’attaquant ne peut pas distinguer lequel des k utilisateurs est concerné.

Le problème de la l-diversité : la k-anonymité ne suffit pas si tous les k enregistrements similaires partagent la même valeur sensible. Si [USER_001] apparaît 10 fois (k=10) mais que dans les 10 cas, le contexte révèle qu’il s’agit d’un compte de service commençant par svc_, l’espace de recherche est toujours très contraint.

La l-diversité exige que, pour chaque groupe de k enregistrements similaires, les valeurs sensibles soient réparties entre au moins l valeurs distinctes.

Dans les logs de sécurité, ces garanties sont difficiles à maintenir :

• Un log d’authentification échouée répétée sur le même compte crée naturellement des groupes homogènes (même compte, k fois)
• La l-diversité exigerait de “bruiter” artificiellement des logs ou de les agréger — ce qui détruit leur utilité pour le diagnostic

Tests de ré-identification : comment évaluer son agent

La méthode recommandée : tester systématiquement les logs anonymisés par l’agent contre un attaquant simulé.

# Squelette de test de ré-identification
for test_case in reidentification_suite:
    anonymized_log = anonymizer.process(test_case["original"])

    # L'attaquant LLM tente de reconstruire les entités masquées
    attacker_guesses = llm_attacker.recollect_and_rank(
        anonymized_log,
        entity_type=test_case["masked_entity_type"],
        top_k=5
    )

    # Succès de l'attaque si la vraie valeur est dans les top-5
    if test_case["original_value"] in attacker_guesses:
        attack_successes.append(test_case)

Un agent performant doit minimiser le taux de succès de cette attaque, particulièrement sur les entités à haute valeur : comptes de service, hostnames de contrôleurs de domaine, subnets critiques.

Métriques à mesurer :

• Taux de succès top-1 : la valeur originale est le premier candidat LLM
• Taux de succès top-5 : la valeur originale est dans les 5 premiers candidats
• Taux de succès par type d’entité : certains labels sont plus vulnérables (les comptes de service ont des patterns prévisibles : svc_*)

Le cas LANL : corrélation temporelle sur 90 jours

Le dataset LANL (Los Alamos National Laboratory) illustre le risque de ré-identification par corrélation temporelle. Il couvre 90 jours d’authentifications sur 420 PC et 30 serveurs.

Le scénario : un utilisateur [USER_001] a été anonymisé. Mais ses horaires de connexion sont réguliers (9h-18h, pause déjeuner 12h-13h30, connexions depuis toujours le même [HOST_001]). Sur 90 jours, ce profil comportemental est unique dans l’organisation.

L’attaquant n’a pas besoin de deviner le nom du compte — il peut corréler le profil comportemental des logs anonymisés avec d’autres sources (calendrier public de l’entreprise, posts LinkedIn, etc.) pour identifier l’individu derrière [USER_001].

Contremesures :

• Généraliser les timestamps (heure arrondie à la demi-heure au lieu de la seconde)
• Supprimer les logs de faible valeur qui ne font que renforcer le profil comportemental
• Introduire du bruit temporel contrôlé dans les séquences d’événements

Ces contremesures dégradent l’utilité du log pour le diagnostic. C’est le compromis fondamental de l’anonymisation : plus la protection est forte, moins le log est exploitable.

Ce que ça implique pour le design de l’agent

Les attaques de ré-identification ont des implications directes sur l’architecture :

1. Ne pas anonymiser seulement les entités explicites L’agent doit identifier et potentiellement généraliser les quasi-identifiants contextuels — versions de logiciels trop précises, combinaisons atypiques d’Event IDs, séquences temporelles caractéristiques.

2. Varier les tokens selon le contexte de destination Un log envoyé à un éditeur pour support technique n’a pas le même niveau de risque qu’un log archivé pendant 5 ans. La stratégie de remplacement doit être calibrée par destination.

3. Tester l’anonymisation avec un attaquant LLM Le score de rappel NER (combien d’entités ont été détectées) est nécessaire mais insuffisant. Le vrai critère est la résistance aux attaques de ré-identification simulées.

4. Auditer les patterns résiduels Après anonymisation, vérifier que les patterns comportementaux (volume de trafic, séquences d’événements, distributions temporelles) ne permettent pas d’inférer les identités masquées.

Conclusion : l’anonymisation est un processus, pas un état

Un log anonymisé n’est pas “sûr” dans l’absolu — il est plus ou moins résistant à une classe d’attaques contre un niveau d’effort attaquant donné. La k-anonymité et la l-diversité fournissent des garanties formelles, mais elles ne résistent pas aux attaques LLM qui exploitent le contexte sémantique plutôt que les quasi-identifiants structurels.

L’agent d’anonymisation doit être évalué non seulement sur ce qu’il masque, mais sur ce que le contexte restant permet d’inférer. C’est un problème d’adversarial robustness — pas seulement de precision/recall NER.

Ressources :

• R.R.: Unveiling LLM Training Privacy through Recollection and Ranking (arXiv:2502.12658)
• SDLog — Détection de sensibilité dans les logs (arXiv:2505.14976)
• LANL Unified Host and Network Dataset
• De-Anonymizing Users via Record Linkage (MDPI)
• Article 1 : Le problème de l’anonymisation des logs de sécurité
• Article 5 : Cohérence inter-fichiers et session de remplacement partagée