Classification des menaces par LLM pour le renseignement sur les cybermenaces

Les équipes de renseignement sur les cybermenaces font face à un problème de données en constante aggravation. Le volume des données de menace brutes — flux d'IOC provenant des ISAC, OSINT collecté sur des sites de partage et des canaux Telegram, exports de forums du dark web, rapports de renseignement de fournisseurs — a augmenté plus vite que les effectifs d'analystes dans toute organisation qui prend le CTI au sérieux. Le résultat est un arriéré : des données de menace qui arrivent à temps pour être exploitables mais qui ne sont pas classifiées, enrichies ou corrélées avant que la fenêtre se ferme. La classification manuelle à grande échelle n'est pas un problème de flux de travail. C'est un problème structurel qui ne peut pas être résolu en embauchant davantage d'analystes.

Les grands modèles de langage offrent une véritable solution — non pas en remplacement du jugement des analystes, mais comme couche de classification et d'enrichissement qui convertit les données de menace non structurées en enregistrements structurés à vitesse machine. Cet article couvre les décisions architecturales qui importent lors de l'intégration des LLM dans un pipeline CTI : quelle classe de modèle utiliser pour quelle tâche, comment structurer le pipeline de l'ingestion à la sortie avec STIX 2.1 et MITRE ATT&CK, quelles données d'entraînement produisent des classifieurs fiables au niveau des techniques, comment évaluer les performances dans un contexte SOC, et comment concevoir les contrôles avec analyste dans la boucle qui maintiennent la fiabilité du système dans des conditions adversariales.

Pourquoi la classification CTI manuelle ne passe pas à l'échelle

Le problème d'échelle est à la fois quantitatif et qualitatif. Sur le plan quantitatif : une organisation de défense de niveau intermédiaire surveillant un ensemble réaliste de flux de menaces — deux ou trois flux ISAC, AlienVault OTX, plusieurs serveurs communautaires MISP, et un enrichissement par DNS passif et journaux de transparence des certificats — reçoit des dizaines de milliers d'indicateurs bruts par jour. Classifier chaque IOC par acteur de menace, famille de maliciels et technique ATT&CK pertinente manuellement se mesure en heures-analyste par jour que la plupart des équipes CTI n'ont pas.

Le problème qualitatif est l'hétérogénéité des sources. Les ISAC livrent des bundles STIX structurés avec des étiquettes relativement propres. Les flux OSINT livrent de la prose non structurée : billets de blog, fils de discussion, exports de canaux Telegram. Les données du dark web arrivent dans des formats qui nécessitent un prétraitement significatif avant toute tentative de classification significative. Chaque source nécessite une approche d'extraction différente, et maintenir des extracteurs basés sur des règles fiables à travers toutes ces sources — tout en suivant le rythme auquel les acteurs de menace varient délibérément leur langage pour éviter la détection — est une charge de maintenance qui s'accumule avec le temps.

L'épuisement des analystes est la conséquence en aval. Lorsque la file d'attente de classification est en permanence surchargée, les analystes cessent d'examiner les enregistrements individuels et ne traitent que les éléments pré-filtrés de plus haute sévérité. Le résultat est des angles morts systématiques dans la vue des menaces — non pas parce que les données n'ont pas été collectées, mais parce qu'elles n'ont jamais été classifiées et corrélées. Une couche de classification LLM n'élimine pas le besoin du jugement des analystes ; elle élimine la partie du flux de travail où les analystes effectuent un travail qui peut être automatisé de manière fiable.

Architecture LLM pour le CTI : modèles encodeurs vs génératifs

Le choix architectural le plus déterminant dans un pipeline CTI basé sur LLM est la classe de modèle à utiliser à chaque étape. Les modèles encodeurs (classe BERT) et les modèles génératifs (classe GPT) ont des forces fondamentalement différentes, et utiliser la mauvaise classe pour une tâche produit soit une faible précision soit un coût inutile.

Modèles encodeurs pour la classification

Les modèles encodeurs de classe BERT — en particulier les variantes adaptées au domaine et affinées sur des textes de sécurité, telles que SecBERT ou CySecBERT — sont le bon choix pour les tâches de classification à taxonomie fixe. Étant donné un document CTI et un ensemble d'étiquettes prédéfini (identifiants de techniques ATT&CK, noms de familles de maliciels, groupes d'acteurs de menace), un encodeur affiné produit des scores de classification sur l'espace des étiquettes en moins de 500 millisecondes sur du matériel modeste. L'affinage sur des corpus CTI étiquetés de 5 000 à 20 000 exemples atteint généralement une précision prête pour la production.

La contrainte critique est que l'ensemble des étiquettes doit être fixe et connu au moment de l'entraînement. Les modèles encodeurs ne peuvent pas généraliser à des étiquettes non vues pendant l'entraînement. Pour la classification des techniques MITRE ATT&CK, ce n'est pas une limitation en pratique : la taxonomie des techniques ATT&CK est versionnée, et les mises à jour peuvent déclencher un cycle d'affinage ciblé. Pour la classification des familles de maliciels, où de nouvelles familles émergent en continu, l'encodeur doit être associé à un mécanisme de détection hors distribution qui achemine les candidats de famille inconnue vers un analyste plutôt que de forcer une classification par correspondance la plus proche.

Modèles génératifs pour l'enrichissement

Les modèles génératifs sont le bon choix lorsque la sortie est ouverte ou nécessite un raisonnement sur le contexte du document. Extraire des champs IOC structurés d'un rapport non formaté sur un acteur de menace, synthétiser un bref narratif à partir d'un ensemble d'enregistrements d'événements structurés, inférer la géographie de la victime à partir d'indices implicites plutôt que de noms de pays explicites — ces tâches nécessitent des capacités que la classification par encodeur ne peut pas fournir.

La discipline clé lors de l'utilisation de modèles génératifs dans un pipeline CTI est la contrainte du format de sortie. Un modèle génératif laissé à produire une sortie en texte libre introduira une synonymie et une incohérence qui rendent l'agrégation en aval peu fiable. La solution est le prompting à sortie structurée : le modèle est instruit de produire une réponse JSON conforme à un schéma strict, avec une validation de schéma appliquée à la réception. Les échecs d'analyse de la réponse déclenchent une nouvelle tentative automatique avec des instructions correctives. Cette discipline convertit un système génératif probabiliste en une source de données structurées fiable.

L'enrichissement génératif est également le bon endroit pour le scoring de confiance. Le modèle est invité à retourner un score de confiance par champ entre 0 et 1, représentant une incertitude épistémique réelle étant donné le contenu du document source. Un message qui nomme explicitement une organisation victime et un pays produit des champs de géographie et d'organisation à haute confiance ; un message qui implique un secteur sans nommer une organisation produit une confiance plus faible. Ces scores guident les décisions d'acheminement en aval dans le pipeline.

Conception du pipeline : de l'IOC brut au mappage MITRE ATT&CK

Un pipeline de classification CTI en production comporte cinq étapes distinctes, chacune avec des entrées, des sorties et des modes d'échec spécifiques.

Étape 1 — Ingestion et normalisation. Les données de menace brutes arrivent dans des formats hétérogènes : bundles STIX 2.1 des flux ISAC, exports d'événements MISP, JSON provenant d'API commerciales de renseignement sur les menaces, et texte non structuré de sources OSINT. L'étape d'ingestion normalise toutes les entrées vers un format de document interne canonique avant tout traitement LLM. Pour les entrées STIX et MISP, il s'agit principalement d'extraction de champs. Pour le texte non structuré, cela inclut la détection de langue, la normalisation de l'encodage et le filtrage par longueur minimale (les documents de moins d'environ 50 tokens manquent de contexte suffisant pour une classification fiable). Les métadonnées source — identifiant du flux, horodatage d'ingestion, score de confiance du fournisseur en amont si présent — sont préservées comme champs d'enveloppe tout au long du pipeline.

Étape 2 — Porte de pertinence binaire. Tous les documents ingérés ne sont pas candidats à la classification LLM complète. Un classifieur binaire léger (un modèle encodeur affiné à 350M de paramètres ou moins) s'exécute en premier pour filtrer les documents qui ne contiennent pas de contenu de menace opérationnel : résumés d'actualités, bulletins administratifs, IOC faux positifs déjà connus comme propres. Cette porte réduit le volume d'inférence LLM de 60 à 80 % dans les configurations de flux typiques, réduisant directement le coût par jour. La porte est calibrée pour un rappel élevé — manquer un véritable document de menace est plus coûteux qu'envoyer un document non opérationnel à l'étape LLM.

Étape 3 — Classification et enrichissement LLM. Les documents passant la porte binaire entrent dans l'étape de classification. Un encodeur affiné attribue des identifiants de techniques ATT&CK et des étiquettes de familles de maliciels. Un passage d'enrichissement génératif extrait des champs structurés : groupe d'acteurs de menace, organisation victime, secteur (à partir d'une taxonomie fixe à huit catégories), géographie (ISO 3166-1 alpha-2), vecteur d'attaque et scores de confiance par champ. Les deux passages peuvent s'exécuter en parallèle puisqu'ils opèrent sur le même document d'entrée.

Étape 4 — Mappage MITRE ATT&CK et résolution d'entités. Les identifiants de techniques du classifieur sont mappés vers des objets ATT&CK avec un enrichissement complet : association de tactique, applicabilité à la plateforme et références aux orientations de détection. Les noms d'acteurs de menace et d'organisations victimes sont résolus par rapport à l'index d'entités existant à l'aide d'une correspondance floue de noms et d'une désambiguïsation par code pays. Les alias connus sont canonicalisés. Les nouvelles entités déclenchent la création d'un enregistrement provisoire pour révision par un analyste plutôt qu'une insertion silencieuse.

Étape 5 — Sérialisation STIX 2.1 et sortie. Les enregistrements enrichis sont sérialisés comme des bundles STIX 2.1 — objets Threat Actor, Malware, Attack Pattern, Indicator et Relationship avec des références externes appropriées aux identifiants de techniques ATT&CK. Les bundles sont validés par rapport au schéma STIX 2.1 avant stockage ou export. Pour l'intégration MISP, les mêmes enregistrements structurés se mappent vers des événements MISP via la galaxie ATT&CK. Pour l'intégration SIEM, les formats CEF et JSON structuré sont supportés pour l'ingestion directe d'alertes.

Données d'entraînement pour la classification des TTP adversariaux

La qualité d'un modèle de classification CTI est déterminée principalement par la qualité et la couverture de ses données d'entraînement. Trois sources fournissent les données étiquetées les plus fiables pour la classification des techniques ATT&CK.

La base de connaissances MITRE ATT&CK est le point de départ canonique. Chaque entrée de technique contient des descriptions en prose, des exemples de procédures tirés de rapports réels d'acteurs de menace, et des orientations de détection. Les exemples de procédures — descriptions de la façon dont des groupes d'acteurs de menace spécifiques ont utilisé une technique dans des opérations confirmées — sont le signal d'entraînement de la plus haute qualité car ils capturent les patterns de langage naturel que les analystes utilisent pour décrire l'activité TTP. Le corpus ATT&CK est maintenu sous contrôle de version ; chaque version ajoute de nouvelles techniques et affine les existantes, de sorte que les pipelines d'affinage doivent être alignés sur des versions ATT&CK spécifiques.

Les exports de pulses AlienVault OTX fournissent des données sur les acteurs de menace et les familles de maliciels étiquetées à grande échelle. Chaque pulse contient un titre, une description et des IOC associés étiquetés avec l'acteur de menace ou la famille de maliciels que le soumetteur leur attribue. La qualité des étiquettes varie selon les soumetteurs ; filtrer les pulses d'organisations vérifiées améliore significativement le signal d'entraînement. Les exports OTX au format STIX permettent une ingestion cohérente.

Pour l'étiquetage des TTP adversariaux, les rapports de renseignement des fournisseurs (publiés sous des termes permissifs) contiennent des attributions de techniques de haute qualité énoncées explicitement : « Le groupe a utilisé T1055.012 (Process Hollowing) pour s'injecter dans des processus Windows légitimes. » Ces déclarations fournissent des étiquettes directes au niveau des techniques avec de la prose contextuelle. Les extraire nécessite un passage d'annotation ponctuel pour aligner le texte du rapport aux identifiants de techniques ATT&CK, mais les exemples étiquetés résultants sont parmi les plus fiables disponibles pour l'affinage.

La stratégie d'étiquetage pour les techniques rares nécessite une attention particulière. ATT&CK contient plus de 600 techniques et sous-techniques, et beaucoup apparaissent dans moins de 20 exemples étiquetés dans tout corpus disponible. Pour ces classes rares, l'augmentation de données (paraphrase des descriptions d'exemples de procédures) et le prompting few-shot avec un modèle génératif comme classifieur de repli sont deux approches viables. Le plancher pratique minimal pour une classification affinée fiable est d'environ 80 exemples étiquetés par classe ; les classes en dessous de ce seuil doivent être acheminées vers un modèle génératif avec un prompt few-shot plutôt qu'un encodeur affiné.

Métriques d'évaluation dans un contexte SOC

Les métriques de précision standard induisent en erreur lorsqu'elles sont appliquées à la classification CTI car la distribution des étiquettes de techniques de menace est fortement déséquilibrée. Des techniques comme T1566 (Phishing) et T1059 (Command and Scripting Interpreter) apparaissent dans une grande part des rapports d'incidents réels. Les techniques rares mais à haute valeur — T1195 (Supply Chain Compromise), T1600 (Weaken Encryption) — apparaissent bien moins fréquemment. Un modèle qui atteint 92 % de précision globale en concentrant ses performances sur les techniques courantes tout en échouant sur les techniques rares à haute valeur est opérationnellement inutile.

Les métriques qui comptent pour la classification CTI en production sont la précision et le rappel par technique, rapportés séparément sur toute la taxonomie des techniques. Le F1 moyenné macro — la moyenne non pondérée du F1 par classe sur toutes les étiquettes de techniques — est la métrique récapitulative qui représente le mieux les performances globales sur une distribution d'étiquettes déséquilibrée. Pour un pipeline CTI servant un SOC, le rappel au niveau de la technique pour les classes de surveillance prioritaires (les techniques spécifiques pertinentes aux acteurs de menace ciblant votre secteur et géographie) est le chiffre opérationnellement le plus important. Manquer 20 % des événements T1055 dans une organisation de défense surveillant des menaces persistantes avancées n'est pas un compromis précision-rappel acceptable, quel que soit l'aspect du score F1 macro.

Le coût des faux positifs dans un contexte SOC est asymétrique. Un faux positif — un document classifié comme contenant une technique ATT&CK spécifique alors qu'il ne le fait pas — coûte du temps à l'analyste qui examine un enregistrement fallacieux. Le coût est limité et gérable. Un faux négatif — une véritable technique ATT&CK non remontée par le classifieur — peut signifier qu'un TTP d'acteur de menace passe inaperçu jusqu'à ce qu'un incident se produise. Calibrer les seuils de confiance pour accepter des taux de faux positifs plus élevés en échange de taux de faux négatifs plus faibles est le point d'opération correct pour les scénarios de surveillance à enjeux élevés.

Intégration opérationnelle : conception en temps réel, par lots et avec analyste dans la boucle

Les pipelines de classification CTI opèrent en deux modes avec des exigences différentes de latence et de débit. La classification en temps réel est requise lorsque la source est un flux en direct — surveillance de canaux Telegram, abonnements à des flux de menaces en direct, télémétrie réseau active. Le pipeline doit classifier chaque document à son arrivée, avec une latence de bout en bout mesurée en secondes plutôt qu'en minutes. Cela contraint la sélection du modèle : l'étape de classification par encodeur doit s'exécuter en moins de 500 millisecondes ; l'étape d'enrichissement génératif doit en moyenne être inférieure à 15 secondes par document. Le traitement asynchrone avec une file de messages entre les étapes empêche la contre-pression de l'étape générative de bloquer l'ingestion.

La classification par lots est appropriée pour l'analyse de corpus historiques — reclassification d'une base de données IOC existante par rapport à une nouvelle version ATT&CK, enrichissement d'une instance MISP héritée avec des champs structurés, ou traitement d'un export en bloc d'une plateforme commerciale de renseignement sur les menaces. Le mode par lots peut utiliser des modèles plus grands et plus précis puisque les contraintes de latence sont assouplies, et peut s'exécuter de nuit sans impacter la capacité du pipeline en temps réel.

La conception avec analyste dans la boucle n'est pas optionnelle pour les systèmes de classification CTI en production. Les classifieurs LLM commettent des erreurs systématiques sur les cas limites, les nouveaux patterns de langage des acteurs de menace, et le contenu délibérément obscurci. Sans mécanisme de correction, ces erreurs s'accumulent dans le graphe en aval et dégradent la qualité des produits de renseignement au fil du temps. La file d'attente des analystes — enregistrements acheminés pour révision humaine en fonction des seuils de confiance — doit inclure une interface de correction en ligne qui capture les modifications au niveau des champs comme données d'entraînement étiquetées. Les corrections doivent alimenter une boucle de rétroaction d'affinage qui s'exécute selon un calendrier régulier, améliorant continuellement la calibration du modèle sur le paysage de menaces spécifique surveillé.

La configuration du seuil de confiance est le principal contrôle opérationnel. Pour les secteurs à haute sévérité (infrastructure critique, défense), des seuils plus bas (0,60–0,70) maximisent le rappel au prix d'un volume plus élevé dans la file d'attente des analystes. Pour une surveillance large où l'objectif principal est l'analyse de tendances plutôt que l'alerte sur des événements individuels, des seuils de 0,78–0,85 réduisent le volume de la file d'attente à un niveau gérable. Les seuils doivent être calibrés séparément par champ — les profils de précision de la confiance en géographie et en technique diffèrent sur l'ensemble d'évaluation du modèle — et revus trimestriellement par rapport aux taux de correction des analystes pour détecter les dérives de distribution.

Pour un regard plus approfondi sur la façon dont les plateformes CTI intègrent des données de menace structurées dans des environnements multi-sources, consultez notre guide sur l'architecture des plateformes CTI de qualité défense.

Intégration de la classification LLM avec les pipelines de surveillance OSINT

La classification LLM ne fonctionne pas de manière isolée. Dans un programme CTI mature, c'est une étape dans un pipeline plus large qui commence par la surveillance des sources et se termine par des produits de renseignement prêts pour les analystes et des alertes intégrées au SIEM. Les points d'intégration qui nécessitent une attention particulière en matière d'ingénierie sont les transferts entre étapes.

La surveillance des sources OSINT — DNS passif, analyse des journaux de transparence des certificats, indexation des forums du dark web, et surveillance des canaux de plateformes de messagerie ouvertes — génère le flux de documents bruts qui alimente le pipeline de classification. Chaque type de source introduit des problèmes de qualité de données différents. Les données DNS passives sont structurées mais à volume élevé avec de nombreux enregistrements bénins. Le contenu des forums du dark web est non structuré, multilingue et nécessite une désambiguïsation des entités pour séparer les véritables acteurs de menace des usurpateurs. Les canaux de plateformes de messagerie ouvertes mélangent des annonces d'attaques à fort signal avec du bruit, de la propagande et de la désinformation à un ratio qui varie significativement selon le canal.

L'étape de porte binaire du pipeline de classification est le principal mécanisme pour gérer le bruit des sources. Un modèle de porte affiné sur des exemples étiquetés de chaque type de source surpassera significativement un classifieur de pertinence générique. Investir dans des modèles de porte par source est l'investissement d'ajustement le plus rentable disponible dans un pipeline de classification CTI car il réduit directement le coût d'inférence LLM qui domine les dépenses opérationnelles par jour.

L'intégration SIEM à l'extrémité de sortie du pipeline nécessite un mappage de schéma soigné. La plupart des SIEM d'entreprise ingèrent du CEF (Common Event Format) ou du JSON structuré via syslog ou un webhook REST. Les bundles STIX 2.1 ne sont pas nativement ingérés par la plupart des SIEM sans couche de traduction. L'approche pratique consiste à maintenir deux flux de sortie depuis le pipeline de classification : un flux de bundles STIX pour l'ingestion dans les plateformes CTI et le partage inter-organisations, et un flux d'alertes natif SIEM qui mappe les champs les plus pertinents opérationnellement (identifiant de technique, acteur, sévérité, organisation affectée) au schéma SIEM. Les règles de corrélation dans le SIEM doivent référencer les identifiants de techniques ATT&CK comme clé de jointure entre les alertes dérivées du CTI et les événements de télémétrie endpoint/réseau.

La maturité opérationnelle de la surveillance des menaces basée sur l'OSINT dans les organisations de défense a considérablement augmenté au cours des trois dernières années, portée en grande partie par l'accessibilité pratique du traitement de texte basé sur LLM. Ce qui nécessitait une équipe d'analystes et une charge importante de maintenance des règles il y a deux ans peut maintenant être traité avec un pipeline de classification bien conçu fonctionnant sur une infrastructure modeste.