From IOCs to Regex: Automating CTI Operationalization for SOC with LLMs

1. Problématique

Les centres d'opérations de sécurité (SOC) dépendent fortement des rapports de renseignement sur les cybermenaces (CTI) pour identifier les indicateurs de compromission (IOCs). Cependant, il existe un fossé fondamental entre la description textuelle des comportements d'attaquants dans les rapports CTI et la manière dont ces activités sont enregistrées dans les journaux de logs système (variations de chemins, capitalisation, paramètres dynamiques).

• Le goulot d'étranglement : Bien que l'extraction automatique d'IOCs à partir de textes soit de plus en plus courante grâce aux modèles de langage (LLM), la transformation de ces IOCs bruts (chaînes de caractères) en expressions régulières (regex) opérationnelles reste un processus manuel, lent et sujet aux erreurs.
• Les limites des approches actuelles :
  • Les méthodes existantes s'arrêtent souvent à l'extraction d'IOCs bruts, laissant aux analystes la tâche difficile de les convertir en regex.
  • Les tentatives d'automatisation des règles de détection (SIEM) produisent rarement des regex complexes, se limitant souvent à des correspondances littérales simples (IPs, domaines).
  • La génération directe de regex par des LLMs souffre de trois problèmes majeurs :
    1. C1 (Groupe de capture) : Incapacité à distinguer les parties fixes (groupe de capture) des parties variables (groupe non-capturant) d'un IOC.
    2. C2 (Validité) : Tendance à produire des regex syntaxiquement invalides ou incomplets.
    3. C3 (Généralisation) : Risque de créer des regex trop larges (trop de .*) qui génèrent de faux positifs, ou trop stricts qui manquent les variantes d'attaque.

2. Méthodologie : Le système IOCRegex-gen

Les auteurs proposent IOCRegex-gen, un système entièrement automatisé basé sur les LLMs conçu pour combler ce fossé. L'architecture se divise en deux phases principales :

Phase 1 : Identification des groupes de capture (Capture Group Finding)

Cette phase vise à résoudre le problème C1 en déterminant quelles sous-chaînes d'un IOC doivent être traitées comme des groupes de capture (éléments fixes) et lesquelles comme des groupes non-capturants (éléments variables).

• Base de connaissances graphiques : Le système utilise une base de données graphique (Neo4j) contenant les structures hiérarchiques natives des systèmes d'exploitation (chemins de fichiers Windows, clés de registre, arguments de ligne de commande).
• Algorithmes de détection :
  • Pour les chemins de fichiers et registres : L'algorithme identifie la plus longue séquence de sous-chaînes adjacentes qui existent dans la base de données graphique (ex: C:\Users\Public est fixe, 11.bat est variable).
  • Pour les lignes de commande : Il distingue les commandes principales (ex: schtasks) de leurs paramètres, en utilisant la structure arborescente de la base de données pour identifier les éléments natifs vs les valeurs injectées par l'attaquant.
• Filtrage : Les IOCs ne contenant aucun groupe de capture valide sont éliminés comme de faux positifs de l'extraction précédente.

Phase 2 : Génération itérative et raisonnée de Regex

Cette phase adresse les problèmes C2 (validité) et C3 (généralisation) via un pipeline de raisonnement itératif.

1. Génération initiale : Le LLM reçoit l'IOC et les informations sur les groupes de capture pour produire un premier regex.
2. Boucle de débogage (Validation syntaxique) : Un outil de débogage vérifie si le regex correspond à l'IOC original. En cas d'échec, les détails de l'erreur sont renvoyés au LLM pour raffinement itératif.
3. Validation des groupes non-capturants : Une seconde boucle s'assure qu'aucun groupe non-capturant n'est présent dans le regex final (car les regex de détection doivent capturer les données pour les SIEM).
4. Vérification de la sur-généralisation (Over-Generalization) : Le système teste le regex candidat contre 10 chaînes aléatoires. Si le regex correspond à toutes les chaînes, il est jugé trop large (trop de .*) et le processus recommence.
5. Classement (Grading) : Pour un même IOC, le système génère plusieurs candidats. Un score est attribué selon la formule : Score = α * (nombre de composants de capture) - β * (nombre de composants non-capturants). Le regex avec le score le plus élevé est retenu.

3. Contributions Clés

1. IOCRegex-gen : Un système novateur qui automatise l'étape critique de traduction des IOCs bruts en regex déployables, comblant le vide entre l'extraction de renseignement et la détection opérationnelle.
2. Mécanisme d'identification des groupes de capture : Une approche hybride combinant une base de connaissances graphiques (pour la sémantique système) et des algorithmes de détection de séquences, permettant de distinguer précisément les parties fixes et variables des IOCs.
3. Pipeline de raisonnement itératif : Une méthodologie de génération qui intègre des boucles de validation multiples (syntaxe, groupes, généralisation) pour garantir la robustesse et la précision des regex, surpassant les approches "prompting direct".
4. Évaluation rigoureuse : Une validation à grande échelle utilisant plus de 3 000 rapports CTI réels et 2 400 chaînes de vérité terrain (ground truth) issues des évaluations MITRE ATT&CK.

4. Résultats Expérimentaux

L'évaluation a été menée sur des données provenant de 10 scénarios d'attaque réels (APT29, LockBit, etc.) et a démontré les performances suivantes :

• Taux de détection (Hit Rate) : Le système atteint un taux moyen de 99,1 % sur les chaînes de vérité terrain. Certains ensembles de données (LockBit, Turla Snake) ont atteint 100 %.
• Taux de faux positifs (False Positive Rate) : Le taux moyen est extrêmement faible, à 0,8 %. Les rares faux positifs observés proviennent de chemins non standards créés par les attaquants, qui peuvent être filtrés par des règles heuristiques simples.
• Complexité et Spécificité :
  • Les regex générés obtiennent un score moyen de complexité supérieur à 3, indiquant qu'ils ne sont pas de simples correspondances littérales mais intègrent une structure complexe.
  • La similarité avec les IOCs originaux est d'environ 0,4, prouvant que le système introduit suffisamment de variabilité pour couvrir différents contextes système sans être trop restrictif.
• Étude d'ablation : La désactivation des composants clés (recherche de groupes de capture ou génération raisonnée) entraîne une chute drastique des performances (baisse du taux de détection de >16 % et augmentation des faux positifs de >23 %), confirmant la nécessité de chaque module.
• Robustesse du modèle : Les résultats sont cohérents quel que soit le modèle LLM sous-jacent (GPT-4o, LLaMA3, DeepSeek-V3), avec une similarité structurelle des regex générés supérieure à 0,97.

5. Signification et Impact

Cet article marque une avancée significative dans l'automatisation de la cybersécurité opérationnelle :

• Opérationnalisation du CTI : Il transforme le renseignement théorique en règles de détection actionnables immédiatement, réduisant le temps de réponse aux menaces de jours à quelques minutes.
• Réduction de la charge cognitive : Il allège la fatigue des analystes en automatisant la tâche fastidieuse et technique de la création de regex, tout en minimisant les erreurs humaines.
• Adaptabilité : Contrairement aux approches basées sur l'apprentissage supervisé qui nécessitent d'énormes jeux de données étiquetés (difficiles à obtenir en sécurité), cette approche repose sur le raisonnement et les connaissances graphiques, la rendant applicable à des menaces émergentes sans réentraînement.

En conclusion, IOCRegex-gen démontre qu'il est possible d'automatiser avec une haute précision la conversion de rapports de menaces textuels en règles de détection complexes, rendant les SOC plus résilients face à la volumétrie croissante des cybermenaces.