Les 10 idées reçues sur la Cyber Threat Intelligence

La Cyber Threat Intelligence (CTI) n'est plus une discipline de niche. Elle fait désormais partie de la façon dont de nombreuses équipes de sécurité priorisent leur travail, expliquent les risques et décident de la marche à suivre.
Cette évolution est visible à travers la stratégie, l'outillage et la réglementation. Dans l'UE, par exemple, NIS2 renforce la gestion des risques et encourage le partage d'informations pour les organisations concernées, y compris les indicateurs de compromission (IOCs) et autres informations liées aux menaces.

La CTI existe également depuis suffisamment longtemps pour avoir acquis de l'expérience, produit quelques livres et accumulé un corpus respectable de mauvaises idées. La communauté les dénonce depuis des années, depuis les Fallacies and Fault Lines de Jeff Bardin jusqu'aux discussions du SANS FOR578 sur les biais cognitifs, en passant par de nombreuses compilations solides sur les « idées reçues » et des listes de lecture. Nous nous appuyons sur ces travaux, avec reconnaissance.
Le problème, c'est qu'à mesure que la CTI devient plus visible, davantage d'idées « presque vraies » se propagent avec elle. Certaines sont des raccourcis inoffensifs. D'autres poussent discrètement les équipes vers les mauvaises métriques, les mauvais workflows et les mauvaises attentes.

Cet article est un diagnostic bienveillant, pas un sermon. Voici dix idées reçues sur la CTI que nous observons encore en 2026, et ce qu'il faut faire à la place. Il y a fort à parier que vous en reconnaissiez quelques-unes. C'est le cas de la plupart des équipes.

TL;DR

• La CTI n'est pas un flux. C'est un support décisionnel, ancré dans le contexte et les exigences.
• Plus de données signifie rarement plus de clarté. Filtrez selon vos Priority Intelligence Requirements (PIRs), pas selon vos limites d'ingestion.
• L'attribution est un outil, pas l'objectif. Optimisez pour les actions que vous pouvez entreprendre : détection, durcissement et priorisation.
• Le partage est possible avec des contrôles. Les groupes de confiance, TLP et la segmentation vous permettent de collaborer sans perdre la gouvernance.
• La maturité se mesure aux décisions modifiées. Si l'intelligence ne fait pas évoluer un workflow, ce n'est que de l'information.

1. « La threat intelligence, c'est un flux. »

C'est le péché originel, et il se cache dans chaque document d'approvisionnement qui demande « un flux d'intel » comme on commanderait du bœuf haché chez le boucher.

Un flux est un stream d'indicateurs. L'intelligence, c'est ce qui se produit quand un humain (ou, de plus en plus, un modèle bien supervisé) corrèle ces indicateurs avec la réalité de votre organisation et produit un jugement sur lequel quelqu'un peut agir. Un flux météo vous dit qu'il fait 14°C à Berlin. L'intelligence vous dit de prendre une veste parce que vous êtes frileux et que vous en avez oublié une hier.

Si votre « programme CTI » se résume à une règle SIEM et une facture trimestrielle, vous avez un abonnement, pas un programme. STIX 2.1 existe pour que les observables, indicateurs, campagnes, acteurs de menace et les relations entre eux puissent circuler ensemble avec le contexte inclus. Utilisez le format comme il a été conçu.

2. « Plus de données, c'est mieux. »

La manière la plus coûteuse de se tromper est de se tromper à grande échelle.

Empiler quinze flux les uns sur les autres ne produit pas quinze fois plus d'insights. Cela produit quinze fois plus de problèmes de déduplication et un score de confiance qui se moyenne discrètement en bouillie. Nous avons vu des plateformes ingérer des millions d'indicateurs par semaine et révéler, à la fin du trimestre, les trois mêmes IP qu'un analyste aurait pu trouver en lisant un seul blog de fournisseur autour d'un café.

La bonne question n'est pas combien, mais à quel point c'est pertinent. Les Priority Intelligence Requirements (PIRs) existent précisément pour cette raison. Ce sont le filtre par lequel tout le reste devrait passer. Si votre plateforme ne peut pas relier un indicateur à un PIR, un secteur ou un intrusion set suivi en quelques clics, les données ne travaillent pas pour vous. C'est vous qui travaillez pour elles.

3. « L'attribution est l'objectif. »

L'attribution est séduisante. Elle vient avec des noms sympas (FIN13, UNC5221, APT10), des cartes animées et la montée de dopamine du « on les a attrapés ». Elle est aussi, pour l'écrasante majorité des défenseurs, une distraction.

Savoir que l'acteur est APT10 est intéressant. Savoir quelles techniques MITRE ATT&CK APT10 privilégie contre votre secteur, lesquelles de ces techniques vos détections manquent, et lesquels de vos fournisseurs figurent dans leur victimologie historique est utile. Le premier est de la culture générale. Le second est un plan de sprint pour mardi matin.

L'Attribution avec un grand A, la preuve au-delà de tout doute raisonnable, celle qui finit dans des actes d'accusation, est rarement votre travail. L'attribution avec un petit a, la prépondérance de preuves suffisante pour regrouper l'activité et orienter les décisions, l'est presque toujours. Confondre les deux mène à la paralysie ou à l'hubris, et souvent aux deux.

4. « Si nous partageons, nous serons punis. »

L'idée reçue sur le partage d'informations se décline en deux variantes. La première : partager nous expose légalement ou commercialement. La seconde, plus rarement admise : notre intel n'est pas assez bonne pour être partagée.

Les deux sont largement fausses, et les deux sont corrosives. L'acteur de menace qui cible votre banque est le même acteur de menace qui cible la banque d'en face. Traiter les détections comme un avantage concurrentiel est à peu près aussi efficace que garder votre parapluie secret pendant un orage.

Les ISAC, les communautés MISP, les groupes de partage sectoriels et les échanges entre groupes de confiance existent pour que le coût de la découverte d'une organisation devienne le bénéfice de plusieurs, avec les marquages TLP appropriés, les expurgations et les contrôles d'accès. La ségrégation organisationnelle et la gestion TLP d'OpenCTI existent précisément pour cette raison. Tout comme celles de MISP. Ce sont des outils complémentaires, pas des concurrents, et prétendre le contraire est sa propre petite idée reçue.

5. « Notre SOC saura quoi en faire. »

Une threat intelligence remise à un analyste SOC à 3 heures du matin sans contexte opérationnel est, généreusement, un post-it du futur. Les SOC sont optimisés pour la réponse, pas pour l'interprétation. Si l'équipe d'intelligence produit un solide rapport stratégique sur un affilié ransomware émergent, et que la seule interaction du SOC avec celui-ci est une page d'IOC dans un CSV, la valeur au-delà de la couche IOC a été discrètement jetée.

La solution n'est pas de « former davantage le SOC ». La solution est de livrer l'intelligence sous la forme dont chaque consommateur a besoin : IOC tactiques et logique de détection pour le SOC, lacunes de couverture TTP pour l'ingénierie de détection, victimologie et analyse de tendances pour le CISO, et briefings avec graphiques, dans la langue que le public parle, pour le conseil d'administration.

Une plateforme, plusieurs perspectives. Si votre plateforme CTI ne peut pas produire tout cela à partir du même graphe de connaissances sous-jacent, ce n'est pas une plateforme CTI. C'est une base de données avec des opinions.

6. « L'intelligence stratégique, c'est du remplissage pour les dirigeants. »

Celle-ci vient généralement des analystes, et on les comprend. La plupart de « l'intelligence stratégique » dans la nature est un jeu de diapositives de photos d'archives et le mot géopolitique utilisé comme un verbe.

Mais une véritable CTI stratégique, celle qui cartographie la motivation des adversaires, les tendances de ciblage sectoriel, les évolutions réglementaires et l'exposition de la chaîne d'approvisionnement, est la couche qui détermine si votre budget de sécurité existera encore l'année prochaine. Les conseils d'administration n'approuvent pas les règles de détection. Ils approuvent les narratifs.

Une organisation qui ne produit que de l'intelligence tactique est à un CFO près de se faire dire d'« utiliser les flux gratuits, ils se ressemblent tous pour moi ». Et honnêtement, au niveau IOC, c'est souvent le cas.

7. « La couverture MITRE ATT&CK équivaut à la sécurité. »

La heatmap est une chose merveilleuse. C'est aussi, de plus en plus, un village Potemkine.

Marquer une technique comme « couverte » parce que quelque détection existe pour quelque sous-technique dans certaines conditions est une erreur de catégorie portant une veste haute visibilité. T1059 (Command and Scripting Interpreter) n'est pas « couvert » parce que vous alertez sur powershell.exe -enc. C'est une petite tranche de la technique et presque rien de ce qu'un adversaire compétent fait en 2026.

ATT&CK est un langage pour décrire le comportement des adversaires, pas une checklist pour s'en défendre. Utilisez le framework pour communiquer, regrouper et raisonner honnêtement sur les lacunes de couverture. Ensuite, associez-le à une validation adversariale. C'est à cela que servent des outils comme OpenAEV, et plus largement la catégorie Breach and Attack Simulation. La carte n'est pas le territoire. La heatmap n'est surtout pas le territoire.

8. « L'IA fera l'analyse pour nous. »

Une idée reçue véritablement moderne, et celle que nous avons un intérêt particulier à bien comprendre.

Les grands modèles de langage sont remarquables pour la synthèse, la traduction, l'extraction structurée et la mise en évidence de patterns à travers un corpus bien plus vaste que ce qu'un analyste pourrait lire. Ils sont aussi avec assurance, éloquence, et parfois de manière catastrophique, faux. Ils n'ont aucune idée de ce qu'ils sont en train d'être aujourd'hui.

Un LLM qui hallucine le profil de ciblage d'un groupe APT dans un briefing au conseil d'administration est pire que pas de briefing du tout, parce que l'hallucination porte le même uniforme que la vérité.

Le cadrage honnête est que l'IA change le levier de l'analyste, pas le travail de l'analyste. Utilisez-la pour importer des flux, rédiger des brouillons de rapports, générer des synthèses de première passe et suggérer des pivots dans un graphe de connaissances. Ne l'utilisez pas pour remplacer le jugement humain qui transforme l'information en intelligence. L'analyste CTI de 2026 est un pilote avec de bien meilleurs instruments, pas un passager en pilotage automatique.

9. « La plateforme est juste un endroit pour stocker des IOC. »

Étroitement liée à l'idée reçue n°1, mais suffisamment distincte pour mériter son propre emplacement. C'est l'idée reçue qui transforme une plateforme de Threat Intelligence en un tableur très cher avec un logo.

Une TIP moderne est un graphe. L'intérêt est qu'un indicateur se connecte à une famille de malware, qui se connecte à un intrusion set, qui se connecte à une campagne, qui se connecte à un secteur de victimes, qui se reconnecte à votre organisation. Pivotez à travers ces arêtes et vous trouverez les questions que vous ne saviez pas poser.

Traitez la plateforme comme une liste d'IOC et vous obtenez, au mieux, une liste de blocage de pare-feu légèrement meilleure. Au pire, vous obtenez un cimetière de contexte pour lequel quelqu'un aux finances paie de l'argent réel.

Si vos analystes ne peuvent pas, en deux clics, passer de « ce hash » à « c'est la troisième campagne en six mois par un acteur qui cible les fabricants européens de taille moyenne », votre investissement n'atterrit pas là où il devrait.

10. « Nous sommes matures parce que nous avons une équipe CTI. »

L'idée reçue sur la maturité est le boss final. Elle arrive enveloppée dans des organigrammes, des effectifs et des lignes budgétaires, et elle est presque toujours fausse.

La maturité n'est pas l'existence d'une fonction. La maturité est le resserrement démontrable de la boucle entre l'intelligence produite et les décisions modifiées. Une équipe de deux personnes avec des PIR clairs, une priorisation impitoyable, des retours réguliers des parties prenantes et la discipline de retirer les rapports que personne ne lit est plus mature qu'une équipe de quinze personnes produisant quarante PDF par trimestre dont personne ne peut prouver que quelqu'un a agi en conséquence.

Le test est inconfortable mais simple : au cours des 90 derniers jours, nommez trois décisions opérationnelles, de détection ou stratégiques qui ont changé à cause de quelque chose que votre équipe CTI a produit. Si la liste est courte, l'équipe n'est pas le problème. C'est la boucle de rétroaction.

Alors, que faire concrètement de tout cela ?

Si vous avez lu les dix et vous êtes senti légèrement attaqué, vous êtes en bonne compagnie. La plupart des programmes CTI, y compris les programmes construits par des personnes qui travaillent maintenant chez Filigran, ont été coupables d'au moins quatre d'entre eux à un moment donné. L'objectif n'est pas de se sentir mal. C'est de remarquer lesquels vous coûtent discrètement, puis de les éliminer par conception.

Quelques points d'ancrage pratiques :

• Partez des exigences, pas des flux. Les PIR d'abord. Tout le reste suit.
• Investissez dans le graphe, pas dans la liste. Les indicateurs sans relations sont du bruit avec des horodatages.
• Adaptez les outputs aux consommateurs. SOC, ingénierie de détection, CISO, conseil d'administration : quatre publics, quatre formats, une seule source de vérité.
• Validez, ne supposez pas. Les revendications de couverture ATT&CK survivent à la simulation adversariale ou pas.
• Mesurez les décisions modifiées, pas les rapports rédigés. C'est la métrique qui compte.

OpenCTI a été construit autour de cette vision du monde : la threat intelligence est connectée, structurée et contextuelle, et la plateforme devrait rendre la bonne chose facile et la mauvaise chose visible. Nous sommes biaisés, évidemment. Nous pensons aussi que ce modèle tient la route dans le monde réel.

Si l'une de ces idées reçues vous a semblé inconfortablement familière, nous serions sincèrement ravis de discuter pour vous aider à arrêter d'acheter celles dont vous n'avez pas besoin.

Bonne lecture, et n'hésitez pas à poser des questions sur notre canal communautaire Slack : https://community.filigran.io/

Merci à la communauté CTI au sens large dont les écrits antérieurs sur ce sujet ont informé et affiné cette liste, notamment Bardin, Lee, Piazza, Nickels, Richard et bien d'autres. Toutes les idées reçues restantes sont entièrement les nôtres.