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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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

Le son n’est pas à son meilleur. Nous avons improvisé une session avec deux personnes en présence et le reste à distance.

Les réseaux sociaux occupent aujourd’hui une place primordiale dans l’écosystème des PME et des solopreneurs. Pour certaines entreprises, ils représentent même la source de revenus la plus importante. Contrairement aux sites web traditionnels, les plateformes comme Facebook, Instagram, LinkedIn et TikTok offrent une accessibilité et une facilité de déploiement qui les rendent particulièrement attractives. Comme le souligne l’équipe du podcast, même sans connaissances techniques approfondies, n’importe qui peut créer et gérer une page professionnelle, ce qui explique leur adoption massive.

Cependant, cette omniprésence s’accompagne d’une problématique majeure

Un des points les plus révélateurs du podcast concerne la réalité du support technique offert par les géants des médias sociaux, notamment Meta (Facebook et Instagram). Contrairement à ce que beaucoup d’utilisateurs pensent, il n’existe pas vraiment de garantie de service professionnel. Julien explique que le support de Meta est en réalité assuré par des firmes sous-traitantes qui n’ont même pas accès au système interne de la plateforme.

Ces équipes de support agissent plutôt comme des messagers : ils peuvent observer ce qui se passe sur les comptes, mais ne peuvent poser aucune action directe. Ils doivent eux-mêmes soumettre des demandes aux équipes internes de Meta, qui détiennent les véritables accès. Si ces équipes internes refusent d’intervenir, le support ne peut rien faire. Cette réalité contraste fortement avec l’image que les utilisateurs se font d’un service client réactif et efficace capable de résoudre rapidement les problèmes.

Le podcast illustre les conséquences dramatiques d’un compte compromis à travers plusieurs exemples concrets. Lorsqu’un pirate prend le contrôle d’une page et publie du contenu qui enfreint les règles de la plateforme, c’est la page elle-même qui est sanctionnée et bloquée, même si ce n’est pas la faute du propriétaire légitime. Meta ne cherche pas à comprendre qui a effectué les actions problématiques ; elle applique simplement ses règles, laissant l’entreprise victime sans recours.

L’exemple du Parc Safari est particulièrement éloquent. En 2023, leur page Facebook comptant 110 000 abonnés a été piratée et fermée. Trois ans plus tard, ils ne sont parvenus à reconstruire qu’une communauté de 5 000 abonnés, perdant ainsi 95 % de leur audience. Cette perte s’est traduite par une chute drastique des demandes de renseignements, passant d’une vingtaine par jour à seulement deux ou trois par mois. Un autre cas mentionné concerne une nutritionniste indépendante qui a perdu sa page de 10 000 abonnés créée en 2016, représentant l’essentiel de sa valeur commerciale, car son activité reposait principalement sur sa présence sur les réseaux sociaux.

Un point important soulevé dans la discussion est que les plateformes comme Meta offrent effectivement tous les outils nécessaires pour se protéger. Leur infrastructure de sécurité interne est solide, et les piratages ne proviennent généralement pas de failles dans leurs systèmes, mais plutôt de la négligence des utilisateurs eux-mêmes. Les entreprises qui ne mettent pas en place les bonnes pratiques de sécurité sont donc responsables de la compromission de leurs comptes.

Cependant, cette réalité soulève des questions sur la responsabilité des plateformes. Bien que les outils de protection existent, si les utilisateurs ne les utilisent pas, les entreprises comme Meta ne considèrent pas nécessaire d’offrir un support efficace. Cette approche peut sembler discutable, mais elle reflète la position de ces géants technologiques : si c’est la faute de l’utilisateur, pourquoi investir dans un support coûteux ?

Le podcast met l’accent sur plusieurs mesures de sécurité fondamentales. La première et la plus importante est l’activation du double facteur d’authentification (MFA) sur tous les comptes de réseaux sociaux, ainsi que sur les adresses courriel qui leur sont associées. Cette couche de sécurité supplémentaire constitue la défense la plus efficace contre les tentatives de piratage.

La gestion des accès représente un autre aspect crucial souvent négligé. Les entreprises doivent régulièrement effectuer des revues d’accès pour s’assurer que seules les personnes autorisées peuvent accéder à leurs pages professionnelles. Lorsqu’un employé quitte l’entreprise ou qu’un mandat avec une agence de marketing se termine, il est impératif de retirer immédiatement leurs accès. Le podcast révèle que de nombreuses entreprises n’ont aucun processus interne pour gérer les accès aux réseaux sociaux lors du départ d’un employé, alors qu’elles ont des protocoles bien établis pour récupérer les ordinateurs portables et fermer les comptes Microsoft.

Un autre principe fondamental est la gestion appropriée des rôles et permissions. Trop souvent, toutes les personnes qui travaillent sur les réseaux sociaux d’une entreprise reçoivent le statut d’administrateur, alors que ce niveau d’accès devrait être réservé uniquement à ceux qui en ont réellement besoin. Un stagiaire qui publie du contenu et gère les commentaires n’a pas besoin d’être administrateur de la page. Cette attribution excessive de privilèges augmente considérablement la surface d’attaque en cas de compromission d’un compte.

Ce podcast met en lumière un paradoxe troublant : alors que les réseaux sociaux sont devenus essentiels pour la survie et la croissance de nombreuses PME, leur sécurité reste largement sous-estimée. La perte d’un compte peut avoir des conséquences dévastatrices, tant sur le plan financier que réputationnel, avec des communautés bâties au fil des années qui disparaissent en un instant. La solution ne réside pas dans l’espoir d’un support client providentiel, mais dans l’adoption proactive de bonnes pratiques de sécurité : activation du MFA, gestion rigoureuse des accès, attribution appropriée des rôles, et sauvegarde des codes de secours. Comme le souligne l’équipe, se protéger avant qu’un incident ne survienne est infiniment plus simple, moins coûteux et moins stressant que tenter de récupérer un compte compromis.

Dans cet épisode spécial PME du podcast Pause Sécure, les animateurs Cyndie Feltz, Nicholas Milot et Dominique Derrier abordent en profondeur le sujet crucial de la sensibilisation à la cybersécurité. Leur message est clair dès le départ : la sensibilisation va bien au-delà du simple fait de cocher une case dans un rapport de conformité. Il s’agit d’un véritable enjeu stratégique pour la protection des entreprises et de leurs employés.

Les experts rappellent une réalité incontournable : la majorité des brèches de sécurité commencent par l’humain. Dans un contexte où les courriels d’hameçonnage sont de plus en plus sophistiqués, notamment grâce à l’intelligence artificielle, personne n’est à l’abri. Même les professionnels de la cybersécurité admettent avoir déjà été victimes de ces attaques. Le quotidien professionnel, avec sa charge de travail intense, ses multiples sollicitations et la nécessité de cliquer constamment sur des liens, rend la vigilance d’autant plus difficile.

Un point important soulevé durant la discussion concerne la distinction entre les tests d’hameçonnage et la sensibilisation proprement dite. Les tests servent principalement à mesurer la progression des employés dans leur capacité à détecter les courriels malveillants et à obtenir des statistiques sur l’efficacité de la sensibilisation. Cependant, la sensibilisation elle-même constitue un processus beaucoup plus large visant à instiguer un véritable changement de comportement.

L’un des messages clés du podcast est la nécessité de considérer les employés comme des maillons forts plutôt que des maillons faibles. Les participants en ont assez de cette étiquette négative. Bien formés et sensibilisés, les employés peuvent devenir la dernière ligne de défense capable de détecter ce que les outils techniques n’auraient pas pu attraper. Au-delà de la simple détection, l’objectif est que les employés développent des réflexes de communication : signaler les menaces au service informatique, alerter leurs collègues et contribuer activement à la sécurité collective de l’entreprise.

Les experts insistent sur un indicateur particulièrement révélateur : le sentiment d’urgence. Qu’il s’agisse d’une fraude du président demandant un virement urgent ou d’un courriel promettant de gagner un voyage à Cancún en cliquant dans les quatre prochaines minutes, ce sentiment d’urgence artificielle devrait immédiatement éveiller les soupçons. Dans un monde où tout va trop vite, il est essentiel d’apprendre à prendre le temps de la réflexion avant d’agir.

Un aspect fondamental de la sensibilisation efficace réside dans l’élimination de toute forme de jugement ou de honte. Tout le monde peut tomber dans un piège d’hameçonnage, même les experts. L’important n’est pas de ne jamais se faire avoir, mais plutôt de le reconnaître rapidement et d’en informer immédiatement le service informatique, même si c’est un vendredi après-midi ou qu’il s’avère finalement qu’il n’y avait pas de menace. Les participants racontent l’histoire d’une entreprise où un employé a attendu le lundi pour signaler une attaque survenue le vendredi, permettant ainsi aux pirates d’agir pendant tout le week-end. Les dirigeants et les équipes informatiques doivent créer une culture d’entreprise où les bons comportements sont récompensés et où il n’y a aucune place pour la honte.

La sensibilisation ne peut pas être une approche universelle. Les experts soulignent l’importance de contextualiser la formation en fonction des différents profils d’employés et de leur réalité quotidienne. Par exemple, former des ouvriers d’usine à la fraude du président n’a pas de sens s’ils n’ont pas accès aux systèmes de paiement. En revanche, les sensibiliser aux clés USB trouvées dans le stationnement ou à la sécurité physique est beaucoup plus pertinent. Cette adaptation nécessite une compréhension fine de l’organisation et des rôles de chacun.

Nicolas Milot fait une proposition audacieuse : la sensibilisation devrait être gérée par les équipes de marketing et de ressources humaines plutôt que uniquement par l’informatique. La raison est simple : créer un test d’hameçonnage efficace ressemble davantage à la création d’une infolettre marketing engageante qu’à un projet technique. Il s’agit de capturer l’attention, de créer de l’engagement et de faire passer un message. Le service informatique reste essentiel pour les aspects techniques, mais le projet dans son ensemble bénéficierait d’une approche plus orientée communication.

Depuis la pandémie de COVID-19, la frontière entre vie personnelle et professionnelle est devenue floue. Les experts encouragent à profiter de cette réalité en abordant aussi la sécurité personnelle lors des formations. Si les employés apprennent à se protéger contre les fraudes sur les sites de vente en ligne, les QR codes malveillants ou autres menaces de leur vie quotidienne, ils appliqueront naturellement ces réflexes dans leur contexte professionnel. Les êtres humains sont fondamentalement égoïstes, et en leur montrant comment se protéger personnellement, on les rend plus réceptifs au message global de sécurité.

Enfin, les participants insistent sur l’importance de rendre la sensibilisation engageante, voire amusante. La cybersécurité ne doit pas être perçue comme une contrainte pénible, mais comme une partie intégrante de la vie professionnelle abordée avec énergie positive. Utiliser l’humour, célébrer les bons comportements et créer des moments d’apprentissage plaisants permet une meilleure rétention de l’information et une adoption plus naturelle des bonnes pratiques.

La sensibilisation à la cybersécurité représente un investissement rentable qui ne coûte pas nécessairement très cher, mais qui peut considérablement améliorer la posture de sécurité d’une organisation. En donnant aux employés les outils, le temps et surtout la confiance nécessaires pour devenir des acteurs actifs de la sécurité, les entreprises se dotent d’une défense humaine efficace, capable de compléter leurs solutions techniques. Le message est clair : transformons nos employés en superstars de la sécurité plutôt qu’en suspects potentiels.

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

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.

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.

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.

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.

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.

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.

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.