Edition 12

Je formule une version de cet argument depuis des mois, aussi est-il utile de l'entendre de quelqu'un extérieur à notre milieu, en langage clair, avec le graphique à l'appui. Le propos n'est pas que l'IA inventera des attaques magiques inarrêtables. C'est l'inverse. L'IA rend les attaques ordinaires, le mot de passe non renouvelé, la machine non patchée, l'accès mal configuré, bon marché, rapides et inlassables, puis les exécute à une échelle qu'aucune équipe humaine ne pourrait égaler. Le mot qui doit vous tenir éveillé est exponentiel. Une capacité qui double tous les quelques mois ne vous laisse pas une longue piste pour vous organiser.

Suivez donc les conseils concrets de Thompson, car ce sont les mêmes que ceux sur lesquels je conclus la moitié de ces newsletters : les fondamentaux sont désormais tout le jeu. Non pas parce qu'ils sont glamour, mais parce que c'est précisément ce que la courbe vient chercher. Les trois points ci-dessous sont ces fondamentaux, qui montrent leurs failles en temps réel. Corrigez les vôtres avant que l'exponentielle ne le fasse à votre place.

C'est « le certificat n'est pas le contrôle », illustré par le MFA. Chacune de ces entreprises pouvait affirmer en toute sincérité « nous avons l'authentification multi-facteurs ». L'auditeur a coché la case. Et les attaquants sont entrés par le seul chemin de connexion que la politique MFA ne couvrait pas, avec des mots de passe qui auraient dû être renouvelés il y a des années. MFA activé n'est pas MFA appliqué. Un contrôle avec un périmètre lacunaire n'est pas un contrôle ; c'est un trou en forme de contrôle.

Le travail à faire est précis, pas philosophique. Vérifiez que votre accès conditionnel s'applique bien à chaque utilisateur, chaque application et chaque type de client, sans exception pour les protocoles legacy, les emplacements de confiance ou les politiques en mode rapport seul que vous avez oublié de promouvoir. Supprimez purement et simplement les grants d'authentification dépréciés comme ROPC. Et priorisez votre réponse en fonction des identifiants réellement valides, et non de la cible la plus exposée, car la cible la plus bruyante n'est généralement pas celle qui est compromise. C'est un audit de deux heures qui ferme une porte à laquelle 81 millions de tentatives n'ont pas suffi.

Deux points simultanément, et les deux comptent. Premièrement, ne laissez pas cela vous dissuader des passkeys ; elles demeurent la meilleure option résistante au phishing dont vous disposez, et cette attaque ne compromet pas la passkey elle-même, elle abuse de la récupération de compte pour en ajouter une. Le problème est l'enrôlement, pas la cryptographie. Deuxièmement, et c'est plus important, cela casse un playbook. « Réinitialiser le mot de passe et révoquer les sessions » est le réflexe de tout responsable de réponse aux incidents, et voici un exemple concret de ce réflexe laissant l'attaquant exactement là où il était.

Mettez donc à jour le playbook maintenant, avant d'en avoir besoin. Lorsque vous répondez à une compromission de compte, la réinitialisation des identifiants n'est pas la dernière étape ; c'est l'étape intermédiaire. Énumérez et supprimez chaque authentificateur et chaque passkey présents sur le compte, examinez les méthodes de récupération et les applications connectées, et confirmez qu'aucun appareil non reconnu n'est encore enrôlé. Si votre runbook de réponse aux incidents ne comprend pas actuellement « auditer les authentificateurs enrôlés », il présente exactement la lacune que ce kit a été conçu pour exploiter.

Ce cas me plaît parce qu'il détruit une hypothèse confortable que tout le monde partage : expiré signifie mort. Ce n'est pas le cas. Une date d'expiration n'a jamais été un contrôle de sécurité ; c'est une commodité logistique pour rééditer du plastique, et ici l'implémentation de Visa ne la liait même pas aux données signées de la carte. Des millions de personnes jettent donc des cartes « mortes » à la poubelle qui sont, pour le bon attaquant, toujours actives.

Tirez le fil et c'est la même leçon que la boîte mail de l'ancien employé dont j'ai parlé il y a quelque temps : la retraite n'est pas la révocation. Une chose n'est vraiment morte que lorsque le backend la tue effectivement, et bien trop souvent la carte, le compte, le token, l'accès continuent de fonctionner longtemps après que tout le monde suppose qu'ils ont disparu. Pour votre propre organisation, la question ne porte pas sur les cartes de crédit. Elle est la suivante : qu'avez-vous « expiré » qui accepte encore silencieusement des connexions ?

Retenez le vocabulaire, ignorez l'argumentaire commercial. La shady AI désigne quelque chose de réel que la plupart des politiques IA manquent entièrement. Tout le monde s'occupe de bloquer les outils non sanctionnés, la shadow AI, pendant que l'assistant approuvé acquiert tranquillement la capacité de lire chaque document, d'interroger chaque système et d'agir au nom de quelqu'un, sans que personne ne le re-gouverne lorsque ses pouvoirs s'étendent. Approuver un outil une fois ne revient pas à approuver tout ce qu'il sera capable de faire le trimestre prochain.

C'est le cœur opérationnel de la gouvernance de l'IA, et c'est précisément ce qu'ISO 42001 encercle : non pas une politique d'usage acceptable ponctuelle, mais une supervision continue de ce que votre IA peut toucher et faire à mesure qu'elle évolue. L'incident Meta est révélateur : un agent approuvé se comportant d'une façon que personne n'avait prédite, exposant des données pendant deux heures. Si votre gouvernance de l'IA est une politique signée dans un tiroir plutôt qu'un contrôle vivant sur les accès aux données et les permissions des agents, vous avez de la shady AI, que vous la voyiez ou non. Après tout ce qui précède, c'est le fondamental sur lequel il vaut la peine de prendre de l'avance.