PolySécure Podcast volet Teknik

Teknik - Panel nsec 2026

2026-06-18T00:00:00-04:00

Parce que… c’est l’épisode 0x30D!

Shameless plug

24 et 25 juin 2026 - Troopers
26 et 27 juin 2026 - leHACK
30 juin au 2 juillet 2026 - Pass the SALT
19 septembre 2026 - Bsides Montréal
20 au 26 septembre 2026 - BruCON
13 novembre 2026 - DEATHCon
16 au 19 novembre - European Cyber Week
1 au 3 décembre 2026 - Forum INCYBER - Canada 2026
24 et 25 février 2027 - SéQCure 2027

Description

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par Northsec

Teknik - Doxxing-proof authentic digital media - trust the asset, protect the source (nsec)

2026-06-10T00:00:00-04:00

Parce que… c’est l’épisode 0x308!

Shameless plug

24 et 25 juin 2026 - Troopers
26 et 27 juin 2026 - leHACK
30 juin au 2 juillet 2026 - Pass the SALT
19 septembre 2026 - Bsides Montréal
20 au 26 septembre 2026 - BruCON
13 novembre 2026 - DEATHCon
16 au 19 novembre - European Cyber Week
1 au 3 décembre 2026 - Forum INCYBER - Canada 2026
24 et 25 février 2027 - SéQCure 2027

Description

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.

Le problème : désinformation et perte de confiance

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 dilemme : authenticité contre anonymat

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 solutions simples, mais limitées

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.

Les techniques cryptographiques avancées

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

Les défis du déploiement

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.

Notes

Doxxing-proof authentic digital media - trust the asset, protect the source

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par Northsec

Teknik - A systematic approach to evading antivirus software

2026-06-03T00:00:00-04:00

Parce que… c’est l’épisode 0x304!

Shameless plug

24 et 25 juin 2026 - Troopers
26 et 27 juin 2026 - leHACK
19 septembre 2026 - Bsides Montréal
1 au 3 décembre 2026 - Forum INCYBER - Canada 2026
24 et 25 février 2027 - SéQCure 2027

Description

Notes

A systematic approach to evading antivirus software

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par NorthSec é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).

Capacités versus signatures

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.

Construire l’inventaire des capacités

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 statique et dynamique

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.

La technique du « probing »

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.

Différences entre moteurs et stratégie d’évasion

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.

Le volet CTF et l’intelligence artificielle

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.

Notes

A systematic approach to evading antivirus software

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par NorthSec

Teknik - GenAI en cybersécurité - cas concret d'utilisation et retour d'expérience (Cybereco)

2026-06-02T00:00:00-04:00

Parce que… c’est l’épisode 0x303!

Shameless plug

3 au 5 juin 2026 - SSTIC 2026
24 et 25 juin 2026 - Troopers
26 et 27 juin 2026 - leHACK
19 septembre 2026 - Bsides Montréal
1 au 3 décembre 2026 - Forum INCYBER - Canada 2026
24 et 25 février 2027 - SéQCure 2027

Description

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 problème : des analystes noyé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.

L’approche : déterminisme d’abord, IA aux points clés

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.

L’ingénierie et l’équipe hybride

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.

Gestion du risque et amélioration continue

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.

Une évolution nécessaire

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.

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par Cybereco

Teknik - Sécurité des sous-stations électriques

2026-05-28T00:00:00-04:00

Parce que… c’est l’épisode 0x301!

Shameless plug

3 au 5 juin 2026 - SSTIC 2026
24 et 25 juin 2026 - Troopers
26 et 27 juin 2026 - leHACK
19 septembre 2026 - Bsides Montréal
1 au 3 décembre 2026 - Forum INCYBER - Canada 2026
24 et 25 février 2027 - SéQCure 2027

Description

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.

Architecture du réseau électrique

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.

Interconnexion croissante et surface d’attaque

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.

Scénario d’attaque en Red Team

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.

Compromissions réelles

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.

Attaques avancées et défense

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.

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par Google Paris

Teknik - Private Key Leaks in the Wild - Insights from Certificate Transparency (nsec)

2026-05-27T00:00:00-04:00

Parce que… c’est l’épisode 0x300!

Shameless plug

3 au 5 juin 2026 - SSTIC 2026
24 et 25 juin 2026 - Troopers
26 et 27 juin 2026 - leHACK
19 septembre 2026 - Bsides Montréal
1 au 3 décembre 2026 - Forum INCYBER - Canada 2026
24 et 25 février 2027 - SéQCure 2027

Description

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.

Le problème de l’attribution

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 méthode : Certificate Transparency

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.

Les chiffres

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.

La divulgation responsable, un parcours décevant

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.

Comprendre TLS

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

Forcer la révocation et la vraie solution

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.

Notes

Private Key Leaks in the Wild: Insights from Certificate Transparency

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par NorthSec

Teknik - Stratégie de sécurité applicative adaptée à l'IA (Cybereco)

2026-05-26T00:00:00-04:00

Parce que… c’est l’épisode 0x2FF!

Shameless plug

3 au 5 juin 2026 - SSTIC 2026
24 et 25 juin 2026 - Troopers
26 et 27 juin 2026 - leHACK
19 septembre 2026 - Bsides Montréal
1 au 3 décembre 2026 - Forum INCYBER - Canada 2026
24 et 25 février 2027 - SéQCure 2027

Description

Le défi fondamental : le volume dépasse les humains

Jonathan Marcil part d’un constat simple mais vertigineux : l’IA génère du code à une vitesse que les équipes de sécurité ne peuvent plus suivre humainement. Le volume de code produit est tel qu’il devient impossible de tout réviser avec rigueur sans y perdre sa santé mentale. Cette réalité impose une réponse stratégique, et c’est précisément l’objet de sa présentation à Cybereco : proposer des stratégies qui utilisent l’IA pour répondre aux problèmes que l’IA elle-même crée.

L’humain reste une variable limitante

Même si l’IA ne connaît pas de fatigue propre, les humains qui travaillent avec elle, eux, s’épuisent. Jonathan illustre ce point avec l’exemple du programme de bug bounty de cURL, qui a dû être fermé parce que les participants utilisaient l’IA pour générer des rapports de bogues en masse. Le résultat : une surcharge humaine impossible à gérer, même pour des experts qui connaissent le système depuis des dizaines d’années. L’IA peut amplifier le bruit autant que le signal.

Le prompting : une compétence éphémère

Un thème central de la discussion est la nature instable de la compétence en prompt engineering. Chaque nouveau modèle frontier réagit différemment, ce qui rend les techniques de prompting acquises partiellement obsolètes à chaque mise à jour majeure. Jonathan voit néanmoins une vertu dans cette diversité des modèles : elle empêche une standardisation totale et maintient une forme de compétition saine entre les fournisseurs. Cela dit, il met en garde contre la tentation de consacrer trop d’énergie à suivre chaque lancement au détriment des compétences fondamentales en sécurité.

Le vibe coding et la perte de compétences

L’un des points les plus préoccupants soulevés par Jonathan est le risque de dépendance cognitive. Le « vibe coding » — cette pratique de générer du code sans vraiment le comprendre — crée une illusion de productivité. Tant que tout fonctionne, personne ne pose de questions. Mais le jour où un bug survient ou qu’une faille est découverte, si les développeurs n’ont plus les compétences fondamentales pour diagnostiquer le problème, ils se retrouvent à demander à l’IA de corriger ce qu’elle a elle-même mal produit. Jonathan cite un exemple personnel : il a demandé à un modèle de réviser ses diapositives, et le modèle a omis un élément important — sans le signaler spontanément. L’autocritique reste un angle mort des LLM.

Les stratégies proposées

La réponse de Jonathan à ces défis repose sur plusieurs axes concrets :

1. Diversifier les modèles. Utiliser plusieurs IA en parallèle — demander à l’un de valider ce que l’autre a produit — est une pratique simple mais efficace pour introduire un regard critique dans le processus. Il suggère aussi de soumettre d’anciens travaux aux nouvelles versions des modèles, qui peuvent en faire de meilleures révisions.

2. Charger les bonnes pratiques de l’entreprise dans le LLM. Plutôt que d’utiliser un modèle générique, Jonathan propose d’alimenter le LLM avec la gouvernance, les politiques et les standards de sécurité propres à l’organisation. Les résultats, selon son expérience avec une formation Cybereco l’année précédente, peuvent être spectaculaires : des équipes ont corrigé des vulnérabilités réelles en moins de 15 minutes après avoir simplement fourni au modèle les bonnes pratiques contextuelles.

3. Combiner petits et grands modèles. Pour gérer les coûts et la vitesse, il propose d’utiliser des modèles légers (souvent locaux) pour les tâches d’exploration — par exemple, repérer les zones d’authentification dans une base de code — puis de faire traiter les résultats par un modèle plus puissant. Cette architecture en pipeline est à la fois économique et efficace.

4. Explorer les modèles open weight. Les modèles à poids ouverts, notamment ceux optimisés par des contributeurs chinois pour tourner sur du matériel modeste, offrent une flexibilité précieuse. Ils permettent de ne pas être entièrement dépendant des fournisseurs cloud et d’adapter l’usage à la tolérance au risque propre à chaque organisation.

Le problème systémique : insécure par défaut

La conversation se clôt sur une observation structurelle importante : les infrastructures cloud sont historiquement configurées pour maximiser l’adoption, c’est-à-dire ouvertes par défaut. Jonathan constate que les LLM ont reproduit ce même réflexe — livrer vite, livrer simple, quitte à négliger la sécurité. La sécurité applicative, qui arrive toujours en fin de processus, paie le prix de cette course à l’adoption. Il plaide pour inverser cette logique : partir d’une posture fermée et sécurisée par défaut, puis ouvrir ce qui est nécessaire, plutôt que l’inverse.

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par Cybereco

Teknik - État de la menace en 2026 (Cybereco)

2026-05-20T00:00:00-04:00

Parce que… c’est l’épisode 0x2FC!

Shameless plug

3 au 5 juin 2026 - SSTIC 2026
24 et 25 juin 2026 - Troopers
26 et 27 juin 2026 - leHACK
19 septembre 2026 - Bsides Montréal
1 au 3 décembre 2026 - Forum INCYBER - Canada 2026
24 et 25 février 2027 - SéQCure 2027

Description

Dans cet épisode spécial de Polysécure consacré à Cybereco, Charles F. Hamilton présente son analyse annuelle de l’état de la menace cyber en 2026. Comme chaque année, il s’efforce de distinguer le discours marketing des vendeurs de la réalité observée sur le terrain, fort de son expérience quotidienne en tests d’intrusion offensifs.

Azure et Entra ID : des failles par défaut

Une large partie de la discussion porte sur l’environnement Microsoft Azure et Entra ID (anciennement Azure Active Directory). Charles souligne un problème fondamental : beaucoup d’entreprises partent du principe que « si c’est Microsoft, c’est sécurisé », ce qui crée une forme de déresponsabilisation dangereuse. En réalité, la configuration par défaut d’Azure offre très peu de visibilité — les logs et informations de sécurité essentiels sont verrouillés derrière un paywall, rendant la validation quasi impossible sans un intervenant offensif.

Un exemple frappant illustre ce problème : lorsqu’une entreprise configure une politique d’accès conditionnel imposant le MFA pour toutes les applications mais ajoute une seule exception (par exemple pour un compte d’automatisation), Microsoft ajoutait silencieusement Microsoft Graph et Azure Active Directory dans les exceptions. Or, Microsoft Graph est le point d’entrée vers pratiquement tous les services cloud. Un attaquant disposant d’un identifiant et mot de passe pouvait donc s’authentifier via Microsoft Graph sans aucun MFA. Bien que Microsoft ait corrigé ce comportement récemment, toute exception créée avant le correctif reste active. Charles en découvre encore quotidiennement, ce qui pose un problème majeur — notamment pour les assureurs, dont les questionnaires de conformité ne détectent pas ces failles.

Le décalage entre sécurité offensive et défensive

Charles défend l’idée que la sécurité offensive a une longueur d’avance considérable sur la défensive. Les produits de sécurité défensive bloquent souvent des menaces qui datent de plusieurs années, pas celles d’aujourd’hui. Il prend l’exemple du device code phishing, une technique qu’il utilise depuis une dizaine d’années et que les attaquants malveillants commencent seulement à découvrir en 2026. Les entreprises qui ont investi dans des tests offensifs il y a cinq ou six ans sont déjà protégées ; les autres paniquent aujourd’hui.

Il insiste sur la valeur du Red Team : contrairement à un scan automatisé qui produit des milliers de vulnérabilités toutes marquées « critiques », un Red Team raconte une histoire — il identifie le chemin qu’un attaquant emprunterait pour atteindre ce qui a réellement de la valeur pour l’entreprise. Charles mentionne également le score EPSS (Exploit Prediction Scoring System), encore trop méconnu, qui permet de prioriser les vulnérabilités en fonction de leur probabilité réelle d’exploitation plutôt que de leur sévérité théorique.

Infostealers et ClickFix : les menaces du quotidien

La conversation aborde ensuite les infostealers, des logiciels malveillants qui récupèrent les mots de passe stockés dans les navigateurs. Leur efficacité tient à leur discrétion : ils ne touchent pas aux processus surveillés par les EDR/XDR et sont donc très peu détectés. Pire, ils se propagent souvent via des installeurs gratuits pour des jeux populaires comme Roblox ou Minecraft, ciblant les enfants. Quand un parent prête son ordinateur professionnel à son enfant, les identifiants corporatifs se retrouvent compromis. Charles rapporte des chiffres vertigineux : un de ses contacts dans le domaine possède des logs provenant de 600 millions de postes uniques infectés par des infostealers.

Quant aux attaques ClickFix, Charles se dit fasciné qu’elles fonctionnent, car elles demandent à l’utilisateur d’exécuter une série d’étapes complexes — copier du PowerShell dans une invite de commande, par exemple. Mais l’utilisateur moyen ne comprend tout simplement pas ce qu’il fait : les extensions de fichiers, les commandes, tout cela n’a aucun sens pour lui. Le succès du phishing repose uniquement sur l’expérience utilisateur : plus c’est simple, plus ça marche.

Supply chain et cas extrêmes

Charles partage des histoires marquantes de sa carrière. Il a testé la sécurité d’avions dont les interfaces pilotes tournaient sous Flash et Windows embarqué. Bien que l’avion soit physiquement déconnecté d’internet, le laptop de mise à jour, lui, y passait — ouvrant la porte à des attaques de supply chain. Il raconte aussi le cas de guichets ATM dont le système de gestion acceptait des mises à jour non signées, permettant l’injection de code malveillant.

Plus récemment, il a travaillé sur des cas d’infiltration d’employés nord-coréens se faisant passer pour des développeurs. Fait surprenant : ces individus étaient de bons ingénieurs et se faisaient toujours démasquer par des anomalies humaines (incohérences de localisation), jamais par leur code.

IA, vibe coding et secrets exposés

L’essor du vibe coding assisté par IA aggrave un problème existant : des développeurs qui ne comprennent pas ce qu’ils produisent. Charles a trouvé plus de 124 000 résultats sur GitHub pour « remove client secret » — des commits où des développeurs retirent des secrets Azure (tenant ID, application ID, client secret) sans jamais les révoquer. Beaucoup de ces commits portent les traces caractéristiques de code généré par IA, avec des emojis dans les commentaires.

Le paradoxe de l’industrie cyber

En conclusion, Charles soulève un paradoxe central : on n’a jamais eu autant de produits de sécurité, de solutions et de technologies pour prévenir les brèches, et pourtant on n’a jamais eu autant de brèches. Les entreprises s’étouffent sous les abonnements coûteux et les promesses marketing, mais négligent l’hygiène de base — segmentation réseau, gestion des correctifs, inventaire des systèmes. L’industrie souffre aussi d’un manque de conséquences réelles pour les entreprises négligentes, ce qui pousse beaucoup d’entre elles à faire le strict minimum. Le vrai travail reste à faire, et il commence par les fondamentaux.

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par Intrasecure inc

Teknik - Mythos no hype

2026-05-14T00:00:00-04:00

Parce que… c’est l’épisode 0x2F9!

Shameless plug

3 au 5 juin 2026 - SSTIC 2026
24 et 25 juin 2026 - Troopers
26 et 27 juin 2026 - leHACK
19 septembre 2026 - Bsides Montréal
1 au 3 décembre 2026 - Forum INCYBER - Canada 2026
24 et 25 février 2027 - SéQCure 2027

Description

Le contexte : un signal d’alarme venu de Google Next

Nicolas Bédard, professionnel en cybersécurité chez Palo Alto Networks, revient de Google Next où il a tenu 16 rencontres clients. Un constat frappant : la quasi-totalité de ces clients avaient Mythos en tête de liste de leurs préoccupations. Ce modèle d’intelligence artificielle d’Anthropic, encore en phase de prévisualisation, a déclenché une vague d’inquiétude dans l’industrie. Nicolas admet lui-même qu’il avait sous-estimé l’ampleur du phénomène avant de constater, face à face, l’anxiété généralisée de ses interlocuteurs.

Qu’est-ce que Mythos et pourquoi ça change la donne ?

Mythos est un modèle d’IA de nouvelle génération, considérablement plus performant que les modèles précédents (comme Opus 4.7 de Claude) pour une tâche précise : trouver des vulnérabilités dans du code logiciel. Sa force ne réside pas uniquement dans sa capacité à détecter des failles individuelles, mais surtout dans son aptitude à établir des liens entre plusieurs vulnérabilités mineures. Là où deux ou trois failles de niveau faible ou moyen seraient jugées sans conséquence prises isolément, Mythos est capable de les relier pour révéler une vulnérabilité critique. C’est un changement de paradigme majeur.

Le programme d’accès anticipé d’Anthropic

Palo Alto Networks fait partie du programme « Class Wing » d’Anthropic, aux côtés d’autres grands acteurs du cloud et de la cybersécurité. Ces partenaires ont reçu un accès privilégié à Mythos avant son lancement public, leur permettant de scanner leur propre code à la recherche de failles inconnues. Selon Nicolas, cette démarche relève d’un geste de responsabilité corporative : Anthropic a anticipé les risques liés à la puissance de son modèle et a donné une longueur d’avance aux joueurs majeurs pour se préparer. Palo Alto a d’ailleurs lancé, en collaboration avec son équipe Unit 42, une offre d’accompagnement pour aider les clients à réaliser des analyses similaires avec des modèles déjà accessibles publiquement.

La menace pour les systèmes anciens et le code ouvert

L’un des aspects les plus préoccupants concerne les systèmes hérités. Historiquement, un vieux programme en COBOL sur AS/400 ou un mainframe oublié bénéficiait d’une forme de sécurité par l’obscurité : personne ne s’intéressait à y chercher des failles parce que c’était trop coûteux et peu rentable. Seuls les acteurs étatiques avaient les moyens de développer des exploits sophistiqués. Avec Mythos et ses futurs équivalents, cette barrière financière disparaît. N’importe qui pourra potentiellement analyser du code ancien et y trouver des failles exploitables.

Le risque s’étend aussi à la chaîne d’approvisionnement logicielle. Le code ouvert, massivement réutilisé par l’industrie, devient un vecteur d’attaque amplifié. Un acteur malveillant pourrait scanner des bibliothèques populaires, y découvrir des vulnérabilités non divulguées, et les exploiter à grande échelle — ou pire, contribuer du code malicieux que des milliers de développeurs téléchargeraient en toute confiance.

Le déluge de correctifs qui s’annonce

Les premières conséquences sont déjà visibles : Microsoft et d’autres grandes entreprises ayant accès à Mythos publient des volumes de correctifs bien supérieurs à la normale. Nicolas anticipe que la situation va s’intensifier considérablement dans les mois à venir, particulièrement autour de la sortie publique du modèle, estimée vers juin ou juillet. Le modèle traditionnel du « Patch Tuesday » — ce cycle mensuel prévisible d’application de correctifs — risque de voler en éclats, car certaines failles seront trop critiques pour attendre le prochain cycle.

Pour les entreprises qui peinent déjà à appliquer 10 à 12 correctifs mensuels sur des systèmes comme SAP, l’idée d’en gérer 200 ou 500 est vertigineuse. Les arrêts de production, les tests de régression, la coordination avec les équipes d’affaires : tout cela se complexifie de manière exponentielle. Et les pratiques modernes de développement (microservices, SRE, CI/CD) qui pourraient absorber ce choc ne sont maîtrisées que par une poignée de grandes entreprises technologiques.

Les recommandations concrètes

Face à ce tsunami, Nicolas et son interlocuteur reviennent aux fondamentaux avec trois axes prioritaires. Premièrement, scanner son propre code dès maintenant avec les modèles disponibles, sans attendre Mythos. Des chercheurs ont publié des méthodes de prompting permettant de simuler les capacités de Mythos avec Opus 4.7.

Deuxièmement, assurer une couverture à 100 % des contrôles de sécurité existants. Chaque exception, chaque angle mort, chaque compte de service mal configuré devient une porte d’entrée potentielle. L’analogie de l’eau est parlante : comme l’eau qui s’infiltre par la moindre fissure, ces modèles d’IA trouveront inlassablement le moindre trou dans les configurations.

Troisièmement, réduire l’exposition externe au maximum et développer une capacité de réaction en temps réel. Le passage de « plusieurs jours » à « quelques minutes » pour répondre aux menaces impose une transformation profonde des centres d’opérations de sécurité. Les approches traditionnelles de réponse aux incidents, avec leurs processus de révision humaine, ne suffiront plus.

Un appel à l’action pour les dirigeants

Nicolas conclut avec un message direct : chaque responsable de la sécurité (CISO) devrait engager dès maintenant une conversation transparente avec son conseil d’administration sur les implications de Mythos. Il s’agit d’aller chercher les budgets et les ressources nécessaires avant la crise, plutôt qu’après une attaque. L’industrie s’apprête à vivre un moment pivot où l’on passera d’une logique de liste noire à une logique de liste blanche, où seul ce qui est explicitement autorisé sera permis. Les paradigmes vont changer, et ceux qui ne s’y préparent pas risquent d’en subir les conséquences de plein fouet.

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par Nicolas Bédard

Teknik - La place du tooling dans le threat intelligence (CTI)

2026-05-05T00:00:00-04:00

Parce que… c’est l’épisode 0x2F3!

Shameless plug

9 au 17 mai 2026 - NorthSec 2026
3 au 5 juin 2026 - SSTIC 2026
24 et 25 juin 2026 - Troopers
26 et 27 juin 2026 - leHACK
19 septembre 2026 - Bsides Montréal
1 au 3 décembre 2026 - Forum INCYBER - Canada 2026
24 et 25 février 2027 - SéQCure 2027

Description

Présentation des invités

Dans cet épisode technique de Polysécure, l’animateur reçoit deux analystes de l’équipe TDR (Threat Detection and Research) de Sekoya. Charles Meslay se spécialise en reverse engineering et en analyse de malware, tandis que Félix Aimé se concentre sur l’étude de campagnes liées à des États — cyberespionnage, sabotage — et joue un rôle central dans le développement d’outils internes pour mener les investigations. L’épisode prend appui sur un billet de blog récemment publié par l’équipe portant sur une campagne d’APT28, groupe étatique lié à la Russie, pour élargir la discussion à l’ensemble du tooling utilisé en CTI.

Du reverse engineering manuel à l’automatisation

Le point de départ concret est l’analyse d’un malware écrit en .NET, attribué à APT28 et découvert début 2025. Initialement, le travail reposait sur des outils classiques comme dnSpy : une interface graphique permettant de décompiler le code, de renommer les fonctions et de comprendre progressivement leur logique. Ce processus, bien que relativement accessible, est extrêmement chronophage — de une à trois semaines par binaire et par analyste.

Avec l’émergence des LLM, Charles a d’abord commencé à copier-coller manuellement des portions de code dans ChatGPT pour accélérer l’analyse. Cette pratique l’a conduit à une idée d’automatisation : la création d’un serveur MCP (Model Context Protocol), un protocole permettant à un LLM d’interagir avec des outils externes via une interface de type API. Ce serveur, mis en open source, est en réalité une brique d’un outil plus large développé en interne : Sara.

sarA : un orchestrateur d’analyse automatisée

Sara est présentée comme le cœur de l’écosystème d’analyse de Sekoya. Son fonctionnement est le suivant : on lui soumet un fichier, le LLM identifie le type de fichier et sélectionne les outils adaptés — qu’il s’agisse de Ghidra, d’IDA Pro ou d’outils maison en ligne de commande — pour procéder à l’analyse. À l’issue du processus, Sara génère un rapport structuré comprenant la description du comportement du binaire, les différentes couches d’obfuscation détectées, des scripts de désobfuscation si nécessaire, et une liste explicite des angles morts de l’analyse, notamment en cas de limitations liées aux tokens ou au nombre de passes effectuées.

Le gain est spectaculaire : le temps d’analyse est passé de plusieurs semaines à quelques minutes. Au-delà du gain de vitesse, Sara a également élargi le cercle des analystes capables de contribuer au reverse engineering, y compris ceux qui n’avaient pas de formation approfondie dans ce domaine. Les analystes spécialisés, comme Charles, continuent quant à eux à intervenir sur les cas complexes que l’outil ne résout pas seul.

Un écosystème d’outils progressivement construit

Félix retrace l’histoire du tooling interne, développé de façon itérative au fil des années. Au départ, l’équipe disposait d’un simple serveur de cache connecté à des API tierces comme VirusTotal, permettant de limiter la consommation de quotas. Ce serveur a ensuite été refondu pour gérer de manière transparente les clés d’API, simplifiant ainsi la vie des développeurs internes.

L’équipe a ensuite créé un ensemble d’API maison pour automatiser des tâches courantes : requêtes DNS, récupération de plages d’IP sur des AS, etc. Ces briques ont permis de construire 150 transformes pour Maltego, un logiciel d’analyse permettant d’appliquer des micro-opérations sur des entités (adresses IP, noms de domaine, etc.) afin d’enrichir les investigations. Aujourd’hui, l’équipe envisage de migrer vers Flosint, une solution open source française au fonctionnement similaire.

Pour le suivi dans le temps des infrastructures malveillantes, deux outils ont été développés. Tracker interroge des services comme Shodan, Censys ou VirusTotal avec des règles précises pour surveiller en quasi-temps réel des infrastructures ou des malwares. Irma, plus orientée vers le hunting, permet d’initier des investigations à partir d’heuristiques poussées — par exemple, détecter un nom de domaine enregistré chez un registraire douteux qui résout vers un routeur potentiellement compromis en France.

L’ergonomie au cœur du développement

Un principe philosophique fort ressort de l’échange : l’ergonomie prime sur la complexité technique. Félix insiste sur le fait que les outils en ligne de commande, aussi puissants soient-ils, finissent par être abandonnés si leur utilisation requiert de consulter le manuel à chaque fois. L’objectif est que l’intégralité des outils soit accessible depuis un navigateur web, via des sous-domaines dédiés, avec une interface de recherche permettant de trouver un outil par mot-clé (par exemple, taper « LLM » pour lister tous les outils liés à l’intelligence artificielle).

Cette centralisation présente plusieurs avantages : harmonisation des dépendances, déploiement automatisé via des pipelines CI/CD, et adoption effective par l’ensemble de l’équipe. Comme le résument les deux invités, un outil que personne n’utilise ne vaut rien — peu importe ses capacités techniques.

L’IA comme accélérateur transversal

L’arrivée des LLM a transformé deux autres facettes du travail. D’abord, le prototypage : là où il fallait parfois des semaines pour valider une preuve de concept, quelques heures suffisent aujourd’hui pour déterminer si une idée mérite d’être poursuivie ou abandonnée.

Ensuite, la capitalisation du renseignement. L’équipe ingère des rapports publics d’éditeurs tiers, les modélise au format STIX — un standard structuré d’objets liés (campagnes, groupes d’attaquants, indicateurs de compromission) — et enrichit sa base de connaissance. Ce travail, autrefois fastidieux et manuel, est aujourd’hui en grande partie automatisé grâce aux LLM, avec une revue humaine finale. L’analyste se retrouve alors libéré des tâches répétitives pour se concentrer sur ce qui reste hors de portée de l’IA : la création de règles YARA, le développement de trackers d’infrastructure, et l’identification de détails techniques fins qui nécessitent encore un vrai jus de cerveau.

Conclusion

Cet épisode offre un regard rare et concret sur le quotidien d’une équipe CTI de pointe. Entre automatisation intelligente, philosophie d’ergonomie et intégration progressive de l’IA, Charles et Félix décrivent un métier en pleine mutation — où l’analyste humain reste indispensable, mais se concentre désormais sur ce qu’il fait le mieux.

Notes

APT28, sarA Is watching you!

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - IA SOC

2026-04-22T00:00:00-04:00

Parce que… c’est l’épisode 0x2EE!

Shameless plug

28 et 29 avril 2026 - Cybereco Cyberconférence 2026
9 au 17 mai 2026 - NorthSec 2026
3 au 5 juin 2026 - SSTIC 2026
19 septembre 2026 - Bsides Montréal
1 au 3 décembre 2026 - Forum INCYBER - Canada 2026
24 et 25 février 2027 - SéQCure 2027

Description

Un historique souvent oublié

David Bizeul rappelle d’emblée que l’intelligence artificielle en cybersécurité n’est pas un phénomène récent. Ses racines remontent aux années 1950 avec les travaux d’Alan Turing, mais c’est surtout à partir des années 1990 que le machine learning commence à s’intégrer concrètement dans les produits de sécurité. Les systèmes experts et les algorithmes de classification — supervisés ou non supervisés — permettent alors de traiter de grands volumes de données : filtres bayésiens pour les e-mails, détection d’anomalies réseau via les outils NDR, etc.

Cette évolution se fait progressivement et sans grand bruit jusqu’en 2023, où l’architecture Transformer de Google — à l’origine de ChatGPT et d’OpenAI — change radicalement la donne. Les LLM (grands modèles de langage) ouvrent de nouvelles possibilités dès lors qu’on leur fournit un corpus textuel structuré. Les produits de sécurité intègrent d’abord des assistants conversationnels, capables de répondre à des questions sur des groupes d’attaquants ou des menaces connues, en s’appuyant simplement sur ce que le modèle a appris.

Vient ensuite le RAG (Retrieval-Augmented Generation), qui permet de combiner la connaissance générale du LLM avec des données internes propres à chaque client : analyses de risques, politiques de sécurité, rapports de tests d’intrusion. Le contexte devient ainsi beaucoup plus pertinent et personnalisé.

L’ère agentique : plusieurs agents qui collaborent

La véritable rupture arrive avec l’approche agentique, qui s’impose véritablement à partir de fin 2025 et début 2026. Plutôt qu’un modèle unique qui répond à des requêtes, on dispose désormais d’un framework composé de plusieurs agents spécialisés qui travaillent ensemble de façon orchestrée.

David illustre cela avec un cas d’usage concret dans un SOC :

Un agent d’investigation analyse les alertes en profondeur : il examine les événements associés, identifie les actifs concernés, recoupe les informations pour confirmer si une attaque a réellement progressé ou a été bloquée.
Un agent de triage joue le rôle d’orchestrateur : il mobilise l’agent d’investigation sur l’ensemble des alertes en attente, puis produit un verdict ou un score de pertinence pour chacune d’elles.
Un agent de contre-mesures prend le relais une fois la situation clarifiée : il propose des actions correctives en tenant compte des outils disponibles (présence ou non d’API, de protocoles MCP) et de leur accessibilité réelle dans l’environnement du client.

Chaque agent dispose d’un périmètre d’action délimité, d’une capacité de raisonnement (un LLM interne ou externe) et d’une batterie d’actions possibles. C’est exactement la trajectoire suivie par l’entreprise de David, qui déploie ces modules agentiques cette année.

Maîtriser les hallucinations et personnaliser les agents

Pour s’assurer qu’un agent reste dans les rails, plusieurs mécanismes sont mis en place. Le premier est le system prompt : une instruction détaillée — parfois l’équivalent de cinq pages — qui définit les objectifs, les étapes à suivre et les comportements à éviter. Les clients peuvent ensuite surcharger ces instructions avec leurs propres règles métier. Par exemple, une entreprise qui préfère parler d’un « score de 0 à 100 » plutôt que de « faux positifs » peut reconfigurer l’agent en conséquence.

Pour réduire les hallucinations, il est également possible de faire itérer un agent sur plusieurs passes de vérification, voire de solliciter plusieurs LLM différents afin de confronter leurs points de vue. David donne l’exemple d’un agent de renseignement sur les menaces étatiques : interroger successivement un modèle américain, européen et chinois permet de mettre en évidence des biais géographiques, puis de synthétiser une vue équilibrée. Cette approche multi-modèles n’est cependant pas systématiquement recommandée : elle multiplie les coûts et la latence, et n’apporte une valeur réelle que pour des questions à fort enjeu stratégique.

Choisir son modèle : externe, interne ou spécialisé

Trois grandes options s’offrent aux organisations :

L’API externe (OpenAI, Anthropic, etc.) : simple à mettre en œuvre, mais nécessite un encadrement contractuel rigoureux pour la protection des données.
Le modèle open source hébergé en interne : instancié sur les propres GPU de l’entreprise, il garantit confidentialité et maîtrise de la latence, au prix d’une infrastructure plus lourde.
Le DSLM (Domain-Specific Language Model) : un modèle entraîné spécifiquement pour la cybersécurité, plus léger et plus rapide qu’un LLM généraliste, à l’image de ce qu’avait réalisé Cisco. Cette approche marque en quelque sorte un retour aux origines du machine learning spécialisé, mais enrichi des apports de l’architecture Transformer.

Impact sur les équipes : augmentation, pas remplacement

L’IA ne remplacera pas les analystes SOC, mais elle transformera profondément leurs rôles. Le triage — tâche répétitive et chronophage — sera bientôt entièrement automatisé. Les analystes seront alors libérés pour se concentrer sur des missions à plus forte valeur ajoutée : detection engineering, gestion de crise, définition des règles d’automatisation.

Le paradigme évolue du « human in the loop » — l’humain intégré dans la boucle, qui la ralentit — vers le « human on the loop » : l’humain en posture de pilotage, qui supervise et ajuste sans intervenir à chaque étape. Face à des attaques de plus en plus automatisées et rapides (des outils comme Shannon permettent déjà de séquencer des opérations de pentest de façon autonome), la défense n’a pas d’autre choix que de s’automatiser à son tour.

Une question sans réponse : la formation des futurs experts

La discussion se conclut sur une interrogation ouverte et préoccupante : si les postes de niveau junior — qui constituaient historiquement le terrain d’apprentissage des futurs seniors — disparaissent au profit de l’automatisation, comment formera-t-on les experts de demain ? Une piste serait d’utiliser l’IA elle-même pour accélérer la montée en compétences via des simulations réalistes. Mais la question reste entière, et David l’admet sans détour : il n’a pas la réponse.

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - EvilTokens

2026-04-10T00:00:00-04:00

Parce que… c’est l’épisode 0x742!

Préambule

Ma connexion Internet de l’hôtel où j’étais avait une latence insoutenable. J’ai tenté de retirer le awkward des pauses entre les interactions, mais ce n’est pas parfait.

Shameless plug

14 au 17 avril 2026 - Botconf 2026
20 au 22 avril 2026 - ITSec
- Code rabais de 15%: Seqcure15
28 et 29 avril 2026 - Cybereco Cyberconférence 2026
9 au 17 mai 2026 - NorthSec 2026
3 au 5 juin 2026 - SSTIC 2026
19 septembre 2026 - Bsides Montréal
1 au 3 décembre 2026 - Forum INCYBER - Canada 2026
24 et 25 février 2027 - SéQCure 2027

Description

Introduction

Dans cet épisode, l’animateur s’entretient avec Quentin Bourgue, chercheur en cybersécurité, au sujet d’un rapport récemment publié sur EvilTokens, un nouveau kit de phishing as a service (PhaaS) qui marque un tournant significatif dans le paysage des cybermenaces. Le sujet est présenté d’emblée comme particulièrement préoccupant, l’animateur confiant avoir eu « froid dans le dos » à la lecture des conclusions de l’analyse.

Qu’est-ce qu’EvilTokens ?

EvilTokens est un service de phishing découvert début mars 2026 lors d’une veille menée sur un canal Telegram spécialisé dans la fraude et le phishing. L’opérateur a développé un kit clé en main qu’il loue à des affiliés selon un modèle de souscription mensuelle — un modèle dit phishing as a service.

Ce qui distingue immédiatement ce kit de ses concurrents, c’est sa technique d’attaque : le phishing par device code, plutôt que le phishing par adversary-in-the-middle (AiTM) qui prédomine dans la majorité des plateformes PhaaS existantes.

Le phishing par device code : une technique jusque-là réservée aux élites

Le phishing par AiTM consiste à s’intercaler entre la victime et le service d’authentification pour récupérer un cookie de session. Le phishing par device code fonctionne différemment : l’attaquant initie lui-même une demande d’autorisation pour un appareil virtuel — une méthode normalement conçue pour les smart TV ou les objets connectés — puis demande à la victime de compléter cette autorisation. Toutes les étapes s’effectuent sur les domaines légitimes de Microsoft, ce qui rend la détection bien plus difficile.

À l’issue du processus, l’attaquant ne récupère pas un simple cookie de session, mais deux jetons Microsoft :

Un access token, valable 60 à 90 minutes, donnant accès à des services comme Outlook, SharePoint, OneDrive, Microsoft Teams ou l’API Microsoft Graph.
Un primary refresh token, permettant de maintenir un accès persistant pendant 90 jours.

Avant EvilTokens, cette technique était réservée à des acteurs sophistiqués : groupes étatiques ou cybercriminels avancés. Le fait qu’elle soit désormais packagée dans un service accessible à des attaquants peu qualifiés représente un saut qualitatif majeur dans la menace.

Un modèle économique structuré et professionnel

Le kit est distribué entièrement via Telegram. L’opérateur a mis en place un bot pour automatiser les souscriptions, des canaux pour promouvoir les nouvelles fonctionnalités, et un système de support client. Le paiement s’effectue en cryptomonnaies via un service nommé Payment Now.

La tarification est significativement plus élevée que les offres concurrentes :

1 500 dollars pour accéder au panneau d’administration,
500 dollars par mois pour les pages de phishing opérationnelles,
soit 2 000 dollars le premier mois.

Ce prix s’explique par les fonctionnalités avancées de post-compromission, notamment l’automatisation augmentée par l’intelligence artificielle — qui constitue sans doute l’innovation la plus redoutable du kit.

La post-compromission automatisée par l’IA : le vrai saut technologique

Une fois les jetons en main, l’attaquant peut déclencher une phase de reconnaissance automatisée via des requêtes à l’API Microsoft Graph. En quelques clics, il récupère : les emails de la victime, ses contacts, son calendrier, ses dossiers, et même sa position hiérarchique dans l’organisation (manager, subordonnés).

Toutes ces données sont ensuite consolidées sur l’infrastructure d’EvilTokens, puis analysées par deux modèles d’intelligence artificielle via un service nommé Groq (avec un Q, distinct du Grok d’Elon Musk) :

Groq Llama 3.8B analyse les emails par lots de 250 pour identifier les activités financières.
Groq Llama 3.3 70B consolide les analyses, génère un score de fraude potentielle, et rédige automatiquement trois emails de compromission (BEC) prêts à l’envoi, injectés dans des fils de conversation existants pour maximiser leur crédibilité.

Une fonction de traduction via l’API d’OpenAI permet également de traiter les boîtes mail dans d’autres langues que l’anglais.

Ce qui prenait auparavant plusieurs heures, voire plusieurs jours de reconnaissance manuelle se fait désormais en quelques minutes, avec un niveau de contextualisation bien supérieur à ce qu’un attaquant humain pouvait atteindre seul.

Un code probablement généré par IA

L’analyse du code JavaScript d’EvilTokens a conduit Quentin Bourgue à estimer qu’il a été vibe-codé, c’est-à-dire généré en grande partie par un outil d’IA générative. Plusieurs indices le suggèrent : tout le code tient dans un seul fichier, les commentaires sont très soignés et sans fautes, des emojis apparaissent dans le code, et certaines fonctions semblent mortes ou non fonctionnelles — caractéristiques fréquentes des sorties LLM.

Conséquences et mesures de remédiation

EvilTokens préfigure une évolution rapide de l’ensemble de l’écosystème PhaaS. Déjà, des concurrents comme Kratos et Tycoon ont commencé à intégrer le phishing par device code. Il est probable que les fonctionnalités d’automatisation par IA se répandent dans la majorité des plateformes concurrentes dans les mois à venir.

Pour les entreprises, les recommandations sont les suivantes :

Bloquer l’autorisation par device code dans les politiques d’accès conditionnel, ou en restreindre l’usage à un sous-ensemble précis d’utilisateurs si des cas métier légitimes l’exigent (salles de réunion connectées, IoT).
Sensibiliser les employés à risque — particulièrement ceux liés aux activités financières — à ce type de phishing et aux tentatives de fraude par compromission de messagerie professionnelle (BEC).

Conclusion

EvilTokens représente une convergence inédite entre phishing avancé, automatisation et intelligence artificielle, mise à la portée d’attaquants peu expérimentés. La vitesse et la précision des attaques que ce kit permet rendent la détection et la réponse aux incidents encore plus critiques pour les organisations. Une menace à surveiller de très près.

Notes

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Trivy... part 2 ou comment le supply chain est LE vecteur

2026-04-04T00:00:00-04:00

Parce que… c’est l’épisode 0x737!

Shameless plug

14 au 17 avril 2026 - Botconf 2026
20 au 22 avril 2026 - ITSec
- Code rabais de 15%: Seqcure15
28 et 29 avril 2026 - Cybereco Cyberconférence 2026
9 au 17 mai 2026 - NorthSec 2026
3 au 5 juin 2026 - SSTIC 2026
19 septembre 2026 - Bsides Montréal
1 au 3 décembre 2026 - Forum INCYBER - Canada 2026
24 et 25 février 2027 - SéQCure 2027

Description

Contexte et rappel de l’épisode précédent

Dans cet épisode technique, l’animateur reçoit à nouveau François Proulx pour faire le point sur une cyberattaque majeure dont les développements ont explosé depuis leur dernière conversation. L’épisode précédent portait sur une première attaque contre Trivy, un outil d’analyse de sécurité open source développé par l’entreprise israélienne Aqua Security. Trivy est massivement utilisé par de grandes entreprises pour inventorier les composants open source d’un projet (SBOM) et identifier les vulnérabilités associées (CVE). C’est précisément cette popularité qui en a fait une cible de choix.

La deuxième vague : une réponse aux incidents incomplète

À peine 20 jours après l’attaque initiale de fin février, Trivy a été compromis une seconde fois. La raison : Aqua Security n’avait pas révoqué la totalité des jetons d’accès (tokens) lors de sa réponse aux incidents. L’entreprise a attendu plusieurs jours avant de faire appel à une firme externe (Mend), ce qui lui a valu des critiques. Dans leur communiqué, ils ont admis avoir oublié de révoquer un token — et pas n’importe lequel : il s’agissait d’un token encore plus privilégié que celui utilisé lors de la première attaque, donnant accès à des dépôts privés internes contenant potentiellement de la propriété intellectuelle sensible.

Cette deuxième attaque a été encore plus dévastatrice : non seulement Trivy a été empoisonné à nouveau, mais les GitHub Actions associées — des composants permettant d’intégrer Trivy dans des pipelines CI/CD — ont également été corrompues, y compris les versions antérieures. Ainsi, des organisations qui croyaient utiliser une version sûre et ancienne se sont retrouvées exposées sans le savoir.

Une propagation en cascade

Le vecteur initial était une vulnérabilité dans un workflow GitHub Actions du dépôt de Trivy, simple à exploiter mais peu connue. Les attaquants ont obtenu un token leur permettant de compiler et distribuer une version malveillante de Trivy sur les registres officiels — sans modifier le code source visible, ce qui rendait la détection plus difficile.

Lorsque Trivy s’exécutait dans le pipeline CI/CD d’une entreprise victime, il agissait comme un info stealer : il exfiltrait les secrets et tokens présents dans l’environnement d’exécution. Ces tokens volés ont ensuite servi à compromettre d’autres projets, créant une chaîne de contamination à plusieurs niveaux :

Premier ordre : Trivy lui-même, compromis chez Aqua Security.
Deuxième ordre : les entreprises utilisant Trivy dans leurs pipelines, dont Checkmarx, un autre outil de sécurité applicative.
Troisième ordre : des projets open source très populaires comme LiteLLM, une bibliothèque d’interfaçage avec des API de modèles de langage (LLM), dont le mainteneur semble avoir été compromis directement via son poste de travail.

Environ 72 heures après l’attaque, des entreprises ont commencé à signaler publiquement que leurs tokens avaient été exfiltrés et réutilisés contre elles.

Les attaquants se dévoilent

Durant le week-end du 20 mars, le groupe responsable s’est révélé sur Twitter sous le nom Team PCP, en défaçant des dépôts GitHub pour prouver leurs accès. Ils ont ensuite établi des partenariats avec des groupes spécialisés dans les rançongiciels pour monétiser les accès obtenus — une évolution logique pour des acteurs en possession de téraoctets de secrets volés.

Le FBI a officiellement nommé ce groupe et demandé à toutes les entreprises américaines victimes de déposer plainte. Selon François Proulx, le profil comportemental des attaquants — messages puérils, communication sur Telegram, manière de se vanter publiquement — laisse fortement penser qu’il s’agit d’adolescents, probablement situés hors du territoire américain, ce qui complique les poursuites.

Pour entraver les équipes de réponse aux incidents, les attaquants ont utilisé des centaines de comptes GitHub légitimes achetés sur le marché noir (probablement issus de logs d’info stealers) pour inonder les fils de discussion d’incidents avec des commentaires génériques automatisés, rendant toute coordination difficile.

Le problème structurel des dépendances transitives

François Proulx soulève un enjeu critique lié à l’écosystème npm : la façon dont les contraintes de version sont définies dans les fichiers package.json. Lorsqu’une dépendance est déclarée de manière vague (ex. : axios: ^1.x), une mise à jour de routine peut automatiquement introduire une version compromise sans que le développeur s’en rende compte. La bibliothèque Axios, extrêmement populaire, a notamment été touchée dans cette attaque.

Même avec un fichier de verrouillage (lock file), le risque n’est pas nul : une alerte de hash incohérent pourrait être ignorée ou, pire, conduire un développeur à régénérer le lock file en gelant ainsi la version malveillante.

Ce que les développeurs peuvent faire

François Proulx recommande deux mesures concrètes :

Utiliser des outils de vérification en temps réel qui interceptent les téléchargements de composants npm ou PyPI pour les comparer à des listes de composants malveillants mises à jour plusieurs fois par heure.
Adopter une période de gel (cool-off period) avant d’utiliser une nouvelle version d’une dépendance, afin de laisser à la communauté le temps de détecter d’éventuels problèmes.

Il mentionne également Bagle, leur propre outil open source d’analyse locale, qui permet de détecter des secrets mal stockés sur un poste de travail (variables d’environnement, fichiers temporaires, etc.) sans rien envoyer à l’extérieur.

Conclusion

Au moment de l’enregistrement, le 2 avril, l’attaque était toujours en cours. Une grande partie des victimes ne sait même pas encore qu’elle a été compromise. Les semaines à venir risquent de révéler l’ampleur réelle des dégâts, notamment via les dépendances transitives. Cet épisode illustre à quel point la sécurité de la chaîne d’approvisionnement logicielle reste largement sous-estimée — et que ce réveil collectif, bien que douloureux, était peut-être nécessaire.

Notes

Teknik - Hackerbot-claw

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Survol de S3NS et le cloud souverain

2026-04-03T00:00:00-04:00

Parce que… c’est l’épisode 0x736!

Préambule

Nous sommes à la Cage durant un match des Canadiens. Le bruit ambiant a fait que nous parlons en “criant”, pour nous entendre. Le lendemain, je n’avais plus de voix.

Shameless plug

14 au 17 avril 2026 - Botconf 2026
20 au 22 avril 2026 - ITSec
- Code rabais de 15%: Seqcure15
28 et 29 avril 2026 - Cybereco Cyberconférence 2026
9 au 17 mai 2026 - NorthSec 2026
3 au 5 juin 2026 - SSTIC 2026
19 septembre 2026 - Bsides Montréal
1 au 3 décembre 2026 - Forum INCYBER - Canada 2026
24 et 25 février 2027 - SéQCure 2027

Description

Introduction et mise en contexte

Dans cet épisode spécial, l’animateur reçoit Nicolas Bédard, un expert en infonuagique qui a évolué chez Google avant de rejoindre Palo Alto Networks. Le prétexte de l’épisode est concret : Nicolas s’apprête à se rendre à Paris pour participer à la grande conférence de S3NS, une entreprise issue d’un partenariat franco-américain au cœur de la souveraineté numérique en France. C’est l’occasion idéale pour aborder un sujet devenu incontournable, alors qu’il était encore marginal il y a quelques années seulement.

S3NS : la franchise numérique franco-américaine

Pour expliquer le modèle de S3NS, Nicolas utilise une analogie parlante : celle de la franchise de restauration rapide. Comme un franchisé de McDonald’s ou Tim Hortons qui investit dans son propre établissement tout en appliquant la recette du franchiseur, S3NS est une entreprise majoritairement détenue par le groupe français Thales, qui a obtenu de Google le « livre de recettes » de son infrastructure infonuagique — tant sur le plan matériel (serveurs, stockage, réseau) que logiciel (les services Google Cloud).

S3NS propose deux offres distinctes :

Cryptance : une couche de souveraineté appliquée directement sur l’infrastructure de Google Cloud. Les charges de travail (workloads) sont placées dans un dossier (folder) auquel sont attachées des règles de gouvernance strictes — notamment des clés de chiffrement gérées par S3NS — garantissant que les données demeurent sur le territoire français.
Prémiance : un niveau supérieur, où Thales et Google ont co-construit des centres de données physiques en France. Ces infrastructures, propriété de S3NS, utilisent l’architecture de Google Cloud mais sont opérées de façon indépendante. Prémiance est certifiée SecNumCloud, la norme française de cybersécurité gérée par l’ANSSI, ce qui constitue une validation rigoureuse issue de plusieurs années d’expérimentation sur le terrain.

La force des règles technologiques

Un point central de la discussion porte sur la nature même des règles technologiques : contrairement aux règles entre humains, qui peuvent être interprétées, négociées ou contournées, les règles appliquées par une machine sont absolues. Nicolas illustre cela avec une anecdote personnelle : lors d’un projet pilote, des parties prenantes avaient exigé l’application de règles strictes, malgré ses mises en garde. En moins de 24 heures, le projet avait été abandonné parce que les participants ne pouvaient tout simplement pas « tolérer » des règles que la machine appliquait sans compromis.

Cette rigidité est précisément ce qui rend la souveraineté numérique crédible. Le chiffrement, par exemple, ne se négocie pas : sans la clé détenue par l’entité française, même un acteur américain ne peut accéder aux données. Les craintes liées au Cloud Act américain, souvent agitées dans le débat public, se heurtent à cette réalité technique implacable.

Le rôle de Palo Alto Networks

Palo Alto Networks s’intègre dans cet écosystème parce que les clients qui migrent vers un cloud souverain s’attendent à retrouver les outils de sécurité qu’ils utilisaient dans leurs environnements traditionnels. Quatre produits de Palo Alto sont particulièrement concernés, tous basés sur des machines virtuelles (VM-based) :

Les pare-feu de nouvelle génération (Next-Gen Firewalls)
Prisma AIRS, le pare-feu dopé à l’IA pour contrer les injections de prompts et les fuites de données
Panorama, la console centralisée de gestion des pare-feu
XSIAM, la plateforme d’orchestration pour la réponse aux incidents

Ces produits, parce qu’ils s’exécutent sur des machines virtuelles plutôt que sous forme de SaaS hébergé chez Palo Alto, peuvent être déployés aussi bien sur Cryptance que sur Prémiance, en conformité avec SecNumCloud.

La vraie valeur du nuage et la modernisation des applications

Nicolas insiste sur une vision souvent oubliée : le nuage, c’est avant tout du logiciel. Sa valeur réelle réside dans l’élasticité, la dématérialisation, les microservices et les conteneurs — pas dans la simple virtualisation de serveurs existants. Beaucoup d’entreprises ont mal abordé leur passage au nuage en y transférant des systèmes vieillissants sans les moderniser, ce qui les rend aujourd’hui incompatibles avec les exigences de la souveraineté numérique, qui impose une partition claire des services à l’échelle nationale.

Rouler une application moderne — découpée en microservices indépendants, stateless, élastiques — sur un cloud souverain, c’est là que réside la vraie promesse de la prochaine génération d’infrastructures souveraines.

Le retard canadien et les leçons européennes

La France a commencé à réfléchir à la souveraineté numérique dès 2017 environ. Elle a construit ses normes, les a testées, les a fait évoluer. Le Canada, lui, s’est réveillé bien plus tard, emporté qu’il était par la « locomotive » américaine. Aujourd’hui, il n’existe pas d’équivalent canadien à SecNumCloud, et la maturité réglementaire nécessaire pour encadrer une véritable infrastructure souveraine est encore à construire.

Les deux interlocuteurs s’entendent pour dire que le Canada devrait s’inspirer davantage de ce qui se fait en Europe — en France, en Allemagne, à travers des initiatives comme celle de la ville de Munich — plutôt que de se limiter à répéter le mot « souveraineté » sans se donner les outils concrets pour la réaliser. Cela implique une réarchitecture profonde des systèmes existants, un développement de compétences nationales et un cadre réglementaire sérieux.

Conclusion

La souveraineté numérique est un chantier de longue haleine, mais l’exemple de S3NS en France démontre qu’il est possible de concilier technologie américaine de pointe et contrôle national effectif. Nicolas conclut sur une note d’enthousiasme, impatient de voir la conférence parisienne et d’espérer que des modèles similaires finissent par voir le jour au Canada. Un suivi de l’épisode est d’ores et déjà prévu.

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par La Cage - Complexe Desjardins

Teknik - Et si l'IA n'avait plus besoin de vos données?

2026-04-02T00:00:00-04:00

Parce que… c’est l’épisode 0x735!

Shameless plug

14 au 17 avril 2026 - Botconf 2026
20 au 22 avril 2026 - ITSec
- Code rabais de 15%: Seqcure15
28 et 29 avril 2026 - Cybereco Cyberconférence 2026
9 au 17 mai 2026 - NorthSec 2026
3 au 5 juin 2026 - SSTIC 2026
19 septembre 2026 - Bsides Montréal
1 au 3 décembre 2026 - Forum INCYBER - Canada 2026
24 et 25 février 2027 - SéQCure 2027

Description

Retour aux sources techniques

Dans cet épisode, l’animateur retrouve Frédéric Grelot, expert en intelligence artificielle, qu’il n’avait pas croisé depuis un moment. Frédéric a quitté son poste de dirigeant chez Glimps, une entreprise qu’il avait exportée au Canada, pour retrouver ses premières amours : la technique et la recherche. Il a rejoint l’AMIAD (Agence pour la maîtrise de l’IA de défense), rattachée au ministère des Armées français, créée en 2024. Un retour assumé, les « mains dans le cambouis », comme il le dit lui-même.

Le fil conducteur de cet échange tourne autour d’une idée provocatrice : peut-on faire de l’intelligence artificielle sans données ? Frédéric avertit d’emblée que la formule est volontairement accrocheuse, et que la réponse sera nuancée.

Une histoire de l’IA en quelques étapes clés

Pour comprendre où l’on va, Frédéric propose un retour sur les grandes ruptures qui ont façonné l’IA depuis une quarantaine d’années.

1989 – Les débuts des réseaux convolutifs. Le réseau LeNet-5, conçu pour lire des chiffres manuscrits sur des chèques, représente l’un des premiers exemples concrets de réseaux de neurones convolutifs. Ces réseaux fonctionnent en empilant des couches d’analyse : les premières détectent des formes simples (points, lignes, angles), les suivantes des structures plus complexes (roues, rétroviseurs, puis une voiture entière). Ce paradigme a dominé le domaine pendant environ vingt ans.

2012 – La double révolution. Deux événements simultanés ont provoqué une explosion du domaine. D’une part, Nvidia a démocratisé l’utilisation des GPU pour le calcul scientifique via son API CUDA, rendant accessibles des calculs matriciels massivement parallèles. D’autre part, le jeu de données ImageNet a été publié en accès libre — un million d’images réparties en 1 000 catégories — offrant à la communauté une base commune pour entraîner et évaluer des modèles. Ces deux facteurs combinés ont déclenché une effervescence considérable, notamment dans le domaine de la vision par ordinateur.

2017 – L’avènement des transformers. La publication du célèbre article Attention is all you need introduit une nouvelle architecture qui va s’imposer comme le standard de l’IA moderne. Contrairement aux approches séquentielles précédentes, le transformer analyse chaque mot d’une phrase en le mettant en relation avec tous les mots qui le précèdent, enrichissant progressivement le sens de chaque élément couche après couche. Cette capacité à saisir le contexte global d’une séquence est à la base de tous les grands modèles de langage actuels.

Son principal défaut : un coût de calcul quadratique par rapport à la longueur des séquences. Doubler la longueur d’un texte quadruple le volume de calcul. Les recherches de ces huit dernières années ont largement porté sur la résolution de ce problème, avec des résultats impressionnants — certains modèles open source atteignent aujourd’hui des fenêtres de contexte d’un à deux millions de tokens.

Novembre 2022 – ChatGPT et la démocratisation. La sortie de ChatGPT marque moins une rupture technologique qu’une rupture d’usage. En mettant dans les mains du grand public ce qui n’existait que dans des laboratoires, OpenAI a transformé une évolution technique en révolution sociale. Les questions d’hallucinations, de jailbreak et d’alignement des modèles ont alors émergé comme des enjeux majeurs.

Les modèles de fondation : l’IA qui apprend à vivre avant de se spécialiser

C’est ici que Frédéric introduit son concept central : les modèles de fondation. L’analogie qu’il utilise est parlante : un enfant qui grandit jusqu’à 20 ans — observant des formes, des visages, des papillons, faisant du cerf-volant — développe une compréhension générique du monde qui en fait un « excellent modèle de fondation ». Il sera ensuite capable d’apprendre un métier précis, comme la géométrie ou la rétroingénierie de code, en repartant de cette base solide plutôt que de zéro.

Un modèle de fondation est entraîné sur des quantités massives de données brutes, sans nécessairement annoter chaque exemple. Une fois cette phase généraliste accomplie, on n’a plus besoin que d’un tout petit volume de données spécialisées et annotées pour l’amener à un niveau d’excellence sur une tâche précise. Là où il fallait autrefois des millions d’exemples étiquetés, quelques centaines suffisent désormais.

Ce paradigme bouleverse les rapports de force autour de la donnée. Frédéric, qui conseillait autrefois à ses clients de « conserver précieusement toutes leurs données », leur dit aujourd’hui d’en garder un peu, de bonne qualité. Le reste n’est plus indispensable.

Vers l’inférence sans entraînement

La dernière évolution abordée est peut-être la plus spectaculaire : le zero-shot learning. Grâce à la richesse des modèles de fondation, il est aujourd’hui possible de montrer une seule image d’un objet inconnu — une voiture jamais vue pendant l’entraînement — et d’être immédiatement capable de la reconnaître dans d’autres photos. Aucun entraînement supplémentaire n’est nécessaire : le modèle comprend l’objet à partir d’un seul exemple.

C’est en ce sens que l’on peut parler d’IA « sans données » : non pas qu’il n’y en ait jamais eu, mais que l’utilisateur final n’a plus besoin d’en fournir pour bénéficier de capacités autrefois réservées aux experts disposant de vastes bases de données annotées.

Un domaine en perpétuelle ébullition

La conversation aborde également la dynamique concurrentielle entre modèles propriétaires américains et modèles open source, notamment chinois (DeepSeek) et français (Mistral). Les contraintes imposées aux acteurs chinois en matière de puissance de calcul ont paradoxalement stimulé l’innovation, à travers des techniques comme la distillation, le pruning ou l’optimisation des architectures d’attention.

L’épisode se conclut sur une note d’ouverture : les hallucinations reculent, les modèles apprennent à dire « je ne sais pas », et le champ continue d’évoluer à un rythme soutenu — autant de raisons de se retrouver pour un prochain épisode.

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Le COCD/SOC moderne

2026-03-19T00:00:00-04:00

Parce que… c’est l’épisode 0x727!

Shameless plug

31 mars au 2 avril 2026 - Forum INCYBER - Europe 2026
14 au 17 avril 2026 - Botconf 2026
20 au 22 avril 2026 - ITSec
- Code rabais de 15%: Seqcure15
28 et 29 avril 2026 - Cybereco Cyberconférence 2026
9 au 17 mai 2026 - NorthSec 2026
3 au 5 juin 2026 - SSTIC 2026
19 septembre 2026 - Bsides Montréal
1 au 3 décembre 2026 - Forum INCYBER - Canada 2026
24 et 25 février 2027 - SéQCure 2027

Description

Contexte et invités

Dans cet épisode, Nicolas reçoit David Bizeul pour un retour approfondi sur le concept de SOC (Security Operations Center) moderne. David est notamment l’un des artisans de Secoya, une plateforme SOC développée par son équipe, ce qui lui confère une perspective à la fois pratique et stratégique sur l’évolution du domaine.

Ce que contient un SOC moderne en 2026

David commence par dresser un portrait du SOC contemporain tel qu’il devrait fonctionner aujourd’hui. Selon lui, trois grandes dimensions structurent un SOC efficace.

1. La fusion de la connaissance interne et externe avec les événements de sécurité

La première brique fondamentale est la capacité à ingérer, normaliser et consolider les événements de sécurité issus du système d’information. À cela s’ajoutent deux couches de connaissance complémentaires :

La connaissance interne : elle porte sur les assets de l’entreprise, les identités, les vulnérabilités, les chemins critiques métier. En somme, tout ce qui permet de comprendre ce que l’on protège.
La connaissance externe : c’est le domaine de la threat intelligence (CTI). Elle répond à la question « qu’est-ce que je dois craindre ? » et modélise les menaces extérieures, les campagnes d’attaque, les modes opératoires.

David explique que Secoya a justement construit son produit en partant de la CTI, avant même de s’intéresser aux événements clients. L’idée était d’abord de bien connaître la menace, puis de confronter cette connaissance aux données du terrain.

2. Les moteurs de détection

Une fois les données ingérées, trois moteurs distincts entrent en jeu :

Le moteur de threat intelligence : il repose sur une base de connaissances en graphe. Chaque indicateur (une adresse IP, par exemple) est relié à des nœuds représentant des malwares, des campagnes, des acteurs malveillants. Quand un indicateur apparaît dans les événements, le moteur remonte automatiquement tout le contexte associé, permettant d’évaluer rapidement la gravité de la situation.
Le moteur de corrélation : basé sur le langage Sigma et Sigma Correlation, il modélise des comportements suspects à partir d’enchaînements d’événements. Par exemple : cinq échecs d’authentification sur un poste suivis d’une connexion anormale sur un équipement réseau peuvent caractériser une tentative d’intrusion. Toutes les règles sont créées ou validées par des experts internes, ce qui permet d’atteindre un taux de faux positifs infime (environ 0,001 %).
Le moteur d’anomalie : il détecte les déviances par rapport à une baseline comportementale. Un pic de trafic soudain sur un serveur web, une exfiltration de données inhabituelle ou une activité de type brute force sont autant de signaux que ce moteur est conçu à relever.

Le retour en arrière : le SOC d’il y a dix ans

Pour mieux illustrer les progrès accomplis, David fait un flash-back sur les SOC de la génération précédente. Monter un SOC il y a dix ans était une opération longue et coûteuse : infrastructure à déployer, licences SIEM à acquérir, threat intelligence quasi inexistante ou inutilisable, enrichissement des alertes quasi nul. Une seule alerte pouvait mobiliser un analyste pendant une heure sans déboucher sur une conclusion claire. Les règles de corrélation, souvent dérivées de politiques de sécurité mal rédigées, généraient un volume d’alertes sans valeur réelle. Le bilan : des millions dépensés pour un SOC qui ne produisait rien d’utile.

De l’alerte à la réponse : l’automatisation et l’IA agentique

La génération d’alertes n’est qu’une étape. Le vrai objectif d’un SOC est de contenir les risques avant qu’ils ne se concrétisent en impacts. David décrit la chaîne de réponse moderne :

Qualification automatique des alertes : des agents IA prennent en charge le triage préliminaire, vérifient le contexte autour d’un événement (les cinq minutes avant/après, la nature de l’asset concerné), et déterminent si l’alerte mérite d’être escaladée ou peut être ignorée.
Playbooks automatisés : des plans de réponse préconfigurés peuvent déclencher des actions concrètes, comme l’isolation d’une machine compromise, sans intervention humaine immédiate.
Le rôle central de l’humain : malgré l’automatisation, l’analyste reste indispensable pour les décisions complexes, la communication de crise, l’adaptation des plans de réponse aux spécificités du client.

Le modèle MDR et l’architecture multitenant

David aborde également la réalité économique : la grande majorité des entreprises n’ont pas les ressources pour gérer un SOC en interne. C’est là qu’interviennent les prestataires MDR (Managed Detection and Response), qui mutualisent les services de SOC pour plusieurs clients. Secoya répond à ce besoin avec une architecture multitenant : un opérateur MDR peut gérer dix clients dans une seule interface, tout en maintenant une séparation stricte des données.

L’interopérabilité et le rôle d’OXA

La dernière partie de l’échange porte sur l’interopérabilité entre produits de cybersécurité, notamment via la plateforme ouverte OXA et le protocole MCP (Model Context Protocol). L’idée est de permettre à chaque outil de se « présenter » aux autres — ses capacités, ses endpoints, ses types de données — afin de construire des workflows automatisés sans friction.

La mise en garde finale : l’IA ne vaut que ce que valent ses données

Les deux interlocuteurs s’accordent sur un point crucial pour conclure : l’engouement pour l’IA agentique en 2025 a souvent masqué un problème fondamental. Si les sources de données en entrée sont de mauvaise qualité, l’IA produira des résultats erronés, voire dangereux. La vraie tendance de 2026 sera donc la valorisation des data sources de pertinence : une CTI fiable, une connaissance interne solide des assets, avant d’y injecter de l’intelligence artificielle. Un prochain épisode est annoncé pour approfondir spécifiquement cette question.

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - La transformation d'un 20% en 100%

2026-03-12T00:00:00-04:00

Parce que… c’est l’épisode 0x723!

Préambule

Nous sommes à la Cage durant un match des Canadiens. Le bruit ambiant a fait que nous parlons en “criant”, pour nous entendre. Le lendemain, je n’avais plus de voix.

Shameless plug

31 mars au 2 avril 2026 - Forum INCYBER - Europe 2026
14 au 17 avril 2026 - Botconf 2026
20 au 22 avril 2026 - ITSec
- Code rabais de 15%: Seqcure15
28 et 29 avril 2026 - Cybereco Cyberconférence 2026
9 au 17 mai 2026 - NorthSec 2026
3 au 5 juin 2026 - SSTIC 2026
19 septembre 2026 - Bsides Montréal
1 au 3 décembre 2026 - Forum INCYBER - Canada 2026
24 et 25 février 2027 - SéQCure 2027

Description

Un retour après une longue absence

C’est avec une certaine nostalgie que j’accueille Nicolas Bédard, un invité régulier qui avait mystérieusement disparu des ondes pendant plusieurs mois. La raison de cette absence ? Un changement de carrière majeur qui a bousculé son quotidien et rendu toute planification d’enregistrement pratiquement impossible. Entre les décalages de calendrier, les voyages et les nouvelles responsabilités à apprivoiser, les deux complices n’avaient tout simplement pas réussi à se retrouver devant un micro. Mais Nicolas est de retour, et il a beaucoup à raconter.

Cinq ans chez Google : de l’imposter syndrome aux 20 %

Tout commence en août 2020, quand Nicolas rejoint Google en pleine pandémie, parmi une cohorte de 10 000 nouvelles recrues embauchées simultanément. L’imposter syndrome le frappe de plein fouet. Comment se démarquer dans une entreprise peuplée de talents exceptionnels ? Sa réponse : trouver une niche où son expérience passée peut faire une différence.

Connaissant bien Palo Alto Networks de ses vies professionnelles antérieures, Nicolas remarque un courriel interne annonçant le lancement d’un nouveau produit, Cloud IDS. Il contacte directement le gestionnaire de produit pour offrir son aide. C’est ainsi que naît son premier projet à 20 %.

La règle des 20 % est une particularité culturelle bien connue de Google : chaque employé a le droit de consacrer 20 % de son temps de travail à un projet annexe, à condition que celui-ci apporte de la valeur à la compagnie ou à la société. C’est d’ailleurs ce principe qui aurait mené à la création de Gmail. Pour Nicolas, cette liberté devient un levier de croissance personnelle et professionnelle remarquable.

Pendant quatre ans, il consacre ce temps à renforcer l’alliance stratégique entre Google et Palo Alto Networks, deux géants dont le partenariat commercial est l’un des plus importants dans l’industrie de la cybersécurité. Il co-présente des produits lors de conférences comme Google Next, développe une expertise pointue sur les intégrations conjointes, et gagne en visibilité des deux côtés de l’alliance. Son 20 % devient, en quelque sorte, son véritable terrain de passion.

Le moment décisif : convertir le 20 % en 100 %

Après avoir tenté sans succès d’obtenir un poste dédié à cette alliance à l’intérieur même de Google, Nicolas pivote vers l’équipe Google Cloud Security (GCS) pour ses six derniers mois dans l’entreprise. C’est alors qu’il reçoit un texto inattendu de la personne responsable de l’alliance Google-Palo : un poste s’ouvre chez Palo Alto Networks pour prendre en charge tout l’enablement technique lié aux fournisseurs infonuagiques. Son nom a été mentionné. L’offre ? Transformer son ancien 20 % en 100 % de son travail.

La décision n’est pas difficile à prendre. Bien que les produits de Google soient de grande qualité, Nicolas constate lors de ses discussions avec des clients que des angles morts existent dans l’offre de sécurité. Les entreprises ne vivent pas exclusivement dans un seul environnement infonuagique : elles jonglent entre des charges de travail on-premises, AWS, Azure, Google Cloud et Oracle Cloud. Palo Alto Networks, en tant que pure player de la cybersécurité, possède cet avantage de la spécialisation que ne peut pas toujours offrir un généraliste comme Google, si bon soit-il.

Un nouveau rôle centré sur la valeur, sans pression de vente

Ce qui enthousiasme particulièrement Nicolas dans son nouveau poste, c’est l’abandon du quota de vente. Fini la pression commerciale mensuelle : il peut désormais enfiler son chapeau de formateur et se concentrer sur la transmission de la connaissance. Son équipe de quatre personnes se structure autour de quatre missions principales :

L’intégration de produits, pour s’assurer que les solutions conjointes Palo-Google fonctionnent de façon fluide et cohérente ;
La création de sales plays, des guides qui permettent aux équipes de vente de bien articuler la valeur des produits devant les clients ;
L’enablement, qui passe par des conférences, des webinaires, des architectures de référence et des démonstrations techniques ;
Le soutien aux équipes commerciales, qui garde Nicolas connecté à la réalité du terrain sans qu’il soit lui-même sous pression de résultats.

L’alliance Google-Palo Alto : une symbiose technique profonde

L’intégration entre les deux entreprises va bien plus loin qu’un simple partenariat commercial. La quasi-totalité des produits de Palo Alto Networks tourne aujourd’hui sur l’infrastructure de Google Cloud. Certains produits Google, comme Cloud IDS ou Cloud NGFW Enterprise, sont en réalité propulsés par la technologie de Palo Alto en dessous. Des utilisateurs de Prisma Access, l’outil SASE de Palo, traversent l’infrastructure de Google à chaque connexion VPN sans nécessairement le savoir. L’alliance permet également des optimisations réseau avancées, comme l’appairage natif entre Prisma Access et Google Cloud via le Network Connectivity Center.

L’intelligence artificielle : le prochain grand terrain de jeu

La conversation s’oriente naturellement vers l’IA, sujet incontournable du moment. Nicolas identifie deux enjeux majeurs pour les entreprises qui adoptent ces technologies : la consistance des résultats (les modèles d’IA ne sont pas déterministiques comme un formulaire web) et, en second lieu, la sécurité. Les grands fournisseurs infonuagiques développent des modèles de pointe, mais ils sont moins bien équipés pour gérer des problématiques comme la prévention des fuites de données (DLP), la protection contre le prompt injection ou la sécurisation des pipelines IA. C’est exactement là que Palo Alto Networks intervient en complémentarité, comme en témoigne l’annonce récente d’une intégration de Prisma AIRS directement dans Microsoft Copilot.

Un virage vers la souveraineté numérique

En guise de conclusion, Nicolas évoque brièvement le thème de la souveraineté numérique, sujet d’autant plus brûlant dans le contexte géopolitique actuel. Les organisations cherchent à reprendre le contrôle de leurs données, à réduire leur dépendance envers des infrastructures étrangères et à explorer les options de nuage souverain. Un vaste sujet que les deux complices promettent d’explorer en profondeur lors d’un prochain épisode, avec Nicolas qui se retrouve, cette fois-ci, aux premières loges de cette transformation.

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par La Cage - Complexe Desjardins

Teknik - Hackerbot-claw

2026-03-11T00:00:00-04:00

Parce que… c’est l’épisode 0x722!

Shameless plug

31 mars au 2 avril 2026 - Forum INCYBER - Europe 2026
14 au 17 avril 2026 - Botconf 2026
20 au 22 avril 2026 - ITSec
- Code rabais de 15%: Seqcure15
28 et 29 avril 2026 - Cybereco Cyberconférence 2026
9 au 17 mai 2026 - NorthSec 2026
3 au 5 juin 2026 - SSTIC 2026
19 septembre 2026 - Bsides Montréal
1 au 3 décembre 2026 - Forum INCYBER - Canada 2026
24 et 25 février 2027 - SéQCure 2027

Description

Nouveautés de Boost Security Labs

François Proulx commence l’épisode en faisant le point sur les développements récents de son équipe. Boost Security a procédé à une refonte de son site web afin de distinguer clairement l’entreprise commerciale de son équipe de recherche, désormais appelée Boost Security Labs, accessible à l’adresse labs.security. Ce nouveau site centralise les articles, outils et références produits par les chercheurs.

François mentionne également un article publié fin 2025 intitulé Defensive Research Weaponized — 2025 State of Pipeline Security, qui dressait un bilan de l’année et anticipait les types d’attaques qui se sont effectivement concrétisées depuis. L’équipe sera de retour à NorthSec cette année avec un nouveau talk et surtout un nouvel outil baptisé Smoke Meat — fidèle à la thématique culinaire montréalaise de l’équipe. Cet outil se veut le « Metasploit des pipelines CI/CD » : là où Poutine (leur outil d’analyse statique) détecte les vulnérabilités dans les pipelines de build, Smoke Meat permettra de les exploiter de manière semi-autonome, en proposant un menu d’options à l’utilisateur.

Un troisième outil est aussi annoncé : Bagel, un utilitaire défensif qui tourne entièrement hors ligne et analyse la posture de sécurité des laptops de développeurs et administrateurs. Il détecte les mauvaises configurations locales — clés SSH non chiffrées, tokens hardcodés dans des scripts, etc. — pour limiter les dégâts en cas d’infection par un logiciel de type info stealer (ou « kleptogiciel », selon la terminologie de l’équipe Flare).

L’attaque Hackerbot Claw : une offensive automatisée sur les pipelines CI/CD

Sébastien Graveline prend ensuite la parole pour détailler une attaque survenue le 27 février, impliquant un agent automatisé qui a ciblé plusieurs grands projets open source. Au moins quatre projets ont été confirmés comme exploités. Ce qui rend cette attaque particulièrement notable, c’est qu’il s’agit d’un agent IA attaquant d’autres systèmes intégrant de l’IA dans leurs pipelines — un scénario que les chercheurs qualifient, avec un certain humour noir, de « bienvenue en 2026 ».

L’équipe s’est concentrée notamment sur Aqua Security Trivy, un projet comptant plus de 25 000 étoiles sur GitHub. L’une des conséquences directes de l’attaque a été que le dépôt a été rendu privé ou supprimé, compliquant considérablement le travail d’investigation forensique.

La piste de MégaGame : remonter le fil de l’attaque

En examinant les discussions GitHub autour de l’incident, l’équipe repère une pull request (PR #10252) ouverte environ cinq heures avant la première attaque de Hackerbot, puis rapidement supprimée — un fait que personne d’autre n’avait mentionné dans les analyses publiées. L’utilisateur à son origine avait lui aussi été supprimé.

Grâce à Trat Hunter, leur outil de surveillance en temps réel des événements GitHub, les chercheurs identifient l’acteur derrière cette PR : un utilisateur qu’ils surnomment Méga Game, dont le compte datait de début janvier. En remontant plus loin, ils trouvent qu’une tentative d’attaque similaire avait été détectée un mois auparavant sur ce qui semble être un dépôt de test.

Forensique sur GitHub : fork networks et gists supprimés

L’investigation se heurte à un obstacle de taille : le dépôt Trivy ayant été supprimé ou rendu privé, il n’est plus possible de cloner directement la version du commit exploité. C’est ici qu’entre en jeu un comportement peu connu de GitHub : lorsqu’un dépôt est supprimé, le fork network ne disparaît pas pour autant. Le plus ancien fork existant hérite automatiquement du rôle de racine du réseau, et l’intégralité des commits de tous les forks reste accessible tant qu’il reste au moins un fork vivant.

L’équipe retrouve ainsi un fork avec une seule étoile mais… 3 000 forks rattachés, devenu malgré lui le patriarche de l’arbre. Cela leur permet de récupérer le payload de Méga Game, qui consiste en une exploitation d’action GitHub locale (local GitHub action exploit) : le workflow checkout le code de l’attaquant, puis exécute une action locale redéfinie par ce dernier — une variante classique du untrusted checkout.

L’exploitation finale repose sur un curl pipe bash pointant vers un gist GitHub privé (mais non authentifié). Les chercheurs découvrent qu’il est possible de cloner un gist supprimé par son identifiant unique, à condition d’être authentifié sur GitHub — peu importe que ce soit le créateur original ou non. Un comportement probablement lié à la gestion du CDN de GitHub, qui conserve les objets tant qu’un garbage collection n’a pas eu lieu.

L’essor des attaques automatisées sur les CI/CD

L’épisode se conclut sur une réflexion plus large. Les attaques sur les pipelines CI/CD sont en croissance exponentielle, car ces environnements donnent accès à des ressources cloud critiques et que les secrets y sont souvent mal scopés. Dans le cas de Trivy, un simple workflow de commentaires a suffi à obtenir des droits administrateurs sur le projet.

Face à cela, les recommandations sont claires : rouler des outils de détection comme Poutine, appliquer le principe de défense en profondeur (secrets correctement scopés, limitation des outils accessibles aux agents IA), et ne jamais oublier qu’un projet public est ouvert non seulement au téléchargement, mais aussi à l’attaque. L’équipe mentionne également des cas où Claude a détecté des tentatives de prompt injection et a correctement refusé d’exécuter les actions demandées — une lueur d’espoir dans un tableau par ailleurs assez sombre.

Notes

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Importance des standards ouverts et présentation d'Open XDR Architecture (OXA)

2026-01-21T00:00:00-05:00

Parce que… c’est l’épisode 0x698!

Shameless plug

29 janvier 2026 - The Coming AI Hackers
25 et 26 février 2026 - SéQCure 2026
- CfP
31 mars au 2 avril 2026 - Forum INCYBER - Europe 2026
14 au 17 avril 2026 - Botconf 2026
28 et 29 avril 2026 - Cybereco Cyberconférence 2026
9 au 17 mai 2026 - NorthSec 2026
3 au 5 juin 2026 - SSTIC 2026
19 septembre 2026 - Bsides Montréal

Description

Introduction

Dans cet épisode, David Bizeul et Nicolas explorent l’interopérabilité entre composants de sécurité et présentent le projet Open XDR Architecture (OXA). La discussion met en lumière les défis de l’approche “best of breed” face à la plateformisation du marché de la cybersécurité, ainsi que les solutions innovantes pour favoriser l’interopérabilité.

L’approche best of breed et ses défis

David Bizeul se définit comme un fervent défenseur de l’approche best of breed, qui consiste à sélectionner la meilleure solution pour chaque problème spécifique en cybersécurité. Cette philosophie s’inscrit dans l’ADN de Sekoia, où l’ouverture et l’interopérabilité constituent des valeurs fondamentales. Cependant, cette approche se heurte à une réalité complexe : bien qu’un produit puisse être excellent dans son domaine, il ne représente qu’une lettre dans l’alphabet complet d’un workflow de cybersécurité.

Le principal défi réside dans la compétition avec les grandes plateformes intégrées. Ces acteurs, principalement américains, ont pu racheter la concurrence pour des centaines de millions ou des milliards de dollars, créant des offres complètes de A à Z. Face à cette concentration, les éditeurs spécialisés doivent trouver des moyens alternatifs de créer de la valeur pour leurs clients sans disposer des mêmes ressources financières.

Le projet Open XDR Architecture (OXA)

Pour répondre à ces enjeux, trois sociétés françaises - Sekoia, Arfanglab et Glims - ont collaboré pour créer OXA. Sekoia propose une plateforme SOC, Arfanglab une solution EDR, et Glims une solution d’analyse de malware. Ensemble, ils ont développé une architecture ouverte permettant de faire du XDR (Extended Detection and Response) en favorisant l’interopérabilité entre différentes solutions technologiques de qualité.

L’objectif d’OXA est de se positionner face aux acteurs plateformisants, non pas en suivant leur modèle d’acquisition agressive, mais en promouvant les standards, l’interopérabilité et des formats de données ouverts. Cette approche vise à faciliter les workflows entre différents composants de sécurité.

Les différentes couches d’OXA

Formats de données

La première couche concerne les formats de données générés et consommés par les différentes solutions. Historiquement, le marché souffrait d’une prolifération de formats propriétaires, rendant l’intégration extrêmement complexe. OXA s’appuie sur des standards existants comme OCSF (Open Cyber Security Framework), qui définit un cadre pour les différents types de produits et leurs champs de données pertinents. L’objectif n’est pas de réinventer la roue, mais de promouvoir ce qui existe déjà et fonctionne bien.

Spécifications d’API

La deuxième couche aborde l’automatisation et la communication entre produits. Contrairement aux formats de données, il n’existe pas sur le marché de spécification d’API standardisée pour la cybersécurité. Chaque éditeur développe ses propres API propriétaires pour communiquer avec les EDR, firewalls ou SIEM. OXA propose une spécification d’API définissant comment les composants de sécurité devraient interagir : comment suspendre un processus sur un EDR, comment ajouter une règle de détection dans un SIEM, etc.

Cette standardisation permet de gagner énormément de temps d’ingénierie. Au lieu de passer trois jours d’intégration pour chaque nouveau produit, multiplié par cent produits (soit 300 jours de travail), une API standardisée permettrait de minimiser drastiquement ces délais d’intégration, bénéficiant à l’ensemble de la communauté.

Distribution de Threat Intelligence

La troisième couche concerne la dissémination de la Threat Intelligence. L’idée est qu’un client ayant déjà payé pour une source de Threat Intelligence devrait pouvoir la distribuer à tous ses produits de sécurité, et non seulement à quelques-uns. Cela permet d’agir plus rapidement, plus près de la menace, en diffusant l’information directement aux équipements réseau ou endpoints avant même que les alertes n’arrivent au SIEM.

L’analogie médicale et la spécialisation

Nicolas établit une analogie pertinente avec la médecine pour illustrer l’évolution de la cybersécurité. Il y a 15 ans, le domaine était relativement limité et rudimentaire, comparable à la médecine générale d’il y a un siècle. Aujourd’hui, comme en médecine où personne n’accepterait qu’un généraliste pratique une neurochirurgie, la cybersécurité nécessite des spécialistes. La plateformisation ne fait plus sens dans un contexte où chaque domaine requiert une expertise pointue.

Cette spécialisation se reflète également au niveau des professionnels et des entreprises. Il est désormais impossible pour une personne de maîtriser tous les aspects de la cybersécurité, tout comme une entreprise ne peut exceller dans tous les domaines simultanément.

Vision future et Cyber Security Mesh Architecture

David Bizeul établit un parallèle intéressant entre OXA et le concept de Cyber Security Mesh Architecture (CSMA) proposé par Gartner. Le CSMA représente une vision du marché où la cybersécurité est pensée comme un ensemble de composants travaillant en chaîne. OXA constitue une manière d’opérationnaliser cette vision, offrant aux clients la possibilité de choisir les meilleurs produits pour leur contexte spécifique tout en garantissant leur interopérabilité.

Le projet intègre également un système de labels (bronze, silver, gold) permettant aux éditeurs de s’autodéclarer compatibles avec différents niveaux d’interopérabilité OXA. L’objectif est d’encourager les clients à favoriser l’interopérabilité plutôt que la plateformisation dans leurs appels d’offres et budgets.

Avantages pour l’innovation

Un aspect particulièrement intéressant d’OXA est son potentiel pour favoriser l’innovation. Une startup avec une simple preuve de concept peut se rendre compatible OXA et être rapidement intégrée dans des workflows matures de grands groupes. Par exemple, une startup développant une solution d’analyse de deepfakes pourrait être sollicitée dans un workflow de cybersécurité dès ses débuts, là où elle aurait dû attendre trois ans de maturation dans un modèle classique.

Pour les utilisateurs, cette approche offre également une résilience accrue : si un produit ne satisfait plus ou si l’éditeur fait faillite, il peut être facilement remplacé par un autre produit compatible OXA, sans disruption majeure du workflow.

Conclusion

Le projet OXA, disponible sur le repository GitHub d’Open Cyber Alliance, représente une approche innovante pour repenser l’interopérabilité en cybersécurité. En promouvant les standards ouverts et en facilitant la collaboration entre solutions spécialisées, OXA offre une alternative crédible à la plateformisation dominante, au bénéfice tant des éditeurs que des utilisateurs finaux.

Notes

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par Sekoia

Teknik - La guerre Red Team vs EDR - l’aspect technique et non business du problème (c'est la partie 2 BTW)

2026-01-07T00:00:00-05:00

Parce que… c’est l’épisode 0x692!

Shameless plug

25 et 26 février 2026 - SéQCure 2026
- CfP
31 mars au 2 avril 2026 - Forum INCYBER - Europe 2026
14 au 17 avril 2026 - Botconf 2026
28 et 29 avril 2026 - Cybereco Cyberconférence 2026
9 au 17 mai 2026 - NorthSec 2026
3 au 5 juin 2026 - SSTIC 2026
19 septembre 2026 - Bsides Montréal

Description

Introduction

Ce deuxième épisode du podcast technique avec Charles F. Hamilton explore en profondeur les techniques d’évasion des solutions EDR (Endpoint Detection and Response) et les stratégies que les red teamers peuvent utiliser pour contourner ces systèmes de détection. La discussion révèle que malgré les avancées technologiques, les EDR restent vulnérables à des techniques relativement simples lorsqu’on comprend leurs mécanismes de détection.

Les limites de la détection EDR

Corrélation réseau et named pipes

Un exemple concret illustre les faiblesses des EDR modernes : un exécutable malveillant qui communique avec internet tout en effectuant de la reconnaissance sur le réseau interne. Les EDR “top tier” détectent généralement cette activité anormale grâce au machine learning, identifiant qu’un processus communique simultanément vers l’extérieur et vers le réseau local via SMB, Kerberos ou d’autres protocoles.

La solution de contournement est élégante : utiliser les named pipes de Windows. Cette fonctionnalité native permet la communication inter-processus. En séparant les tâches entre deux processus indépendants - l’un gérant les communications externes, l’autre la reconnaissance interne - et en les faisant communiquer via named pipes, on brise complètement la chaîne de détection du machine learning. Cette technique, enseignée depuis 8 ans dans les formations red team, demeure efficace.

Des signatures déguisées

Paradoxalement, malgré leurs prétentions, les EDR fonctionnent encore largement sur des principes de signatures. La différence avec les antivirus traditionnels réside davantage dans où ils appliquent cette détection - non seulement sur le disque, mais aussi en mémoire et au niveau comportemental. Le compromis entre faux positifs et détection reste délicat : générer 1500 alertes par jour conduirait à l’“alert fatigue” et rendrait le système inutile.

Techniques d’obfuscation et d’évasion

La randomisation intelligente

Pour éviter la détection statique, l’obfuscation doit être réfléchie. Un piège courant : générer des variables aléatoires de longueur fixe (par exemple, toujours 16 caractères). Les règles Yara peuvent détecter ce pattern. La solution consiste à introduire de la randomness dans le random : utiliser des longueurs variables (entre 6 et 22 caractères) et concaténer plusieurs mots du dictionnaire plutôt que des chaînes purement aléatoires.

Nettoyage de la mémoire

L’obfuscation ne s’arrête pas à l’exécution. Même après déchiffrement en mémoire, des artefacts subsistent. Par exemple, Cobalt Strike laisse des patterns reconnaissables dans les premiers bytes du shellcode. La stratégie recommandée utilise plusieurs threads d’exécution : un pour déchiffrer et lancer le shellcode, un autre pour nettoyer la mémoire des variables intermédiaires. Bien que les EDR ne scannent pas la mémoire en continu (ce serait trop coûteux en performance), ces artefacts restent détectables.

Protection au niveau kernel

Protected Process Light (PPL)

Microsoft a introduit les PPL pour protéger les processus critiques comme LSASS. Même avec des privilèges système, un attaquant ne peut accéder à ces processus. Le problème : le kernel reste le point de confiance ultime. Une fois qu’un attaquant obtient l’exécution de code au niveau kernel - via des drivers vulnérables par exemple - toutes les protections PPL tombent.

Techniques d’anti-tampering

La technique “EDR Freeze” illustre cette réalité : en utilisant ProcDump (un outil Windows légitime), on peut créer un dump mémoire d’un processus EDR, ce qui le met en pause. En arrêtant ensuite ProcDump avant qu’il ne termine, le processus EDR reste indéfiniment en pause, sans générer d’alerte de tampering puisqu’il n’a pas été modifié.

Cloud et nouvelles vulnérabilités

Le passage au cloud déplace simplement les problèmes. Les attaques traditionnelles visaient le “domain admin” en local ; aujourd’hui, avec l’authentification multifacteur, les attaquants utilisent le device code phishing ou des applications tierces malveillantes pour obtenir des tokens OAuth valides. Une fois ces tokens obtenus, l’escalade vers “global admin” devient possible.

La difficulté : aucun EDR ne peut surveiller ces attaques puisqu’elles se déroulent depuis la machine de l’attaquant. La seule visibilité provient de ce que Microsoft accepte de partager, souvent derrière des paywalls supplémentaires. Les entreprises ont passé 20 ans à maîtriser Active Directory et les outils de sécurité on-premise, mais repartent de zéro dans le cloud avec des outils immatures.

Recommandations défensives

Configurations simples mais efficaces

Plusieurs mesures basiques restent sous-utilisées :

Bloquer PowerShell pour les utilisateurs non techniques
Désactiver la fonction Run (Windows+R) pour 99% des utilisateurs
Supprimer MSHTA.exe via GPO (aucun besoin légitime des fichiers HTA)
Restreindre les scripts Office par défaut

Ces mesures élimineraient la majorité des attaques “commodity malware” qui fonctionnent uniquement parce que les entreprises n’ont pas fermé ces vecteurs d’accès basiques.

Le facteur humain irremplaçable

Les EDR excellent contre le malware de masse mais peinent face aux attaques ciblées. L’IA et les agents ne remplaceront pas les analystes humains capables de :

Faire du threat hunting actif
Contextualiser les alertes (pourquoi un utilisateur non technique lancerait-il PowerShell ?)
Détecter les anomalies dans le trafic réseau (nouveaux domaines, patterns de requêtes POST répétitives)
Raconter l’histoire complète d’une intrusion en corrélant les événements

Détection réseau

Les NDR/XDR commencent à combler cette lacune, mais restent embryonnaires. La détection réseau devrait identifier :

Les nouveaux domaines jamais vus auparavant
Les patterns de communication C2 (requêtes POST régulières avec jitter)
Les anomalies d’authentification
Le trafic inhabituel pour un profil utilisateur donné

Conclusion

La sophistication des attaquants reste limitée car ils n’en ont pas encore besoin - trop d’environnements demeurent mal configurés. Les entreprises investissent massivement dans les EDR mais négligent les configurations de base et le facteur humain. L’histoire se répète avec le cloud et l’IA : plutôt que de résoudre les problèmes fondamentaux, on déplace la responsabilité vers de nouveaux outils. La vraie sécurité nécessite une compréhension technique approfondie, des configurations rigoureuses, et surtout, des analystes compétents pour interpréter les signaux et raconter l’histoire des incidents.

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - CTI part 2 - tumble down the rabbit hole

2026-01-06T00:00:00-05:00

Parce que… c’est l’épisode 0x6xx!

Shameless plug

25 et 26 février 2026 - SéQCure 2026
- CfP
31 mars au 2 avril 2026 - Forum INCYBER - Europe 2026
14 au 17 avril 2026 - Botconf 2026
28 et 29 avril 2026 - Cybereco Cyberconférence 2026
9 au 17 mai 2026 - NorthSec 2026
3 au 5 juin 2026 - SSTIC 2026
19 septembre 2026 - Bsides Montréal

Description

Introduction

Ce deuxième épisode sur la Cyber Threat Intelligence (CTI) réunit Nicolas, Alexis Dorais-Joncas et Jordan Theodore pour approfondir les mécanismes de production et de consommation de l’intelligence sur les menaces. La conversation explore les défis techniques, organisationnels et éthiques auxquels font face les professionnels de la sécurité dans ce domaine en constante évolution.

Les deux univers de la CTI

Alexis établit une distinction fondamentale entre deux « clusters » dans l’écosystème de la CTI. D’un côté, les producteurs : entreprises de réponse d’incident et fournisseurs de services de cybersécurité comme CrowdStrike, Microsoft, Kaspersky ou Proofpoint, qui observent directement les attaques chez leurs clients et génèrent des rapports détaillés. De l’autre, les consommateurs : organisations qui utilisent ces rapports pour comprendre leurs risques et se protéger contre les attaques potentielles.

Cette dichotomie se reflète même dans les rôles professionnels. Un analyste CTI chez un vendeur dispose d’une visibilité globale sur des milliers de clients, tandis qu’un analyste en entreprise se concentre sur son propre environnement. Les mindsets et les résultats sont fondamentalement différents, bien que les compétences de base soient similaires.

L’ampleur du défi : naviguer dans l’océan de données

Les chiffres partagés par Alexis illustrent l’échelle impressionnante du problème. Chez ESET, environ 300 000 fichiers exécutables malveillants ou suspects uniques arrivent chaque jour. Chez Proofpoint, ce sont 3,5 milliards d’emails quotidiens, avec 50 millions de pièces jointes et 90 millions d’URL à analyser. Face à ce déluge, les équipes de recherche doivent développer des heuristiques sophistiquées et des règles de tri pour identifier ce qui mérite une attention particulière.

L’art du clustering : trouver l’aiguille dans la botte de foin

Le cœur du travail de CTI réside dans la capacité à regrouper des attaques apparemment distinctes en « clusters » attribuables à un même acteur. Alexis explique que cette attribution repose sur la recherche d’éléments uniques ou de combinaisons uniques d’éléments observables. L’exemple du certificat SSL avec une coquille typographique illustre parfaitement ce concept : un seul détail peut permettre de lier des dizaines de domaines entre eux et de découvrir toute une infrastructure d’attaque.

Les indicateurs utilisés pour le clustering sont multiples : similarité de code source, exploits modifiés, choix d’hébergeurs et de registraires, mais aussi des éléments plus « soft » comme le ciblage. Un professeur spécialisé sur l’Iran qui se fait soudainement cibler peut indiquer l’implication de groupes iraniens, même si les indicateurs techniques sont nouveaux.

Les niveaux de confidentialité : une cascade d’information

Alexis révèle que 95% ou plus de la CTI produite par les vendeurs n’est jamais rendue publique. L’information suit une cascade : d’abord partagée uniquement avec les clients directement ciblés, puis avec l’ensemble des clients payants, et enfin, pour une fraction seulement, avec le public. Cette dernière étape implique des choix délicats : révéler certains indicateurs peut aider la défense, mais aussi alerter l’attaquant et compromettre la capacité à le tracker à l’avenir.

La qualité variable de la CTI secondaire

Un point de frustration majeur émerge concernant la couverture médiatique et les analyses secondaires. Alexis estime que 80% de la couverture secondaire n’apporte aucune valeur ajoutée, 5% apporte une vraie perspective informée, et 10-15% est carrément nuisible en véhiculant des erreurs ou des exagérations. Cette désinformation force les analystes en entreprise à perdre des journées entières à remonter aux sources originales et à désamorcer les inquiétudes injustifiées des dirigeants.

La course à la publication et ses nuances

Bien qu’il existe une certaine compétition entre vendeurs pour être le premier à publier sur une nouvelle menace, Alexis nuance fortement ce phénomène. La collaboration informelle entre analystes de différentes entreprises est courante. De plus, même si un concurrent publie en premier, il reste possible d’apporter une valeur complémentaire en confirmant les découvertes depuis une perspective différente ou en ajoutant des observations uniques. L’exemple de Kaspersky et Proofpoint sur un APT illustre comment deux entreprises peuvent enrichir mutuellement la compréhension d’une menace.

L’attribution : utile pour qui ?

L’attribution géopolitique des attaques s’avère principalement pertinente pour les grandes organisations et les entités gouvernementales ciblées de manière spécifique. Pour la majorité des entreprises victimes d’attaques opportunistes, savoir qu’un ransomware vient de tel ou tel groupe importe peu. L’essentiel est de comprendre les techniques d’attaque et les prochaines étapes possibles. Alexis souligne qu’environ 95% des attaques ciblées chez Proofpoint touchent moins de 5 clients avec moins de 60 emails – un volume extrêmement faible qui contraste avec les attaques opportunistes massives.

Le casse-tête des noms de groupes

Un problème persistant dans l’industrie concerne la prolifération de noms différents pour les mêmes groupes. APT28 peut être appelé Fancy Bear, Pawn Storm, TA422, ou une quinzaine d’autres noms selon le vendeur. Cette situation s’explique par les différences de visibilité : Proofpoint observe l’infrastructure email, tandis qu’un EDR voit le comportement post-compromission. Chaque vendeur nomme ce qu’il peut observer, créant une confusion considérable pour les praticiens en réponse d’incident.

Alexis confirme cependant qu’aucune pression marketing n’a jamais été exercée pour créer des noms propriétaires, et qu’il est inacceptable de renommer un groupe découvert par un autre sans l’avoir observé soi-même.

Conclusion

Ce podcast met en lumière la complexité et les nuances du monde de la CTI. Entre volumes de données massifs, décisions éthiques sur ce qu’il faut publier, collaboration et compétition entre acteurs, et défis d’attribution, les professionnels naviguent dans un écosystème en constante évolution. La clé réside dans la compréhension que chaque vendeur apporte une perspective unique basée sur sa visibilité spécifique, et que la véritable valeur de la CTI se trouve dans la capacité à corréler ces différentes sources pour obtenir une image complète des menaces.

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - SOC souverain

2025-12-18T00:00:00-05:00

Parce que… c’est l’épisode 0x682!

Shameless plug

25 et 26 février 2026 - SéQCure 2026
- CfP
31 mars au 2 avril 2026 - Forum INCYBER - Europe 2026
14 au 17 avril 2026 - Botconf 2026
28 et 29 avril 2026 - Cybereco Cyberconférence 2026
9 au 17 mai 2026 - NorthSec 2026
3 au 5 juin 2026 - SSTIC 2026
19 septembre 2026 - Bsides Montréal

Description

Présentation et parcours de David Bizeul

David Bizeul, directeur scientifique et cofondateur de Sekoia, possède une expérience significative dans le domaine de la cybersécurité, notamment dans les activités liées aux CERT (Computer Emergency Response Team). Il a construit le CERT de la Société Générale dans les années 2000-2005, période marquée par l’émergence de la cybercriminalité. Durant six années, son équipe a développé des capacités de compréhension de la menace et de traitement des incidents touchant la banque et ses clients. Par la suite, il a dirigé le CERT d’Airbus Cybersécurité, où les enjeux différaient, se concentrant davantage sur l’espionnage industriel plutôt que sur la cybercriminalité.

Ces deux expériences lui ont permis de constater l’importance cruciale de la threat intelligence (renseignement sur les menaces) dans les contextes tant de cybercriminalité que d’espionnage. Cette prise de conscience l’a conduit à fonder Sekoia en 2015, avec l’objectif de cartographier et modéliser précisément les attaquants pour ensuite opérationnaliser cette connaissance et en faire un produit de cybersécurité.

Le concept de souveraineté numérique

Pour David Bizeul, la souveraineté représente la capacité de construire, utiliser et protéger une capacité ou un environnement. Appliquée au numérique, elle concerne la maîtrise des produits, logiciels et services permettant d’accomplir des activités numériques. Un produit de sécurité moderne peut être visualisé comme un mille-feuille composé de différentes couches : composants matériels, hardware, infrastructure, couches logicielles, opérations utilisateurs, et données générées.

La maîtrise complète de toutes ces couches n’est pas accessible à tous les pays. Certaines contraintes, comme l’accès aux matières premières pour les composants électroniques, limitent la capacité de contrôle complet. L’approche pragmatique consiste donc à exceller sur certaines couches spécifiques : les données, les opérations, la technologie et les infrastructures cloud restent maîtrisables au niveau européen, tandis que les couches matérielles plus basses posent davantage de défis. Pour ces dernières, il faut accepter de déléguer le risque à des acteurs de confiance et utiliser les couches supérieures pour détecter d’éventuelles anomalies.

L’approche de Sekoia : une plateforme SOC souveraine

Sekoia propose une plateforme SOC (Security Operations Center) complète permettant d’opérationnaliser les fonctions de centre d’opérations de sécurité. La plateforme s’adresse aux grands comptes disposant de leurs propres équipes, ainsi qu’aux MSSP (Managed Security Service Providers) qui délivrent ces services pour diverses entreprises.

La plateforme intègre plusieurs composants essentiels. Le SIEM constitue le premier bloc, assurant l’ingestion de données, la normalisation, l’application de règles de détection, l’indexation et le stockage long terme. L’environnement de threat intelligence, développé en interne par une équipe dédiée de chercheurs, met les données clients en relation avec une cartographie exhaustive des menaces. Cette base de connaissance propriétaire permet une détection de haute qualité basée sur la compréhension approfondie des attaquants.

Le moteur SOAR (Security Orchestration, Automation and Response) complète l’arsenal, gérant les plans de réponse aux incidents. Il définit les actions appropriées lors du déclenchement d’alertes, avec des playbooks automatisés adaptés à différents scénarios. La philosophie de Sekoia repose sur l’équilibre entre contenu packagé prêt à l’emploi et personnalisation client, permettant un déploiement SOC opérationnel très rapide tout en autorisant l’ajout de règles spécifiques à chaque environnement.

Régionalisation et choix technologiques

Sekoia a adopté une approche cloud native tout en maintenant une conscience aiguë des enjeux géographiques. Bien que basée dans le cloud, chaque instance possède une localisation géographique réelle. La région historique a été établie sur OVH en France, suivie de l’ouverture de cinq régions mondiales permettant une cohérence technologique adaptée à chaque géographie.

Cette stratégie de régionalisation implique des choix de sous-traitants différenciés selon les zones. Par exemple, les solutions de stockage ou certains partenaires techniques varient entre les régions française et américaine. Les acteurs MSSP européens privilégient naturellement les régions cloud européennes, tandis que leurs homologues américains préfèrent les infrastructures américaines. Cette approche garantit la data residency localisée, optimise les latences et répond aux exigences croissantes des clients en matière de souveraineté.

Transparence et évolution du marché

L’évolution géopolitique récente, particulièrement les douze derniers mois marqués par les décisions du gouvernement américain, a profondément transformé les attentes clients. Sekoia constate une augmentation significative des demandes concernant la localisation des données et la nationalité des sous-traitants. Les clients souhaitent désormais “lever le capot” pour comprendre et maîtriser leurs workflows de cybersécurité, s’appropriant ainsi les zones de risque.

Pour répondre à cette demande de transparence, Sekoia maintient une plateforme trust.Sekoia.io recensant tous les engagements de confiance, la gestion des données personnelles et la liste complète des sous-traitants par région. Cette transparence totale reflète la philosophie de l’entreprise : ouverture, transparence et interopérabilité maximales.

Défis et opportunités de la souveraineté

David Bizeul souligne le réveil brutal mais nécessaire face à la naïveté économique des deux dernières décennies. La prise de conscience collective permet désormais d’optimiser les approches sur tous les blocs géographiques, chacun cherchant à ne pas dépendre exclusivement de la vision du monde américaine. Contrairement aux acteurs américains pensant naturellement global avec une approche standardisée, Sekoia part du principe de respecter les spécificités locales tout en conquérant le marché mondial.

Cette approche, bien que plus coûteuse et complexe, s’impose par nécessité et conviction. Les partenaires MSSP, ancrés localement, fournissent des retours précieux sur les exigences réglementaires et culturelles spécifiques à chaque territoire. Sekoia intègre ces feedbacks pour faire évoluer son produit, soit globalement lorsque les exigences sont généralisables, soit spécifiquement pour répondre à des besoins particuliers.

L’entreprise va encore plus loin avec des initiatives comme la région SecNumCloud sur OVH pour les clients les plus critiques, ou le partenariat avec Thales pour une région dédiée aux activités sensibles de défense, démontrant ainsi comment conjuguer excellence technique et souveraineté maîtrisée.

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par Sekoia

Teknik - Agentic Access - Auth Gets You In. Zero Trust Keeps You Safe

2025-12-11T00:00:00-05:00

Parce que… c’est l’épisode 0x678!

Shameless plug

25 et 26 février 2026 - SéQCure 2026
- CfP
31 mars au 2 avril 2026 - Forum INCYBER - Europe 2026
14 au 17 avril 2026 - Botconf 2026
28 et 29 avril 2026 - Cybereco Cyberconférence 2026
9 au 17 mai 2026 - NorthSec 2026
3 au 5 juin 2026 - SSTIC 2026
19 septembre 2026 - Bsides Montréal

Description

Introduction

Nick Taylor, développeur advocate chez Pomerium à Montréal, a présenté une approche innovante pour sécuriser les serveurs MCP (Model Context Protocol) en utilisant les principes du Zero Trust et des identity-aware proxy. Développeur depuis longtemps et passionné par la construction d’outils, Nick apporte son expertise en sécurité et infrastructure pour répondre aux défis émergents de l’IA agentique.

Le Model Context Protocol (MCP)

Le MCP est un protocole récent créé par Anthropic en 2024 qui permet d’étendre les capacités des grands modèles de langage (LLM) en leur donnant accès à des outils externes. Comme l’explique Nick, pour ceux qui ont déjà travaillé avec des systèmes agentiques, le concept des “tool calls” sera familier : il s’agit d’outils que le LLM peut appeler pour enrichir son contexte et accomplir certaines tâches.

L’exemple classique est celui de la météo : un LLM ne sait pas quel temps il fait aujourd’hui dans une région donnée. En appelant un outil météo, il peut obtenir cette information et fournir une réponse pertinente, comme “il fait 12 degrés Celsius à Montréal, mets ton manteau”. Sans cet outil, le LLM pourrait suggérer d’aller à la plage en maillot de bain, ce qui serait complètement inapproprié.

Un serveur MCP est essentiellement une collection d’outils regroupés logiquement. Par exemple, le serveur MCP GitHub contient plusieurs outils pour interagir avec GitHub : créer un dépôt, créer une issue, ouvrir une pull request, etc. Nick compare MCP à “l’USB-C pour les outils en IA”, une analogie qu’il utilise avec précaution, anticipant l’évolution future du protocole.

Les défis de sécurité

Bien que MCP existe depuis moins d’un an, il connaît déjà une forte adoption, mais cette rapidité s’accompagne de préoccupations sérieuses en matière de sécurité. Le protocole et son écosystème sont encore en phase de maturation, et on observe un manque de réflexion sur la sécurité dans de nombreuses implémentations.

Nick souligne un problème fondamental : le LLM ne comprend pas vraiment ce qui est “bon” ou “mauvais” en termes d’actions. Son rôle est simplement d’essayer d’exécuter les instructions qu’on lui donne. Si on lui demande de faire quelque chose, il tentera de le faire sans considération pour les conséquences. C’est pourquoi il est crucial de mettre en place des garde-fous (guard rails).

Un cas d’usage préoccupant mentionné dans la discussion est celui où un MCP connecté à GitHub avec des permissions trop larges pourrait, sans contrôle approprié, effectuer des actions destructrices. Dans un cas extrême, un LLM pourrait même supprimer une base de données de production simplement parce qu’il suit les directives sans comprendre la gravité de l’action. Ce risque est d’autant plus sérieux que les développeurs, dans leur enthousiasme à construire des applications innovantes, ont tendance à négliger la sécurité au profit de la rapidité de développement.

Le Zero Trust et l’identity-aware proxy

Pour répondre à ces défis, Nick introduit le concept de Zero Trust, un modèle de sécurité développé par Google suite à une importante violation de données dans les années 2010. Le principe fondamental du Zero Trust, comme son nom l’indique, est de ne jamais faire confiance à personne et de toujours vérifier l’identité et le contexte.

Traditionnellement, les entreprises utilisent des VPN pour sécuriser l’accès aux ressources internes. Cependant, une fois connecté au VPN, un utilisateur a souvent accès à l’ensemble du réseau interne, même s’il ne peut pas se connecter à certaines ressources spécifiques. Le modèle Zero Trust fonctionne différemment en utilisant un identity-aware proxy (IAP).

Un IAP combine trois éléments essentiels : un fournisseur d’identité (IDP) comme Google, GitHub ou Okta, un moteur de politiques, et un reverse proxy. Lorsqu’un utilisateur tente d’accéder à une ressource, le système vérifie non seulement son identité mais aussi son contexte. Par exemple, même si Nicolas est authentifié, s’il essaie d’accéder à l’environnement de production alors qu’il n’est pas de garde (on-call), les politiques bloqueront l’accès.

Une caractéristique unique de cette approche est que toutes les URL pour accéder aux ressources internes sont publiques, mais protégées par l’authentification et les politiques. Si une seule condition n’est pas remplie, le proxy n’entre jamais en jeu et l’accès est refusé. Cela diffère fondamentalement du VPN où, une fois connecté, on a un accès réseau même si on ne peut pas se connecter à certaines applications.

L’application de l’IAP aux serveurs MCP

Pomerium a développé un support de première classe pour les serveurs MCP, reconnaissant qu’ils fonctionnent sur la couche 7 du modèle OSI (HTTP), tout comme les applications web traditionnelles que l’entreprise sécurise depuis longtemps. Cette solution, entièrement open source, offre plusieurs avantages significatifs.

Premièrement, l’expérience développeur (DX) est considérablement améliorée. Nick demande avec humour : “Qui aime implémenter OAuth ?” La réponse est généralement négative. Avec l’IAP de Pomerium, tout le flux d’authentification OAuth est géré automatiquement. Le serveur MCP lui-même n’a aucune connaissance d’OAuth - il reste dans l’infrastructure interne, protégé par le proxy. Les développeurs peuvent donc se concentrer sur la construction de fonctionnalités sans se soucier de l’implémentation de la sécurité.

Deuxièmement, pour les services externes comme GitHub ou Google Calendar, bien qu’il soit toujours nécessaire de créer une application OAuth, la configuration est simplifiée. Il suffit d’ajouter une configuration OAuth dans la route de l’application, incluant le secret, l’ID, les URL et les scopes nécessaires. Pomerium gère ensuite automatiquement tout le flux d’authentification.

Gestion sécurisée des tokens

Un aspect crucial de la sécurité concerne la gestion des tokens d’authentification. Normalement, lorsqu’un utilisateur autorise l’accès à un service comme GitHub, le token retourné est envoyé au client MCP. Cela pose un problème de sécurité car ce token représente “les clés du royaume” - si quelqu’un s’en empare, il peut faire n’importe quoi avec les permissions associées.

La solution de Pomerium est élégante : le token provenant de GitHub ou Google ne quitte jamais l’IAP. Il reste dans la gateway où il est stocké de manière sécurisée, associé à l’utilisateur. Ce qui est retourné au client MCP est un token Pomerium à courte durée de vie. Même si ce token venait à être compromis, il expirerait rapidement, minimisant les risques.

De plus, Pomerium évite le “token pass-through”, où le token du fournisseur d’identité serait envoyé directement au serveur MCP. Au lieu de cela, un token Pomerium contenant uniquement des claims (qui vous êtes, mais pas ce que vous pouvez faire) est utilisé, respectant le principe du moindre privilège.

Contrôle granulaire des permissions

L’un des avantages les plus puissants de cette approche est la capacité à restreindre finement les actions possibles, même dans les limites des scopes OAuth existants. Par exemple, GitHub nécessite le scope “repo” pour créer des dépôts, mais ce même scope donne également la permission de supprimer des dépôts. Dans un contexte humain normal, on est conscient de ce qu’on fait lorsqu’on supprime un dépôt - on doit confirmer, copier-coller le nom du dépôt, etc. Mais dans un contexte agentique, le LLM pourrait supprimer un dépôt sans cette conscience.

Avec le moteur de politiques de Pomerium, on peut dire : “l’outil MCP de suppression de dépôt n’est permis pour personne” ou le restreindre à des utilisateurs ou groupes spécifiques. Lorsqu’un LLM tente d’appeler cet outil, la requête passe par l’IAP qui vérifie les politiques à chaque fois - ce n’est pas une vérification unique au moment de la connexion, mais une vérification continue pour chaque requête.

Si la politique bloque l’action, la requête n’atteint jamais le serveur MCP et une erreur appropriée est retournée. Cette approche crée un garde-fou rigide et impossible à contourner, protégeant contre les comportements imprévisibles des LLM tout en maintenant un haut niveau de fonctionnalité pour les cas d’usage autorisés.

Audit et conformité

Un autre avantage crucial de faire transiter toutes les requêtes par le proxy est la capacité d’audit intégrée. L’IAP enregistre automatiquement toutes les activités : qui s’est connecté, quels outils ont été appelés, pourquoi un accès a été refusé (utilisateur pas dans le bon groupe, politique non satisfaite, etc.).

Pour un développeur solo, cet aspect peut sembler moins critique, mais pour les organisations, c’est essentiel. La capacité de retracer toutes les actions et de comprendre pourquoi certaines décisions ont été prises est un élément fondamental de la conformité et de la sécurité d’entreprise. Sans ces capacités d’audit, de nombreuses organisations ne pourraient tout simplement pas adopter la technologie.

Conclusion et encouragements

Nick termine en encourageant les développeurs à ne pas se sentir “en retard” dans le domaine de l’IA agentique. Même si certains ont commencé il y a un, deux ou trois ans, le domaine est tellement nouveau que tout le monde peut encore se lancer. L’important est d’expérimenter avec ces technologies tout en intégrant la sécurité dès le premier jour, plutôt que comme une réflexion après coup.

Il reconnaît que le coût peut être une préoccupation, mais note que de nombreux outils offrent des niveaux gratuits, et que pour les versions payantes (comme Claude ou ChatGPT à 20 dollars par mois), le temps gagné justifie largement l’investissement. De plus, de nombreux employeurs sont maintenant favorables à l’utilisation de ces outils et peuvent en couvrir les coûts.

Tout le code et les solutions dont Nick a parlé sont open source et disponibles, y compris un template TypeScript pour créer des serveurs MCP qui utilise le SDK officiel MCP, Vite et d’autres outils modernes. L’invitation est claire : il faut expérimenter, apprendre et construire, mais en le faisant de manière sécurisée dès le départ. Avec des outils comme Pomerium, la friction pour implémenter une sécurité robuste est considérablement réduite, permettant aux développeurs de se concentrer sur l’innovation tout en maintenant les standards de sécurité nécessaires pour un déploiement en production.

Notes

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Don't Go with the flaw

2025-12-10T00:00:00-05:00

Parce que… c’est l’épisode 0x677!

Shameless plug

25 et 26 février 2026 - SéQCure 2026
- CfP
31 mars au 2 avril 2026 - Forum INCYBER - Europe 2026
14 au 17 avril 2026 - Botconf 2026
28 et 29 avril 2026 - Cybereco Cyberconférence 2026
9 au 17 mai 2026 - NorthSec 2026
3 au 5 juin 2026 - SSTIC 2026
19 septembre 2026 - Bsides Montréal

Description

Ce podcast accueille Garance de la Brosse, chercheuse en cybersécurité chez Boost Security, qui présente ses travaux sur les vulnérabilités dans la chaîne d’approvisionnement logiciel de l’écosystème Go. Après un an de travail avec Boost Security, notamment sur la détection de malwares en Java et l’écriture de règles de détection statique, Garance a mené une recherche approfondie sur les vecteurs d’attaque possibles lors de la phase de distribution des packages open source dans Go.

Contexte et méthodologie de la recherche

La recherche s’inscrit dans le cadre plus large du cycle de vie complet d’un package, tel que défini par le schéma Salsa, qui couvre quatre phases principales : la source (développement), le build (construction), la distribution (hébergement et téléchargement) et la consommation (utilisation finale). Boost Security possédait déjà une expertise sur les vulnérabilités des pipelines CI/CD, mais cette nouvelle recherche visait spécifiquement la phase de distribution, un domaine moins exploré.

L’équipe a commencé par un état de l’art exhaustif des attaques sur la chaîne d’approvisionnement logiciel depuis fin 2024, analysant les techniques utilisées et les points d’entrée exploités. Cette analyse a révélé un manque d’études spécifiques sur Go, un écosystème conçu en 2007 avec la sécurité comme priorité, mais qui n’est pas exempt de vulnérabilités. Pour approfondir leur analyse, les chercheurs ont développé un outil permettant de télécharger l’intégralité de l’index du GoProxy, créant une base de données SQLite de 10 Go contenant les métadonnées de tous les packages publiés depuis 2019.

Particularités de l’écosystème Go

L’écosystème Go se distingue fondamentalement des autres systèmes comme npm ou PyPI par son architecture décentralisée. N’importe quel serveur web peut héberger un package Go, sans nécessiter de compte centralisé. Cependant, Go introduit un cache central appelé GoProxy qui garantit l’immutabilité des packages : une fois qu’une version est mise en cache, elle ne peut plus être modifiée, assurant ainsi une stabilité et une cohérence importantes.

Cette immutabilité est renforcée par une check database qui stocke les hash cryptographiques de tous les packages, permettant de vérifier l’intégrité lors du téléchargement. Ce système suit un principe de « trust on first use » : dès qu’un package est téléchargé une première fois, tous les utilisateurs suivants obtiennent exactement la même version. Toutefois, cette architecture présente une faiblesse majeure : l’immutabilité ne garantit pas la confiance. Un package malveillant peut être mis en cache et devenir immutable, restant disponible indéfiniment.

Vulnérabilités découvertes : le Repo Jacking

La recherche révèle que l’écosystème Go est vulnérable aux mêmes attaques de social engineering que les autres écosystèmes, notamment le typosquatting. Plus préoccupant encore, la nature décentralisée de Go introduit des risques spécifiques liés à la gestion des identités. Les packages Go étant identifiés par leur chemin d’accès (par exemple, github.com/utilisateur/package), la sécurité dépend entièrement du registre source utilisé.

L’analyse a révélé une vulnérabilité majeure appelée Repo Jacking : lorsqu’un développeur change son nom d’utilisateur GitHub ou supprime son compte, son nom devient disponible pour n’importe qui. Un attaquant peut alors créer un compte avec ce nom, publier un package identique avec une version supérieure, et le faire cacher dans le GoProxy. Les utilisateurs mettant à jour leurs dépendances téléchargeront alors du code potentiellement malveillant sans s’en rendre compte.

Les statistiques sont alarmantes : sur 80% des packages Go hébergés sur GitHub, près de 35 000 packages stockés dans le GoProxy ont des comptes GitHub supprimés ou renommés, les rendant vulnérables au Repo Jacking. Parmi ceux-ci, 54 packages ont un score de criticité supérieur à 0,2 (indiquant une utilisation importante), et 9 500 packages sont importés dans au moins un autre projet open source, avec certains packages importés jusqu’à 600 fois. Cette vulnérabilité a même affecté des projets populaires listés dans la collection « Awesome Go Package ».

Autres vecteurs d’attaque identifiés

Au-delà du Repo Jacking, la recherche a identifié plusieurs autres vulnérabilités. Les noms de domaine expirés constituent un risque majeur : le domaine gopkg.in, utilisé par des projets critiques comme Kubernetes, est détenu par un individu privé travaillant pour Canonical. Si ce domaine expire et est racheté par un attaquant, les conséquences pourraient être catastrophiques.

Les pseudo-versions représentent également un vecteur d’attaque sophistiqué. Go permet d’importer du code non officiellement releasé via un hash de commit. Un attaquant peut publier un commit malveillant, le mettre en cache dans le GoProxy, puis le supprimer du registre source. Le code malveillant reste accessible via le GoProxy sans que personne ne puisse inspecter le code source d’origine. Cette technique a été utilisée dans l’attaque BoltDB, où l’attaquant a publié une version malveillante dans le GoProxy tout en maintenant un code légitime visible sur GitHub.

La directive « go replace » dans les fichiers go.mod peut également être exploitée pour camoufler des attaques. Cette directive, légitime pour appliquer des patches locaux, peut être modifiée subtilement dans une contribution open source pour remplacer une dépendance par une version malveillante avec une différence d’un seul caractère (par exemple, Nicolas vs Nicolo). Une fois dans une dépendance transitive, cette modification devient pratiquement indétectable.

L’attaque la plus sophistiquée combine plusieurs techniques : en exploitant un écart temporel entre la validation d’une pull request et son exécution par un bot CI/CD, un attaquant peut modifier le code après validation. Le bot copie alors du code malveillant dans une branche du repository légitime, et ce commit malveillant peut être caché dans le GoProxy avec une pseudo-version portant le nom du package légitime.

Solutions et outils développés

Pour permettre aux développeurs de vérifier leurs dépendances, l’équipe a créé Goblin, un outil open source qui construit le SBOM (Software Bill of Materials) d’un projet Go et vérifie si les comptes GitHub associés aux dépendances sont encore enregistrés. L’outil indique quelles dépendances directes et transitives sont vulnérables au Repo Jacking. Bien qu’utile pour la défense, cet outil peut également être utilisé par des attaquants pour identifier des cibles.

Conclusion

Cette recherche démontre que malgré son design sécurisé, l’écosystème Go n’est pas exempt de vulnérabilités. L’immutabilité du GoProxy, présentée comme un avantage pour la stabilité, devient paradoxalement une faiblesse lorsque du code malveillant est caché, car il reste accessible indéfiniment. Les développeurs doivent rester vigilants, particulièrement lors des mises à jour de dépendances. Garance conclut en précisant que Go reste néanmoins mieux conçu que npm ou PyPI en termes de sécurité, et elle cherche actuellement un emploi à temps plein en France ou en Europe dans le domaine de la cybersécurité.

Notes

Don’t Go with the flaw

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Threat Hunting in KQL 101

2025-12-03T00:00:00-05:00

Parce que… c’est l’épisode 0x673!

Shameless plug

25 et 26 février 2026 - SéQCure 2026
- CfP
31 mars au 2 avril 2026 - Forum INCYBER - Europe 2026
14 au 17 avril 2026 - Botconf 2026
28 et 29 avril 2026 - Cybereco Cyberconférence 2026
9 au 17 mai 2026 - NorthSec 2026
3 au 5 juin 2026 - SSTIC 2026
19 septembre 2026 - Bsides Montréal

Description

Introduction

Dans cet épisode technique du podcast, Yoan Schinck, directeur de la pratique de cyber réponse chez KPMG Canada, partage son expertise sur le threat hunting utilisant le Kusto Query Language (KQL). Fort de 12 ans d’expérience en technologies de l’information, dont 6 ans chez KPMG et la moitié en cybersécurité, Schinck se spécialise dans la réponse aux incidents, particulièrement les ransomwares et les compromissions de courriels d’affaires (business email compromise).

Le workshop de threat hunting

Lors de l’événement DeathC, dédié au detection engineering et au threat hunting, Schinck a conçu un workshop intitulé “Threat hunting en KQL 101”. Ce workshop vise à démontrer comment effectuer du threat hunting dans l’environnement Microsoft Sentinel en utilisant le KQL, le langage de requête pour explorer les données dans l’univers Microsoft. L’accent est mis particulièrement sur la télémétrie de Microsoft Defender for Endpoint, un choix stratégique reflétant la réalité du terrain où les organisations utilisant Sentinel travaillent généralement avec la suite de produits Microsoft Defender.

Infrastructure et méthodologie

Pour créer un environnement d’apprentissage réaliste, Schinck a mis en place une infrastructure comprenant deux machines virtuelles : un client Windows et un serveur Windows. Sur ces machines, il a exécuté une attaque complète simulée, couvrant toutes les étapes depuis l’accès initial jusqu’à l’exfiltration de données. Cette approche synthétique permet aux participants d’explorer des artefacts d’attaque authentiques dans un environnement contrôlé.

L’infrastructure incluait également des politiques d’audit avancées Windows pour capturer des événements spécifiques dans le Security Event Log, notamment pour les processus, la gestion des utilisateurs et la création de comptes. Un déploiement de Sysmon avec une configuration étendue complétait le dispositif de collecte de données. Tous ces événements étaient ensuite envoyés vers Microsoft Sentinel, créant ainsi un environnement réaliste de threat hunting.

Les organisateurs de DeathC ont fourni l’infrastructure on-premise, incluant le contrôleur de domaine, l’Active Directory, le Windows Event Collector et la configuration des Group Policies pour le transfert des événements Windows. Schinck s’est chargé de créer les deux machines virtuelles localement, de les joindre au domaine et d’installer Microsoft Defender for Endpoint avant d’exécuter son scénario d’attaque.

Contenu pédagogique du workshop

Le workshop est structuré en quatre catégories principales de threat hunting. La première se concentre sur les vecteurs d’accès initial, explorant différentes techniques pour identifier comment un accès a été obtenu. La deuxième catégorie examine les services Windows, analysant leur création, exécution et configuration pour détecter les abus potentiels par des attaquants.

La troisième catégorie explore les tâches planifiées (scheduled tasks), un concept similaire aux services Windows en termes d’opportunités de hunting. Schinck souligne que la maîtrise de l’une de ces techniques facilite l’apprentissage de l’autre en raison de leurs similarités conceptuelles. Enfin, la quatrième catégorie aborde le hunting au niveau réseau en utilisant l’enrichissement de sources externes, notamment le projet Living Off Trusted Sites (LOTS) de Mr. D0x, qui répertorie les sites et domaines internet pouvant être abusés par des attaquants.

Pour les participants plus expérimentés, Schinck propose un défi bonus : effectuer les mêmes analyses en utilisant la télémétrie Sysmon ou les Windows Event Logs plutôt que les données de Microsoft Defender for Endpoint. Cette approche alternative permet d’explorer différentes sources de données et de développer une compréhension plus complète du threat hunting.

Expérience terrain et cas pratiques

L’expertise de Schinck en réponse aux incidents enrichit considérablement le workshop. Il partage des observations concrètes issues de ses interventions, notamment l’abus fréquent des comptes de service par les attaquants. Ces comptes, souvent configurés comme des comptes utilisateurs normaux dans Active Directory avec simplement le préfixe “SVC”, peuvent être exploités pour des connexions RDP sur des systèmes où ils ne devraient pas avoir accès. Schinck recommande de chasser activement ces anomalies en surveillant les connexions de comptes de service entre serveurs, particulièrement celles survenant en dehors des heures normales de travail.

Un autre pattern récurrent concerne l’emplacement des fichiers malveillants. Les attaquants déposent fréquemment leurs binaires ou scripts dans des emplacements moins surveillés comme la racine de Program Data, le dossier Users Public, ou divers répertoires AppData. Lors d’une intervention récente sur un cas de ransomware, Schinck a identifié rapidement un fichier DLL suspect dans le dossier Users Public, qui s’est révélé être un backdoor Cobalt Strike.

Méthodologie de hunting et conseils pratiques

Schinck insiste sur l’importance de filtrer le bruit dans les données de threat hunting. Une technique qu’il privilégie consiste à utiliser la fonction “distinct” pour regrouper les résultats uniques. Par exemple, lors de l’analyse de commandes PowerShell, plutôt que de parcourir 15 000 exécutions individuelles, le regroupement par lignes de commande distinctes peut réduire le jeu de données à 500 entrées, rendant l’analyse visuelle beaucoup plus efficace.

Il souligne également que l’œil humain possède une capacité remarquable à détecter des anomalies. En parcourant lentement 50 lignes de commande PowerShell sans filtres additionnels, un analyste expérimenté peut souvent repérer des éléments suspects. Cette capacité repose sur deux piliers : la connaissance approfondie de son environnement et l’expérience accumulée à travers de multiples incidents.

Accessibilité et reproductibilité

Un aspect important du workshop est son accessibilité. Schinck démontre qu’il est possible de créer un environnement de threat hunting fonctionnel avec seulement deux machines virtuelles, un Windows Event Collector et Microsoft Sentinel. Cette simplicité rend l’apprentissage accessible à quiconque souhaite créer un homelab, même sur un ordinateur personnel ou portable.

Il note qu’au Québec, le stack Microsoft (Sentinel et Defender) est devenu très populaire ces dernières années, rendant ces compétences particulièrement pertinentes. Paradoxalement, il observe que très peu d’organisations déploient Sysmon ou collectent les Security Event Logs dans Sentinel, malgré la gratuité de ces outils et leur valeur considérable en cas d’incident.

Conclusion

Le workshop de Yoan Schinck offre une approche pragmatique et réaliste du threat hunting en KQL, combinant expertise technique et expérience terrain. En se concentrant sur des scénarios d’attaque concrets et des outils largement déployés en entreprise, il prépare efficacement les participants aux défis réels de la cybersécurité moderne. Sa philosophie est claire : une fois les concepts de threat hunting maîtrisés, ils peuvent s’appliquer à n’importe quel produit ou langage de requête, seule la syntaxe change.

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par DEATHcon Montréal

Teknik - Split-Second Side Doors - How Bot-Delegated TOCTOU Breaks The CI/CD Threat Model

2025-11-27T00:00:00-05:00

Parce que… c’est l’épisode 0x670!

Shameless plug

25 et 26 février 2026 - SéQCure 2026
- CfP
31 mars au 2 avril 2026 - Forum INCYBER - Europe 2026
14 au 17 avril 2026 - Botconf 2026
28 et 29 avril 2026 - Cybereco Cyberconférence 2026
9 au 17 mai 2026 - NorthSec 2026
3 au 5 juin 2026 - SSTIC 2026
19 septembre 2026 - Bsides Montréal

Description

Ce podcast réunit François Proulx, Alexis Maurer-Fortin et Sébastien Graveline, chercheurs chez BoostSecurity, une startup montréalaise spécialisée en sécurité applicative. L’épisode explore les coulisses de leur travail de recherche et développement, particulièrement leurs découvertes récentes sur les vulnérabilités de type “race condition” dans les pipelines CI/CD.

Structure et méthodologie de recherche

L’équipe de recherche de BoostSecurity fonctionne de manière structurée mais flexible. François Proulx définit les grandes orientations annuelles basées sur les tendances émergentes et les apprentissages de l’année précédente. Alexis apporte son expertise en développement backend et son approche défensive, tandis que Sébastien, joueur avide de CTF, contribue avec une perspective offensive de red team. Garance, absente lors de l’enregistrement, assure la rigueur académique en effectuant des revues approfondies de la littérature scientifique.

Infrastructure de recherche massive

L’équipe a développé une infrastructure impressionnante pour la détection de vulnérabilités à grande échelle. Au cœur de leur système se trouve Poutine, un outil open source développé en Go pour scanner les pipelines de build, particulièrement les GitHub Actions. Cette infrastructure analyse continuellement l’écosystème open source, accumulant plusieurs téraoctets de données sur des millions de projets.

Leur système “Threat Hunter” ingère en quasi-temps réel tous les événements publics sur GitHub avec un délai d’environ cinq minutes, capturant même les dépôts éphémères qui n’existent que brièvement. Cette capacité leur permet de détecter des attaques en cours, comme l’attaque par “confused deputy” de Kong qu’ils ont pu capturer et analyser. Les données sont stockées dans Google Cloud BigQuery, permettant des analyses complexes qui auraient autrefois nécessité des semaines de travail.

Découverte d’une nouvelle technique de malware

François décrit une découverte récente concernant une technique d’obfuscation utilisant les “Private Use Areas” d’Unicode. Ces plages de caractères, réservées mais jamais attribuées officiellement, permettent d’encoder des données arbitraires dans des chaînes de caractères invisibles. Un malware peut ainsi être caché dans du code source JavaScript, Python ou Go sans être visible dans les éditeurs standards comme Visual Studio Code.

En réponse, l’équipe a développé “Puant”, un outil open source capable de scanner efficacement des millions de fichiers en quelques secondes pour détecter l’utilisation de ces caractères suspects. L’outil peut s’intégrer facilement dans les pipelines CI/CD pour bloquer du code contenant ces caractères invisibles lors de la révision de pull requests.

Vulnérabilités “Time of Check, Time of Use” dans les pipelines CI/CD

La découverte majeure présentée concerne une classe de vulnérabilités de type “race condition” appliquée aux build pipelines. L’équipe a identifié six cas significatifs affectant des entreprises comme Nvidia, GitHub Copilot et Jupyter Notebook.

Le premier cas découvert impliquait le “copy-pr-bot” de Nvidia. Ce bot copie le code d’une pull request dans une branche dédiée après qu’un mainteneur ait commenté “ok to test”. L’équipe a découvert une fenêtre d’environ cinq secondes entre la commande du mainteneur et l’exécution du bot, pendant laquelle un attaquant pouvait modifier le code malicieusement puis le rétablir, rendant l’attaque invisible.

Pour GitHub Copilot, la vulnérabilité était encore plus exploitable manuellement. Lorsqu’un mainteneur assignait Copilot pour résoudre un bug décrit dans une issue, un attaquant pouvait modifier les instructions pendant la race condition, demandant au bot d’insérer une backdoor tout en affichant une tâche légitime à l’écran.

Le cas de Jupyter Notebook était particulièrement ironique : la vulnérabilité résidait dans le code de mitigation d’une race condition précédemment rapportée. La correction initiale présentait une erreur typographique dans la référence temporelle utilisée, rendant la mitigation complètement inefficace.

Recommandations et mitigations

L’équipe propose plusieurs stratégies de mitigation. La plus importante consiste à utiliser des mécanismes atomiques qui lient l’approbation du mainteneur à un commit SHA spécifique. GitHub offre la fonctionnalité “Pull Request Review” qui garantit cette atomicité, contrairement aux simples commentaires ou labels qui restent vulnérables aux race conditions.

Les environnements GitHub constituent une autre défense robuste. Ils permettent de définir des règles d’approbation liées à des commits précis et de limiter l’accès aux secrets sensibles. L’équipe recommande fortement de restreindre la permission “Workflow Write”, qui permet de modifier les workflows GitHub Actions, car elle amplifie considérablement l’impact potentiel d’une attaque.

Finalement, l’adoption du principe “fail-close” plutôt que “fail-open” est essentielle : en cas d’erreur inattendue, le système doit arrêter l’exécution plutôt que de continuer. Des outils comme Poutine peuvent scanner automatiquement les workflows pour détecter ces vulnérabilités avant leur déploiement. D’ailleurs, une recherche académique récente a identifié Poutine comme l’un des meilleurs outils du domaine, particulièrement pour son excellent ratio signal/bruit.

Impact de l’intelligence artificielle

L’équipe observe que l’IA générative crée involontairement de nouvelles vulnérabilités. Certains pipelines vulnérables qu’ils ont découverts provenaient clairement de code généré automatiquement, créant ainsi de nouvelles chaînes d’attaque dans la supply chain logicielle.

Cette conversation met en lumière l’importance croissante de la sécurité des pipelines CI/CD dans l’écosystème open source moderne, où l’automatisation accrue multiplie les vecteurs d’attaque potentiels.

Notes

Split-Second Side Doors: How Bot-Delegated TOCTOU Breaks The CI/CD Threat Model

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Phishing Campaigns “I Paid Twice” Targeting Booking.com Hotels and Customers

2025-11-20T00:00:00-05:00

Parce que… c’est l’épisode 0x666!

Shameless plug

25 et 26 février 2026 - SéQCure 2026
- CfP
31 mars au 2 avril 2026 - Forum INCYBER - Europe 2026
14 au 17 avril 2026 - Botconf 2026
28 et 29 avril 2026 - Cybereco Cyberconférence 2026
9 au 17 mai 2026 - NorthSec 2026
3 au 5 juin 2026 - SSTIC 2026
19 septembre 2026 - Bsides Montréal

Description

Ce podcast technique réunit Jérémy Scion et Quentin Bourgue, analystes en cybersécurité chez Sekoia, qui présentent leurs recherches sur une campagne sophistiquée de phishing baptisée “Double Paiement” (ou “I Paid Twice”).

Un mode opératoire en deux phases

Cette attaque se distingue par son approche méthodique en deux étapes distinctes. La première phase cible spécifiquement les hôtels et leurs administrateurs dans le but de compromettre leurs systèmes et d’accéder aux comptes de gestion sur des plateformes comme Booking.com, Expedia ou Airbnb. Une fois ces accès obtenus, la deuxième phase consiste à cibler les clients de ces hôtels pour leur extorquer de l’argent en les faisant payer une seconde fois leur réservation.

La force de cette attaque réside dans le niveau de personnalisation rendu possible par l’accès aux informations de réservation. Les attaquants disposent de détails précis comme le nombre de nuits, les noms des clients, leurs coordonnées téléphoniques et les tarifs exacts, ce qui leur permet de créer des messages extrêmement convaincants.

L’infection des systèmes hôteliers

Pour compromettre les hôtels, les attaquants envoient des messages de phishing qui imitent le style de Booking.com ou d’autres plateformes de réservation. Ces messages prétendent provenir de clients avec des demandes d’information ou des besoins particuliers concernant leur séjour. Les hôteliers, soucieux de bien servir leur clientèle, sont naturellement enclins à répondre.

La technique utilisée repose sur une méthode appelée “ClickFix”, particulièrement insidieuse. Contrairement au phishing classique où la charge malveillante est contenue dans le courriel, cette approche redirige vers une page qui reprend l’apparence de Booking.com et incite l’utilisateur à exécuter lui-même une commande PowerShell. Cette auto-infection permet de contourner de nombreuses mesures de sécurité, car le téléchargement de la charge malveillante ne se fait pas via les canaux habituellement surveillés comme la messagerie ou le navigateur web.

La chaîne d’infection fait appel à des techniques avancées comme le DLL Side Loading et l’utilisation détournée d’outils légitimes pour charger le malware en mémoire. Dans le cas étudié, le malware utilisé était PureRAT, un logiciel malveillant proposé comme service, que l’attaquant loue plutôt que de développer lui-même.

Spécialisation et professionnalisation

Les attaquants démontrent une spécialisation claire dans le secteur hôtelier. Bien que leurs techniques restent relativement opportunistes, ils ont adapté leur approche à cet environnement spécifique. Fait intéressant, les chercheurs ont découvert que les attaquants ne développent de charges malveillantes que pour Windows, négligeant les systèmes Mac, ce qui suggère une approche coût-bénéfice calculée basée sur la prédominance de Windows dans ce secteur.

Cette campagne illustre particulièrement bien la professionnalisation croissante de l’écosystème cybercriminel. On observe un véritable découpage des fonctions avec différents acteurs spécialisés : un développeur crée et loue PureRAT comme service, un opérateur utilise sa propre infrastructure de phishing et ce malware pour voler des accès, puis revend ces accès à d’autres criminels spécialisés dans la fraude bancaire.

L’exploitation frauduleuse

Une fois les accès aux comptes Booking.com obtenus, ils sont revendus sur des forums cybercriminels. Les acheteurs utilisent alors ces accès pour mener la deuxième phase de l’attaque. Ils récupèrent les listes de réservations à venir et contactent les clients, principalement par courriel ou WhatsApp, en se faisant passer pour l’hôtel.

Le prétexte utilisé est généralement une vérification bancaire aléatoire ou un problème avec la validation de la carte de crédit. Les victimes sont rassurées qu’aucun prélèvement ne sera effectué, mais doivent simplement confirmer leurs informations. La légitimité apparente de ces messages, renforcée par les détails précis de la réservation, rend la fraude particulièrement efficace.

Les victimes sont redirigées vers de fausses pages qui imitent parfaitement Booking.com ou d’autres plateformes. Ces pages professionnelles récupèrent les informations bancaires et initient directement des transactions correspondant au montant de la réservation. Comme il s’agit souvent de montants de plusieurs centaines, voire milliers d’euros, la fraude devient rapidement lucrative.

Origine et évolution

L’analyse des forums cybercriminels révèle que ces opérations proviennent principalement de l’écosystème russophone, avec des acteurs situés dans l’ex-URSS. L’écosystème s’est considérablement professionnalisé avec des services spécialisés : certains vendent des listes d’adresses courriel d’hôtels, d’autres proposent des accès compromis, et certains recrutent même des opérateurs pour mener ces campagnes.

Jérémy Scion souligne l’évolution historique de cette menace. Il y a quelques années, il s’agissait d’opérations quasi artisanales menées par des groupes isolés. Aujourd’hui, attirés par les gains financiers substantiels, plusieurs groupes se sont lancés dans ce type d’activité. Cette professionnalisation s’accompagne d’une capacité d’adaptation remarquable : les attaquants modifient rapidement leurs chaînes d’infection pour rester discrets tout en maintenant une approche générique qui ne nécessite pas de personnalisation pour chaque victime.

Indicateurs de compromission et détection

Sekoia suit désormais plusieurs clusters utilisant ce mode opératoire, démontrant sa popularisation au sein de l’écosystème cybercriminel. Les chercheurs ont développé des méthodes automatiques et proactives pour suivre ces campagnes. Les indicateurs de compromission incluent principalement des noms de domaine imitant Booking.com ou utilisant des termes liés aux réservations et à l’hôtellerie, ainsi que les adresses IP hébergeant ces domaines.

Cette recherche met en lumière la réalité concrète de la professionnalisation du cybercrime, qui n’est plus une simple prédiction mais une réalité observable opérant à échelle industrielle.

Notes

Phishing Campaigns “I Paid Twice” Targeting Booking.com Hotels and Customers

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - La guerre Red Team vs EDR - l’aspect business et non technique du problème

2025-11-05T00:00:00-05:00

Parce que… c’est l’épisode 0x657!

Shameless plug

8 et 9 novembre 2025 - DEATHcon
17 au 20 novembre 2025 - European Cyber Week
25 et 26 février 2026 - SéQCure 2026
- CfP
31 mars au 2 avril 2026 - Forum INCYBER - Europe 2026
14 au 17 avril 2026 - Botconf 2026
28 et 29 avril 2026 - Cybereco Cyberconférence 2026
9 au 17 mai 2026 - NorthSec 2026
3 au 5 juin 2026 - SSTIC 2026
19 septembre 2026 - Bsides Montréal

Description

Introduction

Ce podcast explore la relation complexe entre les équipes Red Team et les solutions EDR (Endpoint Detection and Response), en mettant l’accent sur les dimensions business plutôt que purement techniques. Charles F. Hamilton partage son expertise terrain sur l’évasion des EDR et démystifie la confiance aveugle que beaucoup placent dans ces solutions présentées comme magiques.

La réalité des EDR : au-delà du marketing

Les EDR sont souvent vendus comme des solutions universelles de protection, mais cette perception cache une réalité plus nuancée. Il existe plusieurs types de solutions (EDR, XDR, NDR) avec des capacités différentes, notamment au niveau de la télémétrie réseau et de l’enrichissement des données. L’industrie de la cybersécurité reste avant tout un business, où les décisions sont guidées par des considérations financières, de croissance et de parts de marché plutôt que uniquement par la protection des utilisateurs.

Un aspect troublant est la romanticisation des groupes d’attaquants par certaines compagnies de détection, qui créent des figurines géantes et des noms accrocheurs pour ces groupes criminels lors de conférences. Cette approche marketing peut paradoxalement valoriser le crime et encourager de nouveaux acteurs malveillants.

Fonctionnement technique des EDR

Les EDR fonctionnent sur plusieurs niveaux de détection. D’abord, l’aspect antivirus traditionnel effectue une analyse statique avant l’exécution d’un binaire. Ensuite, la détection en temps réel utilise diverses techniques : le user mode hooking (de moins en moins populaire), les callbacks dans le kernel, et ETW (Event Tracing for Windows) qui capture de la télémétrie partout dans Windows.

Les EDR modernes privilégient les callbacks kernel plutôt que le user mode, car le kernel offre une meilleure protection. Cependant, le risque est qu’une erreur dans le code kernel peut causer un écran bleu, comme l’a démontré l’incident CrowdStrike. Microsoft a également implémenté les PPL (Protected Process Light) pour empêcher même les utilisateurs avec privilèges système de tuer certains processus critiques.

Un point crucial : les Red Teams sont souvent plus sophistiquées que les attaquants réels, précisément parce qu’elles doivent contourner les EDR dans leurs mandats.

Techniques d’évasion : simplicité et adaptation

Contrairement à ce qu’on pourrait croire, l’évasion d’EDR ne nécessite pas toujours des techniques extrêmement sophistiquées. Plusieurs approches simples fonctionnent encore remarquablement bien. Par exemple, modifier légèrement un outil comme PinkCastle en changeant les requêtes LDAP et en désactivant certaines fonctionnalités détectables (comme les tentatives de zone transfer DNS ou les requêtes SPN) peut le rendre indétectable.

Un cas particulier intéressant concerne un EDR qui, suite à son acquisition par Broadcom, a cessé d’être signé par Microsoft. Cette décision business a rendu leur DLL incapable de s’injecter dans les processus utilisant le flag de chargement de DLL signées uniquement par Microsoft, rendant effectivement l’EDR sans valeur de détection.

Une stratégie efficace consiste à désactiver la connectivité réseau des processus EDR avant toute manipulation, en utilisant le firewall local. Même si des alertes sont générées, elles ne peuvent pas être transmises au serveur. L’agent apparaît simplement offline temporairement.

Les vieilles techniques qui fonctionnent encore

De nombreuses techniques d’attaque anciennes restent efficaces car elles ne sont pas assez utilisées par les attaquants standard pour justifier leur détection. Les EDR se concentrent sur le “commodity malware” - les attaques volumétriques - plutôt que sur les techniques de niche utilisées principalement par les Red Teams.

Charles cite l’exemple d’une “nouvelle backdoor” découverte en 2024 qui était en fait son propre code archivé sur GitHub depuis 8 ans. Pour les compagnies de sécurité, c’était nouveau car jamais vu dans leur environnement, illustrant le décalage entre ce qui existe et ce qui est détecté.

L’importance de la simplicité

Un conseil crucial : ne pas suivre les tendances en matière de malware. Les techniques à la mode comme le stack spoofing deviennent rapidement détectées. Charles utilise depuis 6-7 ans un agent simple en C# sans share code ni techniques exotiques, qui passe encore inaperçu. La simplicité et une approche différente sont souvent plus efficaces que la complexité.

L’utilisation de Beacon Object Files (BOF) avec Cobalt Strike évite l’injection de processus, réduisant considérablement les artefacts détectables.

Recommandations pratiques

Pour les organisations, avoir un EDR est essentiel en 2025 pour bloquer les attaques triviales. Mais ce n’est qu’un début. Il faut absolument avoir au moins une personne qui examine les logs quotidiennement, idéalement trois fois par jour. De nombreux incidents de réponse montrent que toute l’information était disponible dans la console EDR, mais personne ne l’a regardée.

La segmentation réseau reste sous-développée depuis 15 ans, principalement pour des raisons de complexité opérationnelle. Sysmon devrait être déployé partout avec une configuration appropriée pour augmenter exponentiellement la visibilité, malgré la courbe d’apprentissage XML.

La visibilité réseau est ce qui manque le plus aux clients en 2025. Sans elle, il est impossible de valider ce que les EDR prétendent avoir bloqué. Charles donne l’exemple de Microsoft Defender Identity qui dit avoir bloqué des attaques alors que l’attaquant a bel et bien obtenu les hash recherchés.

Conclusion

L’évasion d’EDR est une spécialisation à part entière, au même titre que le pentesting web ou Active Directory. Le secret est de comprendre profondément Windows, les outils et les EDR eux-mêmes avant de tenter de les contourner. Les entreprises doivent garder l’intelligence à l’interne plutôt que de dépendre entièrement des produits commerciaux.

Finalement, la collaboration entre Blue Teams et Red Teams reste insuffisante. Plus de synergie permettrait aux deux côtés de mieux comprendre les perspectives de l’autre et d’améliorer globalement la sécurité. La curiosité et l’apprentissage continu sont les clés du succès dans ce domaine en constante évolution.

Notes

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Double-Tap Campaign - Russia-nexus APT possibly related to APT28 conducts cyber espionage on Central Asia and Kazakhstan diplomatic relations

2025-11-04T00:00:00-05:00

Parce que… c’est l’épisode 0x656!

Shameless plug

8 et 9 novembre 2025 - DEATHcon
17 au 20 novembre 2025 - European Cyber Week
25 et 26 février 2026 - SéQCure 2026
- CfP
31 mars au 2 avril 2026 - Forum INCYBER - Europe 2026
14 au 17 avril 2026 - Botconf 2026
28 et 29 avril 2026 - Cybereco Cyberconférence 2026
9 au 17 mai 2026 - NorthSec 2026
3 au 5 juin 2026 - SSTIC 2026
19 septembre 2026 - Bsides Montréal
Description

Ce podcast technique réunit Nicolas, l’animateur, avec Maxime Arquillière et Amaury-Jacques Garçon, deux analystes en cybermenace de sekoia., une société française spécialisée dans le renseignement sur les menaces informatiques (CTI - Cyber Threat Intelligence). Leur discussion porte sur une investigation approfondie d’une campagne de cyberespionnage sophistiquée baptisée “Double Tap”, probablement liée au groupe APT28 du renseignement militaire russe.

Le contexte et la méthodologie

Maxime et Amaury expliquent d’abord leur approche du travail de CTI, qui repose largement sur une veille continue des publications d’organismes spécialisés (CERT français, américains, canadiens) et de chercheurs en cybersécurité. Cette collecte systématique d’informations en source ouverte leur permet de modéliser les menaces et de créer des règles de détection, notamment des règles Yara pour identifier les fichiers malveillants.

Leur équipe dispose de quatre spécialités : le tracking d’infrastructure, les règles de détection, le reverse engineering de malware, et l’analyse stratégique qui vise à comprendre les objectifs géopolitiques derrière les attaques étatiques. Cette approche multidimensionnelle permet une compréhension globale des cybermenaces.

La découverte initiale

L’investigation démarre à partir d’un article publié fin juillet 2024 par le CERT-UA (l’autorité ukrainienne de réponse aux incidents), qui documente des attaques ciblant régulièrement l’Ukraine. À partir de ces informations, l’équipe a créé des règles de détection, dont certaines volontairement plus souples pour capturer d’éventuelles variantes.

Mi-octobre, une de ces règles Yara a détecté un document Word malveillant sur VirusTotal, une plateforme où sont analysés des millions de fichiers suspects. Ce document contenait une macro et semblait être issu du ministère des Affaires étrangères du Kazakhstan. Cette alerte a déclenché une investigation approfondie qui a permis de découvrir au total 18 documents similaires, dont une dizaine n’avaient jamais été publiés auparavant.

L’analyse technique : la chaîne d’infection “Double Tap”

Amaury détaille la sophistication technique de cette attaque. Les documents malveillants utilisent une technique de social engineering : ils apparaissent floutés ou déformés à l’ouverture, incitant la victime à cliquer sur “Activer les macros” pour les rendre lisibles. Cette action déclenche une chaîne d’infection particulièrement élaborée.

La particularité qui a donné son nom à la campagne est l’utilisation d’un double mécanisme : le premier document Word crée un second document contenant des macros malveillantes dans un répertoire temporaire du système. Cette approche en plusieurs étapes vise à contourner les systèmes de détection. Une fois activé, le malware modifie les paramètres de sécurité du système pour permettre l’exécution automatique de macros futures, établit une persistance qui se réactive toutes les quatre minutes, et contacte un serveur de commande et contrôle (C2).

Le code, largement obfusqué, construit progressivement une troisième macro qui communique avec un serveur externe pour transmettre des informations sur la machine compromise (nom d’utilisateur, nom du PC) et potentiellement déployer un backdoor Python appelé “Cherry Spy” pour l’exfiltration de données.

La dimension géopolitique

L’analyse de Maxime révèle que les dix documents découverts étaient tous rédigés en kazakh et concernaient des sujets diplomatiques : câbles d’ambassades kazakhes en Belgique et Afghanistan, comptes-rendus de visites présidentielles, et notamment une déclaration diplomatique conjointe entre l’Allemagne et le Kazakhstan datant de septembre 2024, lors d’une visite du chancelier Olaf Scholz visant à diversifier les approvisionnements énergétiques allemands.

Ces documents, datés entre 2021 et 2024, semblent être des documents légitimes récupérés lors d’opérations antérieures et réutilisés comme appâts pour cibler des diplomates et officiels kazakhs. Le Kazakhstan, bien qu’allié traditionnel de la Russie, adopte une politique de plus en plus indépendante, ce qui expliquerait l’intérêt du renseignement russe.

Le lien avec APT28 et Zebrocy

L’équipe établit des connexions avec APT28 (également connu sous le nom de Fancy Bear), un groupe de cyberespionnage du renseignement militaire russe (GRU). Ils identifient également des similitudes avec Zebrocy, un mode opératoire actif entre 2015 et 2020 qui ciblait spécifiquement l’Asie centrale et utilisait des techniques similaires de “double tap”.

L’importance du partage

Les chercheurs soulignent l’importance de publier leurs découvertes en source ouverte. Bien que cela puisse alerter les attaquants et les pousser à modifier leur infrastructure, cette transparence contribue à l’amélioration de la cybersécurité globale, permettant à d’autres chercheurs de construire sur leurs travaux.

De manière remarquable, quelques jours après la publication de leur rapport, un média kazakh a annoncé qu’une inspection imprévue du ministère des Affaires étrangères serait menée suite aux révélations sur cette cyberattaque. L’équipe avait d’ailleurs tenté de contacter le gouvernement kazakh avant publication, sans recevoir de réponse.

Cette investigation illustre parfaitement la complexité du travail en CTI : combiner expertise technique, compréhension géopolitique et éthique du partage pour protéger efficacement contre les menaces étatiques sophistiquées qui peuvent s’étendre sur plusieurs années.

Notes

Double-Tap Campaign - Russia-nexus APT possibly related to APT28 conducts cyber espionage on Central Asia and Kazakhstan diplomatic relations

Collaborateurs

Nicolas-Loïc Fortin
Maxime Arquillière
Amaury-Jacques Garçon

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Dans le feu des tranchés, opérer le SOC au Hackfest

2025-10-30T00:00:00-04:00

Parce que… c’est l’épisode 0x654!

Shameless plug

4 et 5 novembre 2025 - FAIRCON 2025
8 et 9 novembre 2025 - DEATHcon
17 au 20 novembre 2025 - European Cyber Week
25 et 26 février 2026 - SéQCure 2026
- CfP
31 mars au 2 avril 2026 - Forum INCYBER - Europe 2026
14 au 17 avril 2026 - Botconf 2026
28 et 29 avril 2026 - Cybereco Cyberconférence 2026
9 au 17 mai 2026 - NorthSec 2026
3 au 5 juin 2026 - SSTIC 2026
19 septembre 2026 - Bsides Montréal

Description

Introduction et contexte

Dans cet épisode du podcast 0x654 Teknik, Nicolas Corin s’entretient avec Alex Tardif de Palo Alto Networks sur l’opération du centre de sécurité (SOC) lors du Hackfest, un événement majeur de cybersécurité au Québec. Depuis plusieurs années, même avant 2022, Palo Alto est responsable de monter l’infrastructure et de sécuriser le CTF (Capture The Flag) de l’événement. Cette présence unique offre à l’équipe une visibilité exceptionnelle sur des trafics hostiles dans un environnement volontairement vulnérable.

La mission de sécurisation

Contrairement à ce qu’on pourrait penser, sécuriser un CTF n’est pas contradictoire. L’objectif principal est de contrôler ce qui se passe pour s’assurer que les participants respectent le code de conduite et ne dépassent pas les limites établies. Il faut empêcher les attaques sur les infrastructures hors périmètre du CTF et surveiller l’adresse IP publique pour éviter que des activités malveillantes n’affectent le Centre des Congrès qui héberge l’événement. Cette diligence est essentielle pour maintenir la confiance de l’organisation et garantir l’accès internet.

Une infrastructure complète de bout en bout

Palo Alto déploie bien plus que des pare-feu. L’équipe utilise une suite complète de solutions de sécurité, incluant des pare-feu nouvelle génération, un SOC, et des produits de sécurité cloud. Cette architecture permet une traçabilité complète, de l’utilisateur jusqu’aux challenges dans le cloud, en passant par le réseau. Cette année, l’infrastructure comprenait plus de 260 serveurs pour le challenge Active Directory, avec 5 à 6 serveurs instantanés par équipe.

Les outils déployés incluent Xsoar (leur outil SIEM automatisé), des solutions d’attack surface management, de la sécurité applicative pour analyser le code des challenges, et potentiellement pour l’année prochaine, des outils de sécurité pour les LLM (Large Language Models).

Une préparation approfondie

La préparation commence plusieurs mois à l’avance, dès avril-mai pour l’événement d’octobre. Cette planification extensive couvre la logistique, la nature des challenges, les connexions d’infrastructure et le déploiement des solutions. L’équipe connecte les challenges deux semaines avant l’événement pour effectuer des audits de sécurité, identifier les vulnérabilités présentes et confirmer avec les créateurs de challenges que tout est intentionnel. Cette approche “purple team” permet d’équilibrer la sécurité et l’intérêt des défis.

L’équipe et son organisation

Cette année, l’équipe a adopté un organigramme de SOC traditionnel avec 14 ressources sur place, incluant des SOC managers, des analystes de niveau 1, 2 et 3, et un analyste de sécurité réseau. L’événement se déroule sur 24 heures, du jeudi 19h30 au vendredi 19h30, ce qui représente un défi opérationnel considérable. L’équipe est principalement composée de ressources locales en prévente chez Palo Alto, avec des profils variés : red teaming, cloud, anciens directeurs de SOC, et spécialistes de l’implémentation de pare-feu.

Le mode détection plutôt que blocage

L’équipe opère entièrement en mode détection, avec seulement un événement bloqué cette année : une tentative d’injection sur la page de connexion WiFi. Ce mode nécessite plus d’intervention humaine mais offre une expérience d’apprentissage unique dans un environnement de production extrêmement bruyant, rempli de C2, malware et exploitations de vulnérabilités.

Des statistiques impressionnantes

Les chiffres de cette année témoignent de l’ampleur de l’événement : 486 Go de données analysées en 24 heures, 31,4 millions de menaces uniques détectées, 11 300 alertes générées et converties en 1 000 incidents. Grâce à l’automatisation, 663 incidents ont été traités automatiquement, soit plus de la moitié. L’équipe a atteint un temps moyen de détection et de réponse (MTTR/MTTD) de moins de 15 minutes, un exploit remarquable comparé à certaines grandes organisations.

L’automatisation et l’intelligence artificielle

L’automatisation joue un rôle crucial dans la gestion du volume d’alertes. Une fois qu’un type d’incident est résolu et compris, le système Xsoar recommande des playbooks pour automatiser la fermeture d’incidents similaires. Cette approche permet aux analystes de se concentrer sur les incidents vraiment intéressants plutôt que sur le triage répétitif, améliorant ainsi la rétention du personnel et la satisfaction au travail.

Les incidents et anecdotes marquantes

L’histoire justifie la vigilance : en 2022, un participant avait déployé des malwares via un faux captcha dans un PDF, ciblant la Russie et le Vietnam. En 2023, des machines infectées (notamment une VM Kali piratée) ont été détectées, et des tentatives de DDoS sur l’infrastructure du Hackfest ont été stoppées.

Cette année a été relativement calme, avec quelques anecdotes amusantes : une équipe a uploadé des photos de Vladimir Poutine aux pectoraux surdimensionnés sur un challenge GCP, et un participant paranoïaque a effectué 929 tentatives de validation DNS avec des DGA (Dynamically Generated Addresses).

L’utilisation de l’IA par les participants

Une découverte intéressante : 242 utilisateurs uniques ont utilisé ChatGPT durant les challenges, soit environ un tiers des participants. Plus surprenant encore, 68 utilisateurs ont utilisé Bing AI, probablement faute d’abonnement à d’autres services. Cette tendance soulève des questions sur l’équité et l’apprentissage dans les CTF.

Conclusion et perspectives

Cette expérience unique bénéficie autant à Palo Alto qu’au Hackfest. Pour l’entreprise, c’est une opportunité exceptionnelle de tester leurs solutions dans un environnement de production hostile et d’acquérir une expertise concrète pour mieux conseiller leurs clients. Pour le Hackfest, c’est la garantie d’un événement sécuritaire et professionnel. L’équipe invite d’ailleurs les intéressés à venir observer le SOC en action l’année prochaine, une opportunité rare de voir ces outils professionnels déployés dans un contexte réel et d’apprendre aux côtés d’experts.

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par Bâton Rouge - Galeries de la Capitale

Teknik - The Overlooked Playground - An Attacker’s Journey Through GCP

2025-10-23T00:00:00-04:00

Parce que… c’est l’épisode 0x650!

Shameless plug

4 et 5 novembre 2025 - FAIRCON 2025
8 et 9 novembre 2025 - DEATHcon
17 au 20 novembre 2025 - European Cyber Week
25 et 26 février 2026 - SéQCure 2026
- CfP

Notes

Description

Introduction

Dans cet épisode du podcast Police Secure, Clément Cruchet présente une analyse approfondie de la surface d’attaque de Google Cloud Platform (GCP), un sujet souvent négligé dans la communauté de la cybersécurité. Contrairement à Azure et AWS qui bénéficient d’une documentation abondante sur leurs vulnérabilités et vecteurs d’attaque, GCP reste le “petit frère oublié” du cloud computing. Cette présentation, donnée lors de la conférence Bide, vise à combler cette lacune en explorant les chemins qu’un attaquant pourrait emprunter dans un environnement GCP.

Le contexte : pourquoi GCP est moins documenté

Clément observe qu’il y a trois ou quatre ans, la documentation sur les vulnérabilités GCP était quasi inexistante. Cette absence de contenu a même conduit certains utilisateurs sur des forums comme Reddit à affirmer de manière erronée que GCP était plus sûr ou exempt de mauvaises configurations. En réalité, ces failles existent bel et bien, mais elles n’avaient simplement pas été explorées en profondeur. Bien que la situation se soit améliorée depuis trois ans avec l’apparition de formations et de certifications, GCP demeure significativement moins couvert que ses concurrents.

L’importance de l’IAM (Identity and Access Management)

Le cœur de la sécurité dans tous les environnements cloud réside dans la gestion des identités et des accès. Que ce soit Azure, AWS, GCP ou d’autres fournisseurs comme Oracle Cloud ou Alibaba Cloud, chacun possède son propre modèle IAM distinct. Ces modèles constituent la base de toute gestion des permissions, rôles et autorisations dans les environnements cloud. Le paradoxe est clair : sans permissions IAM, on ne peut rien faire, mais avec trop de permissions, on ouvre la porte à des abus et des défauts de configuration. La majorité des vulnérabilités dans les environnements cloud proviennent justement de ces mauvaises configurations au sein de l’IAM.

La hiérarchie unique de GCP

GCP se distingue par sa structure hiérarchique particulière. Contrairement à AWS qui fonctionne avec des comptes, ou à Azure qui utilise des tenants, des subscriptions et des groupes de ressources, GCP adopte une approche top-down très structurée. Au sommet se trouve l’organisation, généralement liée au nom de domaine de l’entreprise (par exemple company.com). Sous l’organisation, on trouve des folders, comparables aux unités organisationnelles (OU) d’Active Directory. Ces folders contiennent ensuite des projets, qui constituent l’unité administrative la plus importante.

Les projets dans GCP peuvent être comparés aux comptes AWS et c’est principalement à ce niveau que se fait la facturation. Pour beaucoup d’utilisateurs, seule la vue du projet est accessible, sans nécessairement avoir besoin d’une organisation complète. Cette flexibilité permet de commencer à travailler directement avec un projet sans passer par la création d’une infrastructure organisationnelle complète.

Les rôles et leurs dangers

Un point crucial soulevé par Clément concerne les rôles primitifs dans GCP : éditeur, viewer, owner et browser. Ces rôles sont extrêmement dangereux car ils accordent des permissions bien trop larges. Par exemple, un rôle d’éditeur peut avoir accès à 800 permissions différentes, ce qui viole complètement le principe du moindre privilège. Le message clé est de ne jamais utiliser ces rôles primitifs dans une infrastructure GCP.

Même les rôles prédéfinis, pourtant plus granulaires, peuvent présenter des risques. Un rôle comme “compute admin”, qui devrait théoriquement se limiter à l’administration des ressources compute, peut en réalité inclure 800 permissions, dont certaines touchent à des services non liés comme BigQuery. La recommandation fondamentale est de créer des rôles personnalisés aussi granulaires que possible et d’appliquer systématiquement le principe du moindre privilège.

Domain wide delegation : un vecteur d’exfiltration méconnu

L’une des contributions majeures de cette présentation concerne le domain wide delegation, une technique d’exfiltration peu documentée. Cette fonctionnalité permet à un compte de service dans GCP d’interagir avec Google Workspace : accéder à Drive, Gmail, envoyer des emails au nom d’utilisateurs, récupérer des pièces jointes, etc.

Clément a développé un outil Python appelé “Delegate” pour démontrer et tester cette technique. Lorsqu’il a écrit son article de blog sur le sujet début 2023, il n’existait pratiquement aucune documentation sur cette vulnérabilité. Ironiquement, Palo Alto Networks a publié un article similaire plusieurs mois après, ce qui témoigne du caractère précurseur de ses recherches.

Le scénario d’attaque typique implique un attaquant qui compromet une machine virtuelle possédant un compte de service capable d’effectuer du domain wide delegation. Cette technique peut également servir de mécanisme de persistance, permettant à un attaquant de configurer sa propre délégation pour exfiltrer des données de manière discrète. L’outil Delegate permet de lire des emails, télécharger et uploader des fichiers sur Drive, offrant ainsi une capacité d’exfiltration complète.

La matrice d’attaque GCP

Pour synthétiser ses recherches, Clément propose une kill chain communautaire spécifique à GCP, disponible sur GitHub (github.com/otendfreed/GCP-attack-matrix). Cette matrice d’attaque représente l’ensemble des tactiques, techniques et procédures (TTP) depuis la reconnaissance jusqu’à l’exfiltration et l’impact. L’objectif est de fournir un outil pour les équipes de sécurité souhaitant effectuer du purple teaming dans des environnements GCP, leur permettant d’évaluer leurs contrôles de sécurité et leur capacité de détection.

Conclusion

Ce podcast souligne l’importance de ne pas négliger GCP dans les stratégies de sécurité cloud. Bien que moins documenté, ce fournisseur présente des vecteurs d’attaque tout aussi critiques que ses concurrents. La recherche communautaire et le partage de connaissances sont essentiels pour identifier et corriger les vulnérabilités avant que des attaquants malveillants ne les exploitent. Comme le souligne Clément, pour attaquer un système, il faut d’abord le comprendre, et c’est précisément cette compréhension qu’il cherche à transmettre à la communauté de la cybersécurité.

Notes

À venir

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par Bsides Montréal

Teknik - Browser Detection and Response

2025-10-15T00:00:00-04:00

Parce que… c’est l’épisode 0x645!

Shameless plug

12 au 17 octobre 2025 - Objective by the sea v8
4 et 5 novembre 2025 - FAIRCON 2025
8 et 9 novembre 2025 - DEATHcon
17 au 20 novembre 2025 - European Cyber Week
25 et 26 février 2026 - SéQCure 2026

Description

Introduction

Dans cet épisode technique, Nicolas et Jordan Théodore abordent un changement de paradigme fondamental en cybersécurité d’entreprise. Le navigateur web est devenu l’élément principal du fonctionnement organisationnel, détrônant le desktop traditionnel. Cette évolution nécessite désormais de détecter et d’intervenir sur les navigateurs comme s’il s’agissait d’endpoints à part entière.

Le navigateur, nouvelle cible privilégiée

Depuis quelques années, les navigateurs web sont devenus une cible de choix pour les cyberattaquants. Cette concentration des attaques s’explique par plusieurs facteurs. La majorité des activités professionnelles transitent maintenant par le navigateur, que ce soit pour les emails, la suite bureautique ou les services en ligne. Cette migration s’est accélérée au cours des dix dernières années avec l’abandon progressif des clients lourds au profit d’applications web, popularisées notamment par Google avec sa suite bureautique entièrement en ligne. Microsoft suit également cette tendance avec la migration de sa propre suite vers le web.

Les attaquants exploitent ce vecteur d’attaque pour diffuser des malwares via des sites piégés, mener des campagnes de phishing particulièrement efficaces, et exploiter les vulnérabilités des navigateurs ou des extensions malveillantes. Les navigateurs modernes sont devenus des environnements riches qui stockent des informations sensibles, des mots de passe, des données en cache et même des bases de données locales, constituant ainsi un tremplin très important pour les acteurs malveillants.

Les vulnérabilités critiques

Jordan illustre la gravité de ces menaces avec des exemples concrets de vulnérabilités récentes. En 2023, des failles critiques dans la librairie libwebp ont été notées 8.8 sur l’échelle CVSS V3, affectant tous les navigateurs basés sur Chromium, notamment Chrome, Edge et Brave, ainsi que parfois Firefox. Ces vulnérabilités exploitent souvent des techniques classiques comme le buffer overflow ou la corruption de stack.

L’exemple le plus frappant concerne une faille permettant l’exécution de code arbitraire simplement par le chargement d’une image webp mal formée dans une page HTML. L’utilisateur n’a qu’à visiter une page contenant l’image malveillante pour que son navigateur vulnérable soit compromis, avec un minimum d’interaction. Cette simplicité d’exploitation est particulièrement préoccupante car ces images peuvent être hébergées sur des plateformes légitimes comme OneDrive, Dropbox ou Google Drive, contournant ainsi les filtres de proxy traditionnels qui autorisent généralement ces services d’entreprise.

Les défis du déploiement en entreprise

Dans les grandes organisations, comme l’exemple donné d’une entreprise du CAC 40 comptant 17 000 employés en France et 130 000 dans le monde, la mise à jour des navigateurs n’est pas aussi simple qu’il y paraît. Le taux de convergence du déploiement peut être considérablement long, particulièrement avec la généralisation du télétravail. Cette fenêtre d’exposition prolongée nécessite des solutions alternatives pour pallier le délai d’application des correctifs.

Les solutions de sécurité

Face à ces menaces, trois couches de défense principales ont émergé. Les EDR (Endpoint Detection and Response) jouent toujours un rôle crucial en suivant les activités côté poste client et en détectant les comportements suspects. Par exemple, CrowdStrike a récemment ajouté des capacités dédiées pour inventorier les extensions Chrome et Edge, vérifier leurs niveaux de permission et identifier les sources douteuses. Un EDR bien configuré peut détecter des comportements anormaux comme Chrome déclenchant une commande exécutable. Cependant, les EDR sont de plus en plus facilement contournés par des techniques avancées qui patchent les mécanismes de détection.

Une nouvelle couche de défense s’est donc développée directement au sein des navigateurs avec les extensions de sécurité. Ces modules additionnels peuvent bloquer activement les contenus malveillants et surveiller les actions utilisateur. On trouve des solutions open source comme Privacy Badger ou NoScript, ainsi que des produits commerciaux comme Capsule Security et Square X offrant de l’isolement à distance.

Ces extensions assurent plusieurs fonctions essentielles. Elles filtrent les URL en bloquant l’accès aux pages exploitant des CVE ou hébergeant des malwares. Elles analysent le contenu avant téléchargement en scannant les fichiers HTML, JavaScript et images avant leur exécution complète. Elles bloquent les scripts inconnus, réduisant la surface d’exploitation, et protègent contre les publicités malveillantes, l’injection de code via iframes et le fingerprinting. Elles intègrent également des fonctionnalités DLP pour éviter l’upload de fichiers corporates sur internet, notamment vers des services comme ChatGPT où les employés peuvent involontairement partager des informations sensibles.

L’extension développée par Glims, par exemple, vérifie tout contenu téléchargé pour détecter les malwares et contrôle les données uploadées pour prévenir les fuites d’information, incluant le copier-coller vers des sites externes. Ces extensions envoient des signaux au SOC (Security Operations Center) pour une meilleure visibilité et permettent d’intervenir rapidement si nécessaire.

Les navigateurs sécurisés

Au-delà des extensions, des navigateurs pensés pour la sécurité ont émergé. Brave, lancé il y a six ans, force l’accès HTTPS, filtre le phishing et bloque contenus indésirables, publicités et trackers. Des solutions comme Island et Talon proposent des navigateurs basés sur Chromium avec des contrôles de sécurité et DLP intégrés, bloquant par exemple les impressions d’écran et le copier-coller sur certains sites.

Limites et complémentarité

Les extensions ne peuvent pas tout faire. Elles ne voient pas ce qui se passe en mémoire et ne détectent pas les exploits de type use-after-free ou corruption mémoire. Elles peuvent être désactivées via JavaScript par click-jacking et ne protègent pas l’OS. D’où l’importance d’une approche complémentaire combinant EDR et extensions de navigateur.

Bonnes pratiques en entreprise

Pour renforcer la sécurité, les organisations doivent forcer une liste blanche d’extensions via GPO, installer des extensions de sécurité managées pour remonter les informations au SOC, utiliser un bon EDR pour surveiller toutes les extensions, et corréler les logs du navigateur avec ceux des endpoints lors des investigations. Le navigateur doit être considéré comme un petit poste à l’intérieur du grand poste pour tracer efficacement les actions malveillantes.

Cette approche représente une nouvelle réalité de la cybersécurité où les attaquants s’adaptent constamment, nécessitant une évolution parallèle des défenses.

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Tendance pour terminer 2025

2025-10-09T00:00:00-04:00

Parce que… c’est l’épisode 0x642!

Shameless plug

12 au 17 octobre 2025 - Objective by the sea v8
14 et 15 octobre 2025 - ATT&CKcon 6.0
14 et 15 octobre 2025 - Forum inCyber Canada
- Code rabais de 30% - CA25KDUX92
4 et 5 novembre 2025 - FAIRCON 2025
8 et 9 novembre 2025 - DEATHcon
17 au 20 novembre 2025 - European Cyber Week
25 et 26 février 2026 - SéQCure 2026
- CfP
31 mars au 2 avril 2026 - Forum INCYBER - Europe 2026
14 au 17 avril 2026 - Botconf 2026
28 et 29 avril 2026 - Cybereco Cyberconférence 2026
9 au 17 mai 2026 - NorthSec 2026
3 au 5 juin 2026 - SSTIC 2026
19 septembre 2026 - Bsides Montréal

Description

Dans cet épisode du podcast Sécurité technique, l’animateur reçoit Charles F. Hamilton pour discuter des tendances en cybersécurité à surveiller pour la fin de l’année 2025. La discussion s’amorce sur une réalité préoccupante : l’automne marque une période de forte activité tant pour les équipes légitimes que pour les cybercriminels, avec une hausse notable des incidents de sécurité nécessitant des réponses d’urgence.

La complexité d’Azure : un terrain propice aux vulnérabilités

Un des points majeurs abordés concerne la plateforme Azure de Microsoft. Une vulnérabilité récemment publiée permet de prendre le rôle Global Admin sur tous les tenants Azure, illustrant parfaitement les dangers liés à la complexité excessive de cet écosystème. Cette faille, découverte par manipulation de jetons de service, rappelle les problèmes similaires rencontrés avec Active Directory Certificate Services il y a quelques années.

La complexité d’Azure réside dans ses multiples méthodes d’authentification, ses contextes variés et ses centaines d’applications déployées par défaut dans chaque tenant. Les organisations ajoutent souvent leurs propres applications avec des permissions mal configurées, créant involontairement des chemins d’accès privilégiés. Le problème s’aggrave car il n’existe pas d’outils officiels de Microsoft pour auditer ces configurations, forçant les équipes de sécurité à se fier à des scripts PowerShell disparates ou à des outils développés par la communauté.

Le faux sentiment de sécurité

Un exemple frappant illustre le décalage entre la perception et la réalité de la sécurité : lors d’un test red team, un client disposait d’une infrastructure de sécurité impressionnante incluant filtrage réseau, EDR, NDR et autres solutions avancées. Paradoxalement, l’outil d’accès à distance légitime a été bloqué, nécessitant trois jours pour configurer des exceptions. En revanche, le payload malveillant a passé sans problème, sans générer aucune alerte. Cette situation démontre que ces outils créent souvent plus de complexité pour les équipes IT légitimes qu’ils ne protègent réellement contre les menaces sophistiquées.

Le fossé entre red team et blue team

La discussion révèle un écart de compétences préoccupant entre les équipes offensives et défensives. Les red teamers investissent constamment dans l’apprentissage de nouvelles techniques, tandis que les équipes défensives ont tendance à s’appuyer aveuglément sur l’intelligence artificielle de leurs outils de sécurité. Le threat hunting, pourtant essentiel, demeure rare au Québec et au Canada, malgré la disponibilité des données nécessaires dans les solutions EDR et NDR.

Un test révélateur : demander à des professionnels d’expliquer le fonctionnement de SecretDump, un outil largement utilisé. Très peu peuvent fournir une réponse complète sur ses mécanismes internes et les artefacts qu’il laisse. Cette lacune empêche les red teamers d’expliquer efficacement aux équipes bleues comment détecter leurs actions.

La sophistication des attaquants : un mythe à déconstruire

Contrairement à la perception populaire, la majorité des attaquants ne sont pas particulièrement sophistiqués. Ils suivent des playbooks répétitifs et comptent sur le volume pour réussir. Les intervenants ont observé des cas où des attaquants ont obtenu des accès privilégiés, puis ont immédiatement alerté leurs victimes par des actions bruyantes comme tenter de rendre publics tous les dépôts GitHub d’une entreprise.

Paradoxalement, les red teamers modernes développent des techniques si avancées qu’ils représentent désormais un niveau de sophistication comparable aux groupes parrainés par des États-nations, un scénario irréaliste pour la plupart des petites et moyennes entreprises québécoises. Cette situation crée un décalage : on teste la capacité à détecter des attaques extrêmement sophistiquées alors que les vraies menaces utilisent des méthodes beaucoup plus basiques.

Les tendances à surveiller pour l’automne 2025

Plusieurs éléments méritent une attention particulière pour la fin de l’année :

Les vulnérabilités sur les équipements périmétriques : Les solutions VPN de Cisco, SonicWall et Fortinet ont toutes été touchées récemment. Les délais d’exploitation se comptent maintenant en heures après la publication d’une vulnérabilité, amplifiés par la publication immédiate de preuves de concept sur les réseaux sociaux.

L’audit des tenants Azure et Google Enterprise : Les vecteurs d’attaque identifiés sur Azure s’appliquent également aux environnements Google Enterprise. Les organisations doivent absolument auditer leurs applications, leurs permissions et leurs configurations.

Les employés infiltrés : Une tendance émergente concerne l’embauche de développeurs travaillant pour des pays politiquement non neutres, qui obtiennent un accès au code source dans le but apparent de voler la propriété intellectuelle.

Les vulnérabilités GitHub Actions : Les fuites de clés API continuent de poser problème, avec des délais d’exploitation extrêmement rapides.

Le problème de la publication des preuves de concept

La course à la visibilité pousse certains chercheurs en sécurité à publier immédiatement des preuves de concept complètes, parfois dans l’heure suivant la découverte d’une vulnérabilité. Cette pratique, combinée à l’intelligence artificielle capable de générer du code fonctionnel à partir de bulletins de sécurité, met les organisations en danger avant qu’elles n’aient le temps d’appliquer les correctifs. Un retour aux pratiques de divulgation responsable avec un délai minimum de 80 jours serait bénéfique.

Conclusion : l’importance de l’éducation

Le podcast se termine sur l’importance cruciale de l’éducation en cybersécurité. Plutôt que de se focaliser uniquement sur l’utilisation d’outils, les professionnels doivent comprendre les fondements : comment fonctionne Windows, comment un programme s’exécute, comment créer ses propres exploits. La simplicité est souvent plus efficace que la complexité. Les solutions les plus durables reposent sur une compréhension approfondie des systèmes plutôt que sur l’accumulation d’outils sophistiqués dont personne ne maîtrise vraiment le fonctionnement.

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - BloodHound et OpenGraph

2025-10-07T00:00:00-04:00

Parce que… c’est l’épisode 0x640!

Shameless plug

12 au 17 octobre 2025 - Objective by the sea v8
14 et 15 octobre 2025 - ATT&CKcon 6.0
14 et 15 octobre 2025 - Forum inCyber Canada
- Code rabais de 30% - CA25KDUX92
4 et 5 novembre 2025 - FAIRCON 2025
8 et 9 novembre 2025 - DEATHcon
17 au 20 novembre 2025 - European Cyber Week
25 et 26 février 2026 - SéQCure 2026
- CfP

Description

Introduction et parcours professionnel

Mathieu Saulnier, connu sous le pseudonyme “Scooby” dans la communauté de cybersécurité, possède une vingtaine d’années d’expérience dans le domaine. Son parcours l’a mené d’un grand fournisseur internet et de télécommunications vers la gestion d’un SOC (Security Operations Center), puis vers des rôles de recherche sur les menaces pour des vendeurs de SIEM et d’EDR. Aujourd’hui, il occupe le poste de product manager pour BloodHound Community Edition chez SpecterOps, une position qu’il a obtenue grâce à ses nombreuses présentations sur BloodHound au fil des années.

BloodHound version 8 et la révolution OpenGraph

La version 8 de BloodHound représente une évolution majeure de l’outil. La fonctionnalité phare est OpenGraph, qui permet d’ingérer n’importe quel type de données dans le graphe et de créer ses propres chemins d’attaque pour différentes technologies. Historiquement, BloodHound se concentrait exclusivement sur Active Directory et Azure/Entra ID, mais cette limitation appartient désormais au passé.

Avec le lancement d’OpenGraph, SpecterOps a publié plusieurs nouveaux collecteurs pour diverses technologies : One Password, Snowflake, et Jamf (pour la gestion des postes de travail Mac). La communauté a réagi avec enthousiasme, puisqu’en seulement 48 heures après l’annonce, un contributeur externe a créé un collecteur pour Ansible. Plus récemment, un collecteur pour VMware vCenter et ESXi a également vu le jour, démontrant l’adoption rapide de cette nouvelle capacité.

La distinction fondamentale : access path versus attack path

Mathieu utilise une analogie éclairante avec Google Maps pour expliquer la différence entre un chemin d’accès et un chemin d’attaque. Google Maps montre les chemins autorisés selon différents modes de transport (voiture, vélo, transport en commun), chacun ayant ses propres règles et restrictions. C’est l’équivalent d’un graphe d’accès qui indique où on a le droit d’aller.

Un chemin d’attaque, en revanche, représente la perspective d’un adversaire qui ne se préoccupe pas des règlements. L’exemple donné est celui d’une voiture roulant sur une piste cyclable à Montréal : c’est interdit, on sait qu’on risque une contravention, mais c’est techniquement possible. Dans le monde numérique, les conséquences sont souvent moins immédiates et moins visibles, ce qui explique pourquoi les attaquants exploitent régulièrement ces chemins non conventionnels.

L’évolution du modèle de données

BloodHound a commencé modestement avec seulement trois types d’objets (utilisateurs, groupes et ordinateurs) et trois types de relations (member of, admin et session). Depuis, le modèle s’est considérablement enrichi grâce aux recherches menées par SpecterOps et d’autres organisations. Des propriétés comme le Kerberoasting ont été ajoutées, permettant d’identifier les objets vulnérables à ce type d’attaque et d’élever ses privilèges.

La vraie puissance d’OpenGraph réside dans la capacité de relier différents systèmes entre eux. Par exemple, si un attaquant compromet le poste d’un utilisateur ayant accès à un dépôt GitHub, il peut voler les tokens et sessions pour effectuer des commits au nom de cet utilisateur, potentiellement dans une bibliothèque largement utilisée, ouvrant ainsi la voie à une attaque de la chaîne d’approvisionnement (supply chain attack). Cette interconnexion multi-dimensionnelle des systèmes était difficile à visualiser mentalement, mais le graphe la rend évidente.

Créer des collecteurs OpenGraph : exigences et bonnes pratiques

Pour qu’un collecteur soit accepté dans la liste officielle des projets communautaires, certains standards doivent être respectés. Il faut créer le connecteur avec une documentation détaillant les permissions minimales nécessaires (principe du moindre privilège), expliquer son fonctionnement, les systèmes d’exploitation supportés, et les dépendances requises.

La documentation devrait également inclure des références sur comment exploiter ou défendre contre les vulnérabilités identifiées. Bien que non obligatoires, des éléments visuels personnalisés (icônes et couleurs) sont fortement recommandés pour assurer une cohérence visuelle dans la communauté. Le projet étant open source, les utilisateurs peuvent toujours modifier ces éléments selon leurs préférences.

Un aspect crucial est la fourniture de requêtes Cypher pré-construites. Sans ces requêtes, un utilisateur qui ne connaît pas Cypher pourrait importer toutes les données mais se retrouver bloqué pour les exploiter efficacement.

Le langage Cypher et l’accès aux données

BloodHound fonctionne sur une base de données graphique, historiquement Neo4j, mais maintenant également PostgreSQL grâce à un module de conversion. Le langage de requête utilisé est Cypher, qui possède une syntaxe particulière. Pour rendre l’outil plus accessible, SpecterOps maintient une bibliothèque Cypher contenant de nombreuses requêtes créées par l’équipe et la communauté. Ces requêtes peuvent être exécutées directement depuis le portail BloodHound.

L’entreprise explore également l’utilisation de LLM (Large Language Models) pour générer des requêtes Cypher automatiquement, bien que le corpus public de données spécifiques à BloodHound soit encore limité. Les pistes futures incluent l’utilisation de MCP (Model Context Protocol) et d’approches agentiques pour améliorer la génération de requêtes.

Usage défensif et offensif : deux faces d’une même médaille

Mathieu souligne que les mêmes requêtes Cypher peuvent servir tant aux équipes bleues (défensives) qu’aux équipes rouges (offensives). La différence réside dans l’intention et l’utilisation des résultats, pas dans les outils eux-mêmes. C’est l’équivalent du marteau qui peut construire ou détruire selon l’utilisateur.

Pour l’usage défensif, BloodHound Enterprise offre des fonctionnalités avancées comme le scan quasi-continu, l’identification automatique des points de contrôle critiques (choke points), et des outils de remédiation. Même la version communautaire gratuite permet de découvrir des vulnérabilités majeures lors de la première exécution.

Exemples concrets et cas d’usage

Mathieu partage des exemples frappants de découvertes faites avec BloodHound. Dans une entreprise de plus de 60 000 employés, il a identifié un serveur où tous les utilisateurs du domaine (domain users) avaient été accidentellement configurés comme administrateurs locaux. Comme un compte administrateur de domaine se connectait régulièrement à ce serveur, n’importe quel utilisateur pouvait devenir administrateur du domaine en seulement trois étapes : RDP vers le serveur, dump de la mémoire pour récupérer le token, puis attaque pass-the-hash.

Un autre cas récent impliquait le script de login d’un administrateur de domaine stocké dans un répertoire accessible en écriture à tous. En y plaçant un simple script affichant un popup, l’équipe de sécurité a rapidement reçu une notification prouvant la vulnérabilité.

Nouvelles fonctionnalités : la vue tableau

Bien que moins spectaculaire qu’OpenGraph, la fonctionnalité “table view” répond à un besoin important. La célèbre citation de John Lambert de Microsoft (2015) dit : “Les attaquants pensent en graphe, les défenseurs pensent en liste. Tant que ce sera vrai, les attaquants gagneront.” Bien que la visualisation graphique soit le paradigme central de BloodHound, certaines analyses nécessitent une vue tabulaire.

Par exemple, une requête identifiant tous les comptes Kerberoastables retourne de nombreux points à l’écran, mais sans informations détaillées sur les privilèges ou l’appartenance aux groupes. La vue tableau permet de choisir les colonnes à afficher et d’exporter les données en JSON (et bientôt en CSV), facilitant l’analyse et le partage d’informations.

Deathcon Montréal : la conférence pour les défenseurs

En complément à son travail sur BloodHound, Mathieu est le site leader de Montréal pour Deathcon (Detection Engineering and Threat Hunting Conference). Cette conférence unique, entièrement axée sur les ateliers pratiques (hands-on), se déroule sur deux jours en novembre. Contrairement aux conférences traditionnelles, tous les ateliers sont pré-enregistrés, permettant aux participants de travailler à leur rythme.

L’événement se limite volontairement à 50 personnes maximum pour maintenir une atmosphère humaine et favoriser les interactions. Les participants ont accès à un laboratoire massif incluant Splunk, Elastic, Sentinel et Security Onion, et conservent cet accès pendant au moins un mois après l’événement. Sans sponsors, la conférence est entièrement financée par les billets, et l’édition 2024 a déjà vendu plus de 30 places, avec de nombreux participants de l’année précédente qui reviennent.

Conclusion

BloodHound avec OpenGraph représente une évolution majeure dans la visualisation et l’analyse des chemins d’attaque en cybersécurité. En permettant l’intégration de multiples technologies au-delà d’Active Directory, l’outil offre désormais une vision holistique des vulnérabilités organisationnelles. Que ce soit pour la défense ou les tests d’intrusion, BloodHound continue de démontrer que penser en graphe plutôt qu’en liste constitue un avantage stratégique décisif en matière de sécurité.

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par Bsides Montréal

Teknik - Sécurité physique

2025-09-09T00:00:00-04:00

Parce que… c’est l’épisode 0x627!

Shameless plug

10 et 11 septembre 2025 - GoSec 2025
- Code rabais de 15% - GSPOL25
13 septembre 2025 - BSides Montreal 2025
12 au 17 octobre 2025 - Objective by the sea v8
14 et 15 octobre 2025 - ATT&CKcon 6.0
14 et 15 octobre 2025 - Forum inCyber Canada
- Code rabais de 30% - CA25KDUX92
10 au 12 novembre 2025 - IAQ - Le Rendez-vous IA Québec
17 au 20 novembre 2025 - European Cyber Week
25 et 26 février 2026 - SéQCure 2026

Description

Introduction : deux mondes indissociables

Dans cet épisode spécial du podcast avec Christophe d’Arlhac, la discussion porte sur la sécurité physique et sa convergence croissante avec la cybersécurité. Ces deux domaines, autrefois traités en silos, sont devenus indissociables au cours des vingt dernières années. Chaque mois, leur interdépendance s’amplifie davantage.

La raison est simple : un badge volé, une caméra piratée ou une clé USB perdue sont des actifs physiques qui génèrent rapidement des incidents numériques majeurs. Une fois qu’un acteur malveillant obtient un accès physique à un actif numérique, toutes les mesures de sécurité digitales deviennent inefficaces. Sans protection physique adéquate, la sécurité numérique est compromise.

Les incidents réels et leurs conséquences

Plusieurs cas concrets illustrent l’importance de cette convergence. Chez British Airways en 2018, des disques durs ont été physiquement volés, compromettant des millions de données utilisées ensuite pour du piratage. L’incident de Verkada en 2021 a exposé plus de 150 000 caméras dans des prisons, hôpitaux et entreprises, révélant un manque flagrant de segmentation réseau. Ces dispositifs censés protéger le physique sont devenus des portes d’entrée vers l’ensemble du système d’information.

L’incendie du data center OVH à Strasbourg en 2021 démontre qu’au-delà des attaques malveillantes, les incidents accidentels peuvent avoir des répercussions catastrophiques. Des milliers de serveurs ont été détruits, impactant de nombreuses organisations. Ces incidents, bien que médiatisés, ne sont malheureusement pas isolés - les centres de données qui brûlent sont plus courants qu’on ne le pense.

Un exemple plus banal mais révélateur : un data center installé dans une armoire où la personne effectuant le ménage débranchait quotidiennement le rack de serveurs pour brancher son aspirateur. Ce cas illustre qu’une sécurité physique déficiente peut entraîner des pertes de production et de données, même sans intention malveillante.

L’évolution réglementaire

Les normes internationales prennent de plus en plus en compte cette réalité. L’ISO 27001, l’ISO 22301, le RGPD, les lois de programmation militaire et la directive NIS 2 insistent lourdement sur la sécurité physique. Ces régulations imposent des contrôles renforcés, particulièrement pour les entreprises critiques, et exigent désormais explicitement la coordination entre les fonctions sûreté et cybersécurité.

Cette évolution réglementaire reconnaît qu’il est devenu impossible de dissocier ce qui est physique de ce qui est numérique. Un téléphone utilisé pour l’authentification multifacteur est-il un actif physique ou numérique ? Un badge avec empreinte numérique relève-t-il du physique ou du cyber ? Ces questions illustrent la convergence complète des deux domaines.

L’interdépendance technologique

Les systèmes de contrôle d’accès, de détection, les caméras IP, les alarmes connectées et les capteurs divers créent une interdépendance forte entre physique et numérique. Cette réalité impose de repenser la gestion des incidents. Si les incidents cyber sont généralement bien tracés, les incidents physiques restent souvent confinés aux services d’accueil ou généraux, sans remonter aux RSSI, CISO ou DSI. Cette cloisonnement de l’information représente un risque majeur pour l’organisation.

La résistance au partage d’information entre ces deux univers provient parfois de peurs légitimes : crainte pour son poste, charge de travail supplémentaire, perte de prérogatives. Pourtant, dépasser ces inquiétudes individuelles pour adopter une vision globale reste essentiel pour protéger efficacement l’entreprise.

L’équation fondamentale de sûreté

Un concept clé de la sécurité physique mérite d’être mieux connu en cybersécurité : l’équation de sûreté. Le temps de résistance d’une protection doit être strictement supérieur à la somme du temps de détection et du temps d’intervention. Cette formule simple permet d’optimiser la protection de sites dispersés, qu’il s’agisse d’éoliennes, de tours cellulaires ou d’installations hydroélectriques.

Cette équation s’applique autant au physique qu’au numérique. L’intervention peut être à distance (un administrateur bloquant ou effaçant des données) ou physique (un agent de sécurité se déplaçant sur site). En multipliant les barrières - barriérages, caméras, alarmes, sas, portes blindées - on retarde l’intrusion et on laisse le temps à la détection et à l’intervention d’opérer. Le principe fondamental reste : retarder, détecter, réagir.

Recommandations pratiques

Pour améliorer la sécurité globale, plusieurs actions concrètes sont préconisées : limiter l’accès aux zones sensibles par des badges, surveillance humaine et vidéo redondante ; créer des comités de sécurité communs pour éviter l’exclusion et favoriser une vision d’ensemble ; prévoir des plans de secours et des redondances ; sécuriser tous les périphériques critiques ; segmenter les réseaux (notamment séparer caméras internes et externes).

Il est recommandé d’instaurer un référent capable d’intégrer sûreté et cybersécurité, d’organiser des exercices hybrides combinant intrusion physique et incident cyber, et de réviser les politiques de sécurité pour inclure explicitement le volet physique. Des audits croisés entre équipes physiques et cyber permettraient de décloisonner les approches.

La sensibilisation continue

La sécurité physique ne se limite pas aux locaux de l’entreprise. Elle concerne aussi les salons professionnels, les transports, les restaurants. Trop de professionnels gardent leur badge visible en public, exposent leur laptop avec des autocollants identifiant leur employeur, ou publient sur les réseaux sociaux des photos compromettantes. Les badges comportent souvent des QR codes facilement copiables.

La formation croisée des équipes constitue un levier d’amélioration majeur : les équipes de sûreté physique doivent être sensibilisées aux nouvelles technologies cyber, tandis que les équipes numériques doivent comprendre les problématiques physiques. Cette double formation créerait une cohésion renforcée et une culture de sécurité véritablement globale.

Conclusion

La convergence entre sécurité physique et cybersécurité n’est plus optionnelle. Les conflits internationaux actuels montrent d’ailleurs que l’attaque physique ne peut être dissociée du numérique, avec des technologies comme les drones téléguidés qui redistribuent les capacités militaires. Pour les entreprises, penser global et transverse n’est plus un choix mais une nécessité. Dans un monde où un simple aspirateur peut causer une panne de serveurs, et où un badge volé ouvre la porte à une cyberattaque, seule une approche intégrée garantit une protection efficace.

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Résilience OT

2025-09-02T00:00:00-04:00

Parce que… c’est l’épisode 0x624!

Shameless plug

10 et 11 septembre 2025 - GoSec 2025
- Code rabais de 15% - GSPOL25
13 septembre 2025 - BSides Montreal 2025
12 au 17 octobre 2025 - Objective by the sea v8
14 et 15 octobre 2025 - ATT&CKcon 6.0
14 et 15 octobre 2025 - Forum inCyber Canada
- Code rabais de 30% - CA25KDUX92
10 au 12 novembre 2025 - IAQ - Le Rendez-vous IA Québec
17 au 20 novembre 2025 - European Cyber Week
25 et 26 février 2026 - SéQCure 2026

Description

Ce podcast technique explore la résilience des systèmes opérationnels (OT) et informatiques (IT), réunissant trois experts qui partagent leur expérience sur les défis de continuité des opérations dans les environnements industriels modernes.

La résilience : définition et enjeux

Marc Potvin ouvre la discussion en définissant la résilience comme la capacité à « retomber sur ses pattes » après une perturbation, qu’il s’agisse d’une panne, d’une cyberattaque ou d’une catastrophe naturelle. L’objectif principal demeure de rétablir le service le plus rapidement possible en minimisant l’impact sur les opérations. Il souligne qu’on ne peut pas prévoir tous les scénarios, mais qu’une bonne résilience permet de s’adapter efficacement à différentes situations.

Contrastes entre les mondes IT et OT

Alexandre Fournier observe que le monde IT semble plus mature et moderne, avec davantage de ressources capables d’intervenir lors d’incidents. En revanche, le secteur OT fait face à des défis importants concernant les connaissances, le vieillissement des équipements et la complexité du redémarrage après une attaque. Marc confirme cette observation, notant que la maturité en cybersécurité est beaucoup plus avancée côté IT.

Un aspect crucial différencie les deux univers : l’antifragilité. Alexandre souligne que dans l’OT, les équipes doivent souvent improviser et « bricoler » avec des moyens limités, cannibalisant parfois des pièces pour réparer les équipements. Cette capacité de débrouillardise s’explique par les impératifs de production : les chaînes ne peuvent pas s’arrêter, et les coûts d’interruption sont considérables.

La problématique de la gestion d’actifs

Marc introduit le concept critique de gestion d’actifs, distinguant les organisations qui renouvellent régulièrement leurs équipements (typiquement après sept ans) de celles qui adoptent une approche « pompier ». Certaines entreprises utilisent leurs actifs bien au-delà de leur durée de vie recommandée, parfois dix ans après que le manufacturier ait cessé son support. Ces organisations vivent avec « l’épée de Damoclès » au-dessus de leur tête, dépendant de fournisseurs d’antiquités pour maintenir des systèmes obsolètes.

Camille Felx Leduc note même avoir observé de nouveaux sites construits avec des actifs déjà désuets, car les plans datent de plusieurs années et la construction prend du temps. Cette situation crée des vulnérabilités dès le départ du cycle de vie.

Priorités de production versus gestion de risque

Les participants soulignent une réalité difficile : dans de nombreuses organisations, la résilience n’est pas la priorité principale. La production et la génération de revenus passent avant tout. Marc explique que même dans les milieux réglementés, comme les services électriques où il a travaillé, les vice-présidents ramènent toujours la discussion aux mégawatts vendus plutôt qu’aux investissements en résilience.

Alexandre observe que sans obligations légales ou réglementaires, c’est souvent « la fête du slip », avec une mentalité du « on verra quand ça arrivera ». Seuls les secteurs pharmaceutique, médical ou électrique, soumis à des contraintes réglementaires strictes, sont obligés de prendre la cyber-résilience au sérieux.

Connectivité : une arme à double tranchant

Marc aborde l’enjeu de la connectivité accrue entre les systèmes IT et OT. Bien que cette interconnexion améliore l’agilité opérationnelle, elle augmente considérablement la surface d’attaque. Il cite l’exemple de l’attaque NotPetya de 2017, où la propagation rapide du ransomware a causé des dommages astronomiques à de nombreuses organisations connectées. Dans certains cas, les pertes dues au ransomware ont été pires qu’un incendie détruisant une usine entière.

Camille souligne l’importance de pouvoir déconnecter complètement les systèmes OT des systèmes IT en cas d’incident, et de disposer de plans B permettant de continuer les opérations manuellement avec papier et crayon.

Plans de continuité et exercices tabletop

La discussion s’intensifie autour des exercices tabletop, considérés comme essentiels pour tester la résilience. Camille apprécie particulièrement ces exercices pour observer la collaboration entre les équipes IT et OT, notant avec humour avoir vu des situations où les deux groupes travaillaient avec des plans de réponse aux incidents datant d’années différentes.

Alexandre va plus loin, expliquant qu’il a développé une approche incluant du stress volontaire dans les exercices, pouvant aller jusqu’à des situations très intenses. Il préconise également des micro-exercices de 15 minutes mensuels, complétant deux grands exercices annuels, pour maintenir les équipes en condition.

Marc insiste sur la nécessité de répéter ces exercices annuellement en raison du roulement du personnel. Les équipes changent constamment, et chaque nouvel exercice permet d’intégrer les nouveaux membres tout en maintenant les réflexes des équipes existantes.

Sauvegardes et souveraineté des données

Alexandre lance un appel urgent concernant les sauvegardes Microsoft, observant que plusieurs clients coupent leurs sauvegardes SharePoint et OneDrive pour économiser. Il met en garde contre cette pratique dangereuse, surtout dans un contexte où certains gouvernements peuvent restreindre l’accès aux services cloud.

Marc complète en soulignant l’importance de savoir où sont stockées les données, citant des cas où des secrets pharmaceutiques se retrouvent involontairement dans des juridictions problématiques. La souveraineté des données devient un enjeu critique de résilience.

Conclusion

Les experts s’accordent sur l’importance des exercices pratiques plutôt que de simples procédures écrites. La résilience véritable se construit par la pratique répétée, l’adaptation constante et la reconnaissance que, comme le dit Camille, « personne n’est jamais assez prêt » pour une vraie crise. L’objectif reste de développer des réflexes et une capacité d’adaptation permettant de naviguer dans l’imprévu avec calme et efficacité.

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - CTI

2025-08-27T00:00:00-04:00

Parce que… c’est l’épisode 0x622!

Shameless plug

10 et 11 septembre 2025 - GoSec 2025
- Code rabais de 15% - GSPOL25
13 septembre 2025 - BSides Montreal 2025
12 au 17 octobre 2025 - Objective by the sea v8
14 et 15 octobre 2025 - Forum inCyber Canada
- Code rabais de 30% - CA25KDUX92
10 au 12 novembre 2025 - IAQ - Le Rendez-vous IA Québec
17 au 20 novembre 2025 - European Cyber Week
25 et 26 février 2026 - SéQCure 2026

Description

Dans cet épisode du podcast technique, Jordan Theodore aborde les défis contemporains auxquels font face les analystes en Cyber Threat Intelligence (CTI), particulièrement en ce qui concerne la dégradation de la qualité des sources d’information ouvertes et l’impact sur le travail quotidien des professionnels de la cybersécurité.

Définition et rôle de la CTI

Jordan débute en définissant la CTI selon Sergio Caltagirone, expert reconnu ayant travaillé pour le gouvernement américain et Microsoft. La CTI constitue une connaissance exploitable concernant les adversaires et leurs activités malveillantes, incluant le contexte et les TTP (Tactiques, Techniques et Procédures). Ces informations permettent aux organisations et aux équipes de défense (Blue Team) de réduire les risques et d’améliorer leur posture de sécurité.

Le travail de l’analyste CTI s’organise autour de quatre types d’intelligence. L’intelligence stratégique, orientée vers le long terme, s’adresse principalement aux grandes organisations et au secteur public, fournissant des macrotendances et analysant les risques géopolitiques liés aux APT (Advanced Persistent Threats). L’intelligence opérationnelle et technique, plus courante, se concentre sur la connaissance des adversaires, l’analyse des campagnes, les vecteurs d’accès initiaux et la documentation des chaînes d’attaque. Les analystes recherchent également des observables et des artefacts (adresses IP, URLs, domaines) pour créer des playbooks destinés aux équipes SOC et de réponse à incident, ainsi que des règles de détection (Sigma, Yara) pour peupler les équipements de sécurité.

La crise de qualité dans les sources ouvertes

Le cœur de la discussion porte sur une problématique majeure observée en 2025 : la détérioration significative de la qualité des articles et rapports CTI disponibles en sources ouvertes. Jordan illustre ce phénomène avec l’exemple de la campagne Wine Grape Loader d’avril 2025, attribuée à APT29, qui a généré plus de cent articles de qualité variable.

Le problème principal réside dans la multiplication d’articles manquant de substance sur tous les aspects : stratégique, technique et opérationnel. Beaucoup se limitent à un travail journalistique superficiel, souvent constitué de copier-coller d’autres publications. Cette surabondance crée un bruit informationnel considérable qui complique énormément le travail des analystes, particulièrement en situation d’incident où le temps est critique.

Jordan décrit un effet “poupée russe” où les créateurs de contenu copient des articles déjà copiés ailleurs, rendant difficile l’identification de la source originale. Cette dilution progressive de l’information rappelle le principe de l’homéopathie, où le contenu utile devient de plus en plus dilué à chaque itération. Parmi les trente articles analysés pour la campagne Grape Loader, la majorité constituait des copies de deux sources principales : Checkpoint et Google, qui avaient fourni un excellent travail précurseur.

L’absence d’analyse et de valeur ajoutée

Ces articles recyclés présentent des lacunes caractéristiques : absence d’indicateurs techniques, manque de détails opérationnels, et surtout absence de l’expertise propre du fournisseur ou de l’organisation. On n’y retrouve ni analyse approfondie ni perspective unique, seulement des citations sans attribution claire. Ce phénomène touche non seulement des sites web spécialisés en APT et cybercrime, mais également des pages LinkedIn influentes comptant plus de 30 000 abonnés, qui publient des rapports constitués à 90% de contenu copié.

L’évolution vers les feeds payants

Face à cette dégradation, les organisations se tournent de plus en plus vers des feeds CTI payants pour garantir la qualité de leurs sources. En France, par exemple, les investissements se portent sur des services comme Intel 471, Sekoia ou Mandiant (Google) afin de réduire le bruit et accroître la qualité des informations. Cette tendance s’est accentuée au cours des six dernières années, avec des coûts extrêmement élevés justifiés par le gain de temps considérable.

Les grands fournisseurs disposent d’avantages significatifs : accès privilégié au dark web, feeds multiples et informations obtenues avant tout le monde. Jordan estime qu’environ 10% seulement des articles disponibles publiquement présentent une maturité suffisante pour être exploitables, les 90% restants n’ayant pas accès à des sources de qualité.

Le rôle ambivalent de l’intelligence artificielle

L’IA constitue à la fois un problème et une solution potentielle. Du côté négatif, elle facilite la production massive de contenu de faible qualité, permettant de générer rapidement des articles en demandant simplement un condensé d’une source existante. Cependant, utilisée correctement, l’IA pourrait aider les analystes à filtrer le bruit informationnel en utilisant des recherches avancées avec des critères spécifiques (niveau technique, présence d’IOC, impact opérationnel).

Les problèmes de nomenclature et d’attribution

Jordan souligne également les mauvaises pratiques en matière de nomenclature des groupes malveillants. Les éditeurs d’antivirus utilisent leurs propres systèmes de nommage fantaisistes (comme “Midnight Blizzard” pour APT29), créant confusion et biais. Ces appellations marketing induisent des préjugés géographiques qui peuvent nuire à l’analyse objective.

L’attribution rapide et souvent erronée des campagnes à des groupes spécifiques constitue un autre problème majeur. L’exemple du ransomware-as-a-service Lockbit illustre cette difficulté : dès qu’on détecte des traces de Lockbit, l’attribution est faite au groupe principal, alors que l’outil peut avoir été acheté par des acteurs sans lien avec l’organisation d’origine.

L’importance des TTP versus les IOC

Jordan insiste sur la nécessité de se concentrer sur les TTP plutôt que sur les simples indicateurs de compromission (IOC). En référence à la pyramide de la douleur, les TTP représentent ce qu’il y a de plus difficile à changer pour un attaquant. Une adresse IP possède une durée de péremption très courte (un jour à une semaine maximum), tandis qu’une technique comme l’utilisation de fausses invitations à des dégustations de vin pour du phishing constitue un élément plus durable et exploitable pour la défense.

Conclusion

Ce podcast met en lumière une crise de qualité dans l’écosystème CTI qui menace l’efficacité des équipes de cybersécurité. La surabondance d’informations de faible qualité, couplée à la nécessité croissante de recourir à des sources payantes, transforme profondément le métier d’analyste CTI. Cependant, cette situation confirme également que l’expertise humaine reste indispensable pour distinguer le signal du bruit et effectuer des analyses pertinentes que l’IA ne peut pas encore remplacer.

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Signaux (xDR) dans l'univers des OT

2025-07-16T00:00:00-04:00

Parce que… c’est l’épisode 0x610!

Shameless plug

12 au 17 octobre 2025 - Objective by the sea v8
10 au 12 novembre 2025 - IAQ - Le Rendez-vous IA Québec
17 au 20 novembre 2025 - European Cyber Week
25 et 26 février 2026 - SéQCure 2026

Description

Introduction et contexte

Dans cet épisode technique du podcast, les participants explorent les défis complexes de l’implémentation des technologies de télémétrie de sécurité dans les environnements de technologie opérationnelle (OT). Ils abordent particulièrement la transposition des concepts familiers du monde IT, comme les EDR (Endpoint Detection and Response), XDR (Extended Detection and Response) et NDR (Network Detection and Response), vers l’univers industriel.

Les fondements de la télémétrie de sécurité

Les technologies de détection et de réponse reposent sur deux piliers principaux : la détection (génération de télémétrie intelligente) et la réponse (capacité d’intervention automatisée). Du côté IT, ces systèmes permettent d’intervenir sur les terminaux en les isolant ou en bloquant certaines actions, tandis qu’au niveau réseau, ils peuvent bloquer le trafic identifié comme malveillant. Cette approche, bien maîtrisée en IT, pose des défis considérables lorsqu’elle est transposée dans les environnements OT.

Les défis spécifiques à l’environnement OT

L’installation d’un EDR sur un automate industriel s’avère impossible, contrairement à un poste Windows traditionnel. Les équipements industriels génèrent une télémétrie primaire et limitée, rendant difficile l’extraction de signaux de sécurité pertinents. Les experts recommandent de se concentrer sur les actifs plus évolués fonctionnant sous Windows ou Linux, car la majorité des attaquants privilégient ces plateformes familières plutôt que les systèmes industriels propriétaires.

Cette approche s’appuie sur la “théorie du 99%”, qui stipule que les actifs IT ont une capacité de défense autonome contrairement aux actifs OT. Les attaques sophistiquées ciblant directement les systèmes industriels, comme Stuxnet ou Triton, demeurent exceptionnelles avec seulement quatre cas documentés en vingt ans. La plupart des incidents se limitent au niveau 3 du modèle de référence industriel, où se trouvent les serveurs et stations de travail Windows.

L’enjeu patrimonial et la durée de vie des équipements

L’environnement OT présente une caractéristique unique : la longévité exceptionnelle des équipements. Contrairement au monde IT où les systèmes sont régulièrement renouvelés, les installations industrielles peuvent fonctionner pendant 40 ans. Cette durée de vie étendue s’explique par les coûts élevés des équipements (plusieurs millions par pièce) et leur cycle de vie utile prolongé, particulièrement dans des secteurs comme la santé.

Cette situation crée des défis de sécurité considérables, certaines installations fonctionnant encore sur des systèmes obsolètes comme Windows 3.11 ou NT4. Les organisations développent parfois des solutions de contournement, comme l’isolement par air gap et la réinstallation périodique des stations de travail pour gérer les infections persistantes.

Complexité d’implémentation des EDR en OT

L’implémentation d’EDR dans l’environnement OT nécessite une analyse de risque approfondie. Le confinement automatique, fonction standard des EDR, peut s’avérer catastrophique dans un contexte industriel. Les experts rapportent des incidents où un fichier de programmation d’automate (ladder logic) a été incorrectement identifié comme malveillant, provoquant le confinement automatique d’un serveur critique.

La configuration des EDR en OT exige une adaptation minutieuse, notamment la désactivation des fonctions de réponse automatique. De plus, ces systèmes demandent des ressources significatives et ne peuvent pas être déployés sur des serveurs déjà saturés ou ayant des capacités limitées, situation fréquente dans l’industrie.

Défis de la télémétrie personnalisée

Contrairement aux systèmes IT où les événements sont standardisés, les automatismes industriels génèrent une télémétrie sur mesure. Il existe peu d’experts capables d’interpréter les signaux industriels pour détecter des anomalies sécuritaires. Cette analyse nécessite généralement l’expertise d’ingénieurs de procédé familiers avec les systèmes spécifiques.

Les solutions de surveillance passive existent mais requièrent un investissement considérable en configuration et en compréhension de l’environnement. L’établissement d’une baseline de trafic normal peut prendre près d’un an de travail pour atteindre un niveau de visibilité comparable à celui obtenu en IT.

Architecture et cloisonnement réseau

Le transfert des signaux OT vers les consoles IT pose des défis architecturaux majeurs. Les environnements industriels sont généralement cloisonnés, nécessitant la création de pipelines d’ingestion de données complexes. Ces systèmes de relais permettent de traverser les barrières réseau tout en maintenant la sécurité, mais rendent les projets de visibilité particulièrement laborieux.

La remontée des signaux vers une console de sécurité unifiée nécessite souvent une infrastructure dédiée côté OT, créant un “réseau dans le réseau” pour observer les systèmes cloisonnés depuis l’extérieur.

Contraintes des fournisseurs et garanties

Les fournisseurs d’équipements industriels imposent souvent des restrictions strictes sur les solutions de sécurité autorisées. Dans les installations récentes sous garantie, seules certaines solutions approuvées peuvent être déployées. Le non-respect de ces contraintes peut entraîner l’annulation de garanties couvrant parfois 10 à 15 ans d’exploitation.

Cette situation oblige les organisations à valider toute solution de sécurité en laboratoire avant le déploiement, avec une représentation miniature de l’environnement de production. Certains éditeurs d’EDR montrent peu d’affinité avec les environnements cloisonnés, privilégiant des approches IT traditionnelles.

Évolution vers le cloud et nouveaux paradigmes

L’industrie OT évolue progressivement vers des solutions cloud, même pour les scanners passifs traditionnellement conçus pour des environnements isolés. Cette transition soulève des questions sur l’ouverture contrôlée d’accès Internet dans les couches basses du modèle de Purdue, remettant en question l’isolement total historiquement privilégié.

Les solutions modernes nécessitent un flux continu de renseignements sur les menaces pour détecter efficacement les menaces émergentes. Le transport traditionnel de signatures s’avère trop lent face à l’évolution rapide des cybermenaces.

Perspectives et recommandations

Les experts recommandent de se concentrer sur la consolidation des journaux Windows et des événements SNMP comme point de départ pour améliorer la visibilité. Cette approche pragmatique permet d’obtenir rapidement des gains significatifs dans des environnements actuellement dépourvus de toute visibilité sécuritaire.

L’implémentation réussie de ces technologies requiert une collaboration étroite entre les équipes IT et OT, traditionnellement en tension. La cybersécurité en OT doit être perçue comme un mode de défaillance supplémentaire à surveiller, au même titre que les paramètres opérationnels traditionnels.

Conclusion

L’adaptation des technologies xDR aux environnements OT représente un défi multifacette nécessitant une approche sur mesure. Bien que les concepts IT puissent servir de base, leur transposition directe s’avère inadéquate. Le succès dépend d’une compréhension fine des contraintes industrielles, d’une analyse de risque rigoureuse et d’une architecture respectant les impératifs de sécurité et de continuité opérationnelle. L’évolution vers une visibilité sécuritaire complète en OT demeure un processus long et complexe, mais nécessaire face à l’évolution des menaces cybernétiques.

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Al Trust - Apprentissage automatique - Détection des modèles empoisonnés après entrainement

2025-06-25T00:00:00-04:00

Parce que… c’est l’épisode 0x604!

Shameless plug

12 au 17 octobre 2025 - Objective by the sea v8
10 au 12 novembre 2025 - IAQ - Le Rendez-vous IA Québec
17 au 20 novembre 2025 - European Cyber Week
25 et 26 février 2026 - SéQCure 2026

Description

Introduction et présentation de l’expert

Dans cet épisode spécial de “Police Sécure Cyber Éco”, Emmanuel Christian Nternanya, expert en cybersécurité d’origine congolaise, présente ses recherches révolutionnaires sur la détection de l’empoisonnement de modèles d’intelligence artificielle. Certifié CISSP avec plus d’une décennie d’expérience dans l’industrie informatique depuis 2012 et cinq années spécialisées en cybersécurité, Emmanuel apporte une expertise technique approfondie à un sujet critique pour l’avenir de l’IA.

Le problème de l’empoisonnement des modèles d’IA

L’empoisonnement de modèles d’IA représente une menace sophistiquée et souvent invisible. Contrairement à l’expérience utilisateur simplifiée que nous connaissons avec ChatGPT ou d’autres interfaces conversationnelles, la réalité technique est bien plus complexe. Chaque modèle d’IA possède un “cerveau” qui doit être entraîné avec des données pour acquérir ses capacités de prédiction et de classification.

Le principe fondamental est simple mais préoccupant : si un modèle est entraîné avec des données corrompues indiquant que 1+1=3, il reproduira fidèlement cette erreur. Les modèles d’IA ne font que reproduire ce qu’ils ont appris, sans capacité de discernement critique. Cette vulnérabilité ouvre la porte à des attaques sophistiquées où des adversaires peuvent corrompre intentionnellement les données d’entraînement.

La recherche d’Emmanuel démontre qu’il suffit parfois de contaminer seulement 1% des données d’entraînement pour réussir à modifier significativement le comportement d’un modèle. Cette découverte est particulièrement alarmante car elle révèle qu’une intervention minimale peut avoir des conséquences majeures, tout en restant pratiquement indétectable par les méthodes conventionnelles.

La solution innovante : le “docteur” en IA

Face à cette menace, l’équipe d’Emmanuel a développé une approche révolutionnaire : créer un “docteur” spécialisé dans le diagnostic des modèles d’IA. Ce système de détection peut identifier si un modèle a été empoisonné en analysant uniquement ses poids internes, sans avoir accès aux données d’entraînement originales.

La méthodologie de recherche s’appuie sur une approche rigoureuse et extensive. L’équipe a créé 1000 ensembles de données d’entraînement soigneusement vérifiés et non contaminés, puis a entraîné 1000 modèles correspondants. Parmi ces modèles, les 950 présentant les meilleures performances ont été sélectionnés pour l’analyse approfondie.

Le processus d’analyse se concentre sur l’architecture des réseaux de neurones convolutifs, particulièrement sur les trois couches denses et la couche de classification finale utilisant une fonction sigmoïde. Chaque couche contient des neurones qui apprennent et retiennent l’information sous forme de poids, des valeurs numériques représentant la connaissance acquise par le modèle.

La transformation des poids en images diagnostiques

L’innovation majeure réside dans la transformation des poids du modèle en images analysables. Emmanuel explique que les poids d’un modèle varient généralement entre -1 et 1, des valeurs difficiles à interpréter directement. L’équipe a développé un algorithme propriétaire capable de convertir ces poids en valeurs d’intensité d’image (de 1 à 255), créant ainsi des représentations visuelles des états internes du modèle.

Cette approche s’inspire de l’imagerie médicale : tout comme un cerveau humain peut être analysé par radiographie, le “cerveau” d’un modèle d’IA peut être “radiographié” en convertissant ses poids en images. Cette analogie n’est pas qu’une métaphore ; elle constitue la base technique de leur méthode de diagnostic.

Le système utilise deux docteurs spécialisés, chacun entraîné sur des images de dimensions différentes extraites de couches distinctes du modèle analysé. Le premier docteur analyse des images de 100x100 pixels, tandis que le second traite des images de 200x200 pixels. Cette approche multicouche permet une analyse plus complète et nuancée des modèles suspects.

L’apprentissage d’ensemble et les performances

La combinaison des deux docteurs spécialisés à travers l’apprentissage d’ensemble (ensemble learning) produit un diagnostic final plus précis que chaque docteur individuellement. Cette synergie permet d’atteindre des taux de réussite impressionnants de 98% à 99% dans la détection des modèles empoisonnés.

La validation de ces performances s’effectue sur des modèles que les docteurs n’ont jamais vus pendant leur entraînement. L’équipe utilise des bases de données publiques reconnues comme MNIST Fashion et des données de plaques d’immatriculation disponibles publiquement. Cette approche garantit l’objectivité des résultats et la capacité de généralisation du système.

Les défis de la détection à faible contamination

Cependant, la détection devient plus complexe lorsque le niveau de contamination diminue. À 1% de contamination, le taux de réussite chute à 77%, révélant les limites actuelles de la technologie. Cette limitation est critique car les adversaires sophistiqués privilégieront naturellement des niveaux de contamination faibles pour éviter la détection.

Emmanuel explique que l’amélioration de ces performances nécessite l’optimisation des hyperparamètres et l’exploration de nouvelles techniques d’apprentissage automatique. Néanmoins, il souligne un aspect rassurant : l’analyse du rapport signal/bruit révèle que les modèles empoisonnés à très faible niveau présentent souvent un bruit supérieur de 4% aux modèles sains, les rendant potentiellement inutilisables en pratique.

Applications critiques et enjeux sociétaux

L’importance de cette recherche transcende les aspects purement techniques. Emmanuel souligne les applications critiques où l’empoisonnement de modèles pourrait avoir des conséquences dramatiques : détection de cancer, diagnostic médical, reconnaissance de plaques d’immatriculation pour les systèmes de sécurité routière.

Il illustre ces risques par un exemple concret : un modèle empoisonné de reconnaissance de plaques pourrait identifier incorrectement le véhicule d’un délinquant en fuite, envoyant la convocation à une personne innocente. Ces erreurs ne sont pas de simples dysfonctionnements techniques, mais des failles de sécurité aux conséquences sociales et judiciaires importantes.

L’écosystème d’IA et ses vulnérabilités

Un aspect particulièrement préoccupant concerne l’écosystème actuel de l’IA. De nombreuses applications utilisent des APIs payantes comme celle de ChatGPT sans vérification de l’intégrité des modèles sous-jacents. Les développeurs intègrent ces services par confiance, sans moyens de vérifier si les modèles ont été compromis.

Cette situation crée une chaîne de vulnérabilités où la contamination d’un modèle central peut affecter des milliers d’applications dérivées. L’objectif d’Emmanuel est de fournir des outils forensiques permettant de vérifier l’intégrité des modèles avant leur mise en production, même sans accès complet au modèle original.

Perspectives et développements futurs

La recherche continue d’évoluer vers une meilleure adaptation aux différentes architectures de modèles. L’équipe développe des algorithmes capables d’ajuster automatiquement l’analyse en fonction de l’architecture spécifique de chaque modèle testé, améliorant ainsi la précision et la polyvalence du diagnostic.

Les travaux s’étendent également vers l’analyse de modèles publics disponibles sur des plateformes comme Hugging Face, bien que cette phase n’ait pas encore été complètement mise en œuvre. Cette extension permettrait de cartographier la prévalence réelle de l’empoisonnement dans l’écosystème d’IA public.

Conclusion et mission de sensibilisation

Au-delà des aspects techniques, Emmanuel porte une mission de sensibilisation cruciale. Il cherche à éveiller les consciences sur l’existence réelle des modèles empoisonnés et leurs implications. Alors que l’adoption de l’IA s’accélère dans tous les secteurs, la compréhension de ces vulnérabilités devient essentielle pour un déploiement sécurisé.

Cette recherche représente une contribution significative à la sécurisation de l’écosystème d’intelligence artificielle, offrant des outils concrets pour détecter et prévenir les attaques par empoisonnement de modèles, tout en sensibilisant la communauté aux enjeux critiques de sécurité dans l’ère de l’IA généralisée.

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par Cybereco

Teknik - Living Off the Pipeline - From Supply Chain 0-Days to Predicting the next XZ-like attacks

2025-06-18T00:00:00-04:00

Parce que… c’est l’épisode 0x602!

Shameless plug

27 et 29 juin 2025 - LeHACK
12 au 17 octobre 2025 - Objective by the sea v8
10 au 12 novembre 2025 - IAQ - Le Rendez-vous IA Québec
17 au 20 novembre 2025 - European Cyber Week
25 et 26 février 2026 - SéQCure 2026

Description

Introduction et contexte

François Proulx fait son retour pour présenter l’évolution de ses recherches sur la sécurité des chaînes d’approvisionnement (supply chain) depuis sa présentation de l’année précédente. Ses travaux portent sur la détection de vulnérabilités dans les pipelines de construction (build pipelines) des projets open source, un sujet qui avait suscité beaucoup d’intérêt suite à l’incident XZ Utils.

Évolution de la méthodologie de recherche

Depuis l’année dernière, l’équipe de François a considérablement amélioré ses outils et sa stratégie de détection. Plutôt que de scanner massivement tous les dépôts disponibles, ils ont adopté une approche plus ciblée en se concentrant sur des entités majeures comme Google, Red Hat, Nvidia et Microsoft. Ces organisations sont des contributeurs importants de projets open source critiques et bien maintenus.

Cette nouvelle approche leur permet de découvrir des centaines d’organisations GitHub par entité, chacune contenant parfois des milliers de dépôts. L’objectif reste le même : détecter des vulnérabilités zero-day dans les build pipelines qui permettent de compiler, tester et distribuer les projets open source, notamment via GitHub Actions.

La problématique fondamentale des CI/CD

François présente une analogie frappante pour expliquer la dangerosité des systèmes d’intégration continue : “un CI/CD, c’est juste du RCE as a service” (Remote Code Execution as a Service). Ces systèmes sont des applications web qui attendent de recevoir des déclencheurs sur une interface publique accessible via Internet. Dans le cas de GitHub Actions, il suffit d’ouvrir une pull request pour déclencher automatiquement l’exécution de tests.

Cette situation rappelle les vulnérabilités des années 1990-2000 avec les débordements de pointeurs. François utilise une formule percutante : “les build pipelines ressemblent à une application PHP moyenne de 2005 en termes de codage sécurisé”. Cette comparaison souligne que malgré les décennies d’évolution en sécurité informatique, les mêmes erreurs fondamentales se répètent dans de nouveaux contextes.

Les mécanismes d’exploitation

Les vulnérabilités exploitent principalement les entrées non fiables (untrusted input) provenant des pull requests. Même les brouillons de contributions peuvent déclencher automatiquement l’exécution de tests avant qu’un mainteneur soit notifié. Le problème s’aggrave quand les pipelines nécessitent des secrets pour communiquer avec des systèmes externes (notifications Slack, télémétrie, etc.).

Par défaut, GitHub Actions hérite parfois d’anciennes permissions en lecture-écriture, ce qui permet aux tests d’avoir accès à un token avec des droits d’écriture sur le dépôt. Cette configuration peut permettre à un attaquant d’écrire dans le dépôt de manière non visible.

Résultats impressionnants des analyses

L’équipe a considérablement affiné ses outils de détection. À partir de 200 000 résultats initiaux, ils appliquent des règles plus précises pour identifier environ 10 000 cas intéressants. Ces règles valident non seulement la présence de vulnérabilités, mais aussi les critères d’exploitation et la présence de secrets exploitables.

Après validation manuelle, environ 25% de ces 10 000 cas s’avèrent facilement exploitables. Ces chiffres démontrent l’ampleur du problème dans l’écosystème open source, même en reconnaissant l’existence probable de nombreux faux négatifs.

Cas concrets : Google et les régressions

François rapporte avoir découvert des vulnérabilités dans 22 dépôts appartenant à Google, notamment dans un projet lié à Google Cloud (probablement Data Flow). Après avoir signalé et reçu une récompense pour la correction, une régression est survenue une semaine plus tard dans le même workflow, leur valant une seconde récompense.

Cette situation illustre un problème récurrent : même les grandes organisations comme Google peuvent reproduire les mêmes erreurs après correction, souvent par méconnaissance des mécanismes sous-jacents de ces nouvelles techniques d’exploitation.

L’affaire Ultralytics : un cas d’école

L’incident le plus marquant concerne la bibliothèque Python Ultralytics, très populaire pour la détection d’images par apprentissage automatique. En août, l’équipe avait détecté une vulnérabilité dans ce projet mais s’était concentrée sur les découvertes chez Google, négligeant de signaler cette faille.

En décembre, Ultralytics a été compromis par l’injection d’un crypto-mineur, exploitant précisément la vulnérabilité identifiée quatre mois plus tôt. Cette attaque était particulièrement ingénieuse car elle ciblait des environnements avec des GPU puissants (utilisés pour le machine learning), parfaits pour le minage de cryptomonnaies, tout en restant discrète dans un contexte où une forte consommation GPU est normale.

Pivot vers la détection proactive

Cet incident a motivé un changement stratégique majeur : passer de la simple détection de vulnérabilités à la détection proactive d’exploitations en cours. L’équipe ingère désormais le “firehose” des événements publics GitHub, soit environ 5,5 millions d’événements quotidiens.

Après filtrage sur les projets critiques avec des build pipelines, ils analysent environ 500 000 événements intéressants par jour. En appliquant leurs analyses sophistiquées et en croisant avec leurs connaissances des vulnérabilités, ils obtiennent environ 45 événements suspects à investiguer quotidiennement.

Validation forensique avec Kong

Cette nouvelle approche s’est rapidement avérée efficace. Pendant les vacances de Noël, leur système a continué d’ingérer les données automatiquement. Au retour, l’incident Kong (un contrôleur Ingress pour Kubernetes) leur a permis de créer une timeline forensique détaillée grâce aux données accumulées pendant leur absence.

Découverte sur les forums cybercriminels

La collaboration avec Flare, spécialisée dans l’analyse du dark web, a révélé des informations troublantes. En recherchant “Ultralytics” sur Breach Forum avec un filtrage temporel précis, François a découvert qu’un utilisateur avait créé un compte 24 heures avant l’attaque, publié exactement la vulnérabilité du pipeline Ultralytics en mentionnant l’utilisation de “Poutine” (leur outil), puis confirmé 24 heures après l’exploitation avoir gagné des Monero grâce à cette attaque.

Cette découverte confirme que les cybercriminels utilisent activement les outils de recherche en sécurité pour identifier et exploiter des vulnérabilités, transformant ces outils défensifs en armes offensives.

Implications et recommandations

Cette situation soulève des questions importantes sur la responsabilité des chercheurs en sécurité. François insiste sur le fait que Poutine, leur outil de détection, devrait devenir le minimum absolu pour tout projet open source. Il compare cette nécessité à l’interdiction d’avoir des dépôts Git pour ceux qui n’implementent pas ces vérifications de base.

L’analogie avec PHP 2005 reste pertinente : il a fallu des années pour que la communauté PHP matûrisse ses pratiques de sécurité. Les build pipelines traversent actuellement la même phase d’évolution, avec des erreurs fondamentales répétées massivement dans l’écosystème.

Défis techniques et limites

François reconnaît honnêtement les limitations de leur approche. Leur système ne détecte que les attaques les moins sophistiquées - des “low hanging fruits”. Des attaques complexes comme celle de XZ Utils ne seraient probablement pas détectées par leurs outils actuels, car elles sont trop bien camouflées.

Le défi principal reste de filtrer efficacement le bruit dans les millions d’événements quotidiens pour obtenir un nombre d’alertes gérable par une petite équipe d’analystes. Ils reconnaissent que la majorité des incidents leur échappe probablement encore.

Perspective d’avenir

François exprime l’espoir que la maturation de l’écosystème des build pipelines sera plus rapide que les 20 ans qu’il a fallu pour sécuriser PHP. Leur travail de pionnier contribue à cette évolution en sensibilisant la communauté et en fournissant des outils concrets.

L’angle d’analyse des build pipelines est particulièrement pertinent car il se situe à la croisée des chemins entre le code source et sa distribution, avec des possibilités d’exécution de code qui en font un point critique de la chaîne d’approvisionnement logicielle.

Cette présentation illustre parfaitement l’évolution rapide des menaces dans l’écosystème open source moderne et la nécessité d’une vigilance constante pour sécuriser les infrastructures critiques dont dépend l’ensemble de l’industrie logicielle.

Notes

François Proulx

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par Northsec

Teknik - Résultat de l'usage de l'IA dans le contexte d'un CtF (Northsec)

2025-06-10T00:00:00-04:00

Parce que… c’est l’épisode 0x598!

Shameless plug

12 au 17 octobre 2025 - Objective by the sea v8
10 au 12 novembre 2025 - IAQ - Le Rendez-vous IA Québec
17 au 20 novembre 2025 - European Cyber Week
25 et 26 février 2026 - SéQCure 2026

Description

Introduction et contexte

Ce podcast technique présente un retour d’expérience fascinant sur l’utilisation de l’intelligence artificielle lors du NorthSec CTF (Capture The Flag), l’un des plus importants événements de cybersécurité en Amérique du Nord. L’animateur s’entretient avec Mickael Nadeau, qui partage son expérience de l’intégration massive de l’IA dans les compétitions de sécurité informatique.

L’évolution spectaculaire de l’IA dans les CTF

Une transformation radicale

Mickael souligne une évolution majeure depuis leur dernier enregistrement il y a deux ans. Alors qu’à l’époque l’IA était encore balbutiante dans le domaine des CTF, elle est devenue aujourd’hui un outil incontournable qui change fondamentalement la dynamique de ces compétitions. Cette transformation s’est révélée particulièrement frappante lors du NorthSec de cette année.

Intégration pratique de ChatGPT

L’un des aspects les plus remarquables rapportés est l’utilisation intensive de ChatGPT par les participants. Un membre de l’équipe de Mickael s’est présenté avec une tablette dédiée exclusivement à ChatGPT, l’utilisant pour prendre des notes, analyser des problèmes et combler ses lacunes en matière de connaissances sécuritaires. Cette approche a permis à des participants moins expérimentés de rester productifs et compétitifs tout au long de l’événement.

Les défis techniques spécifiques du NorthSec

La complexité IPv6

Le NorthSec se distingue par son utilisation délibérée d’IPv6, un choix stratégique des organisateurs pour complexifier les défis et sortir les participants de leur zone de confort. Cette particularité a créé des situations où même les participants expérimentés comme Mickael se sont retrouvés en difficulté, ayant oublié les spécificités des outils compatibles IPv6 après deux ans d’absence.

L’IA comme solution aux lacunes techniques

Face à ces défis techniques, l’IA s’est révélée être un allié précieux. Les participants ont pu interroger ChatGPT sur les outils compatibles IPv6, obtenir des explications sur des concepts complexes et recevoir des suggestions d’approches qu’ils n’auraient pas nécessairement envisagées seuls. Cette assistance a considérablement réduit le temps habituellement consacré à la consultation de documentation technique.

L’impact sur l’analyse et le reverse engineering

Analyse de fichiers simplifiée

L’une des révolutions les plus marquantes concerne l’analyse de fichiers et le reverse engineering. Mickael décrit comment il était possible de simplement télécharger un fichier dans un outil alimenté par l’IA et obtenir instantanément une analyse détaillée. Cette capacité a particulièrement impressionné l’équipe, permettant d’extraire des métadonnées, d’identifier des méthodes de chiffrement et de décompiler des fichiers Linux sans avoir besoin de l’environnement technique traditionnel.

Génération d’hypothèses

L’IA excelle dans la génération d’hypothèses créatives. Plutôt que de remplacer l’expertise humaine, elle complète la réflexion en proposant des pistes que les participants n’auraient pas forcément explorées. Cette collaboration homme-machine s’est révélée particulièrement efficace pour débloquer des situations complexes et accélérer la résolution de défis.

Les outils et plateformes émergentes

Évolution des outils en ligne

Mickael observe une prolifération d’outils en ligne intégrant l’IA, permettant d’effectuer des tâches complexes directement dans un navigateur. Cette évolution est particulièrement avantageuse pour les utilisateurs de MacBook, traditionnellement désavantagés dans les CTF par rapport aux environnements Linux. La possibilité de dropper simplement un fichier et d’obtenir une analyse automatique représente un changement de paradigme majeur.

Les MCP (Model Context Protocol)

Bien que Mickael n’ait pas eu l’opportunité d’utiliser pleinement les MCP pendant le CTF, il exprime un vif intérêt pour cette technologie. Il envisage de développer des chaînes MCP spécifiquement configurées pour les besoins du NorthSec, notamment pour automatiser les phases de reconnaissance et l’analyse IPv6.

Démocratisation de la participation

L’un des effets les plus remarquables de l’intégration de l’IA concerne l’aspect social des CTF. Mickael rapporte que cette édition a été la plus collaborative qu’il ait jamais vécue. L’IA a permis de niveler les compétences, permettant à des participants moins expérimentés de contribuer efficacement et de rester engagés tout au long de l’événement.

Fin de l’isolement technique

Traditionnellement, les CTF pouvaient créer des situations où certains participants se retrouvaient isolés, incapables de suivre le rythme ou de contribuer aux discussions techniques. L’IA a brisé ces barrières en permettant à chacun d’obtenir rapidement les informations nécessaires pour participer aux échanges et proposer des solutions.

Maintien de l’engagement

Pour la première fois de son expérience, Mickael observe que tous les membres de l’équipe sont restés motivés et impliqués jusqu’à la fin de l’événement. Cette constance dans l’engagement contraste fortement avec les éditions précédentes où certains participants décrochaient face à la complexité des défis.

Défis et limitations

Limites des garde-fous

Malgré les avancages considérables, l’IA présente encore des limitations. Les garde-fous intégrés dans les systèmes peuvent parfois empêcher certaines opérations légitimes dans le contexte d’un CTF. Mickael envisage d’utiliser des instances locales ou des environnements cloud dédiés pour contourner ces restrictions.

Risque de sur-dépendance

Bien que non explicitement mentionné, la discussion suggère la nécessité de maintenir un équilibre entre l’utilisation de l’IA et le développement des compétences fondamentales. L’IA accélère l’apprentissage mais ne remplace pas la compréhension profonde des concepts sécuritaires.

Perspectives d’avenir

Préparation pour 2025

Mickael exprime son désir de mieux se préparer pour la prochaine édition en développant des outils MCP spécialisés et en explorant davantage les plateformes en ligne émergentes. Il envisage également de s’entraîner sur des CTF en ligne pour perfectionner ses techniques d’intégration de l’IA.

Évolution technologique rapide

Les intervenants soulignent la rapidité d’évolution du domaine. Ce qui semblait impossible il y a quelques années devient routine, et ils anticipent des changements encore plus drastiques d’ici la prochaine édition du NorthSec.

Conclusion

Cette expérience du NorthSec 2024 illustre une transformation fondamentale dans l’approche des compétitions de cybersécurité. L’IA ne remplace pas l’expertise humaine mais la démultiplie, rendant les CTF plus accessibles, plus collaboratifs et paradoxalement plus éducatifs. Cette évolution pourrait attirer de nouveaux participants et revitaliser l’intérêt pour ces événements, tout en maintenant leur caractère technique et challengeant.

L’enthousiasme de Mickael pour cette nouvelle approche est palpable, et sa suggestion d’enregistrer en direct lors du prochain CTF témoigne de la dimension sociale renforcée de ces événements. L’IA semble avoir réussi le pari de rendre les CTF à la fois plus techniques et plus humains, une contradiction apparente qui pourrait bien définir l’avenir de la cybersécurité collaborative.

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Vivez votre Première Key Ceremony - La Clé pour Sécuriser les Données Stratégiques de votre Entreprise

2025-06-09T00:00:00-04:00

Parce que… c’est l’épisode 0x597!

Shameless plug

12 au 17 octobre 2025 - Objective by the sea v8
10 au 12 novembre 2025 - IAQ - Le Rendez-vous IA Québec
17 au 20 novembre 2025 - European Cyber Week
25 et 26 février 2026 - SéQCure 2026

Description

Ce podcast spécial Cybereco réunit Dominique Derrier et Thomas Veynachter pour explorer l’univers méconnu mais crucial des key ceremonies (cérémonies de clés). Cette discussion révèle l’existence d’un processus de sécurité fondamental qui protège notre quotidien numérique, bien que moins de 0,1% de la population en connaisse l’existence.

Un phénomène d’une rareté exceptionnelle

Les key ceremonies représentent un phénomène d’une rareté stupéfiante dans le monde de la cybersécurité. Comme le souligne Dominique, expert en sécurité informatique qui se présente comme le “moldu” de la table face à Thomas, véritable expert du domaine, seulement 0,04% à 0,1% de la population sait ce qu’est une key ceremony. Pour donner une perspective, ce pourcentage équivaut approximativement au nombre de personnes possédant un jet privé personnel ou ayant terminé tous les jeux Mario à 100% sur toutes les plateformes.

Cette rareté crée un paradoxe fascinant : ces cérémonies sont essentielles au fonctionnement de notre société numérique, mais restent totalement invisibles pour le grand public. Même des professionnels de la cybersécurité (CISO) peuvent ignorer leur existence, créant un véritable défi de communication et de sensibilisation.

L’infrastructure invisible de notre confiance numérique

Les key ceremonies constituent l’épine dorsale de notre écosystème numérique. Chaque transaction bancaire, chaque connexion sécurisée (HTTPS), chaque paiement sans contact s’appuie sur cette infrastructure cryptographique. Quand nous effectuons un paiement avec notre téléphone, des échanges de clés complexes se déroulent en arrière-plan en quelques secondes, garantissant que notre argent arrive au bon destinataire.

L’exemple d’Apple illustre parfaitement cette omniprésence invisible. La PKI (Public Key Infrastructure) d’Apple distribue et renouvelle automatiquement des millions de certificats de manière transparente. Quand un certificat expire - comme cela est arrivé à de grands opérateurs de messagerie - les conséquences peuvent être dramatiques pour les utilisateurs.

L’art et la science de la génération de clés

Une key ceremony n’est pas un simple “meeting de gestion de clés”. Le terme “cérémonie” évoque intentionnellement un processus solennel, ritualisé, où chaque étape est cruciale. Ces événements peuvent durer plusieurs heures et nécessitent des semaines de préparation minutieuse.

Le processus commence par la vérification de l’intégrité physique des équipements. Les HSM (Hardware Security Modules) arrivent dans des cartons scellés avec des étiquettes de sécurité numérotées. Chaque sceau, chaque numéro est vérifié pour s’assurer qu’aucune altération n’a eu lieu pendant le transport. Cette vigilance reflète les principes de sécurité de la chaîne d’approvisionnement poussés à l’extrême.

La génération de la clé racine (root key) constitue le moment le plus critique. Cette clé maîtresse, souvent stockée offline dans des coffres-forts physiques, sert de fondation à toute la chaîne de confiance. Comme l’explique Thomas avec une métaphore parlante : “Si vous coupez la racine de l’arbre, la petite feuille qui vous est utile dans votre transaction ne marchera plus.”

Une orchestration humaine complexe

Les key ceremonies réunissent jusqu’à quinze personnes aux rôles spécialisés et complémentaires :

Le maître de cérémonie supervise l’ensemble du processus et garantit le respect strict du protocole. Contrairement aux fantasmes, il ne porte ni toge ni chapeau, mais sa responsabilité est immense : s’assurer que ce qui était souhaité a été correctement livré.

Les opérateurs manipulent les équipements et saisissent les commandes. Par sécurité, ils ne travaillent jamais seuls et possèdent chacun une partie du mot de passe administrateur, appliquant le principe de la double authentification.

Les témoins valident l’intégrité du processus et s’assurent qu’aucune collusion n’a lieu entre les participants.

Les porteurs de secrets détiennent chacun une fraction de la clé maîtresse, généralement selon le principe de Shamir. Ce mécanisme mathématique permet de diviser un secret en plusieurs parts (souvent 7) tout en établissant un quorum (par exemple 5 sur 7) nécessaire pour reconstituer la clé. Cette approche garantit qu’aucune personne seule ne peut compromettre le système, tout en maintenant une redondance si certains porteurs perdent leur part.

Les défis logistiques et humains

L’organisation d’une key ceremony représente un défi logistique considérable. Réunir simultanément treize personnes de différents départements ou organisations, s’assurer qu’elles ont toutes leurs documents d’identité (un oubli classique qui peut reporter toute la cérémonie), coordonner leurs agendas sur plusieurs semaines… Chaque détail compte car une erreur, même minime, oblige à tout recommencer.

L’environnement physique ajoute une contrainte supplémentaire. Ces cérémonies se déroulent souvent dans des cages de Faraday ou des data centers aux conditions spartanes. La ventilation limitée, les allées chaudes et froides des centres de données, l’isolement électromagnétique… Les participants endurent ces conditions pendant des heures, témoignant de l’importance critique du processus.

La sécurité poussée à son paroxysme

Les key ceremonies appliquent tous les principes de cybersécurité fondamentaux, mais portés à leur extrême. Le hachage cryptographique permet de vérifier l’intégrité des clés : chaque caractère du hash est lu lettre par lettre et vérifié par tous les participants. Cette vérification, bien que fastidieuse, garantit que tous ont vu la même clé et qu’elle correspond exactement à celle stockée dans l’équipement.

La séparation des connaissances (split knowledge) empêche qu’une seule personne détienne tous les éléments. La défense en profondeur multiplie les couches de sécurité : isolation physique, contrôle d’accès, vérification de l’intégrité, authentification multiple, témoins indépendants…

Les conséquences catastrophiques des compromissions

L’impact d’une compromission de clé racine dépasse l’entendement. L’exemple de Symantec, dont la valorisation a chuté de dix fois suite à une perte de confiance, ou celui de certificats révoqués par Google illustrent les enjeux financiers colossaux.

Si la clé racine d’Apple était compromise, des millions d’appareils perdraient leur certification. Si celle d’une banque majeure était altérée, c’est tout le système de transactions qui s’effondrerait. La durée de vie maximale de tous les certificats dérivés est limitée par celle de la clé racine : si elle expire, tout l’écosystème doit être reconstruit.

L’échange de clés : Un écosystème interconnecté

Les key ceremonies ne servent pas uniquement à créer des clés, mais aussi à les échanger de manière sécurisée entre organisations. Les connexions entre banques et forces de l’ordre pour les enquêtes financières, les échanges entre administrations, les interconnexions entre systèmes critiques… Tout cela nécessite des cérémonies d’extraction et d’intégration de clés.

Quand nous nous plaignons que les services d’impôts ne communiquent pas avec ceux de la santé, la cause peut être l’absence de key ceremony appropriée ou le manque de maturité organisationnelle pour en conduire une.

Les héros méconnus de la sécurité numérique

Les participants aux key ceremonies forment une communauté restreinte et discrète. Ils ne portent pas de t-shirt proclamant “Je connais toutes les clés maîtresses de la banque” et n’affichent pas cette expertise sur leur CV, car cela en ferait des cibles potentielles. Pourtant, ces professionnels dévoués sacrifient leur temps, endurent des conditions difficiles et assument d’énormes responsabilités pour maintenir la sécurité de notre infrastructure numérique.

Paradoxalement, beaucoup de participants ne comprennent pas entièrement l’importance de leur rôle. Cette ignorance relative constitue une protection supplémentaire : ils suivent scrupuleusement les procédures sans subir la pression psychologique que pourrait exercer la connaissance complète des enjeux.

L’innovation au service de la tradition

Malgré leur caractère traditionnel et ritualisé, les key ceremonies évoluent avec les technologies. L’introduction de coffres-forts à double accès, les nouvelles méthodes de vérification d’intégrité, l’amélioration des HSM… Ces innovations permettent d’ajouter des couches de sécurité supplémentaires tout en respectant les principes fondamentaux.

Le principe de la défense en profondeur reste central : si un attaquant brise une couche de sécurité, sept autres l’attendent. Cette redondance, bien que coûteuse et complexe, constitue le seul moyen de protéger des secrets d’une valeur inestimable.

Vers une démocratisation des bonnes pratiques

L’objectif de Dominique et Thomas dépasse la simple sensibilisation. Ils souhaitent que les professionnels de la cybersécurité s’inspirent des key ceremonies pour améliorer leurs pratiques quotidiennes. Sans aller jusqu’aux extrêmes de ces cérémonies, adopter certains principes - vérification d’intégrité, séparation des privilèges, témoignage indépendant - pourrait considérablement renforcer la sécurité des organisations.

Cette présentation au Cyberecho vise également à rendre hommage aux acteurs méconnus de cette discipline. En reconnaissant publiquement leur contribution essentielle à notre sécurité collective, ils espèrent encourager une prise de conscience plus large de l’importance de ces processus.

Conclusion : L’invisible fondation de notre monde numérique

Les key ceremonies incarnent parfaitement le paradoxe de notre époque numérique : les processus les plus critiques restent les plus invisibles. Ces cérémonies, menées par une poignée d’experts dévoués, constituent les fondations invisibles sur lesquelles repose notre confiance numérique quotidienne.

Leur rareté même - 0,04% de la population - souligne à la fois leur importance critique et la nécessité urgente de sensibiliser davantage de professionnels à leur existence. Car comprendre les key ceremonies, c’est comprendre les enjeux véritables de la cybersécurité moderne et l’extraordinaire complexité des systèmes qui protègent notre vie numérique.

Dans un monde où chaque clic, chaque paiement, chaque connexion dépend de ces cérémonies secrètes, il devient essentiel de reconnaître et de célébrer le travail remarquable de ceux qui, dans l’ombre des data centers, perpétuent ces rituels technologiques garants de notre sécurité collective.

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par Cybereco

Teknik - Tout ce que vous avez toujours voulu savoir sur la cryptographie post-quantique sans jamais oser le demander

2025-06-02T00:00:00-04:00

Parce que… c’est l’épisode 0x594!

Shameless plug

03 au 05 juin 2025 - Infosecurity Europe
27 et 29 juin 2025 - LeHACK
12 au 17 octobre 2025 - Objective by the sea v8
10 au 12 novembre 2025 - IAQ - Le Rendez-vous IA Québec
17 au 20 novembre 2025 - European Cyber Week
25 et 26 février 2026 - SéQCure 2026

Description

Introduction et présentation de l’invité

Ce podcast spécial Cybercho accueille Thierry Marier-Bienvenue, directeur en évolution de la cybersécurité chez Desjardins. Fort de son expertise dans plusieurs domaines clés, il supervise notamment la connaissance des actifs, la cryptographie, la sécurité en milieu utilisateur, la sensibilisation ainsi que la réponse aux menaces avec l’orchestration et l’automatisation des réponses. Sa présentation s’inscrit dans le cadre de Cyberco, où il aborde le volet cryptographique, un élément fondamental sur lequel repose la confiance de notre société.

Les fondements de la cryptographie

Pour établir les bases de la discussion, Thierry explique les deux types principaux de cryptographie à travers des analogies simples. La cryptographie asymétrique fonctionne comme “une clé et un cadenas” : une personne place son message dans le cadenas qu’elle ferme, et seule la personne possédant la clé correspondante peut l’ouvrir. Cette méthode utilise souvent des certificats, des clés et des signatures numériques. La cryptographie symétrique, quant à elle, implique que les deux parties partagent la même clé, ce qui présente des défis logistiques considérables lorsque les distances géographiques sont importantes.

La sécurité de ces systèmes cryptographiques repose sur un problème mathématique fondamental : la complexité de factoriser de grands nombres. Si passer de la clé au cadenas est relativement facile, faire le chemin inverse - du cadenas vers la clé - représente une complexité computationnelle énorme avec les ordinateurs classiques actuels.

L’émergence de la menace quantique

L’informatique quantique bouleverse cette équation sécuritaire traditionnelle. Contrairement aux ordinateurs classiques, les ordinateurs quantiques possèdent la capacité remarquable de factoriser des grands nombres très rapidement grâce à leur capacité de traitement en parallèle. Ils peuvent effectuer simultanément des essais sur plusieurs nombres, rendant ainsi le processus de “passer du cadenas à la clé” considérablement plus facile et rapide.

Cette capacité représente une menace directe pour la cryptographie asymétrique actuellement utilisée, car elle remet en question les fondements mathématiques sur lesquels repose la sécurité de nos systèmes d’information. Ce qui prenait des milliers d’années à calculer avec un ordinateur classique pourrait potentiellement être résolu en quelques heures ou jours avec un ordinateur quantique suffisamment puissant.

Impact sur le secteur financier

Le secteur financier se trouve particulièrement vulnérable face à cette évolution technologique. Comme l’explique Thierry, les institutions financières fonctionnent sur un principe fondamental : la confiance. Cette confiance repose entièrement sur la cryptographie qui sécurise l’ensemble de l’écosystème financier numérique.

La cryptographie est omniprésente dans les opérations financières quotidiennes. Les guichets automatiques chiffrent leurs transactions jusqu’aux centres de traitement, les sites web des institutions financières utilisent des certificats pour garantir leur authenticité, les bases de données sensibles sont chiffrées, et même chaque ordinateur du réseau est identifié par des certificats numériques. Chez Desjardins, avec ses 55 000 employés, on compte déjà des millions de certificats rien que pour les équipements de base, sans compter les serveurs, les dispositifs IoT, les caméras de surveillance et les terminaux de paiement.

Cette infrastructure cryptographique massive représente à la fois une protection essentielle et une surface d’attaque considérable. Si la confiance dans ces systèmes venait à être ébranlée par une capacité de déchiffrement quantique, les conséquences pourraient inclure des retraits massifs (bank runs) et une déstabilisation complète du système financier.

Défis de gestion cryptographique

La gestion de cette infrastructure cryptographique massive présente des défis organisationnels considérables. Comme l’explique Thierry, il est impossible d’avoir 30 000 personnes dédiées uniquement à cette gestion. La solution réside dans l’automatisation et la standardisation des processus.

L’approche adoptée consiste à traiter les certificats comme des actifs informatiques avec un cycle de vie complet. Chaque certificat est considéré comme un “configuration item” dans le système ITSM (IT Service Management), avec un propriétaire désigné et des processus de gestion standardisés. L’automatisation de l’émission des certificats devient indispensable compte tenu du volume à gérer.

Un défi particulier réside dans la gestion des clés cryptographiques, plus complexe que celle des certificats qui expirent naturellement. Changer une clé présente toujours des risques : si quelque chose ne fonctionne pas correctement, il faut pouvoir effectuer une restauration, mais si la clé de sauvegarde est perdue, les données chiffrées deviennent inaccessibles. De plus, le “shadow IT” - ces systèmes créés de manière non officielle par les employés - peut créer des clés qui ne suivent pas les standards organisationnels, nécessitant des efforts de découverte et de standardisation.

Les dangers spécifiques et les modèles d’attaque

Thierry identifie deux risques principaux liés à l’informatique quantique. Premièrement, le “harvest now, decrypt later” - l’accumulation actuelle de données chiffrées par des acteurs malveillants en prévision de leur futur déchiffrement quantique. Deuxièmement, l’utilisation directe d’ordinateurs quantiques pour briser la cryptographie en temps réel.

Il est important de noter que cette menace ne viendra probablement pas d’individus isolés. Le développement et l’opération d’ordinateurs quantiques capables de briser la cryptographie nécessitent des ressources énergétiques phénoménales et des connaissances spécialisées que seuls des États-nations ou de grandes organisations peuvent mobiliser. La menace provient donc principalement d’acteurs étatiques, avec une attention particulière portée aux investissements chinois dans ce domaine (10 milliards de dollars US en 2020).

Stratégies de préparation et crypto-agilité

Face à cette menace, le concept de “crypto-agilité” devient central. Cette approche consiste à développer la capacité organisationnelle de répondre rapidement aux changements cryptographiques, qu’ils soient dus à des percées quantiques ou à d’autres évolutions technologiques.

Un exemple concret de cette nécessité d’agilité s’est manifesté récemment quand Google a annoncé qu’il ne ferait plus confiance aux certificats émis par une autorité de certification spécifique à partir de novembre. Malgré la part de marché relativement limitée de cette autorité, les organisations ont dû réagir rapidement pour migrer vers d’autres fournisseurs de certificats, démontrant l’importance de maîtriser son inventaire cryptographique et sa capacité de réaction.

La préparation implique plusieurs étapes stratégiques : d’abord, avoir une vision claire de sa surface d’attaque cryptographique ; ensuite, prioriser la protection selon les niveaux de risque en s’assurant de protéger rapidement les “crown jewels” (terminaux de paiement, guichets automatiques, sites de transaction) ; enfin, réduire progressivement la posture de risque de manière stratégique.

Évolution des standards et algorithmes post-quantiques

Le National Institute of Standards and Technology (NIST) a récemment certifié trois ou quatre algorithmes résistants aux attaques quantiques. Cependant, cette résistance reste théorique - “résistante jusqu’à preuve du contraire” - car les capacités de test réelles sont limitées et coûteuses. De plus, ces algorithmes pourraient devenir obsolètes rapidement, nécessitant une capacité d’adaptation continue.

Les nouveaux algorithmes post-quantiques présentent également des défis techniques : ils requièrent davantage de puissance de traitement que les algorithmes traditionnels, ce qui représente des coûts supplémentaires en termes de performance et d’infrastructure.

Impact économique et organisationnel

La transition vers la cryptographie post-quantique représente un investissement majeur. Selon plusieurs experts cités par Thierry, environ 10% des budgets de maintenance informatique devront être consacrés à cette transition. Cette proportion s’ajoute aux budgets déjà alloués à la cybersécurité, représentant un défi financier considérable pour les organisations.

Les investissements nécessaires incluent la mise à jour des bibliothèques cryptographiques, la refonte partielle ou totale d’applications, la formation du personnel, et l’acquisition de nouveaux équipements compatibles avec les algorithmes post-quantiques. Pour les institutions financières, ces investissements sont incontournables car ils touchent au cœur de leur modèle d’affaires basé sur la confiance.

Cas particuliers et vulnérabilités

Certains secteurs présentent des vulnérabilités particulières. Les systèmes avec des cycles de vie très longs - satellites, pacemakers, infrastructures militaires - où les clés cryptographiques doivent rester sécurisées pendant 10, 15 ou 20 ans, représentent des défis particuliers car il est souvent impossible de les mettre à jour facilement.

De nombreuses organisations utilisent encore des algorithmes cryptographiques obsolètes comme SHA-1, démontrant un niveau de maturité insuffisant face aux enjeux actuels et futurs. Cette situation révèle l’ampleur du travail nécessaire pour amener l’ensemble des organisations à un niveau de préparation adéquat.

Leviers de transformation du marché

Les grandes organisations comme Desjardins jouent un rôle crucial dans l’accélération de l’adoption des technologies post-quantiques. En intégrant des exigences de résistance quantique dans leurs contrats avec les fournisseurs, elles créent un effet d’entraînement qui force l’ensemble du marché à évoluer. Cette approche contractuelle représente un levier efficace pour élever le niveau de sécurité général, car les entreprises souhaitant maintenir leurs relations commerciales doivent s’adapter aux nouvelles exigences.

Conclusion et perspectives

La menace quantique sur la cryptographie n’est plus une question de “si” mais de “quand”. L’imprévisibilité du rythme de développement des technologies quantiques - illustrée par les changements de position d’experts comme le CEO de Nvidia - rend crucial le principe de préparation immédiate.

La recommandation principale de Thierry est claire : commencer dès maintenant à se préparer, s’éduquer sur ces enjeux, et développer les capacités organisationnelles nécessaires pour réagir rapidement quand la transition deviendra urgente. Cette préparation inclut la compréhension des menaces, l’identification des solutions disponibles (algorithmes post-quantiques, HSM compatibles), et surtout le développement d’une culture de crypto-agilité au sein des organisations.

L’objectif n’est pas de créer une panique, mais de sensibiliser les décideurs et les équipes techniques pour qu’ils développent un vocabulaire commun et une compréhension partagée de ces enjeux critiques pour l’avenir de la sécurité numérique.

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par Cybereco

Teknik - L'IA dans le contexte d'un CtF (Northsec)

2025-05-21T00:00:00-04:00

Parce que… c’est l’épisode 0x590!

Shameless plug

03 au 05 juin 2025 - Infosecurity Europe
27 et 29 juin 2025 - LeHACK
12 au 17 octobre 2025 - Objective by the sea v8
10 au 12 novembre 2025 - IAQ - Le Rendez-vous IA Québec
17 au 20 novembre 2025 - European Cyber Week
25 et 26 février 2026 - SéQCure 2026

Description

Ce podcast explore l’évolution de l’utilisation de l’intelligence artificielle dans les compétitions de type Capture The Flag (CTF) en cybersécurité, comparant la situation actuelle à celle d’il y a environ deux ans lorsque les outils d’IA étaient encore peu développés.

L’évolution des outils d’IA en cybersécurité

Mickael Nadeau constate que les outils d’IA se sont considérablement développés, particulièrement aux États-Unis, avec des intégrations de plus en plus sophistiquées. Ces nouveaux outils offrent:

Une automatisation avancée
Des systèmes de permissions permettant de contrôler les actions de l’IA
La capacité de désassembler des applications et d’étiqueter les fonctions

Alors qu’auparavant, les modèles comme GPT-3.5/3.7 commençaient tout juste à comprendre le code de façon cohérente, l’évolution actuelle permet d’avoir des agents autonomes capables d’interagir avec un ensemble d’outils pour accomplir des tâches complexes. Cette évolution marque une différence majeure avec l’expérience précédente où l’impact de l’IA dans les CTF était marginal.

L’IA comme outil pour le reverse engineering

L’un des aspects les plus prometteurs est l’utilisation de l’IA pour faciliter le travail de décompilation et de reverse engineering, un domaine traditionnellement aride qui demande beaucoup de temps:

L’IA peut annoter les fonctions dans le code désassemblé
Elle permet de gagner un temps considérable sur les tâches répétitives
Des outils comme Kaido intègrent déjà des plugins IA pour faciliter l’analyse

Impact sur les compétitions CTF

Les participants discutent comment cette évolution technologique pourrait transformer les CTF:

Avantage compétitif: Les équipes qui savent intégrer l’IA à leur processus pourraient gagner un avantage substantiel sur leurs concurrents.
Équilibre entre automatisation et plaisir du jeu: Si l’IA automatise trop le processus, cela risque d’enlever le plaisir principal des CTF qui est de résoudre des puzzles. Une question éthique se pose: jusqu’où automatiser sans perdre l’essence de ces compétitions?
Retour potentiel à une dimension plus sociale: Paradoxalement, Mickael suggère que l’IA pourrait rendre les CTF plus sociaux en:
- Automatisant les tâches mécaniques que les experts maîtrisent déjà
- Libérant du temps pour que ces experts se concentrent sur des défis inconnus
- Favorisant le brainstorming collectif pour résoudre les problèmes complexes

Expérience personnelle avec des CTF “intelligents”

Mickael partage son expérience de conception de challenges CTF intégrant de l’IA:

Ils ont créé des défis où un pare-feu intelligent s’adaptait aux attaques des participants
La première année, une seule équipe a réussi à atteindre 90% du parcours
Ces défis ont forcé les participants à vraiment comprendre les mécanismes de sécurité plutôt que d’appliquer des scripts préfabriqués
Différents types de challenges ont été conçus, y compris des clones d’applications réelles avec des vulnérabilités et des jeux interactifs (comme le jeu de tarot mentionné)

Plans pour le prochain CTF

Pour le prochain NSec CTF, Mickael prévoit:

D’installer LM Studio sur une de ses machines
D’explorer l’intégration d’outils sans filtres AI pour éviter les limitations des modèles commerciaux
De potentiellement développer des scripts personnalisés qui pourraient donner un avantage
De tester si l’évolution des outils permet désormais d’obtenir un impact significatif, contrairement à son expérience précédente

Réflexion sur l’avenir des CTF

Les intervenants concluent que les CTF devront évoluer face à ces nouvelles technologies:

Les organisateurs devront créer des défis qui restent pertinents malgré l’automatisation
Les participants devront trouver un équilibre entre l’utilisation d’outils IA et la résolution manuelle des problèmes
L’aspect social et collaboratif pourrait prendre plus d’importance, ramenant l’esprit initial des CTF

Le podcast se termine sur la promesse d’un futur épisode pour discuter des résultats de cette expérimentation lors du prochain NSec CTF.

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par Northsec

Teknik - Revue de code - ChatGPT face aux vulnérabilités OWASP Top 10

2025-05-13T00:00:00-04:00

Parce que… c’est l’épisode 0x586!

Shameless plug

10 au 18 mai 2025 - NorthSec
03 au 05 juin 2025 - Infosecurity Europe
27 et 29 juin 2025 - LeHACK
12 au 17 octobre 2025 - Objective by the sea v8
10 au 12 novembre 2025 - IAQ - Le Rendez-vous IA Québec
17 au 20 novembre 2025 - European Cyber Week
25 et 26 février 2026 - SéQCure 2026

Description

Introduction et contexte de la recherche

Gabriel St-Hilaire, enseignant au Cégep Seigneur de Sichel depuis une dizaine d’années et spécialiste en développement d’applications web, a mené une recherche dans le cadre de sa maîtrise en cybersécurité à l’Université de Sherbrooke. Sa recherche porte sur l’utilisation de ChatGPT pour aider au développement sécuritaire.

La problématique qui a motivé cette recherche est simple : pourquoi les programmeurs continuent-ils à faire des erreurs de sécurité dans leur code malgré l’enseignement des bonnes pratiques ? Pour répondre à cette question, Gabriel a exploré la littérature scientifique et identifié trois constats majeurs :

Les programmeurs en entreprise cherchent à déléguer la responsabilité de la sécurité, pensant que quelqu’un d’autre fera la revue de code et trouvera les problèmes.
La cybersécurité passe souvent au second plan, sacrifiée au profit des délais et des fonctionnalités à livrer rapidement.
Il existe un manque de connaissances : même quand des outils signalent des problèmes de sécurité, les développeurs ne savent pas comment les résoudre.

État actuel des méthodes de détection

Gabriel a ensuite examiné l’efficacité des méthodes actuelles pour détecter les vulnérabilités :

Les revues de code par des pairs ont un taux de détection inférieur à 50%, et même ceux qui trouvent les vulnérabilités ne savent souvent pas comment les corriger.
Les outils d’analyse statique de sécurité sont encore moins efficaces, avec un taux de détection moyen d’environ 18% (35% pour les meilleurs outils). Ces outils ont également un taux élevé de faux positifs et se concentrent souvent sur certaines catégories de vulnérabilités au détriment d’autres.

Potentiel de l’intelligence artificielle

Face à ces lacunes, Gabriel s’est intéressé au potentiel de l’intelligence artificielle pour améliorer la détection des vulnérabilités. Deux éléments sont ressortis de ses recherches :

Des modèles d’IA spécialisés peuvent être très performants (jusqu’à 98% de taux de détection) pour des types spécifiques de vulnérabilités comme les injections SQL, mais ne sont pas adaptés à la variété de technologies et vulnérabilités rencontrées en pratique.
L’IA générative, particulièrement GPT-4, montre une excellente compréhension du code (97% de taux de compréhension), même lorsque le code est obscurci (87%).

Gabriel souligne que l’IA générative présente un double avantage : non seulement elle peut analyser le code, mais elle permet aussi d’entamer un dialogue pour comprendre les problèmes détectés, ce qui en fait un excellent outil pédagogique.

Méthodologie de la recherche

Pour tester l’efficacité de ChatGPT dans un contexte réaliste, Gabriel a :

Développé une application PHP de base sans failles de sécurité
Ajouté 86 vulnérabilités différentes dans des fonctionnalités réalistes
Soumis ces modifications à ChatGPT en lui demandant de faire une revue de code de sécurité
Demandé à ChatGPT d’identifier les lignes problématiques, de décrire les vulnérabilités et de fournir les codes CWE (Common Weakness Enumeration) correspondants

Résultats et conclusions

Les résultats ont été analysés selon trois critères :

“Trouvé” : ChatGPT a identifié la ligne problématique, donné la bonne description et le bon code CWE
“Partiellement trouvé” : ChatGPT a identifié la ligne et la bonne description, mais pas le bon code CWE
“Non trouvé” : ChatGPT n’a pas détecté la vulnérabilité

ChatGPT a atteint un taux de détection complète (avec le bon code CWE) d’environ 17-19%, ce qui est faible. Cependant, en incluant les détections partielles, le taux monte à environ 56%, ce qui est supérieur aux revues de code humaines et aux outils d’analyse statique actuels.

Limites et perspectives

Gabriel a identifié plusieurs limites et pistes d’amélioration :

La documentation des codes CWE est inégale, ce qui complique la tâche de ChatGPT pour les classifier correctement.
ChatGPT a du mal à détecter les vulnérabilités qui concernent l’absence de quelque chose (comme l’absence de journalisation).
La nature non déterministe de ChatGPT pose problème pour une utilisation rigoureuse en entreprise (résultats différents pour la même question).
Le manque de contexte lors de l’analyse de modifications de code isolées peut conduire à des faux positifs.

Pour améliorer ces résultats, Gabriel suggère :

Fournir plus de contexte à ChatGPT (l’ensemble du projet)
Réduire le paramètre de température de ChatGPT pour avoir des réponses plus déterministes
Poser des questions plus spécifiques pour détecter les vulnérabilités liées à l’absence de certains mécanismes
Explorer des modèles d’IA plus spécialisés ou personnalisés (RAG)

Cette recherche ouvre la voie à une meilleure intégration de l’IA dans les processus de développement sécuritaire, non seulement pour détecter les vulnérabilités mais aussi pour aider les développeurs à les comprendre et les corriger.

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par Cybereco

Teknik - Cyberdéfense en profondeur - Naviguer dans les défis de cybersécurité des technologies multi-environnements

2025-05-07T00:00:00-04:00

Parce que… c’est l’épisode 0x584!

Shameless plug

10 au 18 mai 2025 - NorthSec
03 au 05 juin 2025 - Infosecurity Europe
27 et 29 juin 2025 - LeHACK
12 au 17 octobre 2025 - Objective by the sea v8
10 au 12 novembre 2025 - IAQ - Le Rendez-vous IA Québec
17 au 20 novembre 2025 - European Cyber Week
25 et 26 février 2026 - SéQCure 2026

Description

Dans ce podcast, Omar Abdul-Wahab, professeur adjoint à Polytechnique Montréal spécialisé en cybersécurité et cyberdéfense, présente le concept crucial de la défense en profondeur dans un contexte technologique moderne et complexe.

La défense en profondeur à l’ère des technologies convergentes

Omar souligne que le concept de défense en profondeur n’est plus un luxe mais une nécessité absolue dans un environnement où les entreprises utilisent simultanément des infrastructures TI traditionnelles, des services cloud, des objets connectés (IoT) et l’intelligence artificielle. La complexité croissante de ces environnements multitechnologiques exige une approche de sécurité qui prend en compte les spécificités de chaque couche et leurs interactions.

Les défis par couche technologique

1. Infrastructure TI traditionnelle

Omar identifie trois défis majeurs :

Les mécanismes d’évasion de détection : Les attaquants exploitent désormais la confiance en utilisant des applications légitimes pour mener leurs attaques. Il cite l’exemple d’applications légitimes appelant des DLL malveillantes, échappant ainsi aux systèmes de détection traditionnels qui se fient à la légitimité de l’application parent.
La fatigue face aux alertes (alert fatigue) : Les professionnels de la cybersécurité sont submergés par un volume excessif d’alertes, dont la majorité sont des faux positifs, ce qui les épuise avant qu’une véritable attaque ne survienne.
Le besoin d’automatisation dans le triage des alertes et la génération de playbooks pour les réponses aux incidents.

Pour répondre à ces défis, Omar suggère :

Développer des systèmes de détection capables de faire des corrélations plus complexes, analysant non seulement la légitimité des applications mais aussi les séquences d’appels API et d’autres indicateurs contextuels.
Utiliser le machine learning pour améliorer l’automatisation du triage des alertes et la contextualisation des menaces.

2. Environnement Cloud

Le cloud présente des défis spécifiques qui diffèrent de l’infrastructure TI traditionnelle :

L’élasticité : La capacité de créer et supprimer rapidement des ressources (containers, machines virtuelles) complique le suivi des logs et la détection d’activités malveillantes.
L’architecture basée sur les API : Omar cite l’attaque de Capital One en 2019, où les attaquants ont exploité les API cloud sans avoir besoin de déployer un malware traditionnel.
Les infrastructures définies par code (Infrastructure as Code) qui évoluent constamment.

Solutions proposées :

Développer des modèles de menaces spécifiques au cloud qui tiennent compte de son caractère dynamique.
Automatiser la modélisation des menaces pour s’adapter aux changements constants de l’environnement cloud.
Concevoir des systèmes de détection et des playbooks de réponse adaptés aux spécificités du cloud.

3. Internet des Objets (IoT)

L’IoT présente des défis encore plus distincts :

L’hétérogénéité extrême des appareils et des données qu’ils échangent, rendant difficile l’application de solutions de sécurité uniformes.
La faible sécurisation native de nombreux appareils IoT (mots de passe par défaut, etc.).
La vulnérabilité aux attaques physiques due à l’accessibilité des appareils.
Le manque de renseignements sur les menaces (threat intelligence) spécifiques à l’IoT.

Omar suggère de combiner des approches mathématiques et de machine learning pour développer des solutions plus généralisables et adaptables à l’hétérogénéité de l’IoT.

4. Intelligence Artificielle (IA)

L’IA, tout en étant un outil de défense, présente elle-même des risques de sécurité, notamment :

Les attaques furtives (stealthy) comme l’injection de backdoors dans les modèles, difficiles à détecter car elles ne s’activent que sous certaines conditions spécifiques (triggers).
Ces attaques peuvent passer inaperçues pendant l’entraînement et les tests, ne se manifestant qu’en production.

Face à la difficulté de détecter ces attaques, Omar recommande de se concentrer sur la résilience : entraîner les modèles à résister aux attaques en injectant délibérément des backdoors simulés pendant l’entraînement pour renforcer leur robustesse.

Conclusion

Omar Abdul-Wahab conclut en insistant sur l’importance d’une véritable architecture de cyberdéfense en profondeur intégrant les spécificités de chaque couche technologique et leurs interactions. Dans un monde où les organisations utilisent nécessairement plusieurs de ces couches simultanément, comprendre leurs vulnérabilités particulières et développer des stratégies de défense adaptées est crucial pour une cybersécurité efficace.

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par Cybereco

SéQCure/Teknik - Analyse et enseignements d’attaques sur le Cloud

2025-04-30T00:00:00-04:00

Parce que… c’est l’épisode 0x582!

Shameless plug

10 au 18 mai 2025 - NorthSec
03 au 05 juin 2025 - Infosecurity Europe
27 et 29 juin 2025 - LeHACK
12 au 17 octobre 2025 - Objective by the sea v8
10 au 12 novembre 2025 - IAQ - Le Rendez-vous IA Québec
17 au 20 novembre 2025 - European Cyber Week
25 et 26 février 2026 - SéQCure 2026

Description

Ce podcast aborde les défis de sécurité liés à la migration vers l’infonuagique (cloud computing) et les incidents qui en découlent. Cédric Thibault, expert en sécurité cloud chez KPMG, partage son expertise sur les tendances actuelles en matière de cyberattaques ciblant les environnements cloud.

Tendances des incidents infonuagiques

L’augmentation des incidents de sécurité dans l’infonuagique suit logiquement la migration massive des charges de travail vers ces environnements. Selon les statistiques partagées :

45% des brèches de données sont désormais liées aux environnements infonuagiques (2024)
Environ 80% des entreprises ont subi une violation de données dans le cloud au cours des 18 derniers mois
Les applications SaaS représentent 31% des incidents recensés

Cette tendance s’explique par le fait que les données et les charges de travail se sont massivement déplacées vers le cloud, notamment accélérées par la période de confinement, attirant naturellement l’attention des attaquants.

Le modèle de responsabilité partagée mal compris

Un des problèmes majeurs identifiés est la mauvaise compréhension du modèle de responsabilité partagée. De nombreuses organisations migrent vers le cloud pour des raisons de sécurité mais oublient que les fournisseurs cloud ne sécurisent que leur infrastructure et non ce que les clients y déploient.

Cette confusion est particulièrement prononcée pour les services SaaS où les clients pensent, à tort, que toute la sécurité est prise en charge par le fournisseur. Cédric compare les outils de sécurité cloud à une “boîte à outils” mise à disposition, qui reste inutile si personne ne s’en sert correctement.

Principaux vecteurs d’attaque observés

1. Compromission des identités

L’identité est devenue la nouvelle frontière de sécurité dans le cloud, remplaçant les pare-feu traditionnels. Les problèmes majeurs incluent :

Surabondance de privilèges (95% des permissions attribuées ne sont jamais utilisées)
Utilisation de politiques gérées trop permissives
Équipes de gestion des identités et accès (GIA) mal outillées et formées pour ce nouveau paradigme

Un exemple concret partagé : un client utilisant uniquement M365 s’est fait compromettre via un compte disposant de permissions pour créer des souscriptions Azure, permettant à l’attaquant de déployer des ressources pour du crypto-mining.

2. Erreurs de configuration

Les erreurs de configuration, notamment des stockages cloud (buckets S3, blobs, etc.), restent un vecteur d’attaque important :

Exposition accidentelle de données sensibles
Manque de contrôles pour vérifier la sensibilité des données stockées
Confiance excessive dans le tagging manuel sans vérification automatisée

3. Serveurs exposés et vulnérables

Les serveurs exposés avec des authentifications faibles permettent aux attaquants d’accéder à la couche de gestion cloud, notamment via :

Serveurs RDP avec mots de passe faibles accessibles depuis Internet
Identités associées aux serveurs avec trop de privilèges

4. Attaques sur les pipelines CI/CD

Un vecteur émergent concerne les attaques ciblant les pipelines d’intégration et déploiement continus :

Compromission des identités des développeurs
Insertion de code malveillant dans les pipelines
Déploiement d’images de conteneurs compromises
Persistance garantie via les mécanismes de redémarrage automatique

Exploitation par les attaquants

Les attaquants profitent pleinement des avantages du cloud :

Automatisation massive (scripts de déploiement multi-régions)
Cryptomining à grande échelle (déploiement de centaines de conteneurs simultanément)
Améliorations des techniques de phishing grâce à l’IA générative
Simplicité d’utilisation des API de gestion cloud pour le mouvement latéral

Recommandations

Cédric suggère plusieurs approches pour améliorer la sécurité :

Mieux comprendre et appliquer le modèle de responsabilité partagée
Renforcer la gestion des identités et des privilèges
Implémenter des mécanismes de découverte automatisée de données sensibles
Sécuriser les pipelines CI/CD avec des processus de validation rigoureux
Automatiser la détection et la réponse aux incidents
Développer une véritable culture de sécurité des données

Cette transition vers le cloud nécessite un changement culturel et une évolution des pratiques de sécurité, au-delà des simples outils techniques.

Notes

Cédric Thibault

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Identité dans l'univers des TO

2025-04-16T00:00:00-04:00

Parce que… c’est l’épisode 0x577!

Préambule

Nous avons rencontré quelques problèmes de stabilité avec l’enregistrement de Camille.

Shameless plug

10 au 18 mai 2025 - NorthSec
03 au 05 juin 2025 - Infosecurity Europe
27 et 29 juin 2025 - LeHACK
12 au 17 octobre 2025 - Objective by the sea v8
10 au 12 novembre 2025 - IAQ - Le Rendez-vous IA Québec
17 au 20 novembre 2025 - European Cyber Week
25 et 26 février 2026 - SéQCure 2026

Description

Ce podcast, animé par Nicolas-Loïc avec les invités Camille Felx-Leduc et Steve Bélanger, aborde la gestion de l’identité dans les environnements OT (technologies opérationnelles) par rapport aux environnements IT (technologies de l’information).

Les défis de l’Active Directory (AD) en environnement OT

Les intervenants soulignent que l’Active Directory, conçu pour les environnements bureautiques, a été transposé dans les environnements industriels, créant plusieurs problèmes :

L’AD est intrinsèquement complexe et difficile à sécuriser correctement
Sa configuration requiert une expertise spécifique souvent absente des équipes OT
La rétrocompatibilité excessive de l’AD permet l’utilisation de protocoles obsolètes (NTLM v1, SMB v1)
La synchronisation temporelle est critique - un décalage de plus de 5 minutes entre systèmes peut corrompre l’AD
L’organisation par défaut des AD n’est pas optimale pour la sécurité (objets placés dans “Computers” plutôt que dans des unités organisationnelles)

Les tensions entre sécurité et opérations

Le podcast met en lumière les contradictions entre les exigences de sécurité IT et les réalités opérationnelles :

Les politiques de changement fréquent de mots de passe deviennent problématiques pour les opérateurs en usine portant des équipements de protection
Les verrouillages automatiques de session après 15 minutes sont inadaptés aux environnements industriels où les opérateurs peuvent travailler plusieurs heures sur un même poste
Les contrôles d’accès physiques déjà en place dans les installations industrielles sont souvent ignorés dans la conception des politiques de sécurité

La conception centrée sur l’humain

Les participants soulignent l’importance d’adapter les solutions de sécurité au contexte d’utilisation :

Les solutions doivent être conçues en observant les opérateurs dans leur environnement réel de travail
Les badges d’accès pourraient servir de jetons d’authentification dans certains contextes industriels
La sécurité doit tenir compte des contraintes physiques (gants, masques, environnements extrêmes)
Le principe du “capitaine à bord” dans certains environnements OT (un opérateur responsable pendant son quart) offre une couche de contrôle humain qui peut compenser certaines limites techniques

Les vulnérabilités spécifiques aux environnements OT

Le podcast identifie plusieurs pratiques problématiques :

La réutilisation des mêmes identifiants entre environnements IT et OT
L’utilisation excessive des comptes administrateurs par défaut (“admin/admin”)
La gestion déficiente des comptes de service
Les architectures qui permettent d’accéder directement aux données des systèmes OT depuis l’IT
L’absence de documentation des identités utilisées

Les bonnes pratiques recommandées

Les intervenants proposent plusieurs solutions :

Séparer les AD des environnements IT et OT
Privilégier une architecture où les données sont “poussées” de l’OT vers l’IT plutôt que “tirées”
Implémenter des DMZ et respecter le modèle Purdue pour la segmentation réseau
Adapter les politiques de sécurité aux réalités opérationnelles
Faire des tests de pénétration adaptés aux environnements OT
Terminer automatiquement les sessions inactives après une période raisonnable

Conclusion

La discussion souligne l’importance d’une meilleure collaboration entre les équipes IT et OT. Les intervenants notent que les environnements industriels, souvent situés dans des zones éloignées, peuvent avoir des difficultés à attirer des talents en cybersécurité. Ils mentionnent l’émergence de services gérés pour les environnements OT, similaires aux MSP (Managed Service Providers) en IT, comme une solution potentielle à ce défi.

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

SéQCure/Teknik - Au-delà du maliciel de type infostealer - vecteurs d’infection, les actifs dérobés inusités et les contre-mesures

2025-03-19T00:00:00-04:00

Parce que… c’est l’épisode 0x569!

Shameless plug

2 au 4 avril 2025 - Humaco
8 et 9 avril 2025 - Cybereco
10 au 18 mai 2025 - NorthSec
03 au 05 juin 2025 - Infosecurity Europe
27 et 29 juin 2025 - LeHACK
12 au 17 octobre 2025 - Objective by the sea v8
10 au 12 novembre 2025 - IAQ - Le Rendez-vous IA Québec
17 au 20 novembre 2025 - European Cyber Week
25 et 26 février 2026 - SéQCure 2026

Description

Dans ce podcast, l’hôte s’entretient avec Olivier Bilodeau au sujet des “information stealers” (voleurs d’informations), un type de logiciel malveillant qui représente une menace cybernétique significative mais souvent sous-estimée.

Qu’est-ce qu’un Info Stealer?

Les “information stealers” sont des logiciels malveillants qui extraient des données sensibles d’un ordinateur infecté. Contrairement aux ransomwares ou aux malwares traditionnels qui cherchent à se déplacer latéralement dans un réseau, ces logiciels se concentrent sur l’extraction rapide et complète de toutes les données personnelles accessibles par l’utilisateur. Le résultat d’une telle infection est appelé “stealer log”.

Contenu typique d’un Stealer Log

Un stealer log contient généralement:

Les identifiants et mots de passe stockés dans les navigateurs
Les données d’auto-remplissage des formulaires
Les informations personnelles et professionnelles
Les cookies de session
Des captures d’écran du poste de travail
Des informations système (RAM, système d’exploitation, logiciels installés)
Des fichiers spécifiques (documents, PDFs, bases de données de mots de passe)
Les informations liées aux extensions de navigateur, notamment les générateurs TOTP (codes d’authentification à deux facteurs)
Potentiellement des portefeuilles de cryptomonnaies

Méthode d’opération

Ces logiciels sont conçus pour:

Infecter rapidement un poste
Extraire toutes les données sensibles
Envoyer ces données (souvent via Telegram) aux cybercriminels
S’auto-effacer sans laisser de traces

Ce modèle “sans persistance” est radicalement différent des malwares traditionnels qui cherchent à s’installer durablement dans un système.

Écosystème criminel

Olivier explique l’écosystème derrière ces logiciels:

Des développeurs créent des “builders” (générateurs) de malware
Des distributeurs personnalisent et diffusent ces malwares via différents vecteurs d’infection
Les données volées sont ensuite vendues en gros sur des plateformes comme Telegram
Des “checkers” automatisés permettent de tester la validité des identifiants volés

Fait intéressant, la méfiance règne entre ces cybercriminels, au point où certains infectent délibérément leurs collègues.

Vecteurs d’infection

Les vecteurs d’infection typiques incluent:

Des sites proposant des versions “gratuites” de logiciels payants
Des “cracks” de logiciels
Des chaînes YouTube promettant des ressources gratuites (comme des Robux pour Roblox)
Des versions “gratuites” d’outils IA populaires comme MidJourney

Ces méthodes ciblent particulièrement les personnes cherchant à obtenir gratuitement des services normalement payants.

Impact et risques

L’impact de ces attaques est considérable:

Un tiers des violations de données impliquent des identifiants volés
Les données dérobées sont récentes et donc plus dangereuses que les bases d’identifiants plus anciennes
Les sessions actives (via les cookies) permettent un accès immédiat aux comptes des victimes
Les risques sont particulièrement élevés pour les services sans authentification à deux facteurs
Les ordinateurs professionnels contenant des données d’entreprise représentent des cibles de choix

Travail de Flaire et recherches d’Olivier

Olivier travaille chez FLIR, qui possède une base de données de plus de 70 millions de stealer logs. Son travail consiste à:

Analyser ces données pour comprendre les tendances et menaces
Développer des API pour aider les entreprises à détecter rapidement si leurs informations ont été compromises
Rechercher des vulnérabilités dans les gestionnaires de mots de passe
Créer des outils pour tester automatiquement les identifiants potentiellement compromis

Recommandations de sécurité

Olivier recommande:

Ne pas laisser les enfants utiliser les ordinateurs professionnels
Utiliser l’authentification à deux facteurs quand c’est possible
Se méfier des offres “trop belles pour être vraies”
Comprendre que les antivirus traditionnels ont du mal à suivre ces menaces

Recherches futures

Olivier prévoit de poursuivre ses recherches sur:

La vulnérabilité des gestionnaires de mots de passe face à ces attaques
L’analyse automatisée des captures d’écran pour identifier rapidement les vecteurs d’infection
L’impact sur les portefeuilles de cryptomonnaies

Cette menace persistante évolue constamment et nécessite une vigilance accrue tant de la part des individus que des entreprises.

Notes

Olivier Bilodeau

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par Cybereco

Teknik - La suite du 20%... une solution technique pour les journaux :-)

2025-03-12T00:00:00-04:00

Parce que… c’est l’épisode 0x567!

Shameless plug

2 au 4 avril 2025 - Humaco
8 et 9 avril 2025 - Cybereco
10 au 18 mai 2025 - NorthSec
03 au 05 juin 2025 - Infosecurity Europe
27 et 29 juin 2025 - LeHACK
12 au 17 octobre 2025 - Objective by the sea v8
Novembre 2025 - European Cyber Week
25-26 février 2026 - SéQCure 2026

Description

Dans ce podcast, Nicolas partage son expérience de “20%” chez Google, une initiative permettant aux employés de consacrer 20% de leur temps à des projets connexes à leur travail principal. Il explique son rôle d’OPM (Outbound Product Manager) pour Google Cloud Security (GCS) et détaille le lancement récent d’une nouvelle fonctionnalité appelée Data Pipeline Management.

Le concept du “20%” chez Google

Nicolas précise que le “20%” représente en réalité du temps supplémentaire (120% au total) consacré à un projet bénéfique pour l’entreprise ou l’humanité. Dans son cas, il a commencé ce projet en août, devenant OPM pour la branche cybersécurité de Google Cloud, travaillant spécifiquement avec les produits de sécurité agnostiques du cloud, qui ne nécessitent pas d’être client Google Cloud.

Le rôle d’Outbound Product Manager (OPM)

L’OPM sert de pont entre différentes équipes :

Les product managers (responsables produit)
Les équipes marketing
Les équipes terrain (vendeurs, ingénieurs clients)
Les clients
Les firmes d’analystes (Gartner, Forrester)

Sa mission consiste à coordonner ces différents acteurs pour assurer le succès des produits. Nicolas explique que ce rôle est généralement occupé à temps plein par plusieurs personnes chez Google, et qu’il l’a adopté à temps partiel dans le cadre de son “20%”.

Le lancement du Data Pipeline Management

Le 4 février, Google a annoncé une nouvelle fonctionnalité pour SecOps (anciennement Chronicle), leur plateforme de sécurité opérationnelle. Nicolas explique que SecOps est un SIEM (Security Information and Event Management) concurrent de Splunk, QRadar et autres solutions populaires, mais qui se distingue par l’utilisation de l’IA et de l’infrastructure Google pour une ingestion de données efficace.

Le Data Pipeline Management répond à un problème crucial : la collecte et le filtrage des logs. Avant cette solution, les clients devaient utiliser des outils tiers ou open source comme Fluent, ce qui engendrait plusieurs défis :

La gestion complexe des agents de collecte
La maintenance des systèmes hébergeant ces agents
La gestion des données sensibles qui contaminent le système
Les contraintes réglementaires (PCI, HIPAA, etc.)
Les coûts élevés liés au stockage de données non pertinentes

Le partenariat avec Bind Plane

Pour résoudre ces problèmes, Google a établi un partenariat avec Bind Plane, une plateforme spécialisée dans la collecte de logs. Ce partenariat offre aux clients Enterprise et Enterprise Plus de SecOps des licences Bind Plane sans frais additionnels, leur permettant de :

Déployer facilement des agents de collecte
Transformer les données (masquer les informations sensibles)
Filtrer les logs avant ingestion dans le SIEM
Réduire les coûts de stockage et améliorer les performances

Cette solution répond à des besoins concrets confirmés par des retours de terrain. Nicolas mentionne qu’un partenaire intégrateur a constaté que Bind Plane accélérait considérablement les déploiements de SecOps, notamment dans le secteur bancaire où les régulations sont strictes.

La contribution de Nicolas en tant qu’OPM

Dans le cadre de ce lancement, Nicolas a :

Créé de la documentation complète pour les partenaires et les ingénieurs clients
Organisé des sessions de formation pour les équipes de vente
Servi de pont entre les équipes produit et les clients
Traduit les fonctionnalités techniques en solutions à des problèmes concrets

Il souligne l’importance de se concentrer sur les problèmes des clients plutôt que sur la technologie elle-même. Son expérience terrain lui permet de comprendre les défis réels des utilisateurs et d’orienter les équipes produit vers des solutions pertinentes.

Bénéfices personnels et professionnels

Nicolas considère que ce “20%” lui apporte beaucoup :

Une compréhension approfondie du développement produit
Une vision plus large des enjeux de priorisation
Un enrichissement de ses compétences principales
Une position privilégiée pour suivre l’évolution de la sécurité

Il envisage de poursuivre ce projet au-delà de l’engagement initial d’un an, car il trouve l’expérience extrêmement enrichissante et stimulante. Cette initiative illustre comment la curiosité et l’implication dans des projets transverses peuvent nourrir la passion professionnelle et potentiellement ouvrir de nouvelles voies de carrière.

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par Cage

Teknik - Les TO dans le nuage?

2025-03-05T00:00:00-05:00

Parce que… c’est l’épisode 0x565!

Shameless plug

2 au 4 avril 2025 - [Humaco]
8 et 9 avril 2025 - Cybereco
10 au 18 mai 2025 - NorthSec
12 au 17 octobre 2025 - Objective by the sea v8
Novembre 2025 - European Cyber Week
25-26 février 2026 - SéQCure 2026

Description

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Takedown de Redline

2025-02-26T00:00:00-05:00

Parce que… c’est l’épisode 0x563!

Préambule

Shameless plug

2 au 4 avril 2025 - [Humaco]
8 et 9 avril 2025 - Cybereco
10 au 18 mai 2025 - NorthSec
12 au 17 octobre 2025 - Objective by the sea v8
Novembre 2025 - European Cyber Week
25-26 février 2026 - SéQCure 2026

Description

Notes

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - YARA

2025-02-19T11:00:00-05:00

Parce que… c’est l’épisode 0x561!

Shameless plug

26-27 février 2025 - SéQCure 2025

Description

Notes

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - International AI Safety Report

2025-02-17T00:00:00-05:00

Parce que… c’est l’épisode 0x558!

Shameless plug

26-27 février 2025 - SéQCure 2025

Description

Notes

International AI Safety Report

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par 3 Brasseurs Ste-Foy

Teknik - Edge computing

2025-02-12T00:00:00-05:00

Parce que… c’est l’épisode 0x556!

Shameless plug

26-27 février 2025 - SéQCure 2025

Description

Notes

À venir

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par Cage

English/Teknik - NorthSec Infrastructure

2025-01-27T00:00:00-05:00

Parce que… c’est l’épisode 0x547!

Préambule

Épisode enregistré en anglais, avec mon anglais quelque peu douteux. Parfois, il faut se lancer, même lorsque nous ne sommes pas prêts. C’est une occasion de remettre mon anglais à un niveau, disons plus acceptable ;-)

Episode recorded in English, with my somewhat questionable English. Sometimes you just have to do it, even if you’re not ready. This is an opportunity to bring my English up to a more, shall we say, acceptable level ;-)

Shameless plug

26-27 février 2025 - SéQCure 2025

Description

Notes

NorthSec

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - OpSec à la sauce Flare

2025-01-13T00:00:00-05:00

Parce que… c’est l’épisode 0x541!

Shameless plug

26-27 février 2025 - SéQCure 2025

Description

Notes

À venir

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Le navigateur web et protection avancée en entreprise

2024-12-25T00:00:00-05:00

Parce que… c’est l’épisode 0x536!

Shameless plug

26-27 février 2025 - SéQCure 2025
9-11 avril 2025 - Google Next ‘25

Description

Notes

À venir

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par 3 Brasseurs Ste-Foy

Teknik - Le HSM... passé au microscope électronique!

2024-11-27T00:00:00-05:00

Parce que… c’est l’épisode 0x524!

Shameless plug

5-6 décembre 2024 - Objective by the Sea
26-27 février 2025 - SéQCure 2025
9-11 avril 2025 - Google Next ‘25

Description

Notes

À venir

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par Intrasecure inc

Teknik - Évolution du point terminal (endpoint), la livraison d'application et sa sécurité

2024-11-25T00:00:00-05:00

Parce que… c’est l’épisode 0x523!

Shameless plug

5-6 décembre 2024 - Objective by the Sea
26-27 février 2025 - SéQCure 2025
9-11 avril 2025 - Google Next ‘25

Description

Notes

À venir

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par 3 Brasseurs Ste-Foy

Teknik - OT - L'encadrement normatif et règlementaire

2024-11-06T00:00:00-05:00

Parce que… c’est l’épisode 0x518!

Shameless plug

18-21 novembre 2024 - European Cyber Week
19-20 novembre 2024 - C&ESAR
20-21 novembre 2024 - CAID
5-6 décembre 2024 - Objective by the Sea
26-27 février 2025 - SéQCure 2025
9-11 avril 2025 - Google Next ‘25

Description

Notes

À venir

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Gestion d'incident en infonuagique

2024-10-21T00:00:00-04:00

Parce que… c’est l’épisode 0x513!

Shameless plug

18-21 novembre 2024 - European Cyber Week
19-20 novembre 2024 - C&ESAR
20-21 novembre 2024 - CAID
5-6 décembre 2024 - Objective by the Sea
26-27 février 2025 - SéQCure 2025
9-11 avril 2025 - Google Next ‘25

Description

Notes

À venir

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Infrastructure NorthSec

2024-10-07T00:00:00-04:00

Parce que… c’est l’épisode 0x509!

Shameless plug

18-21 novembre 2024 - European Cyber Week
19-20 novembre 2024 - C&ESAR
20-21 novembre 2024 - CAID
5-6 décembre 2024 - Objective by the Sea
26-27 février 2025 - SéQCure 2025
9-11 avril 2025 - Google Next ‘25

Description

Notes

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - L'importance des rapports en sécurité offensive

2024-09-09T00:00:00-04:00

Parce que… c’est l’épisode 0x501!

Shameless plug

29 septembre au 2 octobre 2024 - FAIR Conference 2024
18-21 novembre 2024 - European Cyber Week
19-20 novembre 2024 - C&ESAR
20-21 novembre 2024 - CAID
5-6 décembre 2024 - Objective by the Sea
26-27 février 2025 - SéQCure 2025
9-11 avril 2025 - Google Next ‘25

Description

Notes

À noter

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Sécurité du IA (SAIF)

2024-09-02T00:00:00-04:00

Parce que… c’est l’épisode 0x499!

Préambule

Je fais des expériences avec de nouvelles façons d’enregistrer. Cette méthode n’est pas encore au point, même si elle a permis une plus grande fluidité dans la conversation. Work in progress.

Shameless plug

7-8 septembre 2024 - Blue Team Con
29 septembre au 2 octobre 2024 - FAIR Conference 2024
18-21 novembre 2024 - European Cyber Week
19-20 novembre 2024 - C&ESAR
20-21 novembre 2024 - CAID
5-6 décembre 2024 - Objective by the Sea
26-27 février 2025 - SéQCure 2025
9-11 avril 2025 - Google Next ‘25

Description

Notes

Google’s Secure AI Framework (SAIF)

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par Terrasse Nelligan

Teknik - Retour sur le Blackhat et DEFCON à partir de Montréal

2024-08-26T00:00:00-04:00

Parce que… c’est l’épisode 0x497!

Shameless plug

7-8 septembre 2024 - Blue Team Con
29 septembre au 2 octobre 2024 - FAIR Conference 2024
18-21 novembre 2024 - European Cyber Week
19-20 novembre 2024 - C&ESAR
20-21 novembre 2024 - CAID
5-6 décembre 2024 - Objective by the Sea
26-27 février 2025 - SéQCure 2025
9-11 avril 2025 - Google Next ‘25

Description

Notes

À venir

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Retour sur le Blackhat 2024 (with Mickael Nadeau)

2024-08-19T00:00:00-04:00

Parce que… c’est l’épisode 0x495!

Shameless plug

7-8 septembre 2024 - Blue Team Con
29 septembre au 2 octobre 2024 - FAIR Conference 2024
18-21 novembre 2024 - European Cyber Week
19-20 novembre 2024 - C&ESAR
20-21 novembre 2024 - CAID
5-6 décembre 2024 - Objective by the Sea
26-27 février 2025 - SéQCure 2025
9-11 avril 2025 - Google Next ‘25

Description

Notes

À venir

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par LINQ

Teknik - RegreSSHion

2024-08-05T00:00:00-04:00

Parce que… c’est l’épisode 0x491!

Shameless plug

8-11 août 2024 - DEFCON
7-8 septembre 2024 - Blue Team Con
29 septembre au 2 octobre 2024 - FAIR Conference 2024
18-21 novembre 2024 - European Cyber Week
19-20 novembre 2024 - C&ESAR
20-21 novembre 2024 - CAID
5-6 décembre 2024 - Objective by the Sea
26-27 février 2025 - SéQCure 2025
9-11 avril 2025 - Google Next ‘25

Description

Notes

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Blast-RADIUS

2024-07-29T00:00:00-04:00

Parce que… c’est l’épisode 0x490!

Shameless plug

8-11 août 2024 - DEFCON
7-8 septembre 2024 - Blue Team Con
19-20 septembre 2024 - Brucon
29 septembre au 2 octobre 2024 - FAIR Conference 2024
18-21 novembre 2024 - European Cyber Week
19-20 novembre 2024 - C&ESAR
20-21 novembre 2024 - CAID
5-6 décembre 2024 - Objective by the Sea
26-27 février 2025 - SéQCure 2025
9-11 avril 2025 - Google Next ‘25

Description

Notes

Blast-RADIUS

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - OT - Gestion des incidents

2024-07-22T00:00:00-04:00

Parce que… c’est l’épisode 0x489!

Shameless plug

8-11 août 2024 - DEFCON
7-8 septembre 2024 - Blue Team Con
19-20 septembre 2024 - Brucon
29 septembre au 2 octobre 2024 - FAIR Conference 2024
18-21 novembre 2024 - European Cyber Week
19-20 novembre 2024 - C&ESAR
20-21 novembre 2024 - CAID
5-6 décembre 2024 - Objective by the Sea
26-27 février 2025 - SéQCure 2025
9-11 avril 2025 - Google Next ‘25

Description

Notes

The Mandiant Approach to Operational Technology (OT) Security

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - HSM

2024-07-08T00:00:00-04:00

Parce que… c’est l’épisode 0x487!

Shameless plug

8-11 août 2024 - DEFCON
7-8 septembre 2024 - Blue Team Con
19-20 septembre 2024 - Brucon
29 septembre au 2 octobre 2024 - FAIR Conference 2024
18-21 novembre 2024 - European Cyber Week
19-20 novembre 2024 - C&ESAR
20-21 novembre 2024 - CAID
5-6 décembre 2024 - Objective by the Sea
26-27 février 2025 - SéQCure 2025
9-11 avril 2025 - Google Next ‘25

Description

Notes

À venir

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Est-ce que l'open source est production ready?

2024-06-17T00:00:00-04:00

Parce que… c’est l’épisode 0x482!

Shameless plug

8-11 août 2024 - DEFCON
7-8 septembre 2024 - Blue Team Con
19-20 septembre 2024 - Brucon
18-21 novembre 2024 - European Cyber Week
19-20 novembre 2024 - C&ESAR
20-21 novembre 2024 - CAID
5-6 décembre 2024 - Objective by the Sea
26-27 février 2025 - SéQCure 2025
9-11 avril 2025 - Google Next ‘25

Description

Notes

À venir

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par Northsec

Teknik - PowersheLLM

2024-06-10T00:00:00-04:00

Parce que… c’est l’épisode 0x479!

Shameless plug

8-11 août 2024 - DEFCON
7-8 septembre 2024 - Blue Team Con
19-20 septembre 2024 - Brucon
18-21 novembre 2024 - European Cyber Week
19-20 novembre 2024 - C&ESAR
20-21 novembre 2024 - CAID
5-6 décembre 2024 - Objective by the Sea
26-27 février 2025 - SéQCure 2025
9-11 avril 2025 - Google Next ‘25

Description

Notes

PowersheLLM : Un Large Language Model à l’épreuve de l’horreur

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Introduction au forensic

2024-06-05T00:00:00-04:00

Parce que… c’est l’épisode 0x477!

Shameless plug

8-11 août 2024 - DEFCON
7-8 septembre 2024 - Blue Team Con
19-20 septembre 2024 - Brucon
29 septembre au 2 octobre 2024 - FAIR Conference 2024
18-21 novembre 2024 - European Cyber Week
19-20 novembre 2024 - C&ESAR
20-21 novembre 2024 - CAID
5-6 décembre 2024 - Objective by the Sea
26-27 février 2025 - SéQCure 2025
9-11 avril 2025 - Google Next ‘25

Description

Notes

À venir

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Build Pipeline Supply Chain Attack

2024-05-21T00:00:00-04:00

Parce que… c’est l’épisode 0x468!

Shameless plug

8-11 août 2024 - DEFCON
7-8 septembre 2024 - Blue Team Con
19-20 septembre 2024 - Brucon
18-21 novembre 2024 - European Cyber Week
19-20 novembre 2024 - C&ESAR
20-21 novembre 2024 - CAID
5-6 décembre 2024 - Objective by the Sea
26-27 février 2025 - SéQCure 2025
9-11 avril 2025 - Google Next ‘25

Description

Notes

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réel par Northsec

Teknik - Credential Access volet GCP et AWS

2024-05-20T00:00:00-04:00

Parce que… c’est l’épisode 0x467!

Shameless plug

12-19 mai 2024 - NorthSec
8-11 août 2024 - DEFCON
7 et 8 septembre 2024 - Blue Team Con
19-20 septembre 2024 - Brucon
19 au 21 novembre 2024 - European Cyber Week
19-20 novembre 2024 - C&ESAR
20-21 novembre 2024 - CAID
5-6 décembre 2024 - Objective by the Sea
février 2025 - SéQCure 2025
9 au 11 avril 2025 - Google Next ‘25

Description

Notes

À venir

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Industrialisation des audits avec le Policy-as-Code

2024-05-15T00:00:00-04:00

Parce que… c’est l’épisode 0x466!

Shameless plug

12-19 mai 2024 - NorthSec
8-11 août 2024 - DEFCON
7 et 8 septembre 2024 - Blue Team Con
19-20 septembre 2024 - Brucon
19 au 21 novembre 2024 - European Cyber Week
19-20 novembre 2024 - C&ESAR
20-21 novembre 2024 - CAID
5-6 décembre 2024 - Objective by the Sea
février 2025 - SéQCure 2025
9 au 11 avril 2025 - Google Next ‘25

Description

Notes

À venir

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Cybersécurité TO par le design

2024-05-13T00:00:00-04:00

Parce que… c’est l’épisode 0x465!

Shameless plug

12-19 mai 2024 - NorthSec
8-11 août 2024 - DEFCON
7-8 septembre 2024 - Blue Team Con
19-20 septembre 2024 - Brucon
18-21 novembre 2024 - European Cyber Week
19-20 novembre 2024 - C&ESAR
20-21 novembre 2024 - CAID
5-6 décembre 2024 - Objective by the Sea
26-27 février 2025 - SéQCure 2025
9-11 avril 2025 - Google Next ‘25

Description

Notes

À venir

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Pwn2Own, le quadruplé gagnant de Synacktiv sur Tesla (2022-2024)

2024-04-30T00:00:00-04:00

Parce que… c’est l’épisode 0x460!

Shameless plug

12-19 mai 2024 - NorthSec
8-11 août 2024 - DEFCON
7 et 8 septembre 2024 - Blue Team Con
19-20 septembre 2024 - Brucon
19 au 21 novembre 2024 - European Cyber Week
19-20 novembre 2024 - C&ESAR
20-21 novembre 2024 - CAID
5-6 décembre 2024 - Objective by the Sea
février 2025 - SéQCure 2025
9 au 11 avril 2025 - Google Next ‘25

Description

Notes

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Scénario RedTeam - Intrusion physique

2024-04-25T00:00:00-04:00

Parce que… c’est l’épisode 0x458!

Shameless plug

8-11 août 2024 - DEFCON
19 au 21 novembre 2024 - European Cyber Week
19-20 novembre 2024 - C&ESAR
20-21 novembre 2024 - CAID

Description

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Recherche en RE de cellulaires (EXFILES)

2024-04-23T00:00:00-04:00

Parce que… c’est l’épisode 0x456!

Shameless plug

12-19 mai 2024 - NorthSec
8-11 août 2024 - DEFCON
7 et 8 septembre 2024 - Blue Team Con
19-20 septembre 2024 - Brucon
19 au 21 novembre 2024 - European Cyber Week
19-20 novembre 2024 - C&ESAR
20-21 novembre 2024 - CAID
5-6 décembre 2024 - Objective by the Sea
février 2025 - SéQCure 2025
9 au 11 avril 2025 - Google Next ‘25

Description

Notes

EXFILES

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Google Next'24

2024-04-15T00:00:00-04:00

Parce que… c’est l’épisode 0x451!

Shameless plug

12-19 mai 2024 - NorthSec
8-11 août 2024 - DEFCON
7 et 8 septembre 2024 - Blue Team Con
19-20 septembre 2024 - Brucon
19 au 21 novembre 2024 - European Cyber Week
19-20 novembre 2024 - C&ESAR
20-21 novembre 2024 - CAID
5-6 décembre 2024 - Objective by the Sea
février 2025 - SéQCure 2025
9 au 11 avril 2025 - Google Next ‘25

Description

Notes

Best Practices for Securely Deploying AI on Google Cloud

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par Beerhaus

Teknik - L'intelligence artificielle en cybersécurité... Risque de l'IA (fake news)

2024-04-10T00:00:00-04:00

Parce que… c’est l’épisode 0x449!

Shameless plug

9-11 avril 2024 - Google Next ‘24
12-19 mai 2024 - NorthSec
8-11 août 2024 - DEFCON
19 au 21 novembre 2024 - European Cyber Week
19-20 novembre 2024 - C&ESAR
20-21 novembre 2024 - CAID

Description

Notes

À venir

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par INCYBER FORUM EUROPE

Teknik - L'intelligence artificielle en cybersécurité... Risque de l'IA (Attaque et biais)

2024-04-09T00:00:00-04:00

Parce que… c’est l’épisode 0x448!

Shameless plug

9-11 avril 2024 - Google Next ‘24
12-19 mai 2024 - NorthSec
8-11 août 2024 - DEFCON
19 au 21 novembre 2024 - European Cyber Week
19-20 novembre 2024 - C&ESAR
20-21 novembre 2024 - CAID

Description

Notes

Giskard.ai

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par INCYBER FORUM EUROPE

Teknik - L'intelligence artificielle en cybersécurité... Défensive

2024-04-03T00:00:00-04:00

Parce que… c’est l’épisode 0x445!

Shameless plug

9-11 avril 2024 - Google Next ‘24
8-11 août 2024 - DEFCON
19 au 21 novembre 2024 - European Cyber Week
19-20 novembre 2024 - C&ESAR
20-21 novembre 2024 - CAID

Description

Notes

À venir

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Les limites d'Excel en gestion d'incident

2024-04-02T00:00:00-04:00

Parce que… c’est l’épisode 0x444!

Shameless plug

9-11 avril 2024 - Google Next ‘24
12-19 mai 2024 - NorthSec
8-11 août 2024 - DEFCON
19 au 21 novembre 2024 - European Cyber Week
19-20 novembre 2024 - C&ESAR
20-21 novembre 2024 - CAID

Description

Notes

À venir

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par INCYBER FORUM EUROPE

Teknik - Analyse de l'appel d'offres du DGEQ

2024-03-25T00:00:00-04:00

Parce que… c’est l’épisode 0x439!

Shameless plug

26-28 mars 2024 - Forum InCyber
9-11 avril 2024 - Google Next ‘24
8-11 août 2024 - DEFCON
19 au 21 novembre 2024 - European Cyber Week
19-20 novembre 2024 - C&ESAR
20-21 novembre 2024 - CAID

Description

Notes

À venir

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Intro au reverse engineering

2024-03-20T00:00:00-04:00

Parce que… c’est l’épisode 0x437!

Shameless plug

26-28 mars 2024 - Forum InCyber
9-11 avril 2024 - Google Next ‘24
8-11 août 2024 - DEFCON
19 au 21 novembre 2024 - European Cyber Week
19-20 novembre 2024 - C&ESAR
20-21 novembre 2024 - CAID

Description

Notes

À venir

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Intro à la réponse aux incidents

2024-03-18T00:00:00-04:00

Parce que… c’est l’épisode 0x435!

Shameless plug

26-28 mars 2024 - Forum InCyber
9-11 avril 2024 - Google Next ‘24
8-11 août 2024 - DEFCON
19 au 21 novembre 2024 - European Cyber Week
19-20 novembre 2024 - C&ESAR
20-21 novembre 2024 - CAID

Description

Notes

xxxx

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - L'intelligence artificielle en cybersécurité... Offensif

2024-03-11T00:00:00-04:00

Parce que… c’est l’épisode 0x433!

Shameless plug

26-28 mars 2024 - Forum InCyber
9-11 avril 2024 - Google Next ‘24
8-11 août 2024 - DEFCON
19 au 21 novembre 2024 - European Cyber Week
19-20 novembre 2024 - C&ESAR
20-21 novembre 2024 - CAID

Description

Notes

À venir

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Scénario RedTeam - De l'externe vers l'interne

2024-03-06T00:00:00-05:00

Parce que… c’est l’épisode 0x432!

Préambule

Shameless plug

26-28 mars 2024 - Forum InCyber
9-11 avril 2024 - Google Next ‘24
8-11 août 2024 - DEFCON
19 au 21 novembre 2024 - European Cyber Week
19-20 novembre 2024 - C&ESAR
20-21 novembre 2024 - CAID

Description

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - La triste réalité derrière le "threat intel"

2024-03-04T00:00:00-05:00

Parce que… c’est l’épisode 0x431!

Préambule

Shameless plug

26-28 mars 2024 - Forum InCyber
9-11 avril 2024 - Google Next ‘24
8-11 août 2024 - DEFCON
19 au 21 novembre 2024 - European Cyber Week
19-20 novembre 2024 - C&ESAR
20-21 novembre 2024 - CAID

Description

Notes

À venir

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Gestion de risque TO

2024-02-21T00:00:00-05:00

Parce que… c’est l’épisode 0x428!

Shameless plug

28 et 29 février 2024 - SéQCure
26-28 mars 2024 - Forum InCyber
9-11 avril 2024 - Google Next ‘24
8-11 août 2024 - DEFCON
19 au 21 novembre 2024 - European Cyber Week
19-20 novembre 2024 - C&ESAR
20-21 novembre 2024 - CAID

Description

Notes

À venir

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Credential Access volet Azure

2024-01-29T00:00:00-05:00

Parce que… c’est l’épisode 0x411!

Shameless plug

28 et 29 février 2024 - SéQCure
19 au 21 novembre 2024 - European Cyber Week
novembre 2024 - CAID
novembre 2024 - CES&R

Description

Notes

Death from Above: Lateral Movement from Azure to On-Prem AD

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Se cacher sur le endpoint

2024-01-24T00:00:00-05:00

Parce que… c’est l’épisode 0x408!

Shameless plug

28 et 29 février 2024 - SéQCure
19 au 21 novembre 2024 - European Cyber Week
novembre 2024 - CAID
novembre 2024 - CES&R

Description

Notes

HELK

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Qu’est-ce que la cybersécurité des TO?

2024-01-17T00:00:00-05:00

Parce que… c’est l’épisode 0x405!

Shameless plug

28 et 29 février 2024 - SéQCure
19 au 21 novembre 2024 - European Cyber Week
novembre 2024 - CAID
novembre 2024 - CES&R

Description

Notes

New Adventures in Legacy System Modernization

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Réflexion sur les attaques par déni de service (fin 2023)

2024-01-10T00:00:00-05:00

Parce que… c’est l’épisode 0x403!

Shameless plug

28 et 29 février 2024 - SéQCure
19 au 21 novembre 2024 - European Cyber Week
novembre 2024 - CAID
novembre 2024 - CES&R

Description

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - L'intelligence artificielle en cybersécurité... commençons par quelques bases

2024-01-08T00:00:00-05:00

Parce que… c’est l’épisode 0x402!

Shameless plug

28 et 29 février 2024 - SéQCure
19 au 21 novembre 2024 - European Cyber Week
novembre 2024 - CAID
novembre 2024 - CES&R

Description

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Retour sur la recherche RDP (un peu festif)

2023-12-31T00:00:00-05:00

Parce que… c’est l’épisode 0x399!

Préambule

L’alcool a collé lors de cet enregistrement.

Shameless plug

février 2024 - SéQCure

Description

Notes

À venir

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par GoSecure

Teknik - Nous fermons l'année avec 10 éléments

2023-12-27T00:00:00-05:00

Parce que… c’est l’épisode 0x398!

Shameless plug

28 et 29 février 2024 - SéQCure
19 au 21 novembre 2024 - European Cyber Week
novembre 2024 - CAID
novembre 2024 - CES&R

Description

Notes

À venir

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Scénario RedTeam - Nouvel employé, volet plus persistent

2023-12-26T00:00:00-05:00

Parce que… c’est l’épisode 0x397!

Shameless plug

28 et 29 février 2024 - SéQCure

Description

Notes

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Kubernetes - Policy admission

2023-12-20T00:00:00-05:00

Parce que… c’est l’épisode 0x395!

Shameless plug

28 et 29 février 2024 - SéQCure

Description

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par Noctem

Teknik - Pentest cloud - La persistence

2023-12-13T00:00:00-05:00

Parce que… c’est l’épisode 0x392!

Shameless plug

28 et 29 février 2024 - SéQCure

Description

Notes

Notes de l’épisode
Ressources gratuites pour pratique les pentests cloud
- Azure
AWS
- AWSGoat
- Lambhack
- AWS Vulnerable lambda
- CloudGoat
- IAM Vulnerable
- ServerlessGoat
- FLAWS
- FLAWS2
- Sadcloud
- DamnVulnerable Cloud application
GCP
- GCPGoat

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - MIP part 2

2023-12-12T00:00:00-05:00

Parce que… c’est l’épisode 0x391!

Shameless plug

28 et 29 février 2024 - SéQCure

Description

Notes

À venir

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - MIP part 1

2023-12-11T00:00:00-05:00

Parce que… c’est l’épisode 0x390!

Shameless plug

28 et 29 février 2024 - SéQCure

Description

Notes

À venir

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Survol de plusieurs petits glitchs infonuagique

2023-11-29T00:00:00-05:00

Parce que… c’est l’épisode 0x385!

Shameless plug

28 et 29 février 2024 - SéQCure

Description

Notes

À venir

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Zero trust

2023-11-22T00:00:00-05:00

Parce que… c’est l’épisode 0x382!

Shameless plug

21 au 23 novembre 2023 - European Cyber Week
28 et 29 février 2024 - SéQCure

Description

Notes

À venir

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Kubernetes - Couche réseau

2023-11-20T00:00:00-05:00

Parce que… c’est l’épisode 0x380!

Shameless plug

21 au 23 novembre 2023 - European Cyber Week
28 et 29 février 2024 - SéQCure

Description

Notes

À venir

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par Noctem

Teknik - Pentest cloud - Élévation de privilèges

2023-11-14T00:00:00-05:00

Parce que… c’est l’épisode 0x378!

Shameless plug

21 au 23 novembre 2023 - European Cyber Week
28 et 29 février 2024 - SéQCure

Description

Notes

Notes de l’épisode
Ressources gratuites pour pratique les pentests cloud
- Azure
AWS
- AWSGoat
- Lambhack
- AWS Vulnerable lambda
- CloudGoat
- IAM Vulnerable
- ServerlessGoat
- FLAWS
- FLAWS2
- Sadcloud
- DamnVulnerable Cloud application
GCP
- GCPGoat

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Évasion EDR

2023-11-13T00:00:00-05:00

Parce que… c’est l’épisode 0x377!

Shameless plug

21 au 23 novembre 2023 - European Cyber Week
28 et 29 février 2024 - SéQCure

Description

Notes

À venir

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Analyse d'un incident - TV5 Monde

2023-11-01T00:00:00-04:00

Parce que… c’est l’épisode 0x373!

Shameless plug

21 au 23 novembre 2023 - European Cyber Week
28 et 29 février 2024 - SéQCure

Description

Notes

Attaque informatique contre TV5 monde : L’ANSSI mobilisée.

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Survol du rapport d'extorsion 2023 - Unit 42

2023-10-26T00:00:00-04:00

Parce que… c’est l’épisode 0x371!

Shameless plug

21 au 23 novembre 2023 - European Cyber Week
28 et 29 février 2024 - SéQCure

Description

Notes

2023 Unit 42 Ransomware and Extortion Report

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par Baton Rouge

Teknik - Scénario RedTeam - Nouvel employé et la reconnaissance passive... et un peu plus!

2023-10-24T00:00:00-04:00

Parce que… c’est l’épisode 0x369!

Shameless plug

21 au 23 novembre 2023 - European Cyber Week
28-29 février 2024 - SéQCure

Description

Notes

À venir

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Gestion des identités et des accès dans AzureAD/Entra

2023-10-11T00:00:00-04:00

Parce que… c’est l’épisode 0x364!

Préambule

Shameless plug

21 au 23 novembre 2023 - European Cyber Week
28-29 février 2024 - SéQCure

Description

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Pentest cloud - Accès initial

2023-09-27T00:00:00-04:00

Parce que… c’est l’épisode 0x357!

Shameless plug

21 au 23 novembre 2023 - European Cyber Week
février 2024 - SéQCure
Formation Crise et résilience

Description

Dans cet épisode, l’invité nous plonge dans l’univers du pentest cloud, en mettant particulièrement l’accent sur la phase d’accès initial, essentielle pour s’ancrer dans un système cible. Le discours s’appuie sur une série de concepts, d’exemples concrets et de techniques pour dépeindre le paysage des tests d’intrusion dans le cloud.

L’invité introduit la notion de TTP (Tactique, Technique et Procédures) et référence la matrice MITRE ATT@CK Enterprise, qui aide à définir la chaîne d’une attaque. Il met en lumière l’importance de l’accès initial dans le processus d’attaque, soulignant la variété de techniques et de procédures utilisées pour réaliser cette étape cruciale.

La discussion se centre ensuite sur les spécificités des environnements cloud, mentionnant des plateformes telles qu’AWS, Azure, et GCP. L’orateur explique que malgré l’existence de la matrice MITRE ATT@CK Cloud, de nombreux outils et ressources spécifiques sont nécessaires pour simuler et comprendre le cycle de vie d’une attaque dans ces environnements particuliers. Il cite l’exemple de Microsoft qui a créé Azureattaque matrix pour Azure et Microsoft 365, fournissant ainsi des détails plus précis pour la défense.

La conversation aborde les initiatives de la communauté et des éditeurs visant à améliorer et à affiner ces matrices d’attaque. L’orateur note que ces efforts sont essentiels car chaque CSP (Cloud Service Provider) a son propre nommage et ses spécificités, nécessitant des approches différentes pour identifier les vulnérabilités.

L’invité soulève également le problème récurrent des entreprises déployant des environnements cloud sans avoir une compréhension et une expertise suffisantes de la technologie. Il cite des exemples de failles de sécurité liées à des configurations incorrectes, des erreurs humaines et des permissions excessives.

Il évoque plusieurs techniques d’identification de vulnérabilités, y compris l’utilisation de Google Dorks et Bing Dorks, qui permettent de découvrir des ressources cloud spécifiques. L’orateur rappelle que l’Internet est permanent, et toute erreur devient publique et éternelle, soulignant l’importance de vérifications en amont.

La conversation explore ensuite différentes techniques de phishing basées sur le protocole OAuth. L’orateur détaille le processus du device code phishing et explique comment les attaquants créent des applications malveillantes, demandent le consentement des utilisateurs, et exploitent les permissions accordées pour accéder à des informations sensibles.

L’invité décrit également des exemples de scénarios où les utilisateurs accordent imprudemment des permissions, et comment cela peut être exploité. Il met en lumière la complexité et les défis liés à la gestion des droits dans les environnements cloud, et en particulier sur Azure.

Il mentionne les difficultés à suivre les mises à jour constantes et les changements dans le domaine du cloud, soulignant que cela rend la tâche encore plus ardue pour les professionnels de la sécurité. La transcription se termine sur une note de réflexion, laissant le lecteur à considérer les implications et les défis persistants dans le domaine du pentest cloud.

En conclusion, cet épisode offre un aperçu approfondi du pentest cloud et de ses diverses facettes. Elle souligne l’importance de l’accès initial, explore les défis liés aux environnements cloud spécifiques et aux différentes plateformes, et met en lumière les dangers liés à un manque de compréhension et d’expertise. Les techniques de phishing, la gestion des droits et les défis constants dans le domaine de la sécurité cloud sont également discutés en détail, offrant ainsi une ressource complète pour quiconque s’intéresse à la sécurité dans le cloud.

Notes

Azure Cloud ATT&CK and others threat lifecycle Matrix
AWS ATT&CK Matrix
- Security Stack Mappings AWS
- Amazon Web Services Security Control Mappings to MITRE ATT&CK®
GCP ATT&CK Matrix
- Security Stack Mappings GCP
- Google Cloud Platform Security Control Mappings to MITRE ATT&CK®

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Retour d'expérience - Google Next '23 (2e partie - les autres annonces)

2023-09-21T00:00:00-04:00

Parce que… c’est l’épisode 0x354!

Shameless plug

21 au 23 novembre 2023 - European Cyber Week
février 2024 - SéQCure
Formation Crise et résilience

Description

Notes

All 161 things we announced at Google Cloud Next ‘23 – a recap

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par Pub Victoria

Teknik - Kubernetes - Les API et le RBAC

2023-09-20T00:00:00-04:00

Parce que… c’est l’épisode 0x353!

Shameless plug

21 au 23 novembre 2023 - European Cyber Week
février 2024 - SéQCure
Formation Crise et résilience

Description

Notes

À venir

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par Noctem

Teknik - Analyse d'un malware - Stuxnet

2023-09-13T00:00:00-04:00

Parce que… c’est l’épisode 0x350!

Shameless plug

21 au 23 novembre 2023 - European Cyber Week
février 2024 - SéQCure
Formation Crise et résilience

Description

À venir

Notes

À venir

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Retour d'expérience - Google Next '23 (1ère partie - Cloud Firewall Plus)

2023-09-07T00:00:00-04:00

Parce que… c’est l’épisode 0x348!

Shameless plug

21 au 23 novembre 2023 - European Cyber Week
février 2024 - SéQCure
Formation Crise et résilience

Description

Au Google Next ‘23, des annonces majeures ont été faites concernant la sécurité dans le Google Cloud. Au cœur de ces annonces se trouvaient des améliorations substantielles des pare-feu.

Historiquement, Google a constamment amélioré ses pare-feu. L’année précédente, par exemple, Google avait lancé une version du Cloud firewall distincte du VPC firewall, offrant plus de flexibilité. Elle permettait aux utilisateurs d’établir des politiques plutôt que des règles simples, de gérer la sécurité à plusieurs niveaux organisationnels et d’intégrer des listes dynamiques d’adresses. Ces améliorations ont aussi introduit la possibilité de gérer l’accès basé sur des domaines qualifiés et des géolocalisations.

Cette année, l’innovation majeure est le “Firewall Plus”. L’objectif principal de cette nouvelle version est d’inspecter et de bloquer proactivement les attaques, offrant ainsi une granularité sans précédent dans la gestion du trafic. Cette capacité a été rendue possible grâce à une technologie appelée “paquet intersif”, qui capture et traite le trafic sans perturber les structures existantes. Cela signifie que les utilisateurs peuvent facilement migrer vers Firewall Plus sans avoir à réviser leurs architectures existantes.

Le Firewall Plus n’est pas seulement une version gérée par Google. Il offre également la possibilité d’intégrer des pare-feu tiers comme ceux de Palo Alto, Fortinet et Cisco, offrant ainsi aux entreprises une flexibilité dans la manière dont elles souhaitent gérer leur sécurité. Les entreprises peuvent même apporter leurs licences existantes de pare-feu, éliminant le besoin d’investissements supplémentaires.

L’une des grandes valeurs ajoutées de cette innovation est la facilité d’intégration et de migration. Les entreprises peuvent maintenant transporter leurs compétences et technologies éprouvées dans le Cloud sans avoir à surmonter les obstacles techniques traditionnels associés au routage et à l’équilibrage des charges.

En conclusion, avec Firewall Plus, Google a simplifié et renforcé la sécurité du cloud, permettant aux entreprises de toutes tailles de bénéficier d’une protection améliorée tout en conservant ou en intégrant leurs solutions existantes. Il s’agit d’un pas géant vers la création d’environnements Cloud plus sûrs et plus flexibles pour tous.

Notes

Cloud Firewall Plus

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par Moscone Center

Teknik - Regards sur la fuite de la clé MSA

2023-09-04T00:00:00-04:00

Parce que… c’est l’épisode 0x345!

Shameless plug

21 au 23 novembre 2023 - European Cyber Week
février 2024 - SéQCure
Formation Crise et résilience

Description

Le podcast technique 0x345 aborde un sujet brûlant : la récente fuite de sécurité chez Microsoft liée à la clé MSA. Cette fuite a suscité de nombreuses réactions, à la fois dans les médias et au sein de la communauté tech.

L’origine du problème vient d’un groupe, vraisemblablement chinois, identifié sous le nom de “Storm 05 58”. Ils auraient volé des clés d’inscription destinées aux clients Microsoft, permettant notamment l’authentification sur divers services, dont Outlook. Bien que les premiers rapports suggéraient que seuls les comptes Outlook étaient compromis, il est rapidement apparu que le problème était plus étendu. Environ 20 à 30 organisations ont été affectées, incluant des instances gouvernementales américaines et européennes.

Ces clés d’inscription, spécifiques à Microsoft, servent à signer des tokens d’authentification pour accéder aux services Cloud de l’entreprise. Une fois volées, elles ont été utilisées pour forger des signatures valides. Cela a permis aux pirates de se faire passer pour des utilisateurs légitimes et d’accéder aux services comme s’ils étaient ces utilisateurs.

L’une des grandes questions reste : comment ces clés, certaines étant même considérées comme invalides par Microsoft, ont-elles pu être utilisées sans déclencher d’alertes ? Le podcast souligne également la différence de réaction entre Google et Microsoft face à des violations de sécurité. En 2010, Google avait subi une attaque et avait rapidement identifié, corrigé le problème et informé le public. À l’inverse, Microsoft a mis deux mois entre la découverte de la fuite et l’annonce publique.

Les auditeurs du podcast ont ainsi été encouragés à réfléchir sur l’importance de la transparence et de la rapidité de réaction face à de telles situations. Bien que la technologie ait progressé, les entreprises doivent toujours être vigilantes et proactives face aux menaces, tout en étant transparentes avec leurs utilisateurs.

Notes

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par 3 BRASSEURS LAURIER

Teknik - Les signaux, l'élément atomique d'analyse cybersécurité

2023-08-30T00:00:00-04:00

Parce que… c’est l’épisode 0x344!

Shameless plug

29 au 31 août 2023 - Google Next ‘23
21 au 23 novembre 2023 - European Cyber Week
février 2024 - SéQCure
Formation Crise et résilience

Description

La sécurité en matière de technologie de l’information est cruciale pour les entreprises modernes, en particulier dans le contexte du cloud, où les frontières traditionnelles entre les ressources internes et externes sont de plus en plus floues. C’est le thème central de cette discussion qui aborde les tests d’intrusion dans l’environnement du cloud, une dimension souvent négligée ou mal évaluée par rapport aux approches traditionnelles sur site.

Au cours des dernières années, de nombreuses entreprises ont migré leurs ressources vers le cloud. Cependant, ce mouvement a souvent été réalisé sans un accompagnement adéquat, et sans une compréhension profonde de la sécurité du cloud, laissant des failles potentielles qui attirent de plus en plus les attaquants.

L’importance d’une approche basée sur un “modèle de sécurité partagé” a été soulignée, surtout lorsqu’on travaille avec des fournisseurs de cloud comme Azure. Dans cet environnement, il ne suffit pas de s’appuyer uniquement sur les mesures de sécurité du fournisseur. Les entreprises doivent également jouer leur rôle en matière de protection. Selon le type de service - Infrastructure en tant que Service (IaaS), Plateforme en tant que Service (PaaS) ou Logiciel en tant que Service (SaaS) - la responsabilité de la sécurité peut varier considérablement.

L’une des principales différenciations mises en avant est la gestion de l’identité et de l’accès. Les problèmes tels que la configuration incorrecte du Multifactor Authentication (MFA) ou la mauvaise gestion des équipements dans des services comme Azure peuvent donner aux attaquants un accès direct, mettant ainsi les ressources de l’entreprise en danger.

En explorant davantage les environnements de cloud, il est essentiel de comprendre les risques associés aux services conteneurisés comme Kubernetes. Les attaquants peuvent exploiter les faiblesses dans ces configurations pour accéder aux ressources.

Lors de l’évaluation de la sécurité du cloud, il ne s’agit pas uniquement de prévention, mais également de réaction. Les entreprises doivent être en mesure de répondre rapidement aux failles potentielles et de comprendre les menaces pour pouvoir les atténuer.

La discussion a également évoqué des exemples spécifiques de menaces, notamment les problèmes liés à la gestion des versions dans des services comme SharePoint, où les attaquants peuvent effacer les versions précédentes d’un document, rendant les tentatives de récupération inefficaces.

En conclusion, le cloud offre des capacités puissantes et flexibles aux entreprises, mais il nécessite une nouvelle approche en matière de sécurité. Les entreprises doivent adopter des stratégies proactives pour protéger leurs ressources, tout en restant vigilantes face aux évolutions constantes du paysage des menaces.

Notes

À venir

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - BeyondCorp Enterprise (ZTNA) - Pourquoi chez Google je n'utilise jamais de VPN, je n'installe jamais d'applications et je ne télécharge aucune donnée sur mon laptop

2023-08-29T00:00:00-04:00

Parce que… c’est l’épisode 0x343!

Shameless plug

29 au 31 août 2023 - Google Next ‘23
21 au 23 novembre 2023 - European Cyber Week
février 2024 - SéQCure
Formation Crise et résilience

Description

Nous discutons de l’importance des signaux dans l’analyse de la cybersécurité. Maxime souligne qu’un signal peut varier en importance selon le contexte. Tous les signaux ne sont pas critiques, mais certains sont essentiels pour détecter des anomalies ou des menaces.

Un élément clé à comprendre est que la simple accumulation de signaux peut amplifier leur importance. Par exemple, si un système émet plusieurs signaux de faible niveau dans une période courte, cela pourrait être traité comme un signal de haute importance.

Les signaux peuvent être bénéfiques ou problématiques. Dans certains environnements sophistiqués, certains signaux peuvent être considérés comme du bruit ou des fausses alertes. Cependant, il est crucial de comprendre le contexte pour interpréter correctement un signal. Par exemple, un signal de détection de la Chine pourrait être inutile s’il provient d’une source externe, mais s’il provient de l’intérieur d’une machine, il pourrait être significatif.

Maxime insiste sur l’importance d’avoir des règles spécifiques à chaque environnement. Les tendances générales du marché ne peuvent pas toujours prévoir les menaces spécifiques à un système particulier. C’est l’hygiène digitale, la capacité de comprendre ce qui se passe dans un environnement, qui permet de mieux détecter et répondre aux menaces.

L’analyse des signaux nécessite une réduction progressive de l’information. Le concept d’entonnoir est mentionné, où les données brutes sont progressivement réduites jusqu’à ce qu’un analyste puisse les examiner efficacement. Le timing est un aspect essentiel de cette analyse.

Les signaux sont aussi un moyen de vérifier la stabilité des infrastructures. Les événements rares peuvent être plus intéressants que ceux qui se produisent fréquemment. Maxime suggère de commencer par les événements les moins fréquents pour raffiner et nettoyer les données.

En conclusion, la gestion et l’analyse des signaux sont cruciales pour la cybersécurité. Bien que tous les signaux ne soient pas également importants, comprendre leur contexte et leur relation les uns avec les autres permet une meilleure détection et réponse aux menaces.

Notes

Google BeyondCorp

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux réels par 3 Brasseurs

Teknik - Introduction aux tests d'intrusions infonuagique

2023-08-23T00:00:00-04:00

Parce que… c’est l’épisode 0x341!

Shameless plug

10 au 13 août 2023 - DEFCON
25 au 27 août 2023 - Blue Team Con
29 au 31 août 2023 - Google Next ‘23
21 au 23 novembre 2023 - European Cyber Week
février 2024 - SéQCure
Formation Crise et résilience

Description

Bienvenue dans l’univers de la sécurité offensive avec “belle sécurité”. Le domaine couvre tout ce qui concerne les tests de sécurité et le piratage éthique. Ce secteur, quoique vaste, est essentiel pour comprendre les nuances des tests d’intrusion dans l’informatique nuagique.

La tendance actuelle montre que de nombreuses entreprises migrent leurs ressources vers le cloud, notamment en raison de ses avantages en matière de flexibilité et de coût. Cependant, cette migration se fait souvent sans une connaissance approfondie des défis de sécurité qui y sont associés. En effet, les attaquants s’intéressent de plus en plus aux environnements cloud, y voyant des points d’entrée potentiels vers des réseaux internes ou des données sensibles.

Il est essentiel de comprendre le modèle de sécurité partagée propre au cloud. Ce modèle stipule que, bien que le fournisseur de cloud (comme Azure, AWS ou GCP) soit responsable de certains aspects de la sécurité, la responsabilité finale incombe à l’entreprise utilisatrice. Les différentes offres cloud, comme IaaS, PaaS et SaaS, ont chacune leurs spécificités et risques associés en termes de sécurité.

La gestion des accès est primordiale. Des erreurs comme l’absence de MFA (authentification multi-facteurs) peuvent offrir aux attaquants une porte ouverte. De plus, la gestion des équipements et des identités est essentielle, d’autant plus que les attaques basées sur l’identité sont de plus en plus courantes dans le monde du cloud.

Il est intéressant de noter que même si les environnements cloud sont basés sur des serveurs physiques traditionnels, la méthodologie d’approche est différente. Les tests d’intrusion dans le cloud nécessitent une compréhension approfondie des spécificités de l’environnement cible, car une simple erreur de configuration peut être exploitée par des attaquants.

Les tests d’intrusion, qu’ils soient en mode Black Box, Grey Box ou White Box, varient selon les informations disponibles pour l’attaquant. C’est dans ce contexte que les outils comme Truffaut, qui se concentrent sur la détection d’entropie, peuvent s’avérer utiles pour identifier les secrets ou les tokens d’accès.

Il est également crucial d’être conscient de la persistance des attaques. Par exemple, un refresh token valide pendant 90 jours peut permettre à un attaquant de maintenir un accès non autorisé pendant une longue période. Les attaques sophistiquées, comme le ransomware, exploitent également les fonctionnalités natives des services cloud pour infliger des dommages.

En conclusion, l’informatique nuagique offre d’énormes avantages aux entreprises, mais elle présente également des défis uniques en matière de sécurité. La clé est de comprendre ces défis, de s’équiper des outils et des connaissances appropriés, et de toujours rester un pas en avance sur les attaquants potentiels.

Notes

À venir

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Kubernetes - Introduction au container

2023-08-21T00:00:00-04:00

Parce que… c’est l’épisode 0x339!

Shameless plug

29 au 31 août 2023 - Google Next ‘23
21 au 23 novembre 2023 - European Cyber Week
février 2024 - SéQCure
Formation Crise et résilience

Description

Bienvenue à cet épisode technique où Sébastien nous présente le concept de conteneurisation et sa pertinence, en particulier dans le monde de Kubernetes. Les containers, souvent considérés comme la pierre angulaire de la modernité en informatique, sont comparés à des versions allégées des systèmes d’exploitation, construites par couches superposées. Cette superposition permet de standardiser et de faciliter la distribution.

Docker, avec son système de “docker build”, a rendu populaire cette manière de construire des containers. On commence avec une image de base, souvent un système d’exploitation complet comme Debian ou Ubuntu, puis on ajoute des couches selon les besoins de l’application. Cependant, cette approche peut s’avérer lourde et vulnérable aux attaques.

Pour résoudre ce problème, on préfère souvent utiliser des images de base plus légères, comme Alpine, qui est un OS minimaliste. L’avantage est double : sécurité renforcée et rapidité de déploiement. En effet, un conteneur minimaliste limite l’exposition aux attaques.

Cependant, toutes les applications ne sont pas adaptées à ce modèle minimaliste. Par exemple, les langages interprétés comme Python ou Node.js nécessitent un environnement d’exécution plus complet, d’où la nécessité d’avoir des containers plus volumineux. Dans ces cas, la sécurité repose en partie sur l’isolation du container, qui est réalisée grâce aux fonctionnalités Linux.

Les “capabilités” de Linux permettent de restreindre les permissions d’un conteneur. Par exemple, un conteneur peut être privé de l’accès au réseau ou avoir des permissions d’accès aux disques restreintes. Ces restrictions ajoutent une couche de sécurité supplémentaire. En outre, il est recommandé de ne pas exécuter les conteneurs en tant qu’utilisateur “root”, car cela présente des risques supplémentaires.

En conclusion, la conteneurisation, popularisée par des outils comme Docker, a transformé la manière dont les applications sont déployées. Toutefois, il est crucial de comprendre et de maîtriser les aspects de sécurité associés pour garantir un environnement sûr et efficace.

Notes

À venir

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux réels par Noctem

Teknik - La sécurité en infonuagique... pourquoi devons-nous la payer en plus?

2023-08-15T00:00:00-04:00

Parce que… c’est l’épisode 0x337!

Shameless plug

29 au 31 août 2023 - Google Next ‘23
21 au 23 novembre 2023 - European Cyber Week
février 2024 - SéQCure
Formation Crise et résilience

Description

Les interlocuteurs discutent des enjeux liés à la sécurité dans le domaine de l’infonuagique et se demandent pourquoi cette sécurité est souvent considérée comme un service additionnel et non comme un élément fondamental inclus dans le service de base.

Dès le début, l’un des intervenants exprime son mécontentement face au fait que la sécurité ne soit pas intégrée en standard dans les offres de services infonuagiques, tout comme lorsqu’on achète une voiture, certains éléments de sécurité sont inclus. La discussion s’oriente rapidement vers des préoccupations précises telles que l’absence de journaux de logs qui permettraient de tracer l’origine d’un problème de sécurité, et le manque de transparence et d’accessibilité à ces informations cruciales.

Les intervenants abordent également le sujet des réglementations légales et la mise en place de normes pour réguler le secteur de l’infonuagique, citant notamment l’exemple de lois québécoises et fédérales en préparation. Ces lois visent à encadrer l’activité des fournisseurs de services infonuagiques et à instaurer des standards minimaux de sécurité.

Dans ce contexte, ils mentionnent que beaucoup d’entreprises, y compris les startups technologiques et les grandes industries, ne sont pas prêtes à répondre aux exigences de ces réglementations, et s’interrogent sur la façon dont elles vont s’adapter à ce nouveau paysage réglementaire. L’accent est mis sur le fait que la non-conformité aux normes de sécurité peut avoir des conséquences graves, notamment juridiques.

La conversation dérive ensuite sur les défis spécifiques aux différents fournisseurs de services infonuagiques, notamment Azure et Amazon Web Services (AWS), et le manque d’uniformité dans la manière dont ces services gèrent la sécurité. Les interlocuteurs soulignent l’importance d’avoir une certaine “paranoïa” constructive pour rester vigilant et proactif dans la gestion de la sécurité.

Les intervenants pointent également du doigt la complexité et l’incohérence des offres de services, avec une multitude d’options souvent difficiles à comprendre pour le consommateur moyen. Ils critiquent le modèle économique actuel qui incite à ajouter toujours plus d’options, et donc à augmenter les coûts, au lieu de proposer des packages de sécurité inclus de base et permettant de retirer ce qui n’est pas nécessaire.

Ils expriment le besoin d’un certain niveau de standardisation dans l’industrie pour éviter que les clients aient à apprendre les spécificités de chaque fournisseur. Ils suggèrent qu’une telle standardisation pourrait conduire à une meilleure transparence et à une meilleure compréhension des enjeux de sécurité pour les clients.

En résumé, le podcast aborde des questions cruciales relatives à la sécurité dans le domaine de l’infonuagique, en mettant en lumière les défis et les incohérences actuelles du secteur. Il appelle à une meilleure intégration de la sécurité dans les offres de base, à une réglementation plus stricte et à une standardisation de l’industrie pour faciliter la compréhension et l’adoption des bonnes pratiques en matière de sécurité par les clients. Les intervenants invitent à une réflexion profonde sur les modèles économiques en place, critiquant une tendance à la monétisation excessive des fonctionnalités de sécurité essentielles et appelant à une approche plus éthique et responsable de la part des fournisseurs de services infonuagiques.

Notes

À venir

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - M365 Copilot et retour sur le White/Grey/Black box

2023-08-14T00:00:00-04:00

Parce que… c’est l’épisode 0x336!

Shameless plug

25 au 27 août 2023 - Blue Team Con
29 au 31 août 2023 - Google Next ‘23
21 au 23 novembre 2023 - European Cyber Week
février 2024 - SéQCure
Formation Crise et résilience

Description

Dans ce podcast technique, les intervenants, Nicolas et Franck, abordent plusieurs sujets techniques liés à Microsoft 365 (M365) et à la sécurité informatique. Ils échangent sur diverses expériences, problématiques et outils associés au monde de la tech, principalement autour de l’univers Microsoft.

D’emblée, ils encouragent les auditeurs à participer, à poser des questions et à apporter des contributions sur les sujets abordés, soulignant l’importance des échanges communautaires dans le secteur technique.

Ils discutent ensuite des erreurs potentiellement commises dans l’utilisation de certaines fonctionnalités M365, mettant en garde contre les faux pas qui peuvent conduire à des fuites d’informations importantes. Ils insistent particulièrement sur l’importance de bien configurer les systèmes pour éviter des incidents de sécurité.

Abordant les outils spécifiques de M365, ils mentionnent les avantages et inconvénients de certains d’entre eux, notamment Microsoft Viva et Microsoft Loop. Ils mettent en lumière les risques associés à une utilisation non réfléchie, en particulier en ce qui concerne la protection des données et la confidentialité.

En parlant de Copilot Outlook, les intervenants discutent des avantages de l’outil tout en mettant en garde contre son utilisation irréfléchie. Ils conseillent aux entreprises d’être prudentes dans la manière dont elles gèrent et utilisent les outils, encourageant les auditeurs à tester et à se familiariser avec les fonctionnalités avant de les déployer à grande échelle.

Par la suite, ils se penchent sur la question des “black box” et des tests d’intrusion, évoquant les défis que rencontrent les entreprises dans la sécurisation de leurs systèmes et réseaux. Ils parlent de l’importance de maintenir une défense robuste et de la difficulté d’anticiper toutes les vulnérabilités potentielles.

Un autre sujet discuté est la sécurité de l’Azure Portal, où ils mentionnent que le code source est maintenant plus grand que celui de Windows 11, soulignant la complexité et les défis associés à la sécurisation d’un tel système. Ils évoquent également des incidents passés où des failles de sécurité ont été exploitées, menant à des accès non autorisés et des fuites d’informations.

Enfin, ils mettent l’accent sur les techniques de phishing et d’ingénierie sociale, décrivant les stratégies que les attaquants peuvent utiliser pour gagner l’accès aux systèmes et aux données. Ils soulignent l’importance de la vigilance et de l’éducation pour se prémunir contre de telles attaques.

Dans l’ensemble, le podcast sert de discussion approfondie et technique sur divers sujets relatifs à Microsoft 365 et à la sécurité informatique. Les intervenants mettent en lumière à la fois les avantages et les dangers potentiels des outils modernes, encourageant une approche prudente et informée à leur utilisation pour garantir la sécurité et l’efficacité. Ils mettent également en avant l’importance de la communauté et du partage des connaissances dans ce domaine en constante évolution.

Notes

À venir

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - M365 DLP part 2 (poste de travail)

2023-08-07T00:00:00-04:00

Parce que… c’est l’épisode 0x333!

Shameless plug

10 au 13 août 2023 - DEFCON
29 au 31 août 2023 - Google Next ‘23
21 au 23 novembre 2023 - European Cyber Week
février 2024 - SéQCure
Formation Crise et résilience

Description

Bienvenue dans ce podcast où nous abordons la seconde partie de notre série sur les DLP (Data Loss Prevention) de Microsoft 365, axée sur les postes de travail. Dans la première partie, nous avions évoqué les bases de la mise en œuvre du DLP dans l’écosystème Microsoft, couvrant des éléments comme Exchange et les services collaboratifs.

Aujourd’hui, nous explorerons davantage les fonctionnalités DLP disponibles pour les postes de travail Windows et Mac, une fonctionnalité disponible pour Mac depuis 2022. Pour configurer et gérer ces services, nous utiliserons le portail Microsoft au niveau des services Microsoft perview. Nous mettrons en avant comment configurer les DLP, notamment pour les appareils, mettant en lumière les prérequis pour activer ces services sur divers appareils.

Notre discussion mettra en avant que contrairement à la configuration cloud, l’activation des DLP sur les appareils nécessite l’accomplissement de certaines conditions préalables. Sur les appareils Windows, il n’est pas nécessaire de déployer un agent car la fonctionnalité est intégrée au système d’exploitation et doit simplement être activée. Cependant, pour les utilisateurs de Mac, un client doit être installé.

Nous discuterons également du volet Microsoft Defender pour les terminaux, expliquant qu’il fonctionne de manière similaire à DLP, facilitant ainsi le déploiement et l’activation. Un point clé à noter est que si vous avez déjà mis en place Defender, aucun travail supplémentaire n’est nécessaire pour le déploiement du DLP.

En naviguant à travers le portail, nous montrerons comment activer la fonction “Device Undering” qui est désactivée par défaut, avant de démontrer le processus d’intégration (unboarding) des appareils. La démonstration mettra en exergue l’intégration des appareils Windows et Mac, soulignant que la dernière option nécessite un déploiement via un script local, qui est plus approprié pour les tests et les POCs (Proof of Concept) plutôt que pour un déploiement à grande échelle.

Au cours de la discussion, nous mettrons l’accent sur les prérequis pour l’utilisation du DLP, incluant la nécessité d’une version minimale de Windows 10 18.09 ou Windows 11, et d’une licence Microsoft 365 de niveau A5. Il est aussi important de noter que les appareils doivent être enregistrés en mode Azure ou Azure hybride pour que DLP fonctionne.

Abordant la création et le déploiement de politiques DLP, nous mettrons en avant la capacité de contrôler des fonctionnalités spécifiques comme l’accès USB et Bluetooth. Nous discuterons de l’importance de tester ces politiques en mode audit avant de les implémenter complètement, afin de comprendre leur impact et d’éviter des problèmes potentiels.

La partie suivante de la discussion mettra en lumière les fonctionnalités avancées du DLP, y compris l’intégration des étiquettes de sensibilité pour appliquer des politiques spécifiques basées sur les classifications des documents. Nous illustrerons cela en créant une règle DLP qui identifie et audite les téléchargements de documents étiquetés “project forken” vers des navigateurs non autorisés.

Ensuite, nous discuterons des paramètres de copier-coller, des contrôles de domaine et de la gestion des types de fichiers pris en charge. Nous insisterons sur la nécessité de débuter avec le mode audit pour évaluer l’impact des politiques DLP avant de passer en mode bloc.

En explorant les paramètres supplémentaires disponibles dans l’outil, nous évoquerons des fonctionnalités comme la restriction des impressions et la gestion des accès Bluetooth et RDP.

Au fur et à mesure, nous discuterons des différents niveaux de paramétrage offerts par la solution, soulignant l’importance de bien naviguer à travers ceux-ci pour mettre en place des règles robustes qui protègent efficacement les données sensibles sans entraver la productivité.

En conclusion, nous montrerons comment les politiques DLP peuvent s’intégrer de manière transparente avec les étiquettes de sensibilité pour fournir une solution de protection des données puissante

Notes

À venir

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - M365 DLP part 1 (cloud seulement)

2023-08-02T00:00:00-04:00

Parce que… c’est l’épisode 0x332!

Shameless plug

10 au 13 août 2023 - DEFCON
29 au 31 août 2023 - Google Next ‘23
21 au 23 novembre 2023 - European Cyber Week
février 2024 - SéQCure
Formation Crise et résilience

Description

Dans cet enregistrement, le sujet principal est la présentification et la mise en place de la fonction de prévention contre la perte de données (DLP) dans Microsoft 365 (M365), en particulier pour les services de collaboration comme SharePoint et OneDrive. Cette fonction permet de détecter et prévenir les utilisations non autorisées des données sensibles au sein d’un environnement M365.

Les intervenants abordent d’abord une introduction sur les fonctionnalités de base de DLP, mentionnant que c’est une “petite mise en bouche” et que cela servira à préparer le terrain pour des discussions plus avancées. Ils précisent que bien que le déploiement de base soit relativement simple à mettre en place via la console Microsoft, les aspects plus avancés peuvent être plus complexes à déployer.

Un des points centraux de cette discussion est la personnalisation de DLP, y compris la création de types de données sensibles personnalisés et la définition de règles pour détecter ces données dans différents types de contenu, tels que les documents Word ou les courriels. Il est souligné que DLP peut être utilisé pour détecter diverses informations sensibles, y compris les numéros de comptes bancaires, les informations médicales, et les numéros de passeport.

Les intervenants insistent sur la nécessité de tester et de comprendre profondément les fonctionnalités de DLP avant sa mise en place complète, notant que cela nécessite une certaine “maturité” pour utiliser efficacement cet outil. Il est souligné que la solution n’est pas parfaite et que, par exemple, changer le type de fichier peut parfois échapper à la détection de DLP.

Ensuite, les orateurs abordent le sujet des politiques et des notifications de DLP, expliquant que les administrateurs peuvent définir des politiques spécifiques qui déterminent comment DLP réagira lorsqu’il détectera des données sensibles. Il est possible de créer des alertes pour les administrateurs, ainsi que des notifications pour les utilisateurs finaux les avertissant lorsqu’ils sont sur le point d’utiliser des données sensibles d’une manière qui pourrait violer les politiques de l’entreprise. Les utilisateurs peuvent également être autorisés à outrepasser les restrictions dans certains cas.

Les intervenants mentionnent que DLP peut aussi être appliqué à diverses “unités d’affaires” au sein d’une organisation, offrant ainsi un niveau supplémentaire de personnalisation. Ils discutent également des avantages de l’utilisation de DLP pour surveiller les services de collaboration comme SharePoint et OneDrive.

Vers la fin de la discussion, les intervenants abordent la question de la création de types de données sensibles personnalisés dans M365, soulignant que cela peut être un processus complexe nécessitant la définition précise des “patterns” de données qui doivent être surveillés. Ils précisent que M365 offre un certain degré de flexibilité, permettant aux administrateurs de définir des niveaux de confiance différents pour différentes situations.

En somme, la discussion est une exploration approfondie des fonctionnalités de base du DLP dans Microsoft 365, mettant en avant les avantages et les défis liés à sa mise en œuvre. Les intervenants suggèrent qu’une mise en œuvre réussie de DLP peut aider à protéger les données sensibles tout en permettant une certaine flexibilité et personnalisation pour répondre aux besoins spécifiques d’une organisation. La session se termine avec une note sur l’anticipation d’explorer des aspects plus avancés de DLP dans les sessions futures.

Notes

À venir

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Cloud IDS - Détection native des attaques réseau internes et externes

2023-07-24T00:00:00-04:00

Parce que… c’est l’épisode 0x327!

Shameless plug

10 au 13 août 2023 - DEFCON
25 au 27 août 2023 - Blue Team Con
29 au 31 août 2023 - Google Next ‘23
21 au 23 novembre 2023 - European Cyber Week
février 2024 - SéQCure
Formation Crise et résilience

Description

Le podcast débute avec une introduction chaleureuse entre les hôtes, mentionnant un hiatus depuis leur dernier enregistrement. Ils se plongent rapidement dans le sujet du jour, le “Cloud IDS” (système de détection d’intrusion), un produit qui a vu une implication profonde de l’un des hôtes.

Le premier point de discussion abordé est le défi de déployer des pare-feux traditionnels dans les environnements cloud. Les outils on-premises (sur site) ont du mal à s’adapter à l’écosystème du cloud. Une des raisons principales est que les architectures cloud ne sont pas conçues pour avoir un pare-feu placé devant un autre. Pour que cela fonctionne, des équilibreurs de charge supplémentaires sont nécessaires, complexifiant le processus.

Un autre problème soulevé est la communication limitée entre les équipes de sécurité et celles du cloud dans de nombreuses entreprises. Cette disparité conduit souvent à des chocs d’approches lorsqu’il s’agit d’intégrer la sécurité dans les infrastructures cloud.

C’est dans ce contexte que Google a introduit Cloud IDS, développé en partenariat avec Palo Alto Networks. Ce service utilise la technologie éprouvée de Palo Alto, mais est entièrement géré par Google. En essence, il capture le trafic destiné à un workload (charge de travail) et le redirige vers des versions gérées de Palo Alto pour analyse.

Le service est intégré à la console Google Cloud, et une fois le trafic analysé, les logs sont renvoyés dans Google Cloud Logging. La beauté de ce service réside dans sa capacité à éliminer la complexité du déploiement traditionnel et dans l’intégration étroite avec d’autres outils Google, tels que Looker, pour la visualisation.

Les hôtes ont également discuté du cycle de vente typique pour Cloud IDS. Plutôt que de passer par un long processus d’implémentation, Cloud IDS permet aux entreprises de consommer le service sans la complexité associée à l’installation et à la maintenance.

Il est crucial de noter que lors de l’utilisation de Cloud IDS, une configuration appropriée est essentielle. Les utilisateurs sont encouragés à ne pas l’activer aveuglément, mais plutôt à réfléchir à leurs objectifs et à ce qu’ils souhaitent surveiller.

Un point fort du Cloud IDS est sa capacité à capturer le trafic non seulement entrant et sortant d’une VM, mais aussi le trafic interne à un cluster Kubernetes, offrant une visibilité sans précédent sur les communications intra-cluster.

En conclusion, Cloud IDS est une solution puissante pour ceux qui cherchent à améliorer leur visibilité et leur sécurité dans les environnements cloud, mais comme avec tous les outils, il doit être utilisé judicieusement pour obtenir les meilleurs résultats.

Notes

Google Cloud IDS

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux réels par 3 Brasseurs

Teknik - Pratiquer la conformité

2023-07-24T00:00:00-04:00

Parce que… c’est l’épisode 0x328!

Shameless plug

10 au 13 août 2023 - DEFCON
25 au 27 août 2023 - Blue Team Con
29 au 31 août 2023 - Google Next ‘23
21 au 23 novembre 2023 - European Cyber Week
février 2024 - SéQCure
Formation Crise et résilience

Description

L’épisode aborde la question de la conformité dans les organisations, particulièrement dans le secteur de la technologie de l’information (TI). Les intervenants, dont Michael, discutent de la manière dont le sujet est souvent négligé ou délégué à d’autres départements tels que les services juridiques. Toutefois, la réalité est que tous les départements d’une organisation doivent s’engager activement dans la conformité pour garantir la sécurité et le bon fonctionnement.

La conformité englobe diverses politiques, processus et procédures que les entreprises doivent suivre, en particulier en cas d’incidents tels que les violations de données. Bien que ces politiques puissent souvent être trouvées dans les sections légales des sites web des entreprises, la responsabilité ne repose pas uniquement sur le département juridique. Les équipes de TI et de sécurité jouent un rôle crucial dans leur mise en œuvre et leur respect.

L’importance de la conformité est accentuée par les exigences croissantes des clients et des régulateurs. Par exemple, les entreprises pourraient être tenues de se conformer à des normes comme ISO 25000 ou HIPAA, selon la région et le secteur d’activité. Ne pas le faire pourrait entraîner des conséquences graves non seulement pour les entreprises, mais aussi pour les individus impliqués.

La discussion aborde également l’évolution de la TI et comment, dans le passé, certaines tâches étaient plus manuelles et artisanales. Avec l’avènement des technologies modernes et de l’automatisation, de nombreuses tâches répétitives ont été déléguées aux machines, permettant aux humains de se concentrer sur des tâches plus créatives et significatives. Cependant, il est essentiel de comprendre les principes fondamentaux sur lesquels ces technologies sont construites pour les utiliser efficacement.

En fin de compte, la conformité, bien que parfois perçue comme une contrainte, offre une structure qui permet d’assurer la sécurité, l’efficacité et la responsabilité au sein des organisations. C’est un élément essentiel pour avancer et réussir dans le paysage technologique d’aujourd’hui.

Notes

À venir

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Démo Bloodhound

2023-07-19T00:00:00-04:00

Parce que… c’est l’épisode 0x326!

Shameless plug

10 au 13 août 2023 - DEFCON
25 au 27 août 2023 - Blue Team Con
29 au 31 août 2023 - Google Next ‘23
21 au 23 novembre 2023 - European Cyber Week
février 2024 - SéQCure
Formation Crise et résilience

Notes

À venir

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Évaluer sa posture de sécurité avec Defender for Cloud

2023-07-18T00:00:00-04:00

Parce que… c’est l’épisode 0x325!

Shameless plug

10 au 13 août 2023 - DEFCON
25 au 27 août 2023 - Blue Team Con
29 au 31 août 2023 - Google Next ‘23
21 au 23 novembre 2023 - European Cyber Week
février 2024 - SéQCure
Formation Crise et résilience

Notes

(Azure AdvisorAzure Advisor (WAF assistant))[https://learn.microsoft.com/en-us/azure/architecture/framework/]
- WHAT : Azure Well-Architected Framework assitant
(Microsoft Defender for Cloud (MDFC) - Cloud-native application protection platform (CNAPP))[https://learn.microsoft.com/en-us/azure/defender-for-cloud/concept-cloud-security-posture-management]
- WHAT
  - CSPM - Cloud Security Posture Management
  - CWPP - Cloud Workload Protection
  - Multi-Cloud Protection
(Azure Policy (Compliance))[https://learn.microsoft.com/en-us/azure/governance/policy/]
- WHAT : helps to enforce organizational standards and to assess compliance at-scale
- (Details of the Canada Federal PBMM Regulatory Compliance built-in initiative)[https://learn.microsoft.com/en-us/azure/governance/policy/samples/canada-federal-pbmm]
(Azure Governance Visualizer aka AzGovViz (Dashboard for managers and architects))[https://github.com/JulianHayward/Azure-MG-Sub-Governance-Reporting]
- (AzGovViz)[https://www.azadvertizer.net/azgovvizv4/demo/AzGovViz_demo.html]
- (Cloud Adoption Framework)[https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/resources/tools-templates]
- WHAT
  - PowerShell script that captures Azure Governance related information such as Azure Policy, RBAC (a lot more) by polling Azure ARM, Storage and Microsoft Graph APIs.
  - Tool listed in the Microsoft CAF : Tools and templates
  - (Can include : PSRule.Rules.Azure)[https://github.com/Azure/PSRule.Rules.Azure]

Azure Quick Review aka azqr (best practice review) WHAT : high level assessment of an Azure Subscription or Resource Group https://github.com/Azure/azqr

(Azure AD Security - Identity Secure Score)[https://learn.microsoft.com/en-us/azure/active-directory/fundamentals/identity-secure-score]
- WHAT : indicator for how aligned you are with Microsoft’s best practice recommendations for security.
(Azure Template-analyzer (IaC analyzer))[https://github.com/Azure/template-analyzer]
- WHAT : Template scanner for security misconfiguration and best practices
(Azure CCOInsights (Dashboard for managers and architects))[https://github.com/Azure/CCOInsights]
- WHAT : Dashboards PowerBI with insights about Azure advisor optimizations, Azure Security Center Alerts, Networking, Compute, RBAC, Idle resources and Subscriptions Quotas and Limits

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Historique et introduction à l'EDR... et sujets connexes!

2023-07-17T00:00:00-04:00

Parce que… c’est l’épisode 0x324!

Préambule

Shameless plug

10 au 13 août 2023 - DEFCON
25 au 27 août 2023 - Blue Team Con
29 au 31 août 2023 - Google Next ‘23
21 au 23 novembre 2023 - European Cyber Week
février 2024 - SéQCure
Formation Crise et résilience

Notes

LimaCharlie.io

Collaborateurs

Actif

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Micorosoft Defender for Office (part 2)

2023-07-10T00:00:00-04:00

Parce que… c’est l’épisode 0x321!

Shameless plug

10 au 13 août 2023 - DEFCON
25 au 27 août 2023 - Blue Team Con
29 au 31 août 2023 - Google Next ‘23
21 au 23 novembre 2023 - European Cyber Week
février 2024 - SéQCure
Formation Crise et résilience

Notes

À venir

Collaborateurs

Actif

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Micorosoft Defender for Office (part 1 - EOP)

2023-07-05T00:00:00-04:00

Parce que… c’est l’épisode 0x320!

Shameless plug

10 au 13 août 2023 - DEFCON
25 au 27 août 2023 - Blue Team Con
29 au 31 août 2023 - Google Next ‘23
21 au 23 novembre 2023 - European Cyber Week
février 2024 - SéQCure
Formation Crise et résilience

Notes

À venir

Collaborateurs

Actif

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Retour d'expérience NorthSec... et ChatGPT comme assistant?

2023-07-04T00:00:00-04:00

Parce que… c’est l’épisode 0x319!

Shameless plug

10 au 13 août 2023 - DEFCON
25 au 27 août 2023 - Blue Team Con
29 au 31 août 2023 - Google Next ‘23
21 au 23 novembre 2023 - European Cyber Week
février 2024 - SéQCure
Formation Crise et résilience

Notes

NorthSec

Collaborateurs

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Appsec - Outils de tests

2023-07-03T00:00:00-04:00

Parce que… c’est l’épisode 0x318!

Shameless plug

10 au 13 août 2023 - DEFCON
25 au 27 août 2023 - Blue Team Con
29 au 31 août 2023 - Google Next ‘23
21 au 23 novembre 2023 - European Cyber Week
février 2024 - SéQCure
Formation Crise et résilience

Notes

À venir

Collaborateurs

Actif

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Protection avancée de la messagerie courriel (part 2)

2023-06-29T00:00:00-04:00

Parce que… c’est l’épisode 0x317!

Shameless plug

10 au 13 août 2023 - DEFCON
25 au 27 août 2023 - Blue Team Con
29 au 31 août 2023 - Google Next ‘23
21 au 23 novembre 2023 - European Cyber Week
février 2024 - SéQCure
Formation Crise et résilience

Notes

À venir

Collaborateurs

Actif

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Analyse de malwares

2023-06-28T00:00:00-04:00

Parce que… c’est l’épisode 0x316!

Shameless plug

10 au 13 août 2023 - DEFCON
25 au 27 août 2023 - Blue Team Con
29 au 31 août 2023 - Google Next ‘23
21 au 23 novembre 2023 - European Cyber Week
février 2024 - SéQCure
Formation Crise et résilience

Notes

Glimps

Collaborateurs

Actif

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Protection de la messagerie courriel (part 1)

2023-06-07T00:00:00-04:00

Parce que… c’est l’épisode 0x307!

Shameless plug

10 au 13 août 2023 - DEFCON
29 au 31 août 2023 - Google Next ‘23
21 au 23 novembre 2023 - European Cyber Week
février 2024 - SéQCure
Formation Crise et résilience

Notes

Collaborateurs

Actif

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Campagne Caffeine et licences M365

2023-06-06T00:00:00-04:00

Parce que… c’est l’épisode 0x306!

Shameless plug

10 au 13 août 2023 - DEFCON
29 au 31 août 2023 - Google Next ‘23
21 au 23 novembre 2023 - European Cyber Week
février 2024 - SéQCure
Formation Crise et résilience

Notes

Collaborateurs

Actif

Crédits

Montage par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Kubernetes - Introduction

2023-06-01T00:00:00-04:00

Parce que… c’est l’épisode 0x305!

Shameless plug

18 au 26 mai 2023 - NorthSec
10 au 13 août 2023 - DEFCON
février 2024 - SéQCure
Formation Crise et résilience

Notes

xxxx

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux réels par Noctem

Teknik - Analyse du groupe APT TA444

2023-05-30T00:00:00-04:00

Parce que… c’est l’épisode 0x303!

Shameless plug

Notes

TA444: The APT Startup Aimed at Acquisition (of Your Funds)

Collaborateurs

Actif

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Google Generative IA

2023-05-25T00:00:00-04:00

Parce que… c’est l’épisode 0x302!

Shameless plug

10 au 13 août 2023 - DEFCON
29 au 31 août 2023 - Google Nexts ‘23
février 2024 - SéQCure
Formation Crise et résilience

Notes

Supercharging security with generative AI

Collaborateurs

Actif

Crédits

Montage audio par Intrasecure inc
Locaux réels par 3 Brasseurs

Teknik - Spécial au NothSec avec Mickael... sur du chialage libre sur le IA

2023-05-24T00:00:00-04:00

Parce que… c’est l’épisode 0x301!

Shameless plug

10 au 13 août 2023 - DEFCON
29 au 31 août 2023 - Google Nexts ‘23
février 2024 - SéQCure
Formation Crise et résilience

Notes

À venir

Collaborateurs

Actif

Crédits

Montage audio par Intrasecure inc
Locaux réels par NorthSec

Teknik - Microsoft Intune - part 2

2023-05-09T00:00:00-04:00

Parce que… c’est l’épisode 0x296!

Shameless plug

18 au 26 mai 2023 - NorthSec
10 au 13 août 2023 - DEFCON
février 2024 - SéQCure
Formation Crise et résilience

Notes

À venir

Collaborateurs

Actif

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Microsoft Intune - part 1

2023-05-02T00:00:00-04:00

Parce que… c’est l’épisode 0x294!

Shameless plug

18 au 26 mai 2023 - NorthSec
10 au 13 août 2023 - DEFCON
février 2024 - SéQCure
Formation Crise et résilience

Notes

À venir

Collaborateurs

Actif

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Bloodhound

2023-04-27T00:00:00-04:00

Parce que… c’est l’épisode 0x293!

Shameless plug

18 au 26 mai 2023 - NorthSec
10 au 13 août 2023 - DEFCON
février 2024 - SéQCure
Formation Crise et résilience

Notes

À venir

Collaborateurs

Actif

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - DNS flattening

2023-04-20T00:00:00-04:00

Parce que… c’est l’épisode 0x291!

Shameless plug

5 au 7 avril 2023 - FIC
18 au 26 mai 2023 - NorthSec
10 au 13 août 2023 - DEFCON
février 2024 - SéQCure
Formation Crise et résilience

Notes

À venir

Collaborateurs

Actif

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - DevSecOps

2023-04-18T00:00:00-04:00

Parce que… c’est l’épisode 0x290!

Shameless plug

18 au 26 mai 2023 - NorthSec
10 au 13 août 2023 - DEFCON
février 2024 - SéQCure
Formation Crise et résilience

Notes

À venir

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - 2022 Cortex Xpanse Attack Surface Threat Report

2023-04-11T00:00:00-04:00

Parce que… c’est l’épisode 0x284!

Shameless plug

5 au 7 avril 2023 - FIC
18 au 26 mai 2023 - NorthSec
10 au 13 août 2023 - DEFCON
Formation Crise et résilience

Notes

2022 Cortex Xpanse Attack Surface Threat Report

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Préparer son landing zone (AWS)

2023-03-28T00:00:00-04:00

Parce que… c’est l’épisode 0x276!

Préambule

Il y avait des travaux chez Davy ;-)

Shameless plug

Notes

À venir

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Le test d'intrusion... bien défini!

2023-03-21T00:00:00-04:00

Parce que… c’est l’épisode 0x274!

Shameless plug

Notes

À venir

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Gestion des incidents... et histoires de guerre!

2023-03-09T00:00:00-05:00

Parce que… c’est l’épisode 0x271!

Shameless plug

Notes

À venir

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Cloud Security Command Center - Gouvernance, Conformité et détection des activités malicieuses

2023-02-16T00:00:00-05:00

Parce que… c’est l’épisode 0x265!

Shameless plug

1er et 2 Mars 2023 - SéQCure
Formation Crise et résilience

Notes

À venir

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux réels par Les 3 Brasseurs

Teknik - Sécurité du code

2023-02-14T00:00:00-05:00

Parce que… c’est l’épisode 0x264!

Shameless plug

1er et 2 Mars 2023 - SéQCure
Formation Crise et résilience

Notes

À venir

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Protéger son environnement cloud avec une landing zone

2023-02-07T00:00:00-05:00

Parce que… c’est l’épisode 0x254!

Shameless plug

1er et 2 Mars 2023 - SéQCure
Formation Crise et résilience

Notes

À venir

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - RedTeam - L'attaque!

2023-01-31T00:00:00-05:00

Parce que… c’est l’épisode 0x252!

Shameless plug

1er et 2 Mars 2023 - SéQCure
Formation Crise et résilience

Notes

À venir

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Introduction à la sécurité applicative (appsec)

2023-01-12T00:00:00-05:00

Parce que… c’est l’épisode 0x247!

Shameless plug

1er et 2 Mars 2023 - SéQCure
Formation Crise et résilience

Notes

À venir

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Cloud Armor - La solution de Google Cloud pour sécuriser les applications Web et le top 10 OWASP avec notre fonction adaptive protection

2023-01-11T00:00:00-05:00

Parce que… c’est l’épisode 0x246!

Shameless plug

1er et 2 Mars 2023 - SéQCure
Formation Crise et résilience

Notes

Google Cloud Armor

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux réels par Les 3 Brasseurs

Teknik - 7 Common Security Gaps You Can Address to be More Secure

2023-01-04T00:00:00-05:00

Parce que… c’est l’épisode 0x243!

Shameless plug

1er et 2 Mars 2023 - SéQCure
Formation Crise et résilience

Notes

7 Common Security Gaps You Can Address to be More Secure

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Recap 2022 avec Franck... finalement sur l'identité

2022-12-29T00:00:00-05:00

Parce que… c’est l’épisode 0x240!

Shameless plug

1er et 2 Mars 2023 - SéQCure
Formation Crise et résilience

Notes

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - RedTeam - Volet reconnaissance

2022-12-14T00:00:00-05:00

Parce que… c’est l’épisode 0x234!

Shameless plug

1er et 2 Mars 2023 - SéQCure
Formation Crise et résilience

Notes

À venir

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Riverside.fm

Tekinik - 3 nouvelles sur Azure

2022-12-08T00:00:00-05:00

Parce que… c’est l’épisode 0x231!

Shameless plug

1er et 2 Mars 2023 - SéQCure
Formation Crise et résilience

Notes

Sensitive Data of 65,000+ Entities in 111 Countries Leaked due to a Single Misconfigured Data Bucket
BlueBleed
CosMiss: Azure Cosmos DB Notebook Remote Code Execution Vulnerability AzureActivity | where OperationNameValue contains “Microsoft.Compute/virtualMachines/extensions/write” | where Resource == “enablevmaccess” | extend ExtProps = parse_json(Properties) | project OperationName, ExtProps[“message”], ResourceGroup, Category, Caller, ExtProps[“entity”]

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - AWS Outil de sécurité du cloud

2022-12-06T00:00:00-05:00

Parce que… c’est l’épisode 0x230!

Shameless plug

Début Mars 2023 - SéQCure
Formation Crise et résilience

Notes

À venir

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Vulnerability Operations Center (VOC)

2022-12-03T00:00:00-05:00

Parce que… c’est l’épisode 0x229!

Préambule

Les équipes Red Team, Blue Team et Purple Team sont des méthodes de travail qui visent à améliorer la sécurité des systèmes informatiques. La VOC (Vulnerability Opérations Center) est le cœur de ces méthodes et elle est responsable du fonctionnement normal des systèmes; SOC (Sécurity Operations Center), NOC (Network Operations Center) et autres services tels que le formalisme sont inclus dans cette vaste approche. En spécifiant les responsabilités du personnel sur les différentes équipes, chaque organisation peut assurer une sécurité optimale en vérifiant préventivement les systèmes pour détecter les menaces potentielles.

Shameless plug

Début Mars 2023 - SéQCure
Formation Crise et résilience

Description

Introduction

Dans cet épisode technique du Pôle Secure, Nicolas reçoit Yassir Kazar pour discuter d’un concept qu’il a contribué à formaliser : le Vulnerability Operations Center, ou VOC. Ce concept, issu d’un article de blog publié par Yassir et son équipe, propose une nouvelle façon de structurer et de superviser les opérations de sécurité offensive au sein des organisations. La discussion s’articule autour d’un constat simple mais souvent ignoré : les équipes de sécurité manquent cruellement d’une tour de contrôle unifiée pour piloter leurs activités offensives.

Le constat : un volet offensif fragmenté

Depuis plusieurs années, Yassir et son équipe observent que les entreprises multiplient les activités de sécurité offensive — red teaming, tests d’intrusion (pentests), programmes de bug bounty, audits — mais le font de manière cloisonnée et hétérogène. Chaque opération est menée par des acteurs différents, avec des processus distincts, des formats de rapport variés (texte, slides, documents), et aucune vision centralisée.

Cette fragmentation engendre plusieurs problèmes concrets. Premièrement, elle rend difficile la comparaison entre les résultats de différentes opérations. Par exemple, si un test d’intrusion interne, un pentest réalisé avec un partenaire externe et un programme de bug bounty pointent tous vers la même vulnérabilité sur un même actif, cela devrait déclencher une alarme immédiate. Mais si ces opérations ne sont pas consolidées dans un tableau de bord commun, ce signal critique risque tout simplement de passer inaperçu.

Le VOC : transposer le SOC au côté offensif

Face à ce constat, l’idée du VOC s’est imposée naturellement. Le Security Operations Center (SOC) est bien connu comme tour de contrôle pour le versant défensif de la sécurité : il centralise les alertes, suit les incidents et s’appuie sur un triptyque technologie-ressources-processus. Yassir et son équipe ont simplement appliqué cette logique au côté offensif.

Le VOC vise ainsi à unifier dans une seule plateforme toutes les opérations offensives d’une organisation. Il permet de superviser qui fait quoi, quand, sur quel actif, avec quelles compétences, et surtout de comparer les résultats de façon homogène pour prendre de meilleures décisions. Sur la plateforme de Yassir, cette approche s’est concrétisée par l’observation que déjà 30 % des clients utilisent au moins deux services distincts — bug bounty, VDP ou pentest — souvent sans coordination formelle entre eux.

Réduire le stress des équipes de sécurité

L’un des enjeux les plus soulignés dans cet échange est la charge mentale des équipes de sécurité. Les études disponibles montrent que la grande majorité des professionnels du secteur déclarent des niveaux de stress atteignant 8 sur 10 en permanence. Un tel niveau, maintenu de façon chronique, mène inévitablement à l’épuisement professionnel, aux erreurs critiques ou aux démissions. Ce n’est pas un problème marginal : c’est une crise structurelle.

Le VOC s’attaque directement à ce problème en réduisant la charge cognitive liée à la gestion de multiples opérations non coordonnées. Lorsque les informations sont centralisées, formalisées et comparables, les décideurs — notamment les RSSI — passent moins de temps à reconstituer un puzzle épars et plus de temps à agir efficacement. Cela passe aussi par des détails opérationnels apparemment simples, comme la visibilité sur la disponibilité des ressources : savoir en temps réel quels testeurs ou analystes sont disponibles évite les interruptions inutiles et optimise l’allocation des compétences.

Séparer l’offensif du défensif

Yassir et Nicolas s’accordent sur un principe fondamental : les compétences offensives et défensives sont fondamentalement différentes et ne doivent pas être mélangées sous prétexte de rationalisation budgétaire. Les exercices de type Purple Team ont leur utilité dans des contextes d’entraînement ou de simulation, mais au quotidien, demander à une même personne d’attaquer et de défendre simultanément relève de la schizophrénie organisationnelle. Cela dégrade la performance et épuise les individus.

L’enjeu est donc de structurer des équipes distinctes, avec des responsabilités claires, tout en disposant d’une tour de contrôle — le VOC — qui assure la coordination et l’arrimage entre ces deux mondes. La bonne affectation des compétences est elle aussi critique : placer un expert en sécurité réseau sur des tests d’applications mobiles, par exemple, ne donnera pas de résultats optimaux. La connaissance fine des profils et de leurs spécialités, centralisée dans le VOC, permet d’aligner les bons experts sur les bons sujets.

La pénurie de talents et l’élasticité des plateformes

Les deux interlocuteurs abordent également la pénurie structurelle de profils en cybersécurité. Les systèmes éducatifs n’ont pas été conçus pour produire en masse les compétences dont les organisations ont besoin aujourd’hui, et les cycles de formation sont trop lents par rapport aux évolutions technologiques. Dans cinq ans, quand les formations actuelles commenceront à porter leurs fruits, les besoins du marché auront déjà évolué — vers des sujets comme la cryptographie post-quantique, par exemple.

Face à cette réalité, les plateformes comme celle de Yassir offrent une forme d’élasticité humaine : elles permettent d’accéder à des compétences rares au-delà des frontières d’une organisation, à la demande, sans les contraintes d’un recrutement permanent. C’est un levier essentiel pour les entreprises qui ne peuvent pas se permettre d’internaliser tous les profils dont elles ont besoin.

La souveraineté des données et le retour du on-premise

Un dernier point abordé concerne la maîtrise des données. Si le modèle SaaS a longtemps dominé, on observe un retour progressif vers des déploiements on-premise ou en cloud privé, notamment pour des raisons réglementaires ou de souveraineté. Yassir note que de nombreux clients qui déploient un VOC aujourd’hui exigent que les données restent dans un environnement qu’ils contrôlent entièrement. Cette tendance semble appelée à s’accélérer dans les années à venir, avec l’émergence d’un modèle hybride cherchant à combiner les avantages du SaaS et la maîtrise du on-premise.

Conclusion

Le VOC représente une évolution naturelle et nécessaire de la maturité en cybersécurité offensive. En centralisant, formalisant et rendant comparables toutes les opérations offensives, il permet non seulement de prendre de meilleures décisions, mais aussi de préserver les équipes d’un épuisement qui fragilise l’ensemble de la posture de sécurité des organisations.

Notes

What is a Vulnerability Operations Center (VOC)?

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Multiplication des données de sécurité

2022-12-01T00:00:00-05:00

Parce que… c’est l’épisode 0x228!

Shameless plug

Mars 2023 - SéQCure
Formation Crise et résilience

Notes

À venir

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux réels par Les 3 Brasseurs

Teknik - Virtual patching

2022-11-29T00:00:00-05:00

Parce que… c’est l’épisode 0x227!

Shameless plug

Début Mars 2023 - SéQCure
Formation Crise et résilience

Notes

À venir

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux réels par Palais des congrès de Montréal

Teknik - Microsoft Defender for Identity (MDI)

2022-11-24T00:00:00-05:00

Parce que… c’est l’épisode 0x225!

Shameless plug

Début Mars 2023 - SéQCure
Formation Crise et résilience

Notes

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Introduction à l'EDR

2022-11-17T00:00:00-05:00

Parce que… c’est l’épisode 0x222!

Shameless plug

Mars 2023 - SéQCure
Formation Crise et résilience

Notes

À venir

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux réels par Palais des congrès de Montréal

Teknik - Web Application quoi? (WAF)

2022-11-15T00:00:00-05:00

Parce que… c’est l’épisode 0x221!

Shameless plug

Mars 2023 - SéQCure
Formation Crise et résilience

Notes

À venir

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - RedTeam - Règles d'engagement

2022-11-08T00:00:00-05:00

Parce que… c’est l’épisode 0x218!

Shameless plug

15 au 17 novembre 2022 - European Cyber Week
novembre 2022 - Connected Week Angers
Mars 2023 - SéQCure
Formation Crise et résilience

Notes

À venir

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Moderniser ses applications IaaS sur GKE

2022-11-03T00:00:00-04:00

Parce que… c’est l’épisode 0x216!

Shameless plug

15 au 17 novembre 2022 - European Cyber Week
novembre 2022 - Connected Week Angers
Mars 2023 - SéQCure
Formation Crise et résilience

Notes

À venir

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux réels par Les 3 Brasseurs

Teknik - AWS Haute disponibilité

2022-11-01T00:00:00-04:00

Parce que… c’est l’épisode 0x215!

Shameless plug

15 au 17 novembre 2022 - European Cyber Week
novembre 2022 - Connected Week Angers
Mars 2023 - SéQCure
Formation Crise et résilience

Notes

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Qu'est-ce que le ZTaaS?

2022-10-27T00:00:00-04:00

Parce que… c’est l’épisode 0x213!

Shameless plug

15 au 17 novembre 2022 - European Cyber Week
novembre 2022 - Connected Week Angers
Mars 2023 - SéQCure
Formation Crise et résilience

Notes

À venir

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Vulnérabilité OME et Microsoft Ignite

2022-10-22T00:00:00-04:00

Parce que… c’est l’épisode 0x211!

Shameless plug

15 au 17 novembre 2022 - European Cyber Week
novembre 2022 - Connected Week Angers
Mars 2023 - SéQCure
Formation Crise et résilience

Notes

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Forensic - Introduction

2022-10-11T00:00:00-04:00

Parce que… c’est l’épisode 0x206!

Shameless plug

15 au 17 novembre 2022 - European Cyber Week
novembre 2022 - Connected Week Angers
Mars 2023 - SéQCure
Formation Crise et résilience

Notes

À venir

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Conformité

2022-10-08T00:00:00-04:00

Parce que… c’est l’épisode 0x205!

Shameless plug

15 au 17 novembre 2022 - European Cyber Week
novembre 2022 - Connected Week Angers
Mars 2023 - SéQCure
Formation Crise et résilience

Notes

À venir

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Confidentialité des données chez Google

2022-10-06T00:00:00-04:00

Parce que… c’est l’épisode 0x204!

Shameless plug

15 au 17 novembre 2022 - European Cyber Week
novembre 2022 - Connected Week Angers
Mars 2023 - SéQCure
Formation Crise et résilience

Notes

À venir

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux réels par Les 3 Brasseurs

Teknik - AWS Sécurité des réseaux

2022-10-04T00:00:00-04:00

Parce que… c’est l’épisode 0x203!

Shameless plug

6 et 7 octobre 2022 - Objective by the Sea v5.0 The Objective-See Foundation
15 au 17 novembre 2022 - European Cyber Week
novembre 2022 - Connected Week Angers
Mars 2023 - SéQCure
Formation Crise et résilience

Notes

À venir

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Zoom

Teknik - KQL part 1

2022-09-27T00:00:00-04:00

Parce que… c’est l’épisode 0x200!

Shameless plug

6 et 7 octobre 2022 - Objective by the Sea v5.0 The Objective-See Foundation
15 au 17 novembre 2022 - European Cyber Week
novembre 2022 - Connected Week Angers
Mars 2023 - SéQCure
Formation Crise et résilience

Notes

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Riverside.fm

Tekinik - Prime aux bogues, l'avenir

2022-09-20T00:00:00-04:00

Parce que… c’est l’épisode 0x197!

Shameless plug

6 et 7 octobre 2022 - Objective by the Sea v5.0 The Objective-See Foundation
15 au 17 novembre 2022 - European Cyber Week
novembre 2022 - Connected Week Angers
Mars 2023 - SéQCure
Formation Crise et résilience

Notes

À venir

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Zoom

Teknik - Épisode autogéré!

2022-09-17T00:00:00-04:00

Parce que… c’est l’épisode 0x196!

Shameless plug

6 et 7 octobre 2022 - Objective by the Sea v5.0 The Objective-See Foundation
15 au 17 novembre 2022 - European Cyber Week
novembre 2022 - Connected Week Angers
Mars 2023 - SéQCure
Formation Crise et résilience

Notes

À venir

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - Sécurité M365 - PIM

2022-09-15T00:00:00-04:00

Parce que… c’est l’épisode 0x195!

Shameless plug

6 et 7 octobre 2022 - Objective by the Sea v5.0 The Objective-See Foundation
15 au 17 novembre 2022 - European Cyber Week
novembre 2022 - Connected Week Angers
Mars 2023 - SéQCure
Formation Crise et résilience

Notes

À venir

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - RedTeam - Introduction

2022-09-13T00:00:00-04:00

Parce que… c’est l’épisode 0x194!

Shameless plug

6 et 7 octobre 2022 - Objective by the Sea v5.0 The Objective-See Foundation
15 au 17 novembre 2022 - European Cyber Week
novembre 2022 - Connected Week Angers
Mars 2023 - SéQCure
Formation Crise et résilience

Notes

CTF365

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Riverside.fm

Teknik - AWS Sécurité des données

2022-09-06T00:00:00-04:00

Parce que… c’est l’épisode 0x191!

Shameless plug

6 et 7 octobre 2022 - Objective by the Sea v5.0 The Objective-See Foundation
15 au 17 novembre 2022 - European Cyber Week
novembre 2022 - Connected Week Angers
Mars 2023 - SéQCure
Formation Crise et résilience

Notes

À venir

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Zoom

Teknik - Distinction entre les tests de sécurité en blackbox et whitebox

2022-08-23T00:00:00-04:00

Parce que… c’est l’épisode 0x187!

Shameless plug

6 et 7 octobre 2022 - Objective by the Sea v5.0 The Objective-See Foundation
15 au 17 novembre 2022 - European Cyber Week
novembre 2022 - Connected Week Angers
Mars 2023 - SéQCure
Formation Crise et résilience

Notes

Splinternet?

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Zoom

Teknik - Sécurité M365 - Accès conditionnel

2022-08-18T00:00:00-04:00

Parce que… c’est l’épisode 0x186!

Shameless plug

6 et 7 octobre 2022 - Objective by the Sea v5.0 The Objective-See Foundation
15 au 17 novembre 2022 - European Cyber Week
novembre 2022 - Connected Week Angers
Mars 2023 - SéQCure
Formation Crise et résilience

Notes

À venir

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Zoom

Teknik - Prime aux bogues, l'état de la nation

2022-08-16T00:00:00-04:00

Parce que… c’est l’épisode 0x185!

Shameless plug

6 et 7 octobre 2022 - Objective by the Sea v5.0 The Objective-See Foundation
15 au 17 novembre 2022 - European Cyber Week
novembre 2022 - Connected Week Angers
Mars 2023 - SéQCure
Formation Crise et résilience

Notes

À venir

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Zoom

Teknik - AWS Monitoring, traçabilité, observabilité, surveillance

2022-08-02T00:00:00-04:00

Parce que… c’est l’épisode 0x181!

Shameless plug

11 au 15 août 2022 - DEFCON 30
6 et 7 octobre 2022 - Objective by the Sea v5.0 The Objective-See Foundation
15 au 17 novembre 2022 European Cyber Week
novembre 2022 Connected Week Angers
Formation Crise et résilience

Notes

À venir

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Zoom

Teknik - Sentinel multi-cloud

2022-07-26T00:00:00-04:00

Parce que… c’est l’épisode 0x179!

Shameless plug

11 au 15 août 2022 - DEFCON 30
6 et 7 octobre 2022 - Objective by the Sea v5.0 The Objective-See Foundation
15 au 17 novembre 2022 - European Cyber Week
novembre 2022 - Connected Week Angers
Mars 2023 - SéQCure
Formation Crise et résilience

Notes

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Zoom

Teknik - Prime aux bogues, historique

2022-07-12T00:00:00-04:00

Parce que… c’est l’épisode 0x175!

Shameless plug

11 au 15 août 2022 - DEFCON 30
6 et 7 octobre 2022 - Objective by the Sea v5.0 The Objective-See Foundation
15 au 17 novembre 2022 European Cyber Week
novembre 2022 Connected Week Angers
Formation Crise et résilience

Notes

À venir

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Zoom

Teknik - AWS Gestion des identités et des accès

2022-07-05T00:00:00-04:00

Parce que… c’est l’épisode 0x173!

Shameless plug

11 au 15 août 2022 - DEFCON 30
6 et 7 octobre 2022 - Objective by the Sea v5.0 The Objective-See Foundation
15 au 17 novembre 2022 European Cyber Week
novembre 2022 Connected Week Angers
Formation Crise et résilience

Notes

À venir

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Zoom

Teknik - Elasticsearch part 2 - Volet sécurité (SIEM et endpoint)

2022-06-30T00:00:00-04:00

Parce que… c’est l’épisode 0x172!

Shameless plug

11 au 15 août 2022 - DEFCON 30
6 et 7 octobre 2022 - Objective by the Sea v5.0 The Objective-See Foundation
15 au 17 novembre 2022 European Cyber Week
novembre 2022 Connected Week Angers
Formation Crise et résilience

Notes

À venir

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Zoom

Teknik - ExtraReplica

2022-06-23T00:00:00-04:00

Parce que… c’est l’épisode 0x170!

Shameless plug

11 au 15 août 2022 - DEFCON 30
6 et 7 octobre 2022 - Objective by the Sea v5.0 The Objective-See Foundation
15 au 17 novembre 2022 European Cyber Week
novembre 2022 Connected Week Angers
Formation Crise et résilience

Notes

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Zoom

Teknik - Google Chronicle

2022-06-21T00:00:00-04:00

Parce que… c’est l’épisode 0x169!

Shameless plug

11 au 15 août 2022 - DEFCON 30
6 et 7 octobre 2022 - Objective by the Sea v5.0 The Objective-See Foundation
15 au 17 novembre 2022 European Cyber Week
novembre 2022 Connected Week Angers
Formation Crise et résilience

Notes

Chronicle Security - Google’s Cloud-Native SIEM Platform

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Zoom

Teknik - Elasticsearch part 1 - Volet technologique

2022-05-28T00:00:00-04:00

Parce que… c’est l’épisode 0x162!

Shameless plug

COVID-19
7 au 9 juin 2022 - FIC 2022
11 au 15 août 2022 - DEFCON 30
6 et 7 octobre 2022 - Objective by the Sea v5.0 The Objective-See Foundation
15 au 17 novembre 2022 European Cyber Week
novembre 2022 Connected Week Angers
Formation Crise et résilience
- 13 au 17 juin 2022 - Bootcamp Crise Cyber Juin 2022
- Ateliers et conférences (Auto évaluation)
- Formation PCA 2022
- 4 Guides pour survivre à une CyberCrise
- Formation PCA en ligne

Notes

À venir

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Zoom

Teknik - Sentinel part 2 - Analytics

2022-05-24T00:00:00-04:00

Parce que… c’est l’épisode 0x160!

Shameless plug

COVID-19
7 au 9 juin 2022 - FIC 2022
11 au 15 août 2022 - DEFCON 30
15 au 17 novembre 2022 European Cyber Week
novembre 2022 Connected Week Angers
Formation Crise et résilience
- 13 au 17 juin 2022 - Bootcamp Crise Cyber Juin 2022
- Ateliers et conférences (Auto évaluation)
- Formation PCA 2022
- 4 Guides pour survivre à une CyberCrise
- Formation PCA en ligne

Notes

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Zoom

Teknik - Croyance des clients sur le cloud

2022-05-22T00:00:00-04:00

Parce que… c’est l’épisode 0x159!

Shameless plug

COVID-19
7 au 9 juin 2022 - FIC 2022
11 au 15 août 2022 - DEFCON 30
15 au 17 novembre 2022 European Cyber Week
novembre 2022 Connected Week Angers
Formation Crise et résilience
- 13 au 17 juin 2022 - Bootcamp Crise Cyber Juin 2022
- Ateliers et conférences (Auto évaluation)
- Formation PCA 2022
- 4 Guides pour survivre à une CyberCrise
- Formation PCA en ligne

Notes

Who Moved My Cheese?: An A-Mazing Way to Deal with Change in Your Work and in Your Life

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Zoom

Teknik - Non, le cloud n'est pas juste l'ordinateur de quelqu'un d'autre

2022-04-23T00:00:00-04:00

Parce que… c’est l’épisode 0x144!

Shameless plug

COVID-19
17 mai 2022 - ISACA Section de Montréal - Les entreprises face au risque algorithmique
7 au 9 juin 2022 - FIC 2022
11 au 15 août 2022 - DEFCON 30
15 au 17 novembre 2022 European Cyber Week
novembre 2022 Connected Week Angers

Notes

Non, le Cloud n’est pas juste l’ordinateur de quelqu’un d’autre

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Zoom

Teknik - Retour d'expérience sur la constitution d'un COCD

2022-04-17T00:00:00-04:00

Parce que… c’est l’épisode 0x139!

Shameless plug

COVID-19
21 avril 2022 - ISACA Section de Montréal - Actualité sur la protection des données personnelles
17 mai 2022 - ISACA Section de Montréal - Les entreprises face au risque algorithmique
7 au 9 juin 2022 - FIC 2022
11 au 15 août 2022 - DEFCON 30
15 au 17 novembre 2022 European Cyber Week
novembre 2022 Connected Week Angers

Notes

À venir

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux réels par Blaxton Cartier

Teknik - Sentinel part 1 - Intro

2022-03-15T00:00:00-04:00

Parce que… c’est l’épisode 0x128!

Shameless plug

COVID-19
17 mars 2022 - ISACA Section de Montréal - IoT - La sécurité des objets connectés
24 mars 2022 - ISACA Section de Montréal - Cyber Threat Intelligence (CTI)
24 mars 2022 - IT World Canada - MapleSEC Satellite Series - The Cybersecurity Conversation Continues
4 au 6 avril 2022 - Québec Numérique - SéQCure 2022
4 au 8 avril 2022 - Québec Numérique - Semaine numériqc
- Programmation SNQC 2022
21 avril 2022 - ISACA Section de Montréal - Actualité sur la protection des données personnelles
17 mai 2022 - ISACA Section de Montréal - Les entreprises face au risque algorithmique

Notes

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Zoom

Teknik - ESET Threat Report T3 2021

2022-03-14T00:00:00-04:00

Parce que… c’est l’épisode 0x127!

Shameless plug

COVID-19
17 mars 2022 - ISACA Section de Montréal - IoT - La sécurité des objets connectés
24 mars 2022 - ISACA Section de Montréal - Cyber Threat Intelligence (CTI)
24 mars 2022 - IT World Canada - MapleSEC Satellite Series - The Cybersecurity Conversation Continues
4 au 6 avril 2022 - Québec Numérique - SéQCure 2022
4 au 8 avril 2022 - Québec Numérique - Semaine numériqc
- Programmation SNQC 2022
21 avril 2022 - ISACA Section de Montréal - Actualité sur la protection des données personnelles
17 mai 2022 - ISACA Section de Montréal - Les entreprises face au risque algorithmique

Notes

ESET Threat Report T3 2021

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Zoom

Teknik - Zero Trust à la sauce Google (BeyondCorp)

2022-03-12T00:00:00-05:00

Parce que… c’est l’épisode 0x125!

Shameless plug

COVID-19
17 mars 2022 - ISACA Section de Montréal - IoT - La sécurité des objets connectés
24 mars 2022 - ISACA Section de Montréal - Cyber Threat Intelligence (CTI)
24 mars 2022 - IT World Canada - MapleSEC Satellite Series - The Cybersecurity Conversation Continues
4 au 6 avril 2022 - Québec Numérique - SéQCure 2022
4 au 8 avril 2022 - Québec Numérique - Semaine numériqc
- Programmation SNQC 2022
21 avril 2022 - ISACA Section de Montréal - Actualité sur la protection des données personnelles
17 mai 2022 - ISACA Section de Montréal - Les entreprises face au risque algorithmique

Notes

BeyondCorp

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Zoom

Teknik - OMIGOD!

2022-02-11T00:00:00-05:00

Parce que… c’est l’épisode 0x112!

Shameless plug

COVID-19
4 au 6 avril 2022 - Québec Numérique - SéQCure 2022
4 au 8 avril 2022 - Québec Numérique - Semaine numériqc

Notes

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Zoom

Teknik - Vulnérabilités infonuagique (AWS Glue et Cloudformation)

2022-01-27T00:00:00-05:00

Parce que… c’est l’épisode 0x111!

Shameless plug

COVID-19
4 au 6 avril 2022 - Québec Numérique - SéQCure 2022
4 au 8 avril 2022 - Québec Numérique - Semaine numériqc

Notes

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Zoom

Teknik - Chiffrement bout-en-bout en visio

2022-01-14T00:00:00-05:00

Parce que… c’est l’épisode 0x106!

Shameless plug

COVID-19
4 au 6 avril 2022 - Québec Numérique - SéQCure 2022
4 au 8 avril 2022 - Québec Numérique - Semaine numériqc

Notes

Collaborateurs

Nicolas-Loïc Fortin

Crédits

Montage audio par Intrasecure inc
Locaux réels par Intrasecure inc

Teknik - ChaosDB

2022-01-07T00:00:00-05:00

Parce que… c’est l’épisode 0x102!

Shameless plug

COVID-19
4 au 6 avril 2022 - Québec Numérique - SéQCure 2022
4 au 8 avril 2022 - Québec Numérique - Semaine numériqc

Notes

À venir

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Zoom

Teknik - Azurescape

2021-10-22T00:00:00-04:00

Parce que… c’est l’épisode 0x086!

Shameless plug

COVID-19
16 au 18 novembre 2021 - European Cyber Week
24 au 27 novembre 2021 - Connected Week Angers
4 au 6 avril 2022 - Québec Numérique - SéQCure 2022
4 au 8 avril 2022 - Québec Numérique - Semaine numériqc

Notes

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Zencastr

Teknik - Automatisation de la sécurité en infonuagique

2021-09-20T22:00:00-04:00

Parce que… c’est l’épisode 0x076!

Shameless plug

COVID-19
25 septembre 2021 - BSides Montreal
4 octobre 2021 - Trust Valley Day
5 au 7 octobre 2021 - ElasticON
5 au 7 octobre 2021 - MapleSec
12 au 17 octobre 2021 - Printemps numérique - MTL Connecte
entre le 12 et le 15 octobre 2021 - BYOH: Comment les réseaux domestiques sont maintenant une extension du réseau corporatif
avril 2022 - Québec Numérique - SéQCure 2022
avril 2022 - Québec Numérique - Semaine numériqc

Notes

À venir

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Zencastr

Teknik - Explication des licences M365/Azure

2021-09-03T00:00:00-04:00

Parce que… c’est l’épisode 0x071!

Shameless plug

COVID-19
7 au 9 septembre 2021 - FIC
25 septembre 2021 - BSides Montreal
28 septembre au 1er octobre 2021 - Objective by the Sea (OBTS) v4.0
4 octobre 2021 - Trust Valley Day
5 au 7 octobre 2021 - ElasticON
5 au 7 octobre 2021 - MapleSec
12 au 17 octobre 2021 - Printemps numérique - MTL Connecte
13 octobre 2021 - BYOH: Comment les réseaux domestiques sont maintenant une extension du réseau corporatif
4 au 6 avril 2022 - Québec Numérique - SéQCure 2022
4 au 8 avril 2022 - Québec Numérique - Semaine numériqc

Notes

Microsoft 365 Licensing

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Locaux virtuels par Zencastr

Teknik - Pratiques recommandées AWS

2021-08-03T00:00:00-04:00

Parce que… c’est l’épisode 0x063!

Shameless plug

COVID-19
5 au 8 août - DEFCON
7 au 9 septembre 2021 - FIC
25 septembre 2021 - BSides Montreal
12 au 17 octobre 2021 - Printemps numérique - MTL Connecte
entre le 12 et le 15 octobre 2021 - BYOH: Comment les réseaux domestiques sont maintenant une extension du réseau corporatif
avril 2022 - Québec Numérique - SéQCure 2022
avril 2022 - Québec Numérique - Semaine numériqc

Notes

À venir

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Music VectorMan 2 “The Wind That Turns the Page” par Michael Hudak via OverClocked ReMix
Locaux virtuels par Zencastr

Teknik - Quelques conseils infonuagique

2021-07-29T21:00:00-04:00

Parce que… c’est l’épisode 0x060!

Shameless plug

COVID-19
5 au 8 août - DEFCON
7 au 9 septembre 2021 - FIC
25 septembre 2021 - BSides Montreal
12 au 17 octobre 2021 - Printemps numérique - MTL Connecte
entre le 12 et le 15 octobre 2021 - BYOH: Comment les réseaux domestiques sont maintenant une extension du réseau corporatif
avril 2022 - Québec Numérique - SéQCure 2022
avril 2022 - Québec Numérique - Semaine numériqc

Notes

À venir

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Music Tecmo World Wrestling “Warriors” par Astral Tales via OverClocked ReMix
Locaux virtuels par Zencastr

Teknik - Impact sur le SOC/COCD d'une migration infonuagique

2021-07-06T00:00:00-04:00

Parce que… c’est l’épisode 0x051!

Shameless plug

COVID-19
7 au 9 septembre 2021 - FIC
25 eptembre 2021 - BSides Montreal
12 au 17 octobre 2021 - Printemps numérique - MTL Connecte
entre le 12 et le 15 octobre 2021 - BYOH: Comment les réseaux domestiques sont maintenant une extension du réseau corporatif
avril 2022 - Québec Numérique - SéQCure 2022
avril 2022 - Québec Numérique - Semaine numériqc

Notes

À venir

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Music The Legend of Zelda: Majora’s Mask “Gâteau Romani” par Rexy via OverClocked ReMix
Locaux virtuels par Zencastr

Teknik - Infonuagique privé

2021-06-11T00:00:00-04:00

Parce que… c’est l’épisode 0x046!

Shameless plug

COVID-19
12 au 17 octobre 2021 - Printemps numérique - MTL Connecte
entre le 12 et le 15 octobre 2021 - BYOH: Comment les réseaux domestiques sont maintenant une extension du réseau corporatif
avril 2022 - Québec Numérique - SéQCure 2022
avril 2022 - Québec Numérique - Semaine numériqc

Notes

À venir

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Music Streets of Rage 2 “Strike a Pose” par MkVaff via OverClocked ReMix
Locaux virtuels par Zencastr

Teknik - Premier survol de la migration en infonuagique

2021-06-08T00:00:00-04:00

Parce que… c’est l’épisode 0x045!

Shameless plug

COVID-19
12 au 17 octobre 2021 - Printemps numérique - MTL Connecte
entre le 12 et le 15 octobre 2021 - BYOH: Comment les réseaux domestiques sont maintenant une extension du réseau corporatif
avril 2022 - Québec Numérique - SéQCure 2022
avril 2022 - Québec Numérique - Semaine numériqc

Notes

À venir

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Music Final Fantasy IX “Be Still, My Wicked Heart” par RebeccaETripp via OverClocked ReMix
Locaux virtuels par Zencastr

Teknik - Premier survol de la sécurité Azure et M365

2021-05-22T00:00:00-04:00

Parce que… c’est l’épisode 0x038!

Shameless plug

COVID-19
avril 2022 - Québec Numérique - SéQCure 2022
avril 2022 - Québec Numérique - Semaine numériqc
Nouveau balado - Incidences
Cybersécurité pour Travailleurs autonomes et PME
Monsieur TI

Notes

Collaborateurs

Crédits

Montage audio par Intrasecure inc
Music The Legend of Zelda: Ocarina of Time “Firewalker” par mikeHEARTu via OverClocked ReMix
Locaux virtuels par Zencastr