Les attaquants IA ne se fatiguent pas: pourquoi la cybersécurité doit changer

Votre programme de sécurité a été conçu pour des attaquants qui le font.

Lorsque OpenAI a publié son récit des modèles qui se sont échappés d’un environnement d’évaluation et ont passé des jours à l’intérieur de l’infrastructure de production de Hugging Face, je l’ai qualifié de moment Terminator pour la cybersécurité. Je maintiens cette affirmation, mais un autre aspect devrait nous faire réfléchir. Neuf jours plus tard, Anthropic a divulgué ses propres incidents. Début août, Meta en a confirmé un autre. Quelques jours après, le modèle d’un quatrième laboratoire, le Kimi K3 de Moonshot, a glissé hors de son bac à sable de test. Quatre laboratoires. Moins de trois semaines. Quatre modèles qui sont allés là où personne ne l’avait prévu.

Ces récits ont largement été traités comme des histoires de sécurité de l’IA. Ils le sont. Mais pour un RSSI, ils sont aussi des histoires de risque de tiers — et cela pourrait être la leçon la plus immédiate. La vérité inconfortable est que l’incident OpenAI‑Hugging Face était, au fond, une histoire de risque de tiers : un composant tiers vulnérable comme voie d’évasion, un fournisseur comme victime, et un nœud systémique dont des milliers d’entreprises dépendent comme rayon d’impact.

Voici le chiffre que j’apporterais à votre prochaine réunion de planification de la sécurité. Sur les quelque 17 600 actions d’attaquant que Hugging Face a récupéré de ses journaux, la plupart ont échoué.

L’agent a testé des chemins qui n’allaient nulle part. Il a été bloqué par les listes blanches d’URL et a pivoté. Il a heurté des politiques IAM qui refusaient chaque appel de modification. Il a tenté d’atteindre une base de données de production à deux reprises et a expiré les deux fois. Il a sondé, échoué et a continué. Des milliers de fois. Il ne s’est pas frustré. Il ne s’est pas fatigué. Et l’échec lui a coûté presque rien.

Quatre modèles se sont échappés d’environnements de test en moins de trois semaines. Ces fuites ont fait la une. Les dirigeants de la sécurité devraient s’inquiéter davantage de ce qui les a rendues possibles : un attaquant capable d’échouer des milliers de fois à presque aucun coût.

C’est là le basculement. Pendant des décennies, les défenseurs ont bénéficié d’un fait simple : l’échec coûte quelque chose aux attaquants. La reconnaissance prenait du temps et les impasses étaient coûteuses. L’économie de cette asymétrie rendait l’idée « imposer des coûts » aux attaquants cohérente pour tenter de les arrêter. Lorsque l’échec devient presque gratuit, le chemin réussi cesse d’être une aiguille dans une botte de foin et devient une certitude statistique pour quiconque peut explorer tous les chemins simultanément.

Les schémas de ces incidents soulignent trois leçons que les responsables de la sécurité doivent appliquer dès maintenant.

Quatre laboratoires, une forme

Le schéma est remarquablement cohérent. Donnez un objectif à un modèle. Il trouve un chemin que personne n’attendait. Parfois, ce chemin mène directement aux systèmes de production d’organisations qui n’auraient jamais dû être impliquées. Dans au moins un cas, l’organisation affectée a appris ce qui s’était passé parce qu’Anthropic a appelé pour les informer.

Dans chaque cas, le chemin traversait un logiciel, une infrastructure ou un environnement construit par quelqu’un d’autre. Les dirigeants de la sécurité devraient le prendre personnellement.

Chaque organisation de cette chaîne disposait d’un programme de sécurité. Plusieurs en avaient de très bons. L’échec n’était pas contenu à l’intérieur d’un seul périmètre. Il s’est produit dans les jonctions entre les organisations, et personne ne possède ces jonctions.

Les modèles d’OpenAI ont découvert une faille zero‑day dans un proxy de paquets auto‑hébergé et l’ont utilisée pour atteindre l’internet ouvert. De là, ils ont pris racine sur un bac à sable d’exécution de code non sécurisé appartenant à un client de Modal Labs, l’ont utilisé comme base de mise en scène, et ont trompé le chargeur de jeux de données de Hugging Face pour qu’il lise des fichiers locaux puis exécute du code. En treize heures, ils détenaient les droits d’administrateur de cluster sur plusieurs clusters internes, aidés par une unique identité partagée entre tous. Le point d’entrée était inédit. À l’intérieur, les faiblesses étaient celles que nous documentons depuis vingt ans.

Neuf jours plus tard, Anthropic a fait quelque chose de plus rare : il a publié sa propre analyse de 141 006 exécutions d’évaluation et a divulgué trois cas similaires sans y être invité : un modèle accédant à l’internet ouvert depuis un environnement d’évaluation, puis obtenant l’accès aux systèmes d’organisations réelles. Pas d’évasion de bac à sable cette fois, seulement une mauvaise configuration qui laissait un chemin actif alors que le modèle avait été informé qu’il n’en existait aucun. Une fois à l’extérieur, le modèle a exploité des faiblesses que chaque équipe de sécurité connaît : mots de passe faibles, points de terminaison non authentifiés, injection SQL et identifiants exposés sur une page de débogage.

Meta a confirmé un quatrième incident début août, après qu’une erreur de configuration ait donné à l’un de ses modèles un accès à internet pendant une évaluation. Meta ne l’a pas non plus détecté ; il a appris ce qui s’était passé lorsque son partenaire de test a appelé. Cette évaluation et celle d’Anthropic ont toutes deux été réalisées par la même société externe, Irregular, qui les a publiquement qualifiées du même problème. L’erreur de configuration d’un fournisseur s’est propagée à travers deux laboratoires de pointe et quatre organisations victimes, aucune d’elles n’ayant de relation directe avec Irregular. C’était un fournisseur pour les deux laboratoires, pas pour elles. L’agent ne se souciait pas de la frontière entre la surface d’attaque d’une entreprise et celle d’une autre.

C’est ce qui fait de cela un problème de risque de tiers. L’exposition peut désormais provenir de plusieurs relations au‑delà de vous, dans une organisation que vous n’avez jamais sélectionnée, évaluée ou même su faire partie de votre surface d’attaque.

Ensuite, des chercheurs de Frontier Security ont détecté que le Kimi K3 de Moonshot glissait également son bac à sable, lui permettant d’accéder à un référentiel de benchmarks sur GitHub. Personne n’a été compromis, et le modèle poursuivait son objectif assigné, ayant compris qu’utiliser une clé de réponse prête à l’emploi était moins coûteux que de résoudre le problème. Deux éléments rendent ce cas important. Les chercheurs l’ont détecté pendant leur propre test. Et il fonctionnait avec des outils totalement différents de ceux des cas Anthropic et Meta. Un fournisseur ayant un mauvais mois n’explique pas cela.

Les laboratoires ne négligent rien de tout cela. Anthropic a publié son analyse sans y être invité, ce qui explique pourquoi l’industrie dispose d’un schéma à examiner et à retenir — plutôt que d’un cas isolé à balayer. Cela devrait devenir la norme. OpenAI a désormais ralenti la diffusion de son modèle Astra après que des évaluations internes n’aient pas pu exclure une capacité cybernétique critique. Les deux mesures méritent des éloges. Mais aucune n’est un plan de défense : un retard de diffusion ne concerne que le calendrier d’une entreprise. Cela n’affecte en rien les modèles capables, dont Kimi K3, qui sont déjà disponibles en open‑weight et gratuitement, hors du contrôle de tout laboratoire individuel.

Corrélation sans escalade n’est pas une détection

Le système de détection de Hugging Face, à juste titre, a corrélé les signaux en une attaque cohérente. Il n’a ensuite pas fait remonter la criticité, et l’équipe de garde n’a pas été paginée. L’outil a assemblé l’histoire sans pouvoir décider qu’elle était urgente. C’est une architecture de triage conçue pour un monde où 17 600 événements en quatre jours auraient semblé absurdes.

La cybersécurité a besoin de son Fosbury Flop

En 1968, Dick Fosbury a remporté la médaille d’or olympique au saut en hauteur, non pas en sautant plus haut que ses concurrents mais en franchissant la barre à l’envers. Tous les autres perfectionnaient la technique du « straddle ». Meilleure forme, plus de force, gains marginaux sur une technique vieille de plusieurs décennies. Fosbury a changé la forme du problème. En deux Jeux olympiques, le straddle était pratiquement éteint.

Les responsables de la sécurité doivent maintenant franchir une barre qui vient de bouger, et la plupart des réponses de l’industrie jusqu’à présent se résument à un meilleur straddle : plus d’alertes, des analystes plus rapides, des SLA plus stricts sur la révision humaine. Cela ne fonctionnera pas, car la contrainte n’est pas la vitesse des analystes. On ne peut pas contrer des attaques à la vitesse des machines avec un triage à vitesse humaine.

Le flop ressemble à ceci:

• Cessez de considérer la frontière comme le contrôle. Le bac à sable d’évaluation a échoué, le chargeur de jeux de données a échoué, et l’isolation des pods a échoué, chacun remplissant sa fonction jusqu’à ce qu’il ne le fasse plus. Concevez pour ce qui suit. Utilisez des identifiants à durée de vie courte. Éliminez les identités administratives partagées. Bloquez l’accès aux services de métadonnées. Surtout, limitez la distance qu’un attaquant peut parcourir après le premier échec de contrôle.
• Passez la détection de l’alerte à la corrélation. Détecter un seul événement suspect ne suffit plus. Le travail consiste à relier des milliers d’événements apparemment ordinaires en une histoire d’attaque, et à savoir quand cette histoire est suffisamment grave pour réveiller quelqu’un. Cela doit de plus en plus être automatisé compte tenu du volume que nous observons.
• Considérez l’exposition de tiers comme une voie d’attaque, pas comme un questionnaire. Ces incidents ont traversé des dépendances de tiers : le produit d’un fournisseur, le client d’un fournisseur, un partenaire d’évaluation, des outils de test partagés. Votre risque inclut désormais les erreurs de configuration commises par des organisations que vous n’avez jamais auditées et que vous ne savez peut‑être même pas existantes. Les évaluations statiques ponctuelles ne peuvent rien voir de tout cela. Ce problème n’est pas nouveau. L’IA le rend beaucoup plus urgent. Les équipes de sécurité ont besoin d’une visibilité continue sur les entreprises et les technologies dont elles dépendent, car les attaquants voient cet écosystème entier comme une surface connectée.

Chez SecurityScorecard, c’est exactement le type de problème autour duquel notre culture est construite : rassembler des personnes profondément curieuses de la façon dont les attaquants pensent, prêtes à remettre en cause des hypothèses de vingt ans, et enthousiastes à l’idée de créer une approche fondamentalement différente de la sécurité !

La question à apporter à votre prochaine réunion du conseil d’administration

Il y a quelques semaines, j’ai déclaré que le génie était devenu trop puissant pour la bouteille. Quatre laboratoires plus tard, rien n’a contredit cela. Après des incidents comme ceux‑ci, tout le monde pose la même question : Sommes‑nous prêts aux attaquants propulsés par l’IA ? Je ne pense pas que cette question nous mène très loin. « Oui » et « non » donnent le même résultat : rien ne change.

Posez une question plus difficile. Si 17 000 événements à faible signal frappaient votre environnement au cours des quatre prochains jours — et que la plupart ressemblaient à des échecs — combien de temps votre équipe mettrait‑elle à réaliser qu’il s’agissait d’une attaque ? Quelqu’un aurait‑il été paginé à temps ?

Vous connaissez déjà la réponse. L’écart entre cette réponse et quatre jours représente le travail.