Résumé Technique : Interrogation de Journaux de Sécurité Sans Analyseur

Énoncé du Problème

Les analystes en sécurité interrogent régulièrement les journaux système pour détecter des menaces et enquêter sur des incidents, mais la diversité des formats de journaux crée un goulot d'étranglement significatif. Bien que les journaux soient peu coûteux à produire, ils sont coûteux à utiliser car chaque source (pare-feu, services d'authentification, agents de point de terminaison) utilise son propre format semi-structuré.

L'approche standard de l'industrie consiste à construire des analyseurs par source pour normaliser les journaux en schémas structurés (par exemple, OCSF) avant l'analyse. Bien que puissante, cette méthode nécessite un effort d'ingénierie continu pour maintenir les analyseurs à mesure que les formats évoluent ; par exemple, Google SecOps maintient environ 1 000 analyseurs actifs avec plus de 200 mises à jour par mois. À l'inverse, sauter l'étape d'analyse et rechercher directement dans les fichiers bruts avec des outils comme grep ou des scripts ad hoc évite les coûts de maintenance mais reporte la charge sur l'analyste. Cette approche manuelle nécessite une connaissance approfondie des variantes spécifiques des messages et peine à exprimer des requêtes temporelles complexes et multi-lignes (par exemple, « trouver les utilisateurs qui se sont connectés depuis deux adresses IP différentes dans un délai de 60 secondes »), qui nécessitent un état, un regroupement et une agrégation.

Les deux approches échouent pour la même raison : elles nécessitent une connaissance préalable de la syntaxe et de la sémantique du journal source. Les pipelines structurés encodent cela dans des analyseurs, tandis que les flux de travail en texte brut obligent l'analyste à le reconstruire manuellement.

Méthodologie : Le Système Sieve

Les auteurs présentent Sieve, un système qui génère du code d'exécution de requêtes à partir de questions de sécurité en langage naturel, sans nécessiter d'analyseurs préconstruits ni de schémas normalisés. Sieve fonctionne en ancrant un modèle de langage de grande taille (LLM) avec un contexte de format de journal léger, extrait automatiquement.

Aperçu du Pipeline

Sieve fonctionne en quatre étapes :

1. Construction de l'invite : Le système assemble une invite contenant la requête en langage naturel, le chemin du fichier journal et une « stratégie de contexte » (exemples de modèles de journal ou lignes brutes). Il inclut également des contraintes (par exemple, le code doit être Python ou Bash, aucune écriture réseau/fichier) et une spécification de sortie.
2. Génération de code : Un LLM (principalement Gemini 3.1 Pro Preview ou OpenAI GPT-5.4) est invoqué une fois par requête pour émettre un script Python ou Bash autonome. Le modèle reçoit l'instruction de retourner le code dans un wrapper JSON pour assurer une extraction fiable.
3. Exécution en bac à sable : Le code généré s'exécute dans un sous-processus sans accès réseau et avec des permissions de système de fichiers restreintes. Il est soumis à des vérifications de sécurité (rejet de eval, exec, rm, etc.) et à une validation du format de sortie.
4. Mécanisme de nouvelle tentative : Si l'exécution échoue, le script génère une exception ou le format de sortie est violé, le message d'erreur est renvoyé au LLM pour une nouvelle tentative. Jusqu'à quatre nouvelles tentatives sont autorisées.

Stratégies de Contexte

Pour ancrer le LLM dans le format de journal spécifique, Sieve évalue cinq stratégies pour fournir un contexte :

• Modèles Matryoshka : Utilise un pipeline LLM hors ligne pour générer des modèles sémantiques de haute qualité avec des espaces réservés pour les champs nommés.
• Drain3 : Un analyseur en flux qui extrait des modèles avec des caractères génériques dans un seul passage.
• Modélisateur basé sur la fréquence : Un algorithme léger et heuristique (inspiré d'IPLoM) qui normalise les jetons, les regroupe par longueur et identifie les positions variables pour produire des modèles en moins de dix secondes sans appels LLM.
• Échantillon aléatoire : Fournit 100 lignes de journal échantillonnées aléatoirement sans modèles explicites.
• Sans contexte : Fournit uniquement une ligne d'exemple unique, en s'appuyant sur les connaissances pré-entraînées du modèle.

Le système traite le LLM comme un compilateur : il génère la logique d'extraction une fois, et le script résultant s'exécute de manière déterministe à la vitesse normale d'un programme sur l'ensemble du journal.

Contributions Clés

1. Pipeline Sieve : Un système open source pour l'interrogation assistée par LLM de journaux de sécurité bruts qui génère du code exécutable à partir du langage naturel, ne nécessitant qu'un seul appel LLM par requête suivi d'une exécution déterministe.
2. Benchmarks : Un nouveau benchmark comprenant 133 requêtes de sécurité réparties sur 5 types de journaux (Audit Linux, SSH, cron, Puppet, DHCP). Les requêtes vont de filtres simples (Classe 1–2) à des corrélations multi-lignes complexes impliquant des fenêtres temporelles et une agrégation étatique (Classe 3–4). Des réponses de vérité terrain sont fournies pour toutes les requêtes.
3. Exploration de l'espace de conception : Une évaluation des stratégies de contexte, des langages d'exécution (Python vs Bash) et des familles de modèles pour déterminer la configuration optimale pour l'interrogation de journaux.
4. Comparaisons de référence : Une comparaison par rapport à une référence humaine (analystes écrivant des scripts grep/Python naïfs en moins de 10 minutes) et à un pipeline d'analyse structurée automatisé (Matryoshka).

Résultats Expérimentaux

L'évaluation a été menée sur 133 requêtes réparties sur 5 types de journaux.

• Performance vs Référence Humaine : Sieve correspond aux performances humaines sur les requêtes de filtrage simples mais surpasse significativement la scripture manuelle sur les requêtes complexes. Sur les charges de travail complexes (détection de force brute, identification d'anomalies de session, corrélation inter-événements), Sieve réduit le taux d'erreur moyen de 0,34 (humain) à 0,10, soit une réduction d'environ 3,6×. Les gains les plus importants ont été observés sur les tâches nécessitant l'analyse des horodatages, la jointure d'événements par des identifiants partagés et le maintien d'un état de fenêtre glissante.
• Performance vs Analyse Structurée : Sur les charges de travail de filtrage simples, Sieve (utilisant le contexte léger Drain3) atteint un score F1 macro de 0,981, ce qui est dans la marge de bruit du pipeline d'analyse structurée Matryoshka (0,999). Cela démontre que le code généré par LLM peut approcher la précision des représentations entièrement analysées sans l'étape de génération d'analyseur hors ligne.
• Stratégie de Contexte : Le choix de la source de modèle importe moins que prévu. Un modélisateur simple basé sur la fréquence (s'exécutant en quelques secondes sans appels LLM) a produit des résultats statistiquement indiscernables des modèles Matryoshka à fort effort. Le facteur critique est la couverture des variantes de messages plutôt que la sophistication de la représentation du modèle.
• Choix du Langage : Python est le défaut supérieur pour les requêtes complexes. Bien que Bash performe de manière comparable sur les filtres simples, il échoue significativement sur les requêtes temporelles étatiques (par exemple, les requêtes complexes DHCP ont vu une chute de 0,815 F1 en Python à 0,446 en Bash) en raison des limitations dans la gestion des structures de données et de l'arithmétique des horodatages.
• Robustesse du Modèle : Le pipeline se transfère entre les familles de modèles (Gemini 3.1 Pro et GPT-5.4), bien que GPT-5.4 ait montré des performances inférieures sur les tâches étatiques complexes dans cette configuration spécifique.

Signification et Revendications

L'article revendique que Sieve comble le fossé entre l'expressivité de l'interrogation de journaux structurés et l'immédiateté du travail direct avec des fichiers bruts. Sa signification principale réside dans la démonstration que le code généré par LLM peut servir de plan de requête juste-à-temps qui élimine le besoin de maintenance continue d'analyseurs tout en préservant la précision de l'analyse structurée.

Les auteurs soutiennent que Sieve est particulièrement précieux pour la « longue traîne » des requêtes d'analystes qui tombent en dehors du schéma normalisé d'un SIEM ou pour des enquêtes ad hoc où la pression temporelle empêche la construction d'un analyseur. En déplaçant le coût de l'ingénierie continue (maintenance des analyseurs) vers un coût borné par requête (un appel LLM + exécution déterministe), Sieve offre une alternative évolutive à l'architecture « normaliser d'abord, interroger ensuite ». Les résultats suggèrent que pour les enquêtes de sécurité complexes, la génération automatique de code n'est pas seulement faisable mais supérieure à la scripture manuelle, à condition que le système soit ancré avec un contexte de format de journal suffisant.