Suite directe du bilan v3.16. Ce cycle couvre trois corpus successifs (v3.17, v3.18, v3.19) et trois problèmes distincts : améliorer URL_URI qui plafonnait à 80.9%, corriger SCHEDULED_TASK à 0%, et isoler un nouveau label KEY_FINGERPRINT du label FILE_HASH.
Corpus v3.17 — Diagnostic URL_URI Analyse des faux négatifs L’article précédent concluait sur URL_URI à 80.9% avec 66 FN. Le script analyze_fn.py donnait :
Total FN URL_URI : 66 Labels prédits à la place de URL_URI : — 66 (100.
Suite directe du bilan v3.11. Ce cycle a trois étapes : migration de l’architecture tok2vec vers un transformer, diagnostic systématique des faux négatifs par label, puis correction ciblée des causes racines identifiées. Résultat : F1 global 88% → 95,9%.
Contexte v3.12→v3.14 — Entre v3.11 et v3.14, trois cycles d’amélioration ont produit des résultats décevants : ajout de 500 exemples synthétiques EC2 pour HOSTNAME (+2 points de recall), tentatives de rééquilibrage des labels PID et MAC_ADDRESS.
Suite directe du bilan v3.1. L’évaluation par label avait identifié deux labels critiquement faibles : PROCESS_NAME (F1=61.8%) et PROTOCOL (F1=50%). Cause : pas assez de logs exposant ces entités dans le corpus d’entraînement. Ce cycle corrige ça en intégrant deux nouveaux datasets open source.
Nouveaux datasets CTU-13 — Stratosphere IPS Le dataset CTU-13 contient des captures réseau binetflow (CSV) avec des flows légitimes et malveillants étiquetés. Format :
SrcAddr,DstAddr,Proto,Sport,Dport,State,TotPkts,TotBytes,...,Label 147.32.84.59,62.107.124.67,tcp,25857,7726,CON,6,396,...,flow=Background Un script de conversion (extract_ctu13_flows.
AnonyNER est le composant NER du projet Victor — un modèle spaCy entraîné spécifiquement sur des entités sensibles de logs de sécurité. La version 3.1 marque un changement d’échelle significatif : passage de 12 à 30 labels, corpus multiplié par 8, et pour la première fois une évaluation complète par label sur un jeu de test indépendant.
Cet article est un bilan technique, pas un tutoriel. L’objectif est de montrer où en est le modèle, ce qui fonctionne réellement, et ce qui reste à faire pour une utilisation en production.
Avant d’envoyer des logs à un éditeur, de les injecter dans un LLM externe ou de les archiver conformément au RGPD, une question se pose inévitablement : ces fichiers contiennent-ils des informations qui exposent mon infrastructure ?
Les logs de sécurité sont denses en données sensibles — adresses IP internes, noms d’hôtes, identifiants de comptes de service, clés API, adresses MAC. Et contrairement aux bases de données ou aux formulaires, leur format n’est jamais tout à fait uniforme : chaque équipement, chaque version de daemon, chaque intégration produit ses propres variantes.
Fine-tuning NLP pour les logs · N°1
Fine-tuner un NER sur des logs serveur : méthodologie et choix du framework Un log serveur n’est pas du texte. C’est une séquence semi-structurée, produite par un démon, dans un format qui varie selon la version du logiciel, la configuration, et parfois l’humeur de l’admin qui a écrit le rsyslog.conf. Les modèles NLP généralistes — entraînés sur des corpus de presse et de Wikipedia — sont largement aveugles à ce type de données.
AnonyNER · N°1
Quand spaCy ne voit pas l’infrastructure : le problème NLP des logs de sécurité Avant d’envoyer des logs à un éditeur de logiciels pour investigation, à un LLM externe pour analyse, ou simplement de les archiver conformément au RGPD, une question s’impose : ces logs contiennent-ils des informations qui exposent mon infrastructure ?
La réponse est presque toujours oui. Et les outils NLP standards — aussi performants soient-ils sur le langage courant — sont largement aveugles aux entités spécifiques au domaine de la sécurité.
AnonyNER · N°2
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.
AnonyNER · N°3
Entraîner un NER sécurité : du corpus annoté au modèle en production Les entités de sécurité que spaCy standard ne détecte pas ne sont pas impossibles à apprendre — elles sont simplement absentes de ses données d’entraînement. La solution n’est pas de remplacer spaCy par un LLM lourd, mais d’entraîner le composant NER de spaCy sur des exemples spécifiques au domaine.
Ce chemin — annotation LLM-assistée → fine-tuning spaCy → modèle production léger — est à la fois robuste et déployable sans GPU.
AnonyNER · N°4
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.
AnonyNER · N°5
La session partagée : garantir la cohérence d’anonymisation sur un batch de logs Anonymiser un fichier de logs est résolu. Anonymiser un batch de fichiers de logs de manière cohérente — même entité, même token, partout — est un problème d’architecture non trivial que les outils standards ne résolvent pas.
C’est pourtant la condition minimum pour que les logs anonymisés restent exploitables par leur destinataire.
Le cas d’usage qui impose la contrainte L’infrastructure rencontre un problème critique.
