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.py) transforme chaque ligne en log lisible :

flow: 147.32.84.59:25857 -> 62.107.124.67:7726 proto=TCP state=CON pkts=6 bytes=396

Ce format expose naturellement IP_ADDRESS, PORT_NUMBER, PROTOCOL — les trois labels sous-représentés dans les logs OPNsense/SSH/Apache du corpus v3.1.

2 000 lignes annotées, taux d’auto-accept ~96% (confiance LLM haute car le format est très structuré).

KernelDriver — Zenodo 1203289

Le dataset Dynamic Malware Analysis archive les appels système Windows capturés pendant l’exécution de 500 malwares (VirusShare) et de processus propres. Structure : une archive .7z de 415 Mo, un .txt par type de syscall par sample.

Format réel (découvert à l’ouverture de l’archive) :

Time=203783,Pid=812,MethodName=ZwCreateFile,ProcessName=\Device\HarddiskVolume1\WINDOWS\system32\winlogon.exe

Le script extract_kerneldriver.py parse ce format clé=valeur, normalise le chemin (\Device\HarddiskVolume1 supprimé), et génère :

syscall ZwCreateFile: process=winlogon.exe path=\WINDOWS\system32\winlogon.exe pid=812 sample=0

Syscalls retenus : ZwCreateFile, ZwOpenFile, ZwWriteFile, ZwConnectPort, ZwSetValueKey, ZwCreateKey, ZwCreateProcess, ZwCreateThread et variantes. Ce sont les appels les plus informatifs pour PROCESS_NAME et FILE_PATH.

2 000 lignes annotées, confiance ~0.97.

Corpus v3.11

Split : 16 246 train / 4 062 dev (80/20).

Résultats globaux

F1 : 88.0%   Precision : 85.8%   Recall : 90.3%

vs v3.1 : F1 +1.54%, Recall +3.33%.

Le Recall passe au-dessus de 90% — c’est la métrique critique pour l’anonymisation (une entité manquée = une fuite). Early stopping au step 3 800 (epoch 4), convergence rapide dès l’epoch 1 grâce au fine-tuning depuis en_anonyner.

Évaluation par label — v3.11 vs v3.1

Analyse

Ce qui a fonctionné

PROCESS_NAME passe de 61.8% à 92.9% : le dataset KernelDriver apporte exactement les exemples manquants — des noms de processus Windows dans leur contexte d’exécution. Le modèle v3.1 hésitait à classer les noms de processus courts (alg.exe, svchost.exe) ; il les reconnaît maintenant avec confiance.

PROTOCOL passe de 50% à 85.5% : les flows CTU-13 exposent proto=TCP, proto=UDP, proto=ICMP dans un contexte non ambigu. Le recall monte à 98.2% — le modèle ne manque presque plus aucun protocole.

FILE_PATH passe de 87.8% à 91% : les chemins Windows extraits des appels syscall (\WINDOWS\system32\...) diversifient le corpus au-delà des chemins Linux et Apache.

Les régressions — phénomène de dilution

Trois labels régressent significativement : PID (-20.9%), MAC_ADDRESS (-19.8%), FILE_HASH (-28.5%).

Cause probable : dilution. Le corpus v3.11 ajoute ~4 000 exemples où PID apparaît dans un contexte différent (valeurs à 3-4 chiffres dans des logs syscall, sans pid= contextuel fort). Le modèle généralise moins bien.

Pour MAC_ADDRESS et FILE_HASH : les nouveaux datasets n’en contiennent pas. Le ratio exemples-avec-MAC-ADDRESS / total baisse mécaniquement, et les exemples existants ne suffisent plus à ancrer la représentation.

Leçon : ajouter des données pour les labels faibles peut dégrader les labels forts si le ratio de représentation est perturbé. Un corpus équilibré requiert soit d’augmenter tous les labels proportionnellement, soit de contrôler le mélange au niveau des batchs.

Labels toujours à 0%

SCHEDULED_TASK, EVENT_ID : toujours sans exemples suffisants. Le corpus contient quelques exemples synthétiques, pas assez pour l’apprentissage. Ces labels nécessitent des logs Windows réels avec des planificateurs de tâches (schtasks.exe) et des Event IDs explicites (EventID 4688, EventID 7045).

Distance avec la production

Cibles production : F1 ≥ 90% global, Recall ≥ 93%, aucun label à F1 < 80%.

État v3.11 : F1=88%, Recall=90.3%. Environ 2 points sous la cible.

Labels encore sous 80% : PID (55%), COMMAND_LINE (25.9%), FILE_HASH (28.6%), HOSTNAME (56.5%), SCHEDULED_TASK (0%), EVENT_ID (0%).

Prochaines priorités :

1. Restaurer PID et MAC_ADDRESS — les exemples existants semblent insuffisants face à la dilution. Stratégie : ré-extraire des logs SSH/auth.log qui contiennent des PIDs dans un contexte clair (sshd[1234]:), augmenter les exemples MAC dans des logs ARP/DHCP.

2. COMMAND_LINE — nécessite des logs de processus avec lignes de commande complètes (Sysmon EventID 1, ps aux, bash history). Les logs actuels exposent peu de commandes complexes.

3. EVENT_ID et SCHEDULED_TASK — cibler des logs Windows Scheduler et Security Event logs avec EventIDs explicites.

4. Migration spaCy Transformers — tok2vec atteint son plafond naturel. Les gains marginaux deviennent difficiles à obtenir sans architecture plus profonde.

Datasets : CTU-13 Stratosphere IPS, Dynamic Malware Analysis — Zenodo 1203289. Scripts d’extraction disponibles dans Victor/training/scripts/.