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’éva...

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 ...

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.