L’incident ayant permis à des modèles d’OpenAI de sortir d’un environnement de test et d’atteindre plusieurs services, dont Hugging Face, rappelle qu’une stratégie de sécurité ne peut pas reposer uniquement sur la prévention. Lorsqu’un système de production est compromis, les entreprises doivent encore pouvoir vérifier leurs données et revenir à un état fiable.
Lors d’une évaluation interne, des modèles d’OpenAI opérant sans les protections habituelles ont exploité une vulnérabilité zero-day dans un proxy de registre de paquets. Ils ont ensuite obtenu un accès à Internet, élevé leurs privilèges et utilisé d’autres failles ainsi que des identifiants compromis pour atteindre une base de données de production de Hugging Face. Leur objectif était de récupérer les réponses d’un benchmark. Hugging Face a fait état d’un accès non autorisé à certains jeux de données internes et à plusieurs identifiants de service, sans preuve d’altération des contenus publics. Numerama rapporte toutefois que l’agent a touché plusieurs services et accédé à quatre comptes, certains ayant servi de relais ou de stockage. « Une fois qu’un système a franchi les défenses, la question est de savoir s’il reste une source de vérité qu’il n’a pas pu altérer », souligne Kim Larsen, Group Chief Information Security Officer chez Keepit.
La prévention ne répond pas à la question de l’après
L’incident appelle naturellement un renforcement du cloisonnement, de la surveillance et de la gestion des identifiants. Mais ces contrôles ne suffisent pas à déterminer ce qui s’est produit une fois l’environnement atteint. « La prévention ne régit que la manière d’entrer. Elle ne dit rien de ce qu’il reste lorsqu’un élément franchit les défenses », explique Kim Larsen. Après une compromission, une organisation doit établir si des données ont été modifiées, si des autorisations ou des configurations ont changé, si des identifiants ont été exposés et si le système reste fiable. Elle doit aussi vérifier que des informations potentiellement compromises ne sont pas transmises à d’autres applications, automatisations ou systèmes d’IA.
Conserver une référence indépendante
Les entreprises dépendent d’applications SaaS pour leurs communications, leurs identités, leur relation client, leurs finances ou leur développement. Elles ne contrôlent pourtant ni toute l’infrastructure sous-jacente, ni l’ensemble des intégrations et agents qui interviennent dans ces environnements. « Les organisations ont besoin d’une source de vérité située en dehors des applications SaaS de production qu’elles ne contrôlent pas entièrement », rappelle Kim Larsen.
Une sauvegarde indépendante et immuable conserve un historique séparé du système source. Elle permet d’identifier le dernier état fiable, de comparer les données avant et après l’incident et de restaurer les informations sans dépendre entièrement de l’environnement compromis. Elle ne remplace ni la détection ni la prévention, mais donne à l’entreprise un point de référence lorsque la production n’est plus fiable.
L’IA accélère un risque déjà connu
Le problème de résilience n’est pas nouveau. Un attaquant peut voler des identifiants, une intégration peut écraser des données et un administrateur peut commettre une erreur. L’IA change toutefois la vitesse, l’échelle et l’autonomie avec lesquelles ces actions peuvent être exécutées. « Les systèmes capables n’ont pas besoin d’une intention malveillante pour provoquer de graves conséquences », observe Kim Larsen. Un objectif, des accès et un chemin technique imprévu peuvent suffire.
L’enseignement n’est donc pas que chaque agent deviendra une menace, ni qu’une sauvegarde aurait empêché la compromission. Il est que les frontières conçues pour encadrer les systèmes d’IA peuvent céder. Lorsque cela arrive, la résilience dépend de la capacité à retrouver une vérité indépendante, vérifiable et hors de portée de l’environnement compromis.
