Un flux de travail structuré pour transformer l’intelligence cyber en schémas de détection calculables

Résumé

Ici, nous présentons un protocole pour convertir les indicateurs de compromission issus des chemins de fichiers de rapports de renseignement cyber-menace, clés de registre et indicateurs en ligne de commande en expressions régulières validées pour les règles de détection de sécurité des informations et de la gestion des événements (SIEM), en utilisant l’extraction d’ensemble avec de grands modèles de langage (LLM) et l’étiquetage de composants assisté par graphe.

Résumé

Les Centres d’Opérations de Sécurité (SOC) convertissent régulièrement les rapports de renseignement sur les cybermenaces (CTI) en contenu de détection opérationnelle. Un goulot d’étranglement persistant dans ce flux de travail est la traduction des indicateurs de compromission extraits (IOC), en particulier les chemins de fichiers, les clés de registre et les chaînes de lignes de commande, en expressions régulières déployables (regex) adaptées à l’intégration dans les règles de corrélation de sécurité sur l’information et la gestion d’événements (SIEM). Bien que les travaux antérieurs aient amélioré l’extraction automatisée par indicateur de compromis (IOC), la transformation des chaînes extraites en motifs réguliers validés reste largement manuelle, nécessite une expertise spécialisée et est sujette aux erreurs. L’objectif de ce protocole est de fournir une procédure standardisée et reproductible pour la traduction IOC vers regex. Le flux de travail comprend cinq étapes : (1) analyser des rapports CTI hétérogènes en une représentation Markdown unifiée ; (2) extraction de l’IOC à l’aide de plusieurs grands modèles de langage (LLM) avec vote par consensus ; (3) la normalisation, la catégorisation et la déduplication par règles des IOC extraites ; (4) l’étiquetage assisté par graphe des composants IOC en tant que keep (groupe de capture) ou de défausse (groupe non-capture) ; et (5) génération itérative de régex avec validation diagnostique par rapport aux chaînes IOC originales. Pour évaluer l’utilité, le flux de travail a été appliqué à 3 156 rapports CTI, et les régex résultants ont été évalués par rapport à plus de 2 400 chaînes de vérité sur le terrain collectées indépendamment à partir de dix scénarios d’évaluation MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK), donnant un taux de réussite moyen de 99,1 % et un taux moyen de désaccord entre IOC de 0,8 %. Le protocole documente donc une implémentation reproductible pour la traduction IOC vers regex et définit explicitement son champ d’application actuel, ses hypothèses opérationnelles et les cas de défaillance connus.

Introduction

La cybercriminalité continue d’imposer d’importants fardeaux opérationnels et financiers aux organisations des secteurs public et privé. En 2023, les pertes déclarées dues à la cybercriminalité aux États-Unis ont dépassé 12,5 milliards^{de dollars,} mettant en lumière l’ampleur et la persistance des activités malveillantes. Dans ce contexte, les Centres d’Opérations de Sécurité (SOC) servent d’unités opérationnelles principales responsables de la détection, de l’analyse et de la réponse aux menaces en temps réel.
La logique de détection dans de nombreux workflows SOC est implémentée via des mécanismes basés sur des règles au sein des plateformes de gestion de l’information et des événements de sécurité (SIEM), qui sont largement utilisées car interprétables, déterministes et compatibles avec les workflows SOC existants. Parmi les différents types de règles, les règles SIEM basées sur la corrélation sont particulièrement importantes pour identifier les comportements d’attaque couvrant plusieurs événements, hôtes et fenêtres temporelles. Dans ces règles, les expressions régulières (regex) fonctionnent comme des primitives de recherche réutilisables : les analystes les intègrent dans des règles de détection plus larges qui ajoutent des contraintes de champ, des filtres spécifiques à la plateforme et une logique de corrélation d’événements, plutôt que de les déployer comme détecteurs autonomes.

En pratique, les analystes SOC commencent souvent à élaborer des règles avec des indicateurs de compromission (IOC) dérivés de rapports de renseignement sur les menaces cybernétiques (CTI) publiés par des fournisseurs de sécurité, des chercheurs indépendants ou des bases de connaissances publiques telles que MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK⁾². Ces chaînes IOC peuvent inclure des chemins de fichiers, des fragments de ligne de commande, des clés de registre ou d’autres artefacts structurés observés lors des^{attaques 3}. Traduire ces chaînes en motifs réguliers adaptés aux règles de corrélation SIEM est une tâche récurrente dans le flux de travail d’auteur de règles.

Cette étape de traduction constitue un goulot d’étranglement opérationnel pratique. Créer des modèles réguliers suffisamment généraux pour capturer une variation significative mais suffisamment précis pour éviter des correspondances inattendues nécessite une expertise spécialisée ; de petites erreurs syntaxiques ou des décisions incorrectes sur les composants à préserver ou généraliser peuvent rendre une règle de détection autrement utile inefficace. Parce que ce travail est manuel, répétitif et orienté détail, il peut retarder le déploiement de la détection des menaces émergentes, nécessiter une révision par des analystes plus expérimentés, et contribuer à la charge de travail des analystes dans les contextes SOC^{opérationnels 4,5}.

Le défi central dans la traduction IOC vers regex est de décider quelles parties d’un IOC encodent un comportement stable et pertinent pour l’attaquant et doivent donc être préservées, et lesquelles reflètent la variation spécifique à l’environnement ou à l’hôte et doivent être généralisées. Par exemple, les racines canoniques du registre telles que HKEY_CLASSES_ROOT\CLSID, les répertoires système comme System32, et les noms d’exécutables connus comme rundll32.exe doivent généralement rester explicites, tandis que les chemins de profil utilisateur, les identifiants de sécurité spécifiques à l’hôte (SID) et les identifiants globalement uniques (GUID) devraient généralement être abstraits. Faire cela de manière cohérente entre types d’IOC hétérogènes est ce qui rend la tâche de traduction non triviale. Tout au long de ce protocole, nous appelons les premiers composants préservés ou de groupe de capture, et les seconds composantes abstraites ou non-groupes de capture.

Des travaux antérieurs ont exploré l’extraction automatisée de renseignements sur les menaces à partir de texte non structuré à l’aide de techniques de traitement du langage naturel et d’extraction^{d’entités 6,7}. Plus récemment, plusieurs études ont étudié la génération directe de règles de détection à partir de rapports CTI à l’aide de grands modèles de langage (^LLMs)8. Ces approches démontrent que certaines parties du flux de travail d’auteur de règles peuvent être facilitées par des modèles de langage, mais elles ne se concentrent généralement pas sur le problème opérationnel spécifique de la génération de motifs réguliers qui préservent la sémantique des groupes de capture et restent adaptées au déploiement en aval de SIEM. Des lignes de travail complémentaires ont structuré le contenu CTI pour une utilisation ultérieure de différentes manières, notamment des représentations basées sur des graphes de connaissances comme TINKER⁹ et la génération de requêtes de chasse de logs pilotée par CTI comme ThreatRaptor¹⁰, qui convertissent des CTI non structurés en langages de connaissance structurée ou de requête spécifiques à un domaine, plutôt qu’en motifs réguliers destinés à être intégrés dans les règles de corrélation SIEM.

Parallèlement, des études antérieures ont exploré la synthèse automatisée de regex utilisant des méthodes basées sur des exemples, la traduction neuronale et les approches de génération et réparation 11,12,13,14,15,16. Cependant, ces méthodes sont généralement conçues pour des contextes qui reposent sur de grands ensembles d’exemples représentatifs ou de descriptions en langage naturel plutôt que sur des contextes de détection pilotés par l’IOC. Dans les flux de travail SOC, les chaînes IOC sont souvent rares, structurellement hétérogènes et étroitement liées à la sémantique opérationnelle. Ce décalage motive un flux de travail adapté à la traduction IOC vers regex plutôt qu’à affirmer que les méthodes existantes de génération régulière sont globalement inadéquates.

Le protocole présenté ici se concentre spécifiquement sur l’étape de traduction IOC vers regex du flux de travail de détection SOC. L’extraction de l’IOC est traitée comme une entrée en amont qui peut provenir d’une analyse manuelle, d’outils automatisés ou d’une combinaison des deux ; le protocole ne tente pas de générer des règles SIEM complètes. Au contraire, il fournit une procédure systématique pour convertir les chaînes IOC en motifs regex syntaxiquement valides, sémantiquement interprétables et adaptés au déploiement opérationnel. La portée actuelle de l’IOC est délibérée : les chemins de fichiers, les clés de registre et les indicateurs en ligne de commande contiennent à la fois des composants structurels stables et variables qui bénéficient de la généralisation des regex, tandis que les indicateurs atomiques tels que les adresses IP, domaines et hachages sont plus naturellement opérationnels par des conditions de correspondance exacte ou des recherches de type réputation et sortent donc du champ principal. Dans ces limites, le protocole est conçu pour être portable à travers des environnements SOC partageant des formats d’entrée et des préconditions d’outils comparables.

Protocole

Utilisez le flux de travail en cinq étapes suivant pour transformer un rapport CTI en motifs réguliers validés avec des sorties intermédiaires traçables (voir Figure 1 pour un aperçu).

1. Installation du système

1. Prérequis pour l’installation.
   1. Installez Python 3.8 ou une version ultérieure, toutes les dépendances Python listées dans requirements.txt, ainsi qu’une base de données graphique Neo4j.
      1. Confirmez l’accès à une ou plusieurs interfaces de programmation d’applications (API) pour les grands modèles de langage choisis et vérifiez que le service Neo4j fonctionne et est accessible depuis la machine locale.
   2. Confirmez que le tableau des matériaux est complet.
      1. Vérifiez que les dépendances à l’exécution sont listées, y compris la version de l’interpréteur Python, les dépendances du pipeline, la version Neo4j et le backend d’extraction de texte Portable Document Format (PDF).
      2. Vérifiez que les options de configuration du LLM sont listées, y compris les fournisseurs de LLM, les noms et versions des modèles, la température, les options d’effort de raisonnement et les paramètres de vote d’ensemble.
      3. Vérifiez que les formats d’entrée et de sortie sont listés, y compris les formats de fichiers d’entrée pris en charge et les formats d’exportation pris en charge.
2. Lancez l’interface utilisateur web (UI).
   1. Ouvrez un terminal, naviguez jusqu’au répertoire racine de l’implémentation de référence, et lancez l’application en utilisant la commande de lancement documentée (dans l’implémentation de référence : cd langchain_pipeline suivi de streamlit run app_v2.py).
   2. Vérifiez que l’application charge à http://localhost:8501 et que le panneau de configuration de la barre latérale est visible.
3. Configurez le fournisseur de LLM.
   1. Dans la section Configuration du LLM de la barre latérale, sélectionnez un fournisseur de LLM, saisissez le nom du modèle, et fournissez une clé valide de l’interface de programmation d’application (API).
   2. Notez le fournisseur, le nom du modèle, la version du modèle, la température, les options de raisonnement et la date d’accès pour la Table des Matériaux.
      REMARQUE. Dans l’implémentation de référence, l’extraction IOC à un seul LLM se retrouve par défaut sur le LLM commercial principal listé dans le tableau des matériaux avec une température = 0,0 ; La génération régulière est par défaut température = 0,3.
4. Activez le vote d’ensemble (optionnel mais recommandé pour les résultats reproductibles).
   1. Activez l’option Vote en ensemble dans la barre latérale pour ne conserver que les IOC atteignant un seuil minimum de vote (Min Votes ≥ 2 recommandés).
   2. Ajoutez des instances LLM supplémentaires en spécifiant le fournisseur, le nom du modèle, la clé API et le nombre de répétitions d’exécution par modèle.
      1. Notez le nombre de répétitions de chaque prestataire et le seuil minimum de vote sélectionné.
         REMARQUE. Le vote d’ensemble est optionnel. Lorsqu’il est désactivé, le pipeline effectue une extraction en un seul LLM et le filtre consensus est sauté. Les réglages par défaut de l’ensemble sont répétitions = 1 par modèle configuré et min_votes = 2.
5. Connectez-vous à Neo4j.
   1. Dans la section Connexion Neo4j de la barre latérale, saisissez l’URI de connexion (par exemple, bolt://localhost:7687), le nom d’utilisateur et le mot de passe.
   2. Confirmez que l’interface indique une connexion réussie. Ne pas continuer sans connexion active.
6. Sécurisez tous les identifiants.
   1. Traitez les clés API du LLM et le mot de passe Neo4j comme des identifiants sensibles. Stockez-les dans des variables d’environnement ou un gestionnaire de secrets plutôt que dans des fichiers sources, des rapports exportés ou des captures d’écran, et faites pivoter rapidement toute clé si une fuite est suspectée.
      REMARQUE. Ce protocole logiciel ne nécessite pas de hotte chimique, d’armoire de biosécurité ou d’autres équipements de confinement physique ; gérer les rapports et accréditations CTI confidentiels selon les politiques institutionnelles de sécurité des données.

2. Étape 1 : analyse syntaxique des documents

1. Procédure.
   1. Naviguez jusqu’à l’onglet Traitement dans l’interface principale.
   2. Téléchargez un rapport CTI dans un format supporté (.pdf, .docx, .md, .txt ou .html).
   3. Cliquez sur « Exécuter l’étape suivante » pour exécuter l’étape 1, ou sur « Exécuter toutes les étapes » pour exécuter l’intégralité du pipeline dans l’ordre.
2. Confirmez le point de contrôle de l’étape 1.
   1. Confirmez qu’un aperçu Markdown du document d’entrée est affiché.
   2. Vérifiez que les chemins de fichiers, les clés de registre, les fragments de ligne de commande et les limites de section restent intacts dans l’aperçu.
   3. Si les chaînes techniques sont tronquées ou si la mise en forme est supprimée, corrigez le fichier source ou pré-traitez le document avec un convertisseur externe avant de le re-téléverser.

3. Étape 2 : Extraction IOC

1. Procédure.
   1. Confirmez la configuration du LLM (et le vote ensemble, si activé).
   2. Cliquez sur « Exécuter l’étape suivante » pour exécuter l’étape 2.
2. Confirmez le point de contrôle de l’étape 2.
   1. Confirmez que l’interface affiche une collection IOC au format JavaScript Object Notation (JSON) avec trois clés de premier niveau : chemins de fichier, lignes de commande et clés de registre.
   2. Lorsque le vote collectif est activé, vérifiez que les décomptes des votes et les métadonnées du modèle contributif sont enregistrés pour chaque IOC conservé.
      REMARQUE. Le système mot à mot de l’étape 2 et les prompts humains, ainsi que les prompts de génération et d’optimisation de l’étape 5, sont publiés sous forme de fichier supplémentaire 1 (Supplemental_File_1_Prompts.txt).

4. Étape 3 : Analyse et classification du CIO

1. Procédure.
   1. Cliquez sur « Exécuter l’étape suivante » pour exécuter l’étape 3.
2. Confirmez le point de contrôle de l’étape 3.
   1. Confirmez que chaque IOC conservé est listé avec une catégorie standardisée, un tag source et la clé d’extraction originale lorsque disponible.

5. Étape 4 : normalisation de l’IOC assistée par Neo4j

1. Procédure.
   1. Confirmez que la connexion Neo4j est active.
   2. Cliquez sur « Exécuter l’étape suivante » pour exécuter l’étape 4.
   3. Inspectez la sortie de normalisation par IOC et vérifiez que des étiquettes de conservation/défausse sont produites pour les composants de chemin et de ligne de commande, et que les clés de registre produisent une sous-chaîne canonique contiguë.
2. Confirmez le point de contrôle de l’étape 4.
   1. Confirmez que des tables IOC normalisées sont produites pour chaque type d’IOC (chemins de fichiers, clés de registre, indicateurs en ligne de commande).
   2. Vérifiez que chaque entrée inclut la valeur originale, la valeur normalisée, ainsi qu’une liste de composants des paires élément/statut intitulées conserver ou jeter.
      REMARQUE. Le schéma détaillé de Neo4j, les requêtes Cypher, les règles de décision et la procédure de normalisation de la clé de registre sont listés dans le Fichier Supplémentaire 2 ; un exemple travaillé est fourni dans Résultats Représentatifs.

6. Étape 5 : génération et notation de régex

1. Procédure.
   1. Cliquez sur « Exécuter l’étape suivante » pour exécuter l’étape 5. Confirmez que chaque IOC normalisé et sa liste de jetons interdits sont soumis pour génération de regex et validation déterministe.
   2. Si un candidat échoue à la validation, laissez la boucle d’optimisation affiner le régulateur régulier jusqu’à ce qu’un candidat conforme soit produit ou que le plafond d’itération soit atteint.
   3. Inspectez la sortie diagnostique, l’historique d’optimisation et les comptes d’itérations pour tout IOC dont le régex final recule de la conformité à la correspondance partielle la plus haute (enregistrée comme used_fallback = Vrai).
2. Confirmez le point de contrôle de l’étape 5.
   1. Confirmez qu’un régex final est produit pour chaque IOC conservé.
   2. Vérifiez que les scores des candidats, les historiques d’optimisation, les listes de problèmes et le nombre d’itérations sont enregistrés.
   3. Vérifiez que la télémétrie par IOC, y compris l’utilisation estimée du token et la latence, est enregistrée.
      REMARQUE. Les règles détaillées de validation des regex, la formule de notation et les paramètres de contrôle d’itération sont listés dans le Fichier Supplémentaire 2.

7. Analyse et validation

1. Ouvrez l’onglet Analytique pour examiner les distributions IOC, les résultats de vote d’ensemble (lorsque cela est activé), les résumés de qualité regex et les statistiques d’optimisation. Utilisez ces résumés pour détecter des anomalies telles que le déséquilibre d’extraction ou des échecs répétés d’optimisation.

8. Résultats à l’exportation

1. Dans l’onglet Exporter, sélectionnez le format d’exportation (texte brut, JSON ou YAML) et téléchargez l’ensemble de régex. Confirmez que les régex exportés incluent les scores associés et les métadonnées de catégorisation.
2. Générez et téléchargez le rapport JSON complet contenant les documents analysés, les IOC extraites, les représentations normalisées, les régex candidats et les résultats finaux. Conservez ce rapport comme un registre de reproductibilité.

9. Dépannage

1. Si l’étape 1 restitue du contenu PDF tronqué ou vide, pré-traiter le document avec un convertisseur externe ou un outil de reconnaissance optique de caractères avant de le re-téléverser, et confirmez que les artefacts techniques restent visibles dans l’aperçu Markdown.
2. Si l’étape 2 donne trop peu d’IOC consensuels, vérifiez les paramètres du fournisseur, du modèle, de la clé API, du nombre de répétitions et des votes minaux avant de modifier le seuil. Inspecter les candidats exclus afin de distinguer les hallucinations d’un vote trop strict.
3. Si l’étape 4 étiquete tous les composants comme rejetés, vérifiez la connectivité Neo4j et confirmez que le graphe contient le vocabulaire pertinent Path, Registry ou interface en ligne de commande (CLI) pour le type IOC analysé.
4. Si l’étape 5 produit un régulateur régulier qui compile mais ne correspond pas ou généralise de manière excessive, inspectez l’historique d’optimisation, la position de défaillance diagnostique et les contrôles de surgénéralisation avant de régénérer le candidat.

10. Confirmer les sorties finales du protocole.

1. Confirmez que le fichier Markdown analysé, l’ensemble IOC (validé par consensus lorsque le vote en ensemble est activé, ou le modèle unique lorsqu’il est désactivé), la table IOC catégorisée et les représentations IOC normalisées par graphe sont tous présents.
2. Confirmez que l’ensemble régulier compatible SIEM, les résumés analytiques et le rapport JSON complet sont tous présents, et archivez le rapport JSON comme enregistrement de reproductibilité.

Résultats

Cette section présente les résultats représentatifs produits par le protocole IOC-à-regex et résume l’évaluation de référence utilisée pour évaluer son applicabilité opérationnelle. L’évaluation des références a traité 3 156 rapports CTI associés aux techniques MITRE ATT&CK, analysé plus de 230 000 phrases, extrait plus de 63 000 candidats IOC et évalué les regex générés par rapport à plus de 2 400 chaînes de vérité sur le terrain collectées indépendamment à partir de dix scénarios d’évaluation MITRE ATT&ck. Ces chaînes de vérité sur le terrain sont des artefacts d’attaque sélectionnés par des experts, rapportés indépendamment par les fournisseurs de cybersécurité lors des exercices d’évaluation MITRE ATT&CK et reflètent donc les schémas structurels que les analystes et fournisseurs humains documentent en pratique. Les résultats ci-dessous portent sur le comportement des flux de travail, la correction structurelle et les résultats d’évaluation pertinents pour l’analyse opérationnelle des journaux et les flux de détection.

Un aperçu du pipeline de bout en bout est fourni à la Figure 1, qui résume les étapes de recherche par groupe de capture et de génération de regex qui encadrent le reste des résultats représentatifs.

Étape 1 : Analyse des documents Résultats

La figure 2 montre la sortie de l’étape 1, où un rapport CTI d’entrée est analysé en une représentation Markdown unifiée. Une fois exécutée réussie, l’interface affiche un aperçu structuré du document, incluant les limites de section et les indicateurs de pertinence.

L’exécution correcte est indiquée par une segmentation cohérente des paragraphes et la préservation des artefacts techniques tels que les chemins de fichiers, les clés de registre et les fragments de ligne de commande. Une troncature excessive ou une perte de mise en forme à ce stade peut affecter l’analyse en aval et doit être prise en compte avant de procéder.

Étape 2 : Extraction de l’IOC basée sur le consensus

La figure 3 illustre le résultat de l’étape 2, où les candidats IOC sont extraits à l’aide du vote d’ensemble multi-LLM. L’interface résultante présente une collection IOC au format JSON, annotée avec les décomptes des votes et les modèles contributifs.

Seules les IOC atteignant le seuil minimum de consensus configuré sont conservées. Les IOC exclues à ce stade reflètent généralement des hallucinations spécifiques au modèle ou des fragments de texte ambigus. Leur exclusion est un résultat attendu et souhaitable, indiquant que le vote collectif fonctionne correctement.

Étape 3 : Analyse et classification du CIO

Le tableau 2 résume les résultats attendus, les étapes automatisées de validation et les contrôles de contrôle qualité destinés aux analystes pour chaque étape du protocole.

La figure 4 montre les candidats du CIO qui n’ont pas atteint le seuil de consensus lors du vote collectif à l’étape 2 et que l’interface apparaît pour inspection par les analystes. Ces candidats reflètent généralement des hallucinations spécifiques au modèle ou des fragments de texte ambigus. Les figures 4 et 5 correspondent donc à des sorties d’étape distinctes — l’ensemble abandonné de l’étape 2 et l’ensemble conservé de l’étape 3 — plutôt qu’à des vues alternatives du même processus de l’étape 3.

La Figure 5 présente la table IOC conservée produite par l’étape 3 après l’analyse JSON, la catégorisation basée sur des règles et la déduplication IOC. Pour chaque IOC conservée, l’étape enregistre une catégorie standardisée, une balise source et la clé d’extraction originale lorsque disponible, avant de passer l’IOC à la normalisation en aval.

Étape 4 : Normalisation de l’IOC assistée par graphes à travers les types de IOC

Les figures 6, 7 et 8 illustrent les résultats de normalisation représentatifs pour trois catégories IOC abordées dans l’étude actuelle : chemins de fichiers, clés de registre et indicateurs en ligne de commande. Pour chaque catégorie, les chiffres comparent l’IOC original extrait du rapport CTI avec la représentation normalisée produite par analyse assistée par graphe.

Pour tous les types d’IOC, le protocole décompose chaque IOC en composants sémantiques et résout les relations hiérarchiques à l’aide de connaissances structurées encodées dans la base de données de graphes. Dans l’implémentation actuelle, Neo4j stocke les nœuds Path, Registry et CLI normalisés et utilise des relations d’adjacence pour tester si les composants appartiennent à des chaînes reconnues. Ce rôle est analogue à l’utilisation des connaissances structurées ATT&CK lors de l’ingénierie de détection².

Il est important de noter que cette étape de normalisation enregistre explicitement les rôles sémantiques des composants IOC en les étiquetant comme keep ou disject, plutôt que de les supprimer silencieusement de l’enregistrement d’analyse. La chaîne normalisée est principalement reconstruite à partir des composants de conservation, tandis que les composants de défausse sont disponibles comme métadonnées pour la génération et la validation en aval de regex.

La bonne exécution de cette étape est indiquée par des IOC normalisées qui conservent un contexte structurel significatif et présentent un étiquetage cohérent des groupes de capture à travers différents types d’IOC. La comparaison visuelle entre les représentations originales et normalisées fournit un mécanisme pratique de contrôle qualité pour vérifier que la résolution du groupe de capture a été appliquée de manière cohérente et sans perte d’information involontaire.

Étape 5 : Génération d’expressions régulières avec sélection auxiliaire basée sur les contraintes

La figure 9 illustre la sortie de l’étape 5, où le protocole génère des expressions régulières structurellement conformes à partir de IOC normalisées via un flux de validation itératif. L’implémentation combine une invite de génération initiale, une re-invitation diagnostique lorsqu’un candidat ne correspond pas à l’IOC, une validation consciente du rejet et des boucles de réessayage plafonnées.

Étant donné un IOC normalisé et sa spécification associée de composant keep/discharge, le workflow génère d’abord un candidat régex initial. Le candidat est ensuite testé par rapport à l’IOC, reprogrammé de façon diagnostique en cas d’échec de correspondance, vérifié pour détecter des jetons interdits abandonnés, et évalué pour surgénéralisation à l’aide de chaînes négatives aléatoires.

Lorsque plusieurs candidats satisfont aux vérifications de validation de base, le protocole applique un mécanisme auxiliaire de sélection basé sur des contraintes pour conserver un regex représentatif destiné à une utilisation en aval. L’implémentation actuelle note les candidats avec « Score = n_cg - n_wc », où « n_cg » est le nombre de composants de maintien représentés et « n_wc » le nombre de jetons défaussés ou non cartographiés présents dans le regex.

La fonction de sélection est définie comme suit :

Score = n_cg − n_wc

C’est la spécialisation à poids égal (α = β = 1) de la forme plus générale Score = α·n_cg − β·n_wc. Ici, n_cg désigne le nombre de composants de keep représentés et n_wc désigne le nombre de composants de défausse ou de jetons supplémentaires non cartographiés réintroduits par le regex. L’implémentation enregistre également le nombre d’itérations, les listes de problèmes, la consommation estimée de tokens, l’utilisation du cache et la télémétrie de latence pour chaque IOC. Le réglage de poids égal était utilisé comme un défaut déterministe simple pour l’implémentation de référence ; Parce qu’il considère un composant de maintien manquant et un composant de défausse réintroduit comme également indésirables, d’autres pondérations peuvent être préférées dans les contextes de déploiement où les faux négatifs et faux positifs comportent des coûts opérationnels différents.

Le régex final est choisi comme le candidat qui satisfait le mieux ces contraintes. Les régex qui placent des composants de groupe de capture requis dans des constructions optionnelles, par exemple ( ... ) ?, sont exclues de la sélection car elles affaiblissent la cohérence sémantique. Cette étape de sélection est auxiliaire au processus de génération et n’a pas pour but de servir de métrique de qualité autonome.

Aperçu analytique du traitement CTI

La Figure 10 présente un aperçu des résultats de l’analyse CTI sur tous les documents traités. Lors de l’évaluation des références, l’extraction par l’IOC de plus de 3 156 rapports CTI a produit plus de 63 000 candidats IOC, dont 12 195 chemins de fichiers, 2 302 clés de registre et 10 286 indicateurs en ligne de commande, les candidats restants appartenant à des types IOC non cibles à regex.

Ces décomptes fournissent une validation de haut niveau que les indicateurs extraits sont concentrés dans les trois catégories IOC ciblées par le protocole actuel, tout en montrant que de nombreux artefacts extraits restent en dehors du champ de la génération régulière. Lors de la reproduction du flux de travail, rapportez le nombre exact de rapports CTI traités, le total des candidats IOC, les décomptes par catégorie, ainsi que le fournisseur, le modèle, la version du modèle, la température, le nombre de répétitions et le seuil de consensus utilisés lors de l’extraction.

Dans l’évaluation de référence, les régex générés ont été évalués par rapport à plus de 2 400 chaînes de vérité sur le terrain collectées indépendamment à partir de dix scénarios d’évaluation MITRE ATT&CK et ont atteint un taux moyen de réussite de 99,1 %, ainsi qu’un taux moyen de désappariement entre l’IOC de 0,8 %. Dans ce manuscrit, le taux de désappariement est utilisé comme mesure de spécificité sémantique : un désaccord se produit lorsqu’un regex généré pour un IOC correspond également à une chaîne de vérité de terrain associée à un autre IOC. Cette quantité ne doit pas être interprétée comme un taux d’alerte opérationnelle de faux positifs de bout en bout, qui dépend également de la logique des règles en aval et du contexte de déploiement.

La distribution reflète la composition structurelle du corpus CTI et permet aux utilisateurs de vérifier que les indicateurs extraits correspondent aux types attendus de CIO. De grandes écarts par rapport aux proportions attendues peuvent indiquer des problèmes d’analyse ou d’extraction en amont et doivent être examinés avant de procéder à la normalisation en aval et à la génération de regex.

Analyse des actions d’optimisation Regex

La figure 11 résume les actions effectuées lors de la génération et du raffinement des expressions régulières. La distribution comprend trois types d’actions : la génération initiale de regex, les étapes d’optimisation pilotées par LLM, et la régénération basée sur des réessais.

L’optimisation pilotée par LLM représente 51,7 % de toutes les actions observées. Cette prévalence indique que la génération initiale seule est souvent insuffisante pour produire des regex satisfaisant les contraintes du groupe de capture et les exigences d’exclusion. À la place, l’optimisation itérative est appliquée activement et à plusieurs reprises pour affiner les régex candidats.

Plutôt que de refléter une inefficacité, cette distribution démontre que le flux de travail d’optimisation est un composant nécessaire et essentiel du protocole lors de la génération de regex structurellement conformes à partir d’entrées IOC complexes.

Une caractérisation distincte de la scalabilité sur un échantillon aléatoire de 6 000 IOC générés avec le LLM testé de scalabilité (voir le tableau des matériaux) a rapporté une latence médiane de 2,95 s par IOC et une latence moyenne de 23,18 s. Dans la même caractérisation, la compilation regex syntaxiquement valide a atteint 99,56 %, le succès global de la génération a atteint 99,4 %, l’utilisation moyenne estimée des tokens était d’environ 3 986 tokens par IOC, et le workflow nécessitait en moyenne environ 7,89 appels LLM par IOC. Les taux de réussite au premier passage étaient de 56,46 % pour la boucle de correspondance-débogage et de 72,92 % pour la boucle de validation hors groupe de capture. Ces mesures aident à caractériser le coût computationnel et le débit opérationnel pour une utilisation en batch.

Aucune revue d’expert d’un sous-ensemble de sortie échantillonnée n’a été utilisée pour le réentraînement du modèle dans la caractérisation de référence actuelle ; Les résultats rapportés reflètent l’exécution automatisée des pipelines et les ensembles de données d’évaluation en aval décrits ci-dessus.

Preuves opérationnelles et gestion des défaillances. La figure 12 montre la structure du fichier régulier SIEM exporté produit par le protocole, ainsi que des preuves de validation au niveau des règles pour les schémas représentatifs de chemin de fichier, clé de registre et ligne de commande. La figure 13 montre le rapport JSON complet correspondant, qui expose toutes les sorties d’étape (IOC extraites, analysées et normalisées ainsi que les motifs regex générés et les indicateurs de validation par IOC) et constitue l’artefact principal consommé par les outils en aval. La figure 14 illustre la gestion par le protocole d’une entrée CTI bruitée : un chemin de fichier décroché et perturbé par l’espace blanc est signalé à l’étape d’analyse, corrigé, normalisé au modèle canonique %TEMP %, puis converti en un registre régulier de compilation correspondant. Cet exemple résolu complète les preuves opérationnelles de la Figure 12 et de la Figure 13 en documentant le comportement du protocole lorsque le texte brut de l’IOC s’écarte de la forme canonique.

Figure 1 : Architecture globale du protocole IOC-à-regex. La figure résume le pipeline de bout en bout. Les chaînes d’IOC candidates produites par l’extracteur d’IOC en amont sont décomposées et comparées aux nœuds de référence dans un graphe Neo4j rempli à partir de la documentation Windows (étape 1), qui récupère les composants de chemin, de registre et de ligne de commande connus (étape 2). Les fragments variables ou spécifiques à l’environnement sont étiquetés comme défauchés et exclus de la reconstruction normalisée tout en étant conservés dans les métadonnées des composants, ce qui donne une IOC normalisée avec des étiquettes de conservation et de défausse au niveau des composants (étape 3). Ces IOC normalisés sont ensuite transmis à une étape de génération régulière basée sur un LLM (étape 4) qui produit des expressions régulières candidates, qui sont notées et optimisées de manière itérative selon les contraintes du groupe de capture et les règles des jetons défaussés (étape 5) avant qu’un régex final ne soit sélectionné (étape 6). Veuillez cliquer ici pour voir une version agrandie de cette figurine.

Figure 2 : Document de l’étape 1 : Analyse de la sortie. Comparaison côte à côte du rapport CTI original et de l’aperçu du document analysé. Le panneau de gauche affiche le rapport CTI original au format PDF, tandis que le panneau de droite affiche la représentation unifiée de Markdown générée par l’analyseur. Veuillez cliquer ici pour voir une version agrandie de cette figurine.

Figure 3 : Extraction de l’IOC basée sur le consensus à l’aide du vote d’ensemble multi-LLM. L’interface illustre le processus d’extraction de l’IOC basé sur un ensemble et ses résultats intermédiaires. La case rouge met en évidence les instances LLM configurées participant à l’extraction IOC, y compris les fournisseurs sélectionnés et le nombre de répétitions d’extraction effectuées pour chaque modèle. La case bleue indique le seuil de consensus défini par l’utilisateur, qui précise le nombre minimum d’occurrences requis pour qu’un IOC soit conservé. Après avoir agrégé les résultats d’extraction sur tous les modèles et répétitions, les IOC candidats qui apparaissent moins souvent que le seuil sont écartés. La boîte orange montre l’ensemble final de COI conservés qui satisfont au critère de consensus et sont transmis aux étapes d’analyse en aval. Veuillez cliquer ici pour voir une version agrandie de cette figurine.

Figure 4 : CIO rejetés par vote collectif à l’étape 2. Vue côte à côte des candidats du CIO qui n’ont pas atteint le seuil minimum de vote configuré lors du vote collectif et qui sont exposés pour inspection par les analystes. Les candidats rejetés reflètent généralement des hallucinations spécifiques au modèle ou des fragments de texte ambigus et ne sont pas passés à l’étape de catégorisation de l’étape 3. Veuillez cliquer ici pour voir une version agrandie de cette figurine.

Figure 5 : Ensemble IOC conservé avec classification standardisée. Les candidats IOC conservés après le traitement de l’étape 3 sont affichés avec leurs catégories standardisées, les tags source et les clés d’extraction originales lorsque disponibles. Ce tableau fournit l’entrée structurée IOC utilisée par l’étape de normalisation. Veuillez cliquer ici pour voir une version agrandie de cette figurine.

Figure 6 : Normalisation IOC du chemin du fichier à l’aide d’analyse assistée par graphe. Comparaison côte à côte d’un IOC du chemin de fichier original et de sa représentation normalisée. Les requêtes de parcours basées sur les graphes connaissent les composants de chemin par un nom normalisé et étiquettent chaque composant comme keep ou disface. Les identifiants de disque et les fragments de noms de fichiers variables peuvent donc être marqués comme défaussés dans l’enregistrement composant tandis que la forme normalisée est principalement reconstruite à partir de segments structurels conservés nécessaires à la construction de motifs en aval. Veuillez cliquer ici pour voir une version agrandie de cette figurine.

Figure 7 : Normalisation de l’IOC de la clé de registre à l’aide d’analyse assistée par graphe. Normalisation d’une clé de registre IOC par résolution assistée par graphe des structures hiérarchiques de registres. Les clés racines abrégées sont étendues aux ruches canoniques du registre, et l’analyseur extrait la plus longue sous-chaîne de registre contiguë connue tout en sautant les placeholders hôtes, les valeurs similaires à SID et les jetons de type GUID. Les enregistrements de sortie conservent/suppriment des labels pour chaque composant conservé et produisent un chemin de registre canonique pour le traitement en aval. Veuillez cliquer ici pour voir une version agrandie de cette figurine.

Figure 8 : Normalisation IOC en ligne de commande utilisant l’analyse assistée par graphe. Comparaison d’un IOC original en ligne de commande et de sa représentation normalisée. Le protocole tokenise la ligne de commande tout en préservant les chaînes de guillemets, normalise le jeton de commande principal via la recherche Neo4j lorsque possible, et analyse récursivement les fragments intégrés de type chemin ou de type registre. Les composants stables liés à la commande sont étiquetés conserver, les arguments des variables sont appelés « défaussez, » et la structure de commande canonique finale est reconstruite à partir des éléments conservés. Veuillez cliquer ici pour voir une version agrandie de cette figurine.

Figure 9 : Sélection des candidats à expression régulière basée sur les contraintes. Plusieurs candidats réguliers sont générés pour chaque IOC normalisé en utilisant un flux de validation itératif. Un mécanisme de notation piloté par contraintes est appliqué pour sélectionner un régex final qui préserve les composants désignés du groupe de capture tout en limitant les sous-chaînes de variables indésirables. Veuillez cliquer ici pour voir une version agrandie de cette figurine.

Figure 10 : Répartition des IOC extraits à travers les rapports CTI. Résumé des résultats d’extraction IOC montrant le nombre total d’indicateurs identifiés à partir des rapports CTI et leur répartition entre les chemins de fichiers, les clés de registre et les indicateurs en ligne de commande. Cette vue fournit une validation de haut niveau de la couverture du contenu CTI et du comportement d’extraction. Veuillez cliquer ici pour voir une version agrandie de cette figurine.

Figure 11 : Distribution des actions d’optimisation lors de la génération d’expressions régulières. Décomposition des actions effectuées lors de la génération de regex, y compris la génération initiale, l’optimisation pilotée par LLM et la régénération basée sur des réessais. L’optimisation pilotée par LLM représente 51,7 % de toutes les actions, illustrant que l’affinement itératif est un élément essentiel du protocole pour produire des régex satisfaisant les contraintes du groupe de capture. Veuillez cliquer ici pour voir une version agrandie de cette figurine.

Figure 12 : Fichier regex exporté de façon représentative. Exemples de contenus de l’exportation régulière SIEM (siem_rules.txt) générée par le protocole. Chaque entrée inclut l’IOC source, la catégorie inférée (chemin du fichier, clé de registre ou ligne de commande) et le motif regex validé. Le tableau de validation accompagnant résume le comportement attendu et les preuves système utilisées pour confirmer la correction de chaque type de règle. Veuillez cliquer ici pour voir une version agrandie de cette figurine.

Figure 13 : Rapport JSON complet représentatif. Sortie de pipeline de bout en bout produite après l’exécution des cinq étapes du protocole sur un rapport CTI représentatif. Le document JSON enregistre le fichier source, le nombre de sections analysées, les IOC extraits regroupés par catégorie, les enregistrements catégorisés de l’étape 3 avec des tags source, la différencielle de normalisation de l’étape 4, et les motifs réguliers de l’étape 5 avec des drapeaux de validation par IOC. Le rapport expose également des métadonnées de réussite et d’erreur de haut niveau qui permettent aux outils en aval de détecter des défaillances partielles. Veuillez cliquer ici pour voir une version agrandie de cette figurine.

Figure 14 : Entrée ratée ou bruyante : identification et correction. Exemple fonctionnel de la façon dont le protocole identifie et récupère à partir d’un IOC bruyant. L’entrée brute %T E M P %\malware[.]EXE est signalé car son jeton à variable d’environnement contient des espaces insérés et son extension de fichier a été défangée. L’étape de correction supprime l’espace blanc inséré et restaure le point littéral ; La normalisation de l’étape 4 étend alors %TEMP % au modèle de répertoire Windows Temp canonique ; et l’étape 5 génère un regex qui compile et correspond à l’IOC normalisée corrigée. Cet exemple illustre la gestion des entrées bruyantes discutée dans la Discussion. Veuillez cliquer ici pour voir une version agrandie de cette figurine.

Élément	Type	Valeur / Schéma	Exemple	Notes
Étiquette de nœud	Label	:P ath	Windows, System32, cmd.exe	Stocke les composants du chemin de fichiers Windows
Étiquette de nœud	Label	:Registre	LOGICIEL, Microsoft, Windows NT	Stocke les composants de la clé de registre sous les ruches racinaires
Étiquette de nœud	Label	:CLI	powershell.exe, -ExécutionPolitique, Contournement	Stocke les jetons de commande et les paramètres
Propriété du nœud	Corde	Nom	cmd.exe	Enveloppe d’origine ; Utilisé pour l’affichage dans la sortie normalisée
Propriété du nœud	Corde	name_lower	cmd.exe	Forme minuscule ; utilisé comme clé de recherche pour toutes les requêtes MATCH
Relation	Arête dirigée	(a)-[ :NEXT]->(b)	(Windows)-[ :NEXT]->(System32)	Les deux extrémités partagent la même étiquette ; encode l’adjacence native sur les systèmes Windows
Contrainte	Unicité	n.name_lower UNIQUE par label	-	Postulé à :P ath, :Registry, :CLI
Source des données	Couverture	Windows 8, 10, 11	-	OS client rempli en graphe
Source des données	Couverture	Windows Server 2012, 2016, 2019, 2022	-	OS serveur rempli en graphe

Tableau 1 : Schéma de graphe Neo4j utilisé pour la normalisation de l’IOC (Étape 4). Liste les trois étiquettes de nœuds (Chemin, Registre, CLI), leur schéma de propriété partagée (nom, name_lower), la relation d’adjacence dirigée utilisée pour l’ordre natif des arêtes, les contraintes d’unicité, ainsi que les versions client et serveur Windows qui peuplent le graphe.

Scène	Production attendue	Validation automatisée	Contrôle qualité orienté vers les analystes
Étape 1 : Analyse syntaxique des documents	Texte Markdown unifié, divisé à 4 000 caractères avant le traitement du LLM.	—	Vérification visuelle de l’aperçu Markdown pour confirmer que les chemins de fichiers, les clés de registre, les fragments de ligne de commande et les limites de section survivent à l’analyse ; Changez de backend si les chaînes techniques sont tronquées.
Étape 2 : extraction de l’IOC	JSON avec trois clés de premier niveau (chemins de fichier, lignes de commande, clés de registre) ; les décomptes de votes par COI et les métadonnées du modèle contributif lorsque le vote en ensemble est activé.	Le filtre de seuil de consensus (min_votes) exclut les IOC dont le nombre de votes est inférieur au seuil configuré.	Inspection des candidats exclus pour distinguer les hallucinations du vote trop strict avant d’ajuster min_votes.
Étape 3 : Analyse et classification du CIO	Liste IOC catégorisée : chaque IOC associé à une catégorie standardisée, une balise source et une clé d’extraction originale lorsque disponible.	Mappage standardisé de catégories via des règles basées sur des règles régulières et des heuristiques de motifs IOC ; (IOC, catégorie) déduplication de paires.	Vérification ponctuelle des résultats catégorisés pour des candidats ambigus ou bruyants (Figure 4A).
Stade 4 : Normalisation assistée par Neo4j	Formulaire normalisé par IOC avec étiquettes de maintien / défausse au niveau des composants.	Les requêtes de chiffrement (i)-(iii) sur le graphe de référence Windows ; Prétraitement déterministe en option lorsque Neo4j n’est pas disponible.	Inspection des cas entièrement déchus afin d’identifier les lacunes de couverture graphique ; extension des données de graphes avec des références spécifiques au fournisseur ou à l’environnement lorsque cela est nécessaire.
Étape 5 : Génération et notation Regex	Régex final par IOC avec les scores des candidats, l’historique d’optimisation, le nombre d’itérations et la télémétrie par IOC.	Test de correspondance, contrôles de qualité statiques, vérification des jetons interdits conscients des frontières, test de surgénéralisation contre 5 échantillons déterministes négatifs ; Revenir au match partiel le plus haut score (drapeau used_fallback).	Revue de l’historique d’optimisation pour les regex de secours ; inspection diagnostique de la position de défaillance par IOC avant la régénération.

Tableau 2 : Résumé des résultats et validation par étape. Associe chaque étape du protocole (1–5) à son artefact attendu, aux preuves de validation automatisée produites par le pipeline (statut de compilation regex, taux de réussite, taux de désappariement inter-IOC, nombre d’itérations d’optimisation), et au contrôle qualité correspondant face aux analystes (comparaison visuelle, inspection des candidats écartés et revue de catégorie).

Fichier supplémentaire 1 : Prompts de LLM verbatim. Le système mot à mot et les prompts humains utilisés pour l’extraction IOC de l’étape 2 et la génération et l’optimisation des regex de l’étape 5. Veuillez cliquer ici pour télécharger ce fichier.

Fichier supplémentaire 2 : Détails de mise en œuvre pour les étapes 4 et 5. Détails algorithmiques et d’implémentation supportant la normalisation IOC assistée par graphe de l’étape 4 ainsi que la validation, le score et le contrôle de l’itération regex de l’étape 5. Veuillez cliquer ici pour télécharger ce fichier.

Discussion

Traduire les rapports CTI non structurés en logique de détection exécutable reste une tâche longue et sujette aux erreurs dans les flux de travail de sécurité opérationnelle. Bien que les efforts antérieurs aient exploré l’automatisation au niveau de l’extraction de l’IOC ou de la génération de règles de haut niveau, les praticiens rencontrent encore d’importants défis pour convertir les chaînes IOC extraites en regex structurellement correctes, sémantiquement précises et adaptées à une utilisation SIEM en aval. Le protocole présenté ici couvre cette lacune via un flux de travail en étapes où chaque phase produit un artefact intermédiaire bien défini et applique une validation explicite avant de passer les résultats à l’étape suivante. La figure 14 documente un de ces cas, dans lequel un chemin de fichier décroque, perturbé par l’espace blanc, est identifié, corrigé, normalisé et converti en un régulateur de compilation ; La gestion des entrées bruitées du protocole et son champ actuel sont discutés conjointement avec les limitations énumérées ci-dessous.

Une contribution centrale de ce protocole est sa décomposition explicite du flux de travail en étapes avec des sorties intermédiaires inspectables. L’implémentation est désormais décrite de manière concrète : l’analyse des documents produit du Markdown et du texte en blocs pour le traitement des LLM ; L’extraction IOC émet du JSON structuré pour les chemins de fichiers, les clés de registre et les indicateurs en ligne de commande ; l’analyse IOC basée sur des règles standardise et déduplique les valeurs extraites ; La normalisation assistée par Neo4j étiquette chaque composant IOC comme conserver ou rejeter ; et la génération de régex applique le débogage de correspondance, la validation des défausses et des contrôles de généralisation excessive avant la sélection des candidats.

Le protocole considère la génération d’expressions régulières comme une tâche de construction itérative plutôt que comme un problème de prédiction en un seul coup. L’implémentation utilise une invite de génération initiale, des diagnostics automatisés de correspondance, des boucles de raffinement plafonnées, et une fonction de notation basée sur les composants pour préserver les éléments IOC structurellement importants tout en pénalisant les sous-chaînes rejetées ou non cartographiées. Cette conception itératif, combinée aux validateurs déterministes appliqués à chaque étape, permet la production de motifs réguliers qui restent structurellement fidèles à travers un ensemble d’évaluation large et hétérogène. Dans l’évaluation de référence, ce flux de travail a été appliqué à 3 156 rapports CTI et évalué sur plus de 2 400 chaînes indépendantes de vérification du terrain, donnant un taux moyen de réussite de 99,1 % et un taux moyen de désaccord entre IOC de 0,8 %. Parce que ces chaînes de vérité sur le terrain sont des artefacts sélectionnés par des experts rapportés par des fournisseurs de cybersécurité lors des exercices d’évaluation MITRE ATT&CK, cette évaluation compare implicitement les résultats du protocole aux schémas IOC documentés par des analystes humains plutôt qu’à ceux générés automatiquement.

Comme le montrent les résultats représentatifs, l’optimisation itérative est particulièrement importante lorsque le workflow gère des structures IOC complexes telles que des chemins de fichiers imbriqués ou de longues chaînes de lignes de commande. Les résultats d’évaluation des références indiquent également que les cas non appariés les plus courants surviennent lorsque les attaquants utilisent des exécutables personnalisés ou des paramètres qui ne sont pas représentés dans la base de données des graphes ou qui ne sont pas explicitement documentés dans les rapports CTI sources. En usage opérationnel, ces modes de défaillance doivent être considérés comme des conditions aux limites attendues plutôt que comme des erreurs silencieuses et devraient déclencher l’examen de la couverture du graphe, de la complétude source-rapport et de la télémétrie par débogage régulier.

Le protocole peut être comparé à trois familles de méthodes alternatives. Premièrement, les méthodes de synthèse regex basées sur des exemples telles que TransRegex¹¹ et Regex+¹² apprennent les régex à partir d’ensembles sélectionnés d’exemples de chaînes positives et négatives. Ces méthodes fonctionnent bien lorsque des ensembles d’exemples représentatifs sont disponibles mais sont moins directement applicables aux contextes SOC, où chaque IOC rapporté dans le CTI apparaît généralement comme une seule chaîne représentative, et la frontière de généralisation requise est déterminée par la sémantique opérationnelle plutôt que par la couverture par exemple. Deuxièmement, les approches de programmation génétique telles que celles introduites par Bartoli et ^al.13,14 explorent l’espace des régex à travers des opérateurs évolutifs et nécessitent généralement un corpus étiqueté de chaînes de correspondance et de non-correspondance ; ils sont bien adaptés à la construction en lots de schémas d’extraction mais ne consomment pas directement des récits non structurés de la CTI. Troisièmement, les approches récentes basées sur les neurones et les LLM^15,16 traduisent directement les descriptions en langage naturel en chaînes de régulation régulière ; ces méthodes sont puissantes pour des invites bien spécifiées mais, en usage en un seul coup, peuvent produire des régex syntaxiquement valides mais manquent les composants du groupe de capture requis ou se généralisent à l’excès entre variantes IOC non liées. Le protocole actuel complète ces directives en (i) prenant des rapports CTI non structurés plutôt que des ensembles d’exemples sélectionnés ou des requêtes en langage naturel en entrée, (ii) décomposant chaque IOC en composants keep et discard via une normalisation assistée par graphe avant la génération d’un regex, et (iii) validant chaque regex candidat avec des contrôles déterministes de correspondance, de rejet et de surgénéralisation au sein d’une boucle itérative plafonnée. L’objectif n’est pas de surpasser les méthodes précédentes sur leurs propres benchmarks, mais de fournir un pipeline IOC-regex reproductible dont les décisions intermédiaires sont inspectables et auditables par les analystes SOC.

Le protocole fait plusieurs hypothèses sur la qualité des rapports CTI d’entrée. Elle suppose que (i) les chaînes IOC apparaissent sous forme textuelle récupérable après l’analyse des documents, c’est-à-dire que les chemins de fichiers, les clés de registre et les indicateurs de ligne de commande ne sont pas intégrés exclusivement dans les images, captures d’écran ou encodages obscurcis ; (ii) les fragments IOC rapportés dans le CTI sont suffisamment complets pour préserver leurs ancrages structurels (par exemple, les clés de registre conservent leur préfixe de ruche, les chemins de fichiers conservent au moins un ancrage de répertoire reconnaissable pour le graphe de documentation Windows, et les lignes de commande conservent l’exécutable invoquant ou une référence de module connue) ; et (iii) les IOC rapportés ne sont pas tronqués, caviardés ou réécrits de manière à supprimer les composants du groupe de capture dont dépend le protocole. Les rapports CTI qui satisfont à ces hypothèses incluent la plupart des descriptions de techniques MITRE ATT&CK, avis aux fournisseurs, rapports d’intervention et bulletins de menaces bien formatés. Les rapports qui reposent principalement sur des captures d’écran, des listes IOC très abrégées sans contexte environnant, ou des paraphrases en texte libre sans chaînes explicites d’IOC sortent de l’enveloppe opérationnelle prévue et devraient s’attendre à ce qu’elles produisent une réduction du rappel d’extraction et une normalisation moins fidèle ; Ces rapports peuvent bénéficier d’un prétraitement image en texte en amont ou d’une revue par les analystes avant d’entrer dans la chaîne de jeu.

Plusieurs limitations doivent être prises en compte lors de l’application de ce protocole. Premièrement, l’implémentation actuelle se concentre sur les chemins de fichiers, les clés de registre et les indicateurs en ligne de commande, plutôt que sur des catégories plus larges d’IOC telles que les domaines, les artefacts email, les chaînes d’agent utilisateur ou les séquences comportementales. C’est un choix délibéré de portée, car les indicateurs atomiques sont généralement bien servis par des flux de travail à correspondance exacte et le protocole actuel cible les IOC à structure variable bénéficiant de la généralisation des regex ; elle restreint néanmoins l’applicabilité aux types IOC qui ne sont pas actuellement représentés dans le graphique. Deuxièmement, les scénarios de défaillance actuels se divisent en trois grandes catégories : des chemins non natifs ou des arguments en ligne de commande absents du graphe du système d’exploitation, une couverture incomplète du graphe pour les utilitaires ou structures pertinentes, et l’incomplétude dans la source CTI elle-même lorsque des fragments de commande importants ou des cmdlets ne sont jamais rapportés. Troisièmement, la métrique de désappariement inter-IOC utilisée dans l’évaluation de référence mesure la spécificité sémantique des régex générés plutôt que les faux positifs d’alerte de bout en bout sous la logique SIEM déployée.

Reproductibilité sous la variabilité et le versionnement des LLM. Parce que les étapes d’extraction et de génération de régulateurs réguliers de l’IOC dépendent des terminaux LLM commerciaux, deux sources de variabilité affectent la reproductibilité : les mises à jour du modèle côté fournisseur au fil du temps et la stochasticité par échantillonnage par appel. Pour atténuer le premier, tous les champs liés aux LLM dans la Table des matériaux enregistrent les identifiants exacts du modèle et la date d’accès utilisée dans l’évaluation de référence, et le protocole recommande d’épingler sur un instantané spécifique du modèle chaque fois que le fournisseur en expose un. Pour atténuer la seconde, l’implémentation de référence fixe la température d’extraction IOC à 0,0 et utilise une température non nulle uniquement à la génération de regex, où le vote d’ensemble et les validateurs déterministes aux étapes 2 et 5 absorbent la variation résiduelle. Lors de la réplique de ces résultats, les utilisateurs doivent enregistrer la version exacte du modèle, la date d’accès, la température et le seuil de vote de l’ensemble utilisé ; Des déviations substantielles sur l’un de ces axes devraient être attendues pour modifier les indicateurs de taux de réussite et de désaccord.

Plusieurs modes de défaillance récupérables peuvent être traités au niveau de l’étage qui les a produits. Les échecs d’analyse de l’étape 1 (par exemple, des PDF numérisés produisant un Markdown vide ou brouillé) : prétraiter l’entrée avec reconnaissance optique de caractères ou un convertisseur externe avant de le re-téléverser ; Vérifiez que le nombre de sections analysées et le nombre total de caractères sont différents avant de poursuivre. Échecs d’extraction de l’étape 2 (aucun IOC retourné, ni entrées hallucinées) : augmenter le seuil de vote d’ensemble (votes minimaux ≥ 2), permettre des instances de modèles supplémentaires ou baisser la température du LLM ; vérifier la connectivité API et que le modèle configuré accepte la sortie formatée JSON. Normalisation de l’étape 4 avec des étiquettes entièrement défaussées (chaque composant IOC est étiqueté comme défauché) : étendre le graphique de référence Neo4j avec des composants de chemin spécifiques au fournisseur ou à l’environnement et aux racines du registre ; les scripts d’importation Cypher et la règle de décision de conserver/rejeter sont listés dans le Fichier Supplémentaire 2. Défaillances regex de l’étape 5 (used_fallback = vrai, ou rejets répétés de validation de défausse) : inspectez le champ d’historique d’optimisation par IOC pour identifier le validateur défaillant ; si le CIO manque réellement de composants de maintien stables, envisagez la création manuelle de régulation régulière pour ce CIO ou son exclusion de la génération automatisée des règles tout en le conservant dans le tableau catégorisé de l’IOC pour la revue par les analystes.

Conformément aux limitations ci-dessus, les régex générés sont mieux traités comme des primitives de recherche réutilisables dans un contenu plus large de détection SOC plutôt que comme des détecteurs autonomes. Dans les contextes opérationnels, les analystes peuvent les combiner avec une logique de terrain spécifique à la plateforme, des listes blanches, des vérifications de provenance ou des conditions de corrélation pour supprimer des correspondances bénignes provenant de chemins inhabituels mais non malveillants.

Les travaux futurs pourraient inclure une comparaison systématique avec des regex rédigés par des humains, une évaluation plus large sur d’autres catégories IOC, des études structurées de rétroaction par les analystes, une couverture accrue des graphes pour les utilitaires et cmdlets créés par les attaquants, ainsi qu’un reporting plus complet de la latence et des coûts de bout en bout à travers les contextes de déploiement. Néanmoins, le protocole actuel fournit un cadre reproductible et interprétable opérationnellement pour la traduction IOC vers regex, qui documente à la fois ses forces et ses limites actuelles.

Matériaux

Liste des matériaux utilisés dans cet article

Nom	Entreprise	Numéro de catalogue	Commentaires
Computer (CPU)	—	≥ 4 cœurs recommandés	Aucune GPU requise
LangChain	LangChain	≥ 0.1.x	Cadre d'orchestration LLM
LLM (extraction IOC, modèle unique)	OpenAI	gpt-5.1	Utilisé pour l'extraction IOC (étape 2) lorsque le vote par ensemble est désactivé. temperature = 0.0; max_workers = 5. Consulté : 2025-12-15.
LLM (génération de regex)	OpenAI	gpt-5.1	Utilisé pour la génération de regex (étape 5). temperature = 0.3 avant la validation en aval. Consulté : 2025-12-15.
LLM (caractérisation de l'évolutivité)	OpenAI	gpt-5.1	Utilisé pour l'exécution d'évolutivité 6 000-IOC rapportée dans les résultats représentatifs. Consulté : 2025-12-15.
Mémoire (RAM)	—	≥ 16 Go recommandés	Requis pour le traitement des documents
Neo4j	Neo4j, Inc.	≥ 5.x	Base de données graphique pour la normalisation IOC
Pilote Python Neo4j	Neo4j, Inc.	≥ 5.x	Interface Python pour Neo4j
Système d'exploitation	Microsoft / Apple / Linux	Windows, macOS ou Linux	Support multiplateforme
Analyse PDF — backend principal	Microsoft	MarkItDown ≥ 0.0.x	Backend de l'étape 1 ; convertit les entrées PDF/DOCX/HTML/TXT en Markdown. Sortie analysée par segments de 4 000 caractères avant le traitement LLM. Consulté : 2025-12-15. https://github.com/microsoft/markitdown
Configuration du pipeline (étape 2 — extraction IOC)	—	Référence par défaut	Mode LLM unique : temperature = 0.0, max_workers = 5. Mode de vote par ensemble par défaut : repeats = 1 par modèle configuré, min_votes = 2.
Configuration du pipeline (étape 5 — génération regex)	—	Référence par défaut	Température de génération = 0.3. Validation : overgen_random_tests = 5 échantillons négatifs déterministes par IOC. Limites d'itération : max_iterations = 10, debug_loop_cap = 5, discard_validation_cap = 5.
Python	Python Software Foundation	≥ 3.8	Environnement d'exécution requis
Moteur de regex	Bibliothèque standard Python	module re	Utilisé pour la validation et les tests regex
Streamlit	Streamlit Inc.	≥ 1.25	Interface utilisateur web
Code source de l'implémentation de référence	Auteurs / GitHub | Dépôt GitHub		Code source de l'interface Streamlit, du pipeline LangChain, de la normalisation assistée par Neo4j, de la génération de regex, des utilitaires de validation et des fichiers de configuration d'exemple. Disponible sur https://github.com/SOCautomatic/cti-ioc-regex-pipeline. Consulté : 11 juin 2026.