Dans cet épisode spécial enregistré en marge de la conférence NorthSec, Christian Paquin, cryptographe chez Microsoft Research et ancien étudiant de Gilles Brassard à l’Université de Montréal, présente ses travaux sur la provenance des actifs numériques et sur une approche permettant de concilier authenticité du contenu et protection de l’identité de son créateur.

Avec la prolifération de l’intelligence artificielle générative, il devient de plus en plus difficile de distinguer le contenu authentique du contenu fabriqué. Pour répondre à ce défi, l’industrie s’est rassemblée autour de la C2PA (Coalition for Content Provenance and Authenticity), un protocole qui permet de signer numériquement images, vidéos, fichiers audio et même textes afin d’en tracer l’origine et toutes les transformations subies.

Le principe repose sur la cryptographie à clé publique, la même que celle utilisée pour sécuriser le web (HTTPS). Une caméra signe une photo avec une clé privée intégrée à l’appareil ; chaque transformation ultérieure (retouche, redimensionnement, republication sur un réseau social) invalide la signature précédente et nécessite une nouvelle signature de la part de l’éditeur responsable. On obtient ainsi un historique complet, dit « écran à écran », de la création jusqu’à la consommation du contenu. Si seule la dernière signature est généralement vérifiée, l’historique des transformations antérieures peut être conservé, soit en clair, soit de façon compressée grâce à des preuves à divulgation nulle de connaissance (zero-knowledge proofs).

Cette norme est déjà largement adoptée : OpenAI signe ses images générées, Sony intègre la fonctionnalité dans certains appareils photo, Google l’offre sur ses téléphones Pixel, et Adobe ainsi que Microsoft l’intègrent à leurs outils.

Le problème, souligne Christian Paquin, est que cette forte authentification crée un lien direct entre le contenu et l’identité de son auteur. Or, dans plusieurs contextes, cette traçabilité pose un risque réel : journalistes couvrant des zones de conflit qui pourraient être identifiés et visés par un régime hostile, lanceurs d’alerte révélant des pratiques répréhensibles, ou artistes souhaitant publier anonymement tout en prouvant que leur œuvre leur appartient bel et bien. Dans ces cas, on souhaite prouver qu’un contenu provient d’une source légitime (par exemple, un journaliste affilié à une organisation reconnue) sans révéler de quel individu précis il s’agit.

Deux approches rudimentaires existent déjà dans l’écosystème C2PA. La première consiste à utiliser un certificat auto-émis, à la manière de PGP : on publie sa propre clé publique pour que d’autres puissent vérifier le contenu, mais cela ne permet pas à un tiers de valider une affiliation institutionnelle (par exemple, confirmer qu’une personne travaille bien pour telle agence de presse). La seconde consiste à utiliser des certificats à très courte durée de vie, voire à usage unique, comme le fait Google sur ses téléphones Pixel, qui émet un nouveau certificat pour chaque photo prise. Cette méthode empêche les plateformes de lier différentes publications à un même utilisateur, mais exige de faire confiance à l’émetteur (ici Google) pour ne pas conserver de journal reliant les certificats entre eux.

Pour résoudre ce dilemme sans dépendre de la confiance envers un tiers, Christian Paquin a développé un prototype open source combinant deux techniques. La première remplace les signatures classiques (RSA, ECDSA) par des signatures dites « randomisables », notamment l’algorithme BBS, actuellement en voie de standardisation à l’IETF. Ces signatures permettent de prouver qu’un certificat appartient bien à une hiérarchie de confiance donnée (par exemple, celle de Google ou de Radio-Canada) sans révéler les éléments uniques qui permettraient de relier plusieurs signatures à une même personne.

La deuxième technique utilise des preuves à divulgation nulle de connaissance. Plutôt que d’inclure le certificat directement dans le fichier signé, on y insère une preuve démontrant que la signature a été générée correctement, que le certificat utilisé a bien été émis par une autorité reconnue, et qu’il était valide au moment de la signature, tout cela sans révéler la valeur exacte du certificat (qui pourrait servir d’identifiant indirect, par exemple via sa date d’expiration unique).

Ces techniques, longtemps trop lourdes pour un usage pratique, sont devenues envisageables grâce aux avancées en efficacité des protocoles de preuves à divulgation nulle, largement stimulées par les investissements massifs dans l’écosystème des cryptomonnaies et des contrats intelligents (notamment Ethereum).

Christian Paquin compare ce chantier à la transition historique vers HTTPS, qui a pris plus d’une décennie et continue de poser des défis d’interface et de gestion de la confiance. Le déploiement de la provenance des contenus sera toutefois plus complexe encore : il touchera un nombre d’acteurs bien plus large (médias, fabricants d’appareils, éditeurs de logiciels, industries du cinéma et de la publicité, secteurs médical et militaire) et un volume de données incomparablement plus élevé, chaque photo prise pouvant nécessiter son propre certificat.

Malgré ces défis, l’urgence est réelle : selon Christian Paquin, sans déploiement substantiel de ces mécanismes dans les deux prochaines années, l’érosion de la confiance envers le contenu numérique, déjà bien engagée dans la sphère politique, pourrait devenir difficile à renverser. À terme, le contenu dépourvu de marque d’authenticité pourrait être désavantagé par les algorithmes des plateformes, un peu comme les sites non sécurisés en HTTPS ont fini par être pénalisés par les moteurs de recherche.

L’épisode se conclut sur une note encourageante : cette participation demeure volontaire, et les techniques discutées permettent d’envisager un avenir où authenticité et anonymat ne sont plus mutuellement exclusifs.

L’épisode s’ouvre sur une idée centrale et provocatrice : traiter le cerveau humain comme une infrastructure critique de cybersécurité. Mélissa Canseliet, conférencière spécialisée dans le facteur humain, propose d’appliquer au cerveau les mêmes approches que celles utilisées pour les systèmes techniques — cartographie, mesure, gestion des risques. Son constat de départ est simple mais dérangeant : on parle abondamment d’intelligence artificielle sans jamais se demander ce qu’est l’intelligence humaine. Si personne n’est capable de définir ce qu’on cherche à protéger ou à augmenter, comment espérer construire une défense cohérente ?

Depuis plus d’une décennie, le facteur humain représente le vecteur d’attaque dominant en cybersécurité. Mélissa souligne que cette réalité n’a pas été suffisamment prise au sérieux, et que l’IA générative l’aggrave considérablement. Les deepfakes, la manipulation émotionnelle, les campagnes de désinformation ciblée : autant d’armes qui ne s’attaquent pas aux systèmes, mais directement au cerveau. L’IA n’est donc pas seulement un outil technologique entre les mains des attaquants — c’est une arme neurologique. Face à cela, les stratégies de défense actuelles restent largement insuffisantes, car elles protègent les données sans renforcer les humains qui les manipulent.

Pour structurer sa pensée, Mélissa recourt à une analogie éclairante : l’industrialisation a augmenté la force musculaire de l’être humain, tandis que l’ère numérique cherche à augmenter sa capacité cognitive. Or, nos systèmes éducatifs sont restés figés à l’époque industrielle. On n’a jamais mis en place d’équivalent pédagogique à la révolution numérique. Résultat : face à des outils qui sollicitent et manipulent le cerveau de façon de plus en plus sophistiquée, les individus n’ont reçu aucune formation adaptée. Comme on a dû inventer le sport synthétique une fois que le travail physique a disparu du quotidien, on devra inventer des pratiques pour entraîner le cerveau à l’ère de l’IA.

L’un des passages les plus marquants de l’échange porte sur ce que Mélissa appelle l’« économie de la relation ». L’IA, par son aspect fluide et non-contraignant, s’est insérée dans nos vies sans friction. Elle nous conforte, nous flatte, nous évite l’effort de la contradiction. Ce faisant, elle érode progressivement les interactions humaines réelles — celles qui permettent de se remettre en question, de confronter ses idées, de grandir collectivement. Les deux interlocuteurs s’accordent : la psyché humaine se développe au contact de l’autre, de la frustration, de l’imprévisible. En se substituant à ces interactions, l’IA crée une forme de régression cognitive et affective. On devient plus vulnérables, moins capables d’esprit critique, plus facilement manipulables.

Une part importante de la conversation tourne autour du rapport à l’inconfort. Mélissa défend une idée contre-intuitive mais biologiquement étayée : le confort permanent appauvrit. Le cerveau humain, comme le corps, a besoin de stimuli variés, d’efforts, de frustrations intermittentes pour fonctionner à son plein potentiel. Elle cite notamment le BDNF (brain-derived neurotrophic factor), une molécule produite lors de l’activité physique qui favorise la croissance des neurones — un rappel que le cerveau et le corps sont indissociables. Trop de confort, à l’inverse, abaisse le seuil de satisfaction, érode la capacité d’appréciation et finit par diminuer la qualité de vie. Cette logique vaut aussi dans les organisations : blâmer l’erreur plutôt que de l’accueillir comme un apprentissage est une stratégie perdante, particulièrement en cybersécurité.

En conclusion, Mélissa refuse le fatalisme. L’avenir dépendra des choix opérés maintenant — individuellement et collectivement. Elle appelle à sortir des incantations et des buzzwords pour passer à des actions mesurables : entraîner concrètement le cerveau, valoriser le partage d’expériences au sein des équipes, construire la résilience sur des bases tangibles. Le cerveau humain n’est pas une variable molle à mentionner dans les politiques de sécurité — c’est une infrastructure à gérer avec autant de rigueur qu’un pare-feu. La bonne nouvelle, selon elle : les leviers sont entre nos mains. La moins bonne : on ne peut plus se permettre d’attendre.

Un épisode dense, ancré à la croisée des neurosciences, de la cybersécurité et de la philosophie de l’effort — une invitation à reprendre en main notre intelligence avant de la déléguer.

Dans cet épisode, l’animateur réunit son trio composé de Cyndie Feltz, Nicholas Milot et Dominique Derrier pour discuter de Mythos, un sujet qui fait beaucoup les manchettes. D’entrée de jeu, l’équipe précise que l’important n’est pas tant Mythos en soi — entouré de beaucoup de bruit et de marketing — que la prise de conscience qu’il provoque : les modèles d’IA, qu’ils soient spectaculaires comme Mythos ou plus sobres comme Opus, marquent un changement de paradigme dans la découverte de vulnérabilités et dans la façon dont les attaquants opèrent. L’enjeu central pour les PME est simple : il deviendra encore plus facile de s’attaquer aux systèmes, alors que c’était déjà facile.

Pour ceux qui auraient « vécu sous une roche » ces dernières semaines, l’équipe explique le concept. Nous sommes à l’ère de l’IA et des LLM (large language models), capables de générer des images, de communiquer, de faire du « vibe coding ». Des chercheurs ont eu l’idée d’utiliser ces modèles pour découvrir des vulnérabilités dans les applications. En poussant le modèle, on obtient une puissance démultipliée — quoique coûteuse en tokens — capable d’analyser du code, de tester et de trouver les failles permettant de pénétrer les systèmes.

Mythos est un modèle hautement spécialisé qui n’est pas encore réellement accessible au public; seules de grosses organisations et certains gouvernements peuvent y accéder. L’équipe évoque le fait qu’Anthropic l’utiliserait elle-même pour tester de grands projets open source, et mentionne un projet (« Glass Wind » ou similaire) regroupant de gros joueurs comme CrowdStrike, Amazon et Apple, qui utiliseraient Mythos pour sécuriser les systèmes. Un participant souligne avec ironie l’angle marketing : si l’outil était vraiment si dangereux, Anthropic n’en aurait simplement pas parlé et l’aurait gardé à l’interne.

Les intervenants insistent : il s’agit avant tout d’un excellent outil d’analyse de code permettant de corriger des vulnérabilités. C’est précisément le travail quotidien de Nicholas et Cyndie. L’avantage d’une machine, c’est qu’elle ne dort pas la nuit ni les fins de semaine — elle fonctionne 24/7, sans relâche. L’exploit le plus médiatisé a été la découverte de vulnérabilités dans le navigateur Firefox, des failles qu’un humain n’aurait peut-être pas trouvées dans un temps ou avec une logique humaine.

Un point technique crucial est soulevé : Mythos n’est pas un outil « point and shoot ». Il ne suffit pas de pointer une URL pour faire pirater une application. Il faut fournir le code source de l’application. C’est une nuance importante, d’autant que bien des organisations — voire des gouvernements — ne savent même pas où se trouve leur propre code source.

L’équipe reste honnête : en mai 2026, leur propre métier de recherche de failles repose déjà sur l’IA, tout en conservant un volet manuel. Ils perfectionnent leurs propres outils. Et les acteurs malveillants, moins scrupuleux, font exactement la même chose. C’est là le vrai message : l’IA va faciliter et accélérer les attaques.

L’aspect positif demeure : connaître ces vulnérabilités permet de les corriger et de produire du code plus sécuritaire. La fondation Mozilla profite ainsi du travail effectué, et personne ne peut s’opposer à du code plus solide — surtout pour un navigateur, qui constitue notre principale porte d’entrée vers Internet.

Preuve que l’IA ne remplace pas tout : Anthropic a justement lancé un programme de bug bounty cette semaine. À la question « pourquoi ne pas simplement utiliser Mythos? », la réponse est que le modèle n’est pas encore capable de trouver tous les bugs qu’un humain détecterait, et vice versa. L’humain et l’IA ne perçoivent pas le code ni l’application de la même manière.

Faut-il paniquer? Non, mais il faut accélérer. Le mantra d’hygiène de base en cybersécurité reste valable, mais doit devenir plus strict. Il faut accélérer les déploiements et l’application des correctifs. D’autres modèles arriveront, possiblement bon marché (un « DeepSeek » de la vulnérabilité), donc la pression de correction touchera toutes les entreprises. Les notions d’inventaire, de mise à jour et d’application des correctifs deviennent incontournables : on ne pourra plus dire « on sait qu’on a des portes ouvertes et on vivra avec ça. »

Les intervenants notent toutefois avec lucidité que beaucoup de clients peinaient déjà à maintenir un inventaire à jour et à gérer leur programme de vulnérabilités, avec des outils comme Tenable. S’exciter pour Mythos sans d’abord régler ces bases serait contre-productif. Il faut prendre le dessus sur ses vulnérabilités actuelles et tenir un inventaire d’actifs à jour avant même de songer à utiliser ce type d’outil. Cette hygiène n’est plus optionnelle : sans elle, impossible de sortir la tête de l’eau. Et dès qu’une vulnérabilité reçoit un nom médiatisé — comme Heartbleed ou Dirty COW —, on ne peut plus l’ignorer : sinon, c’est le patron ou les clients qui exigeront une action.

L’animateur propose une analogie : avant, les voleurs d’autos étaient peu nombreux dans un quartier tranquille. Aujourd’hui, votre voiture se trouve dans un quartier chaud où de nombreux voleurs potentiels circulent. Vous n’êtes pas mieux protégé, mais votre risque augmente fortement. La priorité n’est plus de craindre les outils sophistiqués, mais de commencer par verrouiller ses portes. L’équipe conclut que, là où l’on connaissait peut-être un incident par année, on risque désormais un incident par mois sans une hygiène suffisante. Le message final : verrouillez vos portes, car vous n’avez plus le choix.

Dans cet épisode spécial enregistré au Northsec, Philippe Pépos Petitclerc se présente comme chercheur académique en voie de terminer son doctorat, avec un parcours en pentest et une grande passion pour les CTF (Capture The Flag). L’entretien porte sur sa recherche en techniques d’évasion d’antivirus, présentée lors de l’événement.

Philippe insiste d’abord sur deux éléments de cadrage. Premièrement, la modernité : on ne parle plus vraiment d’antivirus mais d’EDR (Endpoint Detection and Response). Selon lui, l’antivirus a été fusionné dans le concept d’EDR, qui correspond à un antivirus auquel s’ajoutent des capacités de télémétrie, de visibilité et de réponse pour les équipes de défense (Blue Team). Deuxièmement, pour rendre la recherche constructive comme première étude dans ce domaine, il a mis de côté les modèles statistiques pour se concentrer d’abord sur les moteurs déterministes, c’est-à-dire ceux dont le résultat est certain (par exemple, chercher un hash précis dans un fichier).

Pour généraliser son approche, Philippe travaille avec un « AV générique » plutôt qu’un produit en particulier, l’objectif étant de bâtir un plan d’évasion applicable à n’importe quel antivirus rencontré. Il introduit une distinction centrale : la capacité de détection, qu’il décompose en « une analyse plus une raison ou une façon de regarder ». Il compare cela aux signatures : la signature, c’est ce qu’on cherche (par exemple le hash lui-même), tandis que la capacité, c’est comment et où on le cherche. Hacher un fichier et comparer le résultat constitue une capacité ; le hash recherché est la signature.

Pour cartographier ces capacités, Philippe a combiné deux sources. D’une part, la littérature scientifique sur les techniques de détection, abondante, bien qu’on ignore lesquelles ont réellement été adoptées dans les produits commerciaux (beaucoup relèvent du secret industriel, difficile à citer en recherche académique). D’autre part, l’observation des techniques d’évasion utilisées « in the wild », même non documentées sérieusement, car leur popularité révèle indirectement quelles détections fonctionnent vraiment. Il a ensuite classifié ces capacités selon les mêmes principes que l’analyse de programme classique, produisant une arborescence où chaque technique s’inscrit dans des classes successives, ce qui permet de « couper des branches » pour identifier précisément la méthode en jeu — une démarche qu’il rapproche de la philosophie d’ATT&CK.

La cartographie se divise en deux grandes catégories. Les analyses statiques examinent un fichier sur disque sans l’exécuter : hashes, recherche de séquences d’octets (avec ou sans « trous »), reconstruction d’information sémantique comme un graphe de flot de contrôle (CFG), ou simple analyse de chaînes de caractères. Ces analyses « cheap » sont fréquentes mais faciles à évader, car l’apparence d’un fichier se modifie aisément. Les analyses dynamiques se subdivisent entre le virtuel (sandbox, émulation, dans un faux système) et le concret (sur le vrai système). On y trouve le traçage d’appels de fonction, le hooking, et la réapplication de détections statiques à des moments clés — puisque scanner la mémoire est coûteux, l’antivirus utilise des déclencheurs pour choisir quand inspecter. Philippe souligne cet effort d’économie de ressources inhérent à chaque implémentation.

Une contribution importante est le probing (sondage) : on teste un programme, on le modifie légèrement, puis on le reteste pour comparer les détections. Si le programme part non détecté, il peut rester non détecté ou le devenir. S’il part détecté, trois issues sont possibles : devenir non détecté, rester détecté avec le même identifiant, ou être détecté avec un nouvel identifiant. Comme les antivirus retournent des identifiants distincts plutôt qu’un simple verdict binaire, on extrait davantage d’information. En choisissant intelligemment la transformation, on isole la capacité réelle. Par exemple, ajouter un octet inoffensif casse un hash : si la détection reste identique, elle n’était pas basée sur un hash. Pour le dynamique, utiliser un packer (crypter) qui chiffre le payload et le déchiffre à l’exécution permet de révéler la présence d’une sandbox.

Tous les moteurs testés possèdent une sandbox détectable, mais leur usage varie énormément : certains détectent beaucoup via leur sandbox, d’autres presque rien. Philippe note que la capacité marketing (« on a du behavior, du sandboxing ») peut exister tout en ayant une banque de signatures si mince qu’elle ne se déclenche presque jamais. Les philosophies d’implémentation diffèrent : chaque éditeur capitalise sur sa technologie de prédilection. Sa méthode d’évasion consiste à « blinder » chaque capacité détectée : une fois la présence d’un unpacker ou d’une sandbox identifiée, il associe les techniques d’évasion connues qui neutralisent spécifiquement chacune, construisant un ensemble minimal couvrant toutes les capacités trouvées. L’objectif n’est pas une évasion universelle unique, mais un flowchart indiquant quoi faire et quoi éviter — ajouter du code inutile risquant de se faire repérer. Les résultats détaillés figureront dans sa thèse, le protocole étant maintenant stable et prêt à être lancé à grande échelle.

L’équipe montréalaise de Philippe, active depuis une dizaine d’années, monte presque toujours sur le podium au Nordsec et vise une qualification au DEF CON. Leur distinction : une propension à sortir des sentiers battus et à trouver des solutions « weird », parfois des bypass transformant un défi de six heures en trente minutes. Sur l’IA, le Nordsec a levé cette année ses restrictions. L’équipe constate que le harnessing et le prompting ont moins d’impact que de simplement relancer le modèle plusieurs fois : la température et la répétition comptent davantage. Les modèles plus puissants, surchargés d’outils, « se creusent des trous » en polluant leur contexte. L’IA réussit aujourd’hui environ 95 % des défis sauvegardés, ce qui soulève des questions sur le plaisir et l’avenir des CTF — un défi que Philippe fait confiance aux organisateurs du DEF CON pour relever.

Dans cet épisode spécial Cybereco, Cédric Thibault partage un retour d’expérience sur le développement d’une plateforme d’automatisation de workflows de cybersécurité utilisant réellement l’IA générative. Sa motivation : il existe beaucoup de discours sur l’IA, mais peu de retours concrets de bâtisseurs qui ont fait des choix, commis des erreurs et obtenu des succès.

Le constat de départ est partagé par toutes les entreprises qu’il côtoie. Face à la montée réelle des attaques — ce n’est pas qu’un argument marketing — les moyens humains restent très limités. Paradoxalement, ajouter des outils, même justifié, produit souvent l’effet inverse : cela noie davantage les équipes et réduit la capacité humaine en bout de chaîne.

Son objectif est de redonner de la capacité aux clients et de remettre les analystes dans un véritable poste d’analyste. Un analyste devrait faire de l’analyse et exercer son esprit critique, pas exécuter des clics séquencés en suivant un playbook. Beaucoup de processus de sécurité existent d’ailleurs en dehors du SOC. L’exemple récurrent est le triage des courriels signalés comme hameçonnage par les utilisateurs : ces signalements s’accumulent dans une boîte cyber partagée, et les analystes valident les indicateurs, lisent les courriels et jugent leur caractère malicieux. Additionné, cet effort représente des heures, pour une tâche répétitive sans réelle valeur ajoutée — comparable à la roue d’un hamster, puisque le flux de courriels malicieux est infini.

Cédric insiste sur le mot clé du déterminisme. Par nature, un agent IA ne sera jamais pleinement déterministe : on peut maximiser sa fiabilité sans jamais la garantir totalement. Face à la pression marketing qui promet de remplacer des équipes entières par un agent, son retour d’expérience est différent : il faut utiliser l’IA là où elle est réellement utile, et s’appuyer sur des bases solides et déterministes — du procode ou du low-code via des plateformes d’automatisation.

Ces plateformes existent depuis des années, et la cybersécurité connaît bien les SOAR, mais ceux-ci sont restés cantonnés à l’univers du SOC. L’avantage de l’IA est qu’en mêlant les deux technologies — automatisation robuste et agents IA très ponctuels à des endroits clés — on obtient une valeur maximale : interaction intelligente avec les utilisateurs d’un côté, garantie que la prise d’action est exécutée par des scripts de l’autre. Bloquer le port 80 doit signifier exactement le port 80, pas une approximation. Cette fiabilité est indispensable, car aucune équipe cyber n’adoptera des processus qui ne sont pas fiables à 100 %.

Cédric rappelle un constat partagé deux ou trois ans plus tôt par David Gérard : en cybersécurité, la tolérance à la déviation est nulle, et dès qu’un analyste constatait une hallucination, c’était l’abandon systématique de toute la solution. Ces abandons sont dommageables, car la technologie bien employée apporte beaucoup de valeur. Le mode « yolo » n’est pas recommandé : déployer des workflows IA en production exige une démarche très structurée et beaucoup d’ingénierie, un aspect trop peu évoqué face aux vidéos YouTube spectaculaires.

Un conseil fort : ne jamais confier un projet d’ingénierie IA uniquement à des ingénieurs IA. Il faut des spécialistes de domaine. Pour un workflow anti-hameçonnage dans M365, un spécialiste M365 est nécessaire, car les API ne sont pas si simples. Cédric recommande une équipe hybride en binôme : un ingénieur IA qui maîtrise la plateforme d’automatisation et l’invocation optimale du LLM (tokens, coûts, garde-fous), et un spécialiste de contenu qui choisit le meilleur flow et la bonne façon de travailler avec les outils tiers.

Concrètement, dans ce type de workflow, environ 90 % des nodes sont purement déterministes et seulement 10 % relèvent d’agents IA — mais placés au bon endroit, ils servent de « colle » permettant de finaliser le processus de bout en bout. Il déconseille d’utiliser des agents pour prendre des actions en console quand un simple script déterministe fait l’affaire, sans risque ni coût en tokens.

Le niveau d’acceptation du risque varie selon les clients. Certains gardent un human in the loop — une alerte Teams avec un bouton « approve » ou « reject » avant toute action. D’autres, après une preuve de concept concluante, acceptent une automatisation complète, mais toujours avec des actions déterministes qui réduisent le risque sans le supprimer.

Une fois les premiers résultats observés, l’effet est impressionnant : les clients veulent enrichir leurs workflows et améliorer des processus qu’ils n’optimisaient pas faute de temps. L’analyste passe alors en mode amélioration et critique. Mais il faut stabiliser des versions, car l’observabilité et l’évaluation de performance exigent des jeux de tests roulés en permanence pour garantir la stabilité, tout en développant les versions suivantes en parallèle.

L’automatisation génère aussi de nombreux KPI, impossibles à obtenir dans des processus manuels, formant une boucle de rétroaction continue. Comme le reporting des plateformes low-code/no-code est souvent pauvre, son équipe exporte les logs des agents vers les SIEM des clients pour créer des tableaux de bord. Ce qu’on ne peut mesurer, on ne peut le faire évoluer.

Cédric reprend une formule tirée d’un papier de la CSA lié à Mythos : ne pas faire évoluer ses processus de cybersécurité aujourd’hui revient à préparer ses équipes au burnout. Il ne s’agit pas que l’IA fasse tout, mais qu’elle améliore des points critiques pour décharger les analystes face à l’alert fatigue déjà bien présente. Les premiers retours clients sont très positifs. Il anticipe une adoption plus large et précise qu’il n’a pas abordé le sujet des agents personnels, un autre enjeu dont on parlera beaucoup en 2026.

Finalement, ce n’est pas tant concluant la nouvelle façon d’enregistrer. J’aurai d’autres tests à faire si je désire continuer avec cet équipement.

Dans cet épisode, Georges Badro, consultant chez Mandiant à Paris spécialisé dans les infrastructures critiques et les systèmes industriels, explique le fonctionnement et la sécurisation des sous-stations électriques.

Le réseau électrique se décompose en trois zones : la génération (centrales hydrauliques, nucléaires, thermiques, renouvelables), le transport et la distribution. Le réseau de transmission permet de limiter les pertes d’énergie et surtout d’équilibrer production et consommation afin de maintenir une fréquence stable. Contrairement à un réseau d’eau, un réseau électrique exige un équilibre permanent entre ce qui est produit et ce qui est consommé, sous peine de l’endommager.

Les sous-stations sont les nœuds névralgiques de ce réseau de transmission : ces grands parcs clôturés que l’on aperçoit au bord des routes centralisent et redistribuent l’électricité. On y trouve des transformateurs et des disjoncteurs, ces derniers permettant d’ouvrir ou de fermer le courant. Aujourd’hui, ces équipements ne sont plus opérés manuellement mais via du contrôle numérique : interfaces homme-machine (IHM), contrôle à distance, RTU (Remote Terminal Units servant de passerelle vers le centre de contrôle), relais de protection et de contrôle (qui lisent tension, intensité et fréquence pour automatiser des décisions), postes d’ingénierie et équipements réseau.

Badro insiste sur la disparition de l’« air gap » d’autrefois. Les sous-stations sont désormais interconnectées avec les centres de contrôle, des tiers, des partenaires, parfois directement à internet, voire avec le cloud pour la maintenance prédictive. L’architecture type comprend un réseau IT, une DMZ séparant l’IT des systèmes industriels (OT), un centre de contrôle régional ou national (avec historians, serveurs SCADA, bases de données) relié aux sous-stations via VPN ou MPLS. Chaque sous-station est configurée différemment. Certaines connexions exploitent le Powerline Communication (PLC), qui utilise les câbles électriques existants pour transmettre des paquets TCP/IP. Cette multiplication des accès distants, justifiée par la difficulté d’intervenir physiquement dans des zones rurales, augmente considérablement le risque. Les protocoles courants incluent IEC 104, DNP3 et GOOSE.

Badro détaille l’approche Red Team de Mandiant, précisant qu’un véritable attaquant ne prendrait pas les mêmes précautions. L’attaque commence généralement par un accès initial à l’IT via phishing ou exploitation de vulnérabilités. Suit une phase de reconnaissance : énumération du domaine, recherche de documentation sur les partages réseau et wikis, fichiers de configuration aux extensions spécifiques, mots de passe en clair (notamment de VPN) et schémas d’architecture.

L’accès au réseau OT s’obtient ensuite via un VPN, l’exploitation de flux autorisés au firewall, ou la compromission d’hyperviseurs hébergeant des VM IT et OT. Plutôt qu’un scan NMAP destructeur, l’équipe privilégie une reconnaissance furtive : écoute passive du trafic, analyse des adresses IP et MAC, utilisation de logiciels légitimes d’opérateurs et de scripts spécialisés (Modbus, DNP3). Les vulnérabilités exploitées sont souvent basiques : mots de passe par défaut sur interfaces web, SSH ou Telnet, parfois sur des fonctionnalités cachées utilisées par les fournisseurs et inconnues des équipes. À partir d’une IHM, l’attaquant remonte vers les relais de protection, cibles plus insidieuses permettant des dégâts coûteux.

Badro compare deux attaques réelles. En Ukraine en 2015, l’attaque a démarré sur l’IT par phishing (malware Black Energy via macro), récupéré des mots de passe VPN, accédé aux IHM, RTU et switchs Moxa, puis ouvert les disjoncteurs et déployé des firmwares corrompus pour empêcher la reprise de contrôle.

En Pologne en décembre 2025, l’attaque a ciblé directement l’OT en exploitant une CVE connue mais non corrigée pendant plusieurs semaines sur des firewalls exposés à internet. L’attaquant s’est étendu aux RTU, relais, IHM et convertisseurs série-Ethernet via des comptes par défaut, a lancé des scans locaux, uploadé des firmwares corrompus, supprimé des fichiers système des relais et déployé des wipers sur les IHM.

Le constat marquant : malgré dix ans d’écart, les mêmes vulnérabilités basiques persistent. Si l’entrée dans les réseaux IT s’est durcie, le côté OT reste comme l’IT « d’il y a très longtemps » — peu de mots de passe robustes, peu de contrôles — par préjugé d’isolement et par des pratiques de maintenance figées.

Au-delà de la simple ouverture d’un disjoncteur, des attaques plus subtiles ciblent la logique des relais : modifier des valeurs de déclenchement, fausser une LED, ou altérer la fonction de réenclenchement automatique. Ces manipulations restent invisibles jusqu’à une condition rare (un arbre tombant sur une ligne) et sont très difficiles à diagnostiquer sans journalisation.

Côté défense, Badro recommande : changer les mots de passe par défaut (et alerter si l’ancien est réutilisé), maintenir à jour les systèmes exposés à internet, restreindre les accès SSH/HTTP à des points spécifiques, contrôler les flux PLC venant des centrales, et surtout établir une visibilité réseau et événementielle à tous les niveaux. La prévisibilité des réseaux OT facilite la définition d’une baseline et la détection d’anomalies. L’approche consiste à décomposer chaque système, comprendre les fonctions et leurs interfaces internes/externes (par exemple le GPS spoofing), puis concevoir protections et détections adaptées — en protégeant avant tout le disjoncteur, élément le plus critique.

Dans cet épisode du podcast Polysécure enregistré au NorthSec, Gaëtan Ferry et Guillaume Valadon, tous deux cyber security researchers chez GitGuardian depuis deux ans, présentent une recherche consacrée aux fuites de clés privées cryptographiques. Guillaume est par ailleurs mainteneur du logiciel Scapy et rédacteur en chef du magazine MISC.

Contrairement à des secrets classiques comme les clés AWS, dont on peut retrouver le propriétaire en interrogeant les services associés, une clé privée cryptographique (RSA par exemple) ne se rattache à aucune identité. C’est un simple objet mathématique aux propriétés cryptographiques, utilisable pour de multiples usages : connexion SSH, protection d’un site web en TLS, etc. En regardant la clé seule, impossible de savoir à quoi elle sert ou à qui elle appartient. Quelques indices existent parfois — le nom de fichier (norssec.io.key) — mais souvent on tombe sur des private.key inexploitables. L’enjeu de la recherche était donc de trouver une technique générique de catégorisation.

La solution repose sur les Certificate Transparency logs, un mécanisme de l’infrastructure X.509 datant de 2015. Chaque fois qu’une autorité de certification émet un certificat, elle doit le journaliser dans ces registres publics, souvent opérés par d’autres autorités. Ces journaux contiennent donc l’historique de tous les certificats émis.

Le principe du matching est le suivant : une clé privée contient des informations sur sa partie publique (le module, dans le cas de RSA). On extrait cette partie publique, on calcule une empreinte SHA-256, et on fait de même pour les certificats. Comme un certificat TLS associe une clé publique à une identité (généralement le nom du site protégé), une simple jointure entre les deux bases d’empreintes permet de relier une clé privée à un site et à son propriétaire.

La recherche s’est accélérée lors de la conférence Pass the SALT à Lille, où des contacts chez Google les ont alertés : les anciens logs de Certificate Transparency, coûteux à opérer, allaient être mis hors ligne. Or c’était précisément la dimension historique du dataset qui les intéressait. Un partenariat s’est noué : GitGuardian a fourni une liste d’empreintes, et Google a effectué la correspondance dans sa base propriétaire, renvoyant les certificats associés.

Le dataset de fin 2025 comptait un million de clés privées distinctes, collectées via l’activité historique de GitGuardian — le public monitoring qui scanne GitHub, Docker Hub et d’autres sources à la recherche de secrets codés en dur, puis avertit les victimes en mode « bon samaritain ».

Sur ce million, 42 000 clés correspondaient à des certificats émis par des autorités. Le chiffre peut sembler modeste, mais la majorité des clés ne servent jamais au TLS (projets personnels, SSH, autorités privées d’entreprise absentes des logs publics). Ces 42 000 clés étaient liées à plus de 140 000 certificats, signe que certaines avaient servi à émettre plusieurs certificats successifs, prolongeant d’autant la durée d’exposition. Après vérification, 2 600 clés restaient associées à un certificat valide en septembre 2025. Grâce à des techniques d’OSINT, 1 300 certificats ont pu être rattachés à environ 600 entités.

L’équipe a entrepris un responsible disclosure en envoyant environ 4 300 emails à ces 600 entreprises. Résultat : seulement 54 réponses, soit environ 9 %. Même en se limitant aux adresses certaines à près de 100 %, le taux ne dépassait pas 36 %. Pour gérer un envoi aussi massif sans être bloqués comme spam, ils ont dû collaborer avec leurs collègues du marketing, rompus aux techniques de délivrabilité.

Plus frappant que le silence : l’incompréhension des répondants. Beaucoup confondaient clé privée et certificat. Certains ont répondu avoir « changé le certificat », croyant le problème réglé. Une équipe de réponse à incident d’une grande entreprise a même produit une analyse détaillée pour conclure que l’endpoint utilisait désormais un autre certificat, refusant toute révocation — alors qu’un attaquant peut toujours mener une attaque man-in-the-middle avec l’ancien certificat non révoqué. Le certificat a fini par expirer un mois plus tard. Fait notable, 19 entités gouvernementales étaient concernées, et aucune n’a répondu.

Le malentendu de fond tient au fonctionnement de TLS. On génère sa clé privée chez soi, puis on signe une demande de certificat (CSR) envoyée à l’autorité avec la clé publique. L’autorité vérifie les informations, journalise dans CT et renvoie le certificat. Le certificat n’est qu’une partie publique : il associe une clé publique à une identité, sans contenir le secret. Changer de certificat sans changer de clé n’invalide donc rien : l’ancien certificat reste exploitable pour usurper le service tant qu’il n’est pas révoqué.

Face au silence, l’équipe a contacté directement les autorités de certification pour demander la révocation, en fournissant les preuves de possession. Cette voie autoritative s’est révélée plus efficace, mais a généré des réactions parfois hostiles — dont un individu insultant expliquant que sa clé était « volontairement publique » pour permettre l’interception (cas d’usage type Burp), sans que le site l’indique clairement.

Les chercheurs avouent un moment de doute, au point de vérifier auprès d’anciens collègues de l’ANSSI : le problème est bien systémique. La solution qu’ils privilégient n’est pas seulement l’éducation, mais l’automatisation. La réduction drastique de la durée de vie des certificats (vers 47 jours) imposera des outils comme Certbot, qui renouvelle déjà la clé privée en même temps que le certificat. Or 20 % des clés trouvées avaient fui plus de deux ans avant l’expiration du certificat le plus récent : des clés compromises réutilisées sur de nouveaux certificats pendant des années. Renouveler systématiquement la clé aurait éliminé ce cinquième des compromissions.