Why Netskope Let AI Hack Its Own Software

0:00:02 Emily Wearmouth : On a beaucoup parlé des risques potentiels que pourraient présenter les modèles d’IA Frontier, et l’invité d’aujourd’hui va nous offrir une perspective alternative. C’est un membre de l’équipe rouge au sein d’une équipe de sécurité, et il utilise les modèles frontières avec beaucoup d’efficacité. Bienvenue donc dans le podcast Security Visionaries, Mohit Kulamkolly. Mohit est ingénieur principal dans l’équipe rouge de l’équipe sécurité Netskope, et c’est un plaisir de t’avoir avec nous, Mohit.

0:00:26 Mohit Kulamkolly : Merci. Merci de m’avoir invité. Oui, content d’être sur le podcast. Oui.

0:00:31 Emily Wearmouth : Vous avez fait quelques articles de blog, et ils m’ont poussé à vous contacter parce que ce dont vous avez parlé dans ces articles concernait un travail que vous et votre équipe élargie avez mené en utilisant ces modèles dans vos efforts de red teaming. Et je voulais en parler un peu, et il y en a quelques-unes différentes, que je vais appeler des expériences. J’espère que cela ne les fera pas paraître trop petits. Vous avez utilisé plusieurs expériences et modèles différents, et mon intention est de vous poser beaucoup de questions qui, je l’espère, révéleront tous les détails et découvertes que vous avez faits au fil de votre parcours. Depuis que vous avez eu accès aux modèles d’IA de Frontier, et je crois que Netskope a rejoint « Glasswing » en juin de cette année, votre équipe mène des expériences vraiment instructives. Vous avez mis ces modèles de frontière sur la voie des produits de sécurité de Netskope, si j’ai bien compris, et vous cherchez à détecter de graves bugs de sécurité, et en particulier des bugs de corruption de mémoire.

0:01:26 Emily Wearmouth : Nos auditeurs viennent d’une église très large, alors pourriez-vous commencer, Mohit, en expliquant à un auditeur qui n’a peut-être jamais directement étudié les vulnérabilités lui-même, ce qu’est un bug de corruption de la mémoire et pourquoi pourrait-il être considéré comme l’une des catégories de failles de sécurité les plus dangereuses et difficiles à identifier ?

0:01:45 Mohit Kulamkolly : Oui, bien sûr, bien sûr. Oui, cela capture bien la situation. Commençons donc par ce que la corruption de mémoire bugge elle-même, comme tu l’as justement souligné. Ainsi, un bug de corruption de mémoire survient lorsqu’un logiciel gère mal son propre espace mémoire alloué de manière incorrecte. Cela est donc géré par le système d’exploitation, mais ensuite cela est attribué et décidé par le logiciel lui-même. Donc, lorsque cela arrive, cela conduit à des vulnérabilités qui peuvent déclencher plusieurs autres effets au sein du système d’exploitation, ce qui n’est pas un comportement attendu. Alors pourquoi est-ce dangereux ? Parce que, donc, nous allons prendre du recul sur la raison pour laquelle il est dangereux de mieux la comprendre. Nous pouvons donc diviser globalement le système d’exploitation en deux parties. L’un sera donc le mode utilisateur et l’autre le mode noyau. Le mode utilisateur est celui où tous les programmes restent, tous nos programmes, et le mode noyau est ce qui est lié au système d’exploitation.

0:02:44 Mohit Kulamkolly : Et le mode utilisateur a souvent besoin de choses du noyau pour exécuter certaines actions et tout le reste. C’est donc là que commence la surface d’attaque. Donc, si un programme plante en mode utilisateur, il reste dans le mode utilisateur lui-même. Et quand il commence à poser des questions au noyau, l’attaquant peut aussi voir cela ou l’attaquant peut aussi l’utiliser. Ainsi, par ce chemin, il peut aussi planter des éléments dans le système d’exploitation, ce qui entraîne plus de vulnérabilités. C’est pourquoi c’est très dangereux comparé à d’autres vulnérabilités.

0:03:15 Emily Wearmouth : Et qu’essayiez-vous de découvrir en pointant ces modèles d’IA vers ces bugs de corruption de mémoire ?

0:03:22 Mohit Kulamkolly : En gros, Netskope fonctionne au sein du système au sein de l’entité du système d’exploitation du client. Et à partir de là, si une vulnérabilité est déclenchée, c’est une vulnérabilité liée à la corruption de la mémoire. Comme je l’ai dit, cela peut entraîner des interruptions du système ou des vulnérabilités liées à l’escalade de privilèges, et tout ce genre de choses. L’objectif ici était donc de voir si une vulnérabilité dans Netskope Client en particulier pouvait être escaladée en quelque chose qui affecterait le système d’exploitation. Nous sortons donc de notre programme pour passer à la vision d’ensemble, ce qui est plus catastrophique comparé au simple crash de Netskope Client . Donc oui, c’était l’objectif.

0:04:03 Emily Wearmouth : Et avant d’examiner comment vous utilisez les outils d’IA, comment vous procédiez normalement pour rechercher ces vulnérabilités avant d’avoir Frontier AI ?

0:04:13 Mohit Kulamkolly : Donc, avant de commencer par essayer de déterminer quelle est la surface d’attaque. Il existe donc des API écrites pour ce type de communication qui se font du mode utilisateur au mode noyau. Donc vous essayez d’abord de comprendre quelles API existent et comment le programme est écrit, entièrement sous le point de vue boîte noire. Quand je parle de boîte noire, nous n’avons pas de code source, rien de tout ça. C’est là que nous avons commencé. Et à partir de là, nous essayons de voir si une charge utile que nous envoyons ou une donnée que nous envoyons provoque un plantage dans un système ou dans ce système d’exploitation particulier. Et nous essayons sans cesse pour déterminer quelle charge utile ou instruction il s’agit de la faille. C’est à ce moment-là que nous essayons de développer des fuzzers nous-mêmes. C’est ce que nous avons détaillé maintenant. J’ai donc développé des fuzzers qui aident à identifier ces vulnérabilités.

0:05:10 Mohit Kulamkolly : Mais avoir l’IA dans ce contexte a atteint un tout New autre niveau de test, où il faut beaucoup, beaucoup plus d’expertise pour entrer dans ce domaine. Et puis, grâce à l’avènement de l’IA, nous pouvons l’escalader encore davantage.

0:05:29 Emily Wearmouth : Et je vais citer votre billet de blog ici. Donc, lors de la première phase de travail que vous avez faite, et vous utilisiez OpenAI 5.5, ai-je bien compris ?

0:05:38 Mohit Kulamkolly : Modèle cyber.

0:05:39 Emily Wearmouth : Tu as dit que ton point de départ était que tu ne pouvais pas simplement demander à l’IA, me trouver un bug et faire confiance à la réponse. Il faut lui donner les mêmes outils qu’un vrai chasseur de bugs humain et forcer chaque revendication qu’elle fait à être vérifiée par rapport à un vrai système en cours. Donc, pour prendre les points dans l’ordre, d’abord, pourquoi est-ce dangereux ? Nous le savons peut-être. Dites-moi explicitement, pourquoi est-il dangereux de simplement faire confiance à la parole d’un modèle qui a trouvé une vulnérabilité ? Et qu’est-ce qui pourrait mal tourner si vous sautez cette phase de vérification ?

0:06:09 Mohit Kulamkolly : Oui, bien sûr. Avant d’approfondir, je pense que je vais finir par contredire cette affirmation depuis un certain temps, car c’est ce que le Mythos m’a appris avec les expériences New . Ce qui se passe donc avec ces modèles cyber, OpenAI 5.5 ou modèle cyber, c’est qu’ils sont entraînés sur une quantité colossale de données, toutes les vulnérabilités et découvertes de sécurité. Cela permet donc d’halluciner dans des situations où il doit faire des suppositions plutôt que des informations. Donc, si vous demandez simplement au modèle de trouver la vulnérabilité pour vous, ce qui se passe, c’est que c’est la seule chose qu’il sait. Il doit donc tirer des conclusions de ses hypothèses initiales. Donc, d’une certaine manière, c’est bien, ce que nous avons compris plus tard. Au départ, lorsque nous voulions écrire, nous devions nous assurer d’être aussi déterministes que possible dans nos conclusions. C’est là que nous avons décidé, d’accord, commençons par ce que nous savons.

0:07:11 Mohit Kulamkolly : Essayons d’approfondir cela, puis nous aborderons le chapitre de ce que nous ne savons pas et de ce que le modèle peut faire.

0:07:17 Emily Wearmouth : D’accord. Alors, racontez-moi ce que vous avez réellement construit ici. À quoi ressemble réellement un laboratoire pour un tel système ?

0:07:24 Mohit Kulamkolly : Oui, sans entrer dans les détails très précis de la situation, à un niveau très général, il s’agit simplement de donner à un chercheur en vulnérabilité les outils dont il a besoin. Je veux dire, il doit en avoir besoin pour exécuter certaines actions. Réfléchissez-y, il existe des missions virtuelles dans lesquelles le logiciel va tourner. Il y a des missions virtuelles dans lesquelles les outils seront exécutés. J’ai donc tout relié ensemble, j’ai relié les points ensemble et j’ai donné ceci au modèle, puis je lui ai demandé de chercher une vulnérabilité d’une manière très spécifique que j’examinerais avec mon expérience des précédentes chasses. C’est comme ça que nous avons commencé. C’est à quoi ressemble le laboratoire à un niveau très général.

0:08:12 Emily Wearmouth : Je vais poser une question potentiellement délicate. Il y a donc eu beaucoup d’histoires au cours des dernières semaines ou deux sur des agents et des IA sortant des bacs à sable et faisant des choses qui répondent peut-être à la tâche qui leur a été confiée, mais certainement pas d’une manière qui nous conviendrait. Y a-t-il des barrières spécifiques que vous mettez autour de ces expériences en anticipant qu’elles pourraient essayer de s’échapper ? Comment fais-tu pour t’assurer que ça ne marche pas ?

0:08:36 Mohit Kulamkolly : Oui, donc c’est une très bonne question car, particulièrement dans ce contexte, quand un agent est chargé d’accomplir une tâche spécifique, nous ne la disons pas de manière très spécifique. C’est ce que j’ai fait au départ, et c’est ce que j’ai compris comme un facteur limitant pour l’agent. Pour sortir de là, ce que nous avons créé, c’est un environnement bac à sable individuel. Ainsi, chaque mission virtuelle dispose d’un environnement bac à sable, auquel elle ne peut pas être cassée ou accessible si nous ne lui autorisons pas explicitement l’exécution. Surtout dans le cas de ces tests de machines Windows et tout le reste, au lieu d’exécuter un conteneur Docker ou d’autres concepts, les missions virtuelles fonctionnent le mieux. C’est donc le niveau d’isolation que nous avons construit pour chaque outillage et le type d’accès qu’ils ont à eux. Et nous faisons tous ces tests sur un système et une mission séparés, sans accès internet adéquat.

0:09:34 Emily Wearmouth : Je suppose que le fait de le garder hors d’internet est l’un des éléments clés pour limiter sa capacité à agir en mode invoquo. Vous avez aussi mentionné dans l’article que vous avez écrit que vous aviez construit cela autour d’une machine cible spécifiquement autorisée à planter et d’une autre machine qui la surveille avec un déboguageur. Pourquoi avez-vous gardé ces éléments séparés et pourquoi est-il utile de laisser le crash plutôt que de l’arrêter avant que cela n’arrive ?

0:09:58 Mohit Kulamkolly : Oui, c’est tout le concept de cette vulnérabilité liée à la corruption de la mémoire et pourquoi c’est intéressant. Ainsi, chaque fois qu’un système essaie de détecter qu’une mémoire est mal gérée par un programme, il passe en mode fail-safe. Donc c’est une phase de crash qui se passe. Donc, quand vous essayez de tester un bug individuel, quand vous essayez de tester une charge utile individuelle au niveau microscopique, la meilleure façon de le confirmer initialement est que le bug existe est de voir s’il plante ou non. Et s’il y a un crash absurde, cela signifie qu’il y a une mauvaise gestion de la mémoire. Ensuite, nous pourrons discuter plus tard de la manière d’escalader la situation, des productions système à contourner, et ainsi de suite. Ces choses arrivent donc plus tard. Mais aussi, pour ajouter à une chose intéressante que tu as mentionnée, pourquoi ne pas le mettre en pause juste avant qu’il ne plante ?

0:10:53 Mohit Kulamkolly : Il existe donc un système similaire aussi. Nous faisons donc cela aussi en interne. C’est une infrastructure de fuzzing instantané que nous avons construite et que nous essayons de détecter juste avant qu’il ne plante afin de pouvoir la rejouer des millions de fois et ainsi trouver New variantes de notre vulnérabilité. Donc oui, c’est tout le contexte.

0:11:12 Emily Wearmouth : Et j’ai une dernière question sur cette phase de l’expérience. Je me réserve le droit de poser plus de questions, mais pour l’instant je pense en avoir une. Il semble que beaucoup des premières hypothèses du modèle sur les bugs se sont révélées fausses. Qu’il utilisait des hypothèses dépassées sur le logiciel. Et je me demandais pourquoi vous aviez déterminé que cela se produisait ? Et selon vous, qu’avez-vous appris le modèle en se trompant et en traversant cette phase de faute ?

0:11:43 Mohit Kulamkolly : Oui, ce qui se passe pour ce type de logiciel, c’est qu’il est difficile de tester ce type car cela dépend beaucoup de l’environnement sur lequel il est déployé. Donc, s’il y a de petits ajustements apportés au système d’exploitation, disons qu’il y a une fonction ou un programme censé tourner en arrière-plan, il ne tourne pas, le logiciel ne se comportera pas comme il le devrait. C’est donc l’une des raisons pour lesquelles le système doit non seulement s’adapter à l’environnement qu’il possède pour les vulnérabilités, mais en même temps, il doit aussi déterminer l’étape suivante en fonction des résultats qu’il en retire. Ce n’est pas seulement ça, d’accord, c’est la procédure standard, allez-y. Il faut donc s’assurer que le système accepte cela ou que le logiciel est prêt à accepter cette procédure standard et qu’elle fonctionne avant de commencer à ajouter des charges utiles.

0:12:39 Mohit Kulamkolly : Parce que si vous n’installez pas d’IA ici, ce qui se passera, c’est que j’enverrai beaucoup de charges utiles et ensuite l’IA ne le fera pas ou le logiciel ne répondra même pas. Alors, comment puis-je tester ? C’est donc une des raisons pour lesquelles le modèle a fait cette correction. Oui.

0:12:54 Emily Wearmouth : Exact. Donc ce dont nous avons parlé jusqu’à présent, c’était votre phase un. Ainsi, vous avez eu des humains, vous qui concevaient toutes les étapes, puis l’IA était chargée d’exécuter des tâches dans un processus que vous aviez conçu. Je veux que nous passions maintenant à votre deuxième phase. Pour ta deuxième phase, tu as changé de modèle et tu as commencé à jouer avec Claude Mythos à la place. Y avait-il une raison de changer cela ou était-ce simplement que vous cherchiez à l’origine à faire des expériences avec les deux ? Ou y avait-il un avantage que vous pensiez obtenir en passant à un autre modèle ?

0:13:30 Mohit Kulamkolly : Pas vraiment. On a juste New outils sophistiqués et New analogiques.

0:13:34 Emily Wearmouth : Nous sommes tous passés par là. D’accord. Et pour ce deuxième point, je vais essayer de dessiner ce qui était différent, et je suis sûr que vous éclairerez un peu plus. Donc, au lieu de concevoir chaque étape puis de demander au modèle d’exécuter, vous lui demandiez de décider ce qu’il fallait étudier. Vous lui avez ensuite demandé de prouver tout bug qu’il trouvait contre un système réel. Et puis, ce qui semble être un élément assez critique de celui-ci, vous exigeez aussi qu’une seconde copie indépendante de lui-même soit vérifiée à la fois par rapport à cette preuve. Donc vous lui donnez plus de responsabilités au processus, mais vous ajoutez aussi plus de contrôles à faire parce que vous retirez plus d’humains de la charge de travail. Pouvez-vous m’expliquer ce qui vous a poussé, depuis la fin et la conclusion de vos expériences OpenAI, qu’est-ce qui vous a poussé à concevoir ce projet de cette manière ?

0:14:30 Mohit Kulamkolly : Nous avons donc tiré nos leçons d’OpenAI lorsque nous avons commencé les tests avec Mythos. Donc sous le capot, toute la sécurité, tous les modèles. Ce sont donc tous essentiellement des systèmes de prédiction. Même si on dit qu’ils ont développé New logiciel et tout, ils prédisent simplement ce qui vient ensuite de manière très efficace en fonction du contexte qui leur est donné. Donc, plus vous restreignez le contexte ou plus vous le mettez en laisse, plus ce qui se passera, c’est que le type d’informations qu’il peut produire diminuera également. Donc, quand nous testions avec OpenAI, nous avons produit un fuzzer. Nous lui avons demandé de construire par-dessus. Nous voulions maintenant voir si, puisque nous lui avons donné le fuzzer, la seule chose qu’il a pu en construire est une extension.

0:15:21 Mohit Kulamkolly : Nous avons donc retiré le fuzzer de l’image puis nous lui avons montré comment construire le fuzzer et comment on peut le faire soi-même. Soit vous pouvez le faire vous-même, soit vous pouvez simplement faire ce que vous jugez bon pour atteindre cette interface particulière du programme. C’est pour ça qu’on voulait essayer de cette façon. Donc, au lieu de s’y mettre de côté. Donc ça s’est très bien passé. Nous avons donc compris comment le modèle se comportait et les façons créatives nécessaires pour identifier une vulnérabilité. C’est donc là le cœur du problème.

0:15:57 Emily Wearmouth : Y avait-il des considérations supplémentaires à prendre en compte parce que vous confiiez plus de contrôle cette fois ? Y avait-il différentes façons de structurer les choses ou des garde-fous supplémentaires que vous pensiez devoir mettre en place ?

0:16:10 Mohit Kulamkolly : Oui, plus d’isolement. Je pense que plus d’isolement était la clé pour ça. Le modèle, pas dans notre système de fonctionnement. Nous avions donc un ordinateur portable séparé juste pour tester cela. C’était hors réseau. Et puis oui, nous nous sommes mis à fond cette fois-ci. Donc, au lieu de lui demander d’utiliser les outils présents sur le système, nous avons simplement veillé à ce qu’il soit de plus en plus isolé. Oui, c’est tout.

0:16:35 Emily Wearmouth : D’accord. Et ensuite, je suppose qu’en l’intégrant avec ce double contrôle de ce qu’il produit, cela crée aussi des garde-fous supplémentaires autour des conclusions qu’il dessine, je suppose que vous intégrez dans le modèle.

0:16:47 Mohit Kulamkolly : Oui, oui. Exact.

0:16:49 Emily Wearmouth : Comment avez-vous évité qu’il se convaince lui-même qu’il avait raison ? Comment avez-vous gardé cette double vérification suffisamment séparée pour qu’elle ne puisse pas le faire ? Je veux dire, l’une des choses que nous avons vues la semaine dernière, c’est un agent qui est allé jusqu’à créer des deepfakes d’employés pour obtenir l’approbation interne. Nous savons donc que l’IA sait comment convaincre. Comment avez-vous fait pour vous assurer qu’il ne se contentait pas de se convaincre lui-même ou de ce second contrôle que ce qu’il faisait était juste ?

0:17:21 Mohit Kulamkolly : Oui. L’élément principal est aussi ce que nous avons déjà évoqué : le modèle étant un système de prédiction et le contexte étant un élément clé ici. J’aimerais reprendre le même concept ici aussi, le contexte. Donc, presque tout le temps, 100 % du temps, quand un modèle se trompe, c’est parce qu’il n’a pas le bon contexte ou qu’il a un contexte médiocre, je dirais. Donc la raison pour laquelle il existe deux systèmes distincts est la même. Donc, chaque fois qu’un modèle regarde New œuvre, cela signifie simplement qu’il regarde d’un contexte simple vers une fenêtre. Ainsi, il ne fait pas de fausses hypothèses qui ont été créées auparavant. Donc, dans le cas que vous avez mentionné aussi, tout dépend de ce que le modèle doit accomplir. Ainsi, l’objectif pour un agent peut ne pas être celui de l’autre.

0:18:16 Emily Wearmouth : Ah, intéressant.

0:18:18 Mohit Kulamkolly : Et d’après ce que vous avez dit également, l’objectif initial n’est peut-être pas de créer des deepfakes de cet employé en particulier, mais plutôt de contourner ce système de validation de la signature. Donc il fera tout ce qu’il peut pour mal, mais le modèle n’a rien fait de nuisible dans son contexte, mais du côté externe oui. Donc le contexte est un roi. Oui.

0:18:40 Emily Wearmouth : Donc j’imagine que vous avez instauré un peu de friction entre les deux niveaux : si elle ne vérifie pas son propre travail, c’est un autre agent IA qui vérifie certains travaux pour éviter qu’ils ne s’associent et que vous gardiez une certaine distinction entre les deux. C’est un point de conception vraiment intéressant.

0:18:58 Mohit Kulamkolly : Exactement, exactement. Oui.

0:19:00 Emily Wearmouth : Alors, parlez-nous de ce que celui-ci a trouvé. Comment cela s’est-il passé ? Qu’est-ce que ça a donné ?

0:19:08 Mohit Kulamkolly : Donc oui, nous avons obtenu beaucoup de bons résultats grâce à ces deux premières expériences que nous avons réalisées. Nous avons donc pu obtenir environ 17 à 18 vulnérabilités uniquement sur des logiciels open source. Ces logiciels sont donc utilisés par Netskope pour créer nos produits. Mais ensuite, ces vulnérabilités sont trouvées sur les packages en amont, puis elles ont été signalées au bon personnel qui les gère aussi. Et puis il y a eu ces vulnérabilités liées à la corruption de la mémoire que j’ai découvertes. Il y avait donc 15 à 20 vulnérabilités de corruption de mémoire également. Et enfin, pour le test différentiel, nous en avons trouvé quatre ou cinq. Ce n’est donc pas une question d’échelle partagée, 20 000 vulnérabilités ont été découvertes, et c’est juste une petite échelle dont je parle, 15 à 20. La raison ou la partie clé à noter ici est que chaque vulnérabilité, lorsqu’elle est signalée par un client ou sur Netskope, sera imputée à un FMI.

0:20:15 Mohit Kulamkolly : Ainsi, ces incidents avec le FMI entraîneront d’énormes pertes pour l’entité particulière qui les a subis. Ainsi, le fait de le trouver dans nos produits nous fait économiser beaucoup d’argent et nous assure la confiance de nos clients quant à ce à quoi on nous oppose.

0:20:35 Emily Wearmouth : Oui. J’ai de nouveau noté à partir de votre article quelque chose que je voulais explorer et qui semblait particulièrement intéressant. Il y a eu un bug que le modèle a trouvé côté noyau, et vous avez raconté une histoire de plantage qui n’est pas survenu avant qu’il n’ait trouvé quelque chose de subtil sur la façon dont la mémoire est allouée en coulisses. Voulez-vous nous expliquer de façon générale cet exemple particulier ?

0:20:59 Mohit Kulamkolly : Oui, bien sûr, bien sûr. Je pense donc que cette vulnérabilité était dans un analyseur de configuration. Ainsi, ce parseur de configuration copiait essentiellement la valeur du registre dans une allocation de pool de taille exacte en utilisant une fonction de copie de longueur de chaîne. Et cette fonction de copie liée par chaîne n’avait pas de vérification sortante qui était présente. Donc, check hors limite. Pour cette raison, c’est un manuel de vulnérabilité hors frontière, et il peut être exploité très facilement. Pour aborder cette vulnérabilité, il y avait presque cinq ou six préconditions à remplir. Ainsi, les préconditions seront aussi simples que de vérifier si le logiciel accepte un type spécifique de service ou s’il s’agit d’une autre chose qu’il accepte ou d’une version différente. Ce sont toutes des conditions préalables.

0:21:54 Mohit Kulamkolly : Donc, après avoir réglé toutes les conditions préalables, le crash ne s’est toujours pas produit. Il a donc dû se connecter au débogage, essayer de simplifier l’allocateur. Puis il a découvert que le système d’exploitation avait apparemment ajouté quelque chose appelé un terminator nul, ce qui est très courant. Et ensuite, l’allocateur a arrondi ce tampon en une table complète, en gros. Cela a donc provoqué une lecture hors frontière pour ne pas atterrir là où nous avions atterri. Il a donc déterminé la géométrie de l’alloueur pour comprendre comment cela se produit, puis il a modifié son exploit pour qu’il corresponde exactement à ce qui est censé déclencher la panne. C’est donc ce qui s’est passé là-bas, à un très haut niveau. Oui.

0:22:35 Emily Wearmouth : Une partie de la raison pour laquelle je t’ai demandé d’expliquer cela, c’est parce que je voulais vivre ce moment qui te renverse. Je veux dire, la complexité et les couches de détails que cela aborde, si vous deviez imaginer un monde où vous auriez atteint ce résultat manuellement, combien de temps et combien d’heures de travail ? À quoi cela ressemblerait-il ? Ou pensez-vous que cela n’arriverait que par accident ?

0:23:02 Mohit Kulamkolly : Je veux dire, ce serait des jours et des jours d’efforts. Et comme tu l’as dit, ce serait aussi un accident. Donc, parce qu’il est très difficile de comprendre ces choses, car quand on regarde un débogueur et qu’on essaie de trouver où l’alloquateur s’est trompé, il faut donner un sens à beaucoup d’informations présentes. Vous n’êtes peut-être pas expert dans ce domaine très précis que vous envisagez, mais il faut alors connaître tout cela pour bien faire le lien. Donc encore une fois, oui, il se peut que ce soit un hasard que vous tombiez sur ces problèmes ou des mois et des heures d’efforts pour trouver cette vulnérabilité.

0:23:40 Emily Wearmouth : Il y en a un autre que j’ai trouvé intéressant dans votre article. C’était un bug qui a pris plusieurs jours et des milliers de tentatives pour être maîtrisé, même avec l’IA. Tu as parlé du fait qu’un équivalent humain prendrait des jours et des jours. Même avec l’IA en marche, celui-ci a pris plusieurs jours et des milliers de tentatives. Qu’est-ce qui a permis de faire avancer ce processus ? Qu’est-ce qui a changé entre les tentatives ratées et celle qui a finalement fonctionné ? Et pourquoi cela n’a-t-il pas pris de temps mort ? Je veux dire, combien de temps, si cela avait pris au lieu de milliers de tentatives, si vous aviez été dans les centaines de milliers, aurait-il simplement abandonné et ne l’aurait-il pas trouvé ? J’y ai posé plusieurs questions. Faites votre choix.

0:24:18 Mohit Kulamkolly : Non, ça se tient. Donc, en fait, pour cette vulnérabilité ou la recherche de ce cas particulier, la raison pour laquelle le processus était difficile, c’est parce que nous n’avions pas de code source. Nous n’avions pas de table de symboles, nous n’avions rien. C’est un test complet en boîte noire que nous avons fait. Le problème, c’est que pour ce genre de vulnérabilités, quand on essaie de les découvrir, il y a plusieurs nuances qui existent avant même d’atteindre la vulnérabilité elle-même. Donc, pour la partie IA concernant le timout, c’est la façon dont elle a été conçue qui fait que vous allez faire face à beaucoup de ces contrecoups, votre hypothèse initiale peut fonctionner ou non. Vous ne devriez pas simplement attendre qu’une hypothèse se termine et que l’autre passe à la suivante. Donc, au lieu d’une mode linéaire, c’était surtout une mode parallèle.

0:25:09 Mohit Kulamkolly : Ainsi, les agents créent des sous-agents au fur et à mesure que c’est nécessaire pour explorer ces idéologies jusqu’à ce que vous trouviez ou trouviez la bonne façon d’y aborder. C’est donc la raison pour laquelle il n’a pas vraiment expiré. Je pense qu’il a fonctionné pendant quelques jours pour détecter ce genre de vulnérabilités, notamment en raison de la complexité et de la disponibilité de moins d’informations. Mais oui, les sous-agents ont fait l’affaire là-dessus.

0:25:34 Emily Wearmouth : Je vais donc prendre un peu le recul, et je pense que ça vaut, espérons-le, que les auditeurs aient compris que ces deux articles que vous avez publiés valent vraiment la peine d’être lus. Nous inclurons donc des détails sur les endroits où vous pouvez lire davantage de ces détails dans les notes de l’exposition. Mais prenons un moment de recul sur les expériences exactes que vous avez menées et réfléchissons à ce que cela signifie dans un contexte plus large et ce que cela signifie pour certains de nos auditeurs lorsqu’ils réfléchissent à leur propre environnement et qu’ils n’ont peut-être pas accès à tous ces modèles de frontière à ce stade ? Je suppose que la première chose à laquelle mon cerveau pense, c’est que ce genre de capacité n’est pas exclusif à Netskope. Il existe une large liste d’organisations ayant accès à ces modèles, et même les modèles qui ne sont pas considérés comme des modèles frontières deviennent plus ingénieux.

0:26:17 Emily Wearmouth : Donc, si cette technique vous aide à trouver des bugs dans votre code et vos systèmes, et qu’ils sont disponibles, ou si des outils similaires sont accessibles à tout le monde, qu’est-ce que cela signifie pour l’équipe de sécurité moyenne qui n’a peut-être pas une équipe de recherche comme la vôtre et qui est à l’abri d’autres personnes utilisant ces systèmes pour attaquer et détecter ces problèmes ? Quand vous regardez le défi auquel l’industrie est confrontée, comment le voyez-vous ?

0:26:47 Mohit Kulamkolly : Oui, donc ce qui va se passer, c’est que les modèles vont devenir de plus en plus moins chers à cause de la façon dont ils progressent aussi en matière de sécurité, dans tous les points de vue du développement. Je pense donc que ce qui va se passer, c’est que certains autres modèles, tout le monde peut désormais accéder à des modèles open source open weight pour explorer ces sujets. Ce que je recommanderais donc à toute équipe de recherche en sécurité, quoi qu’elle essaie de faire et qu’elle veuille commencer, c’est de commencer à fournir à ces IA les bons outils. Et puis, plus vous donnez les bons outils à l’IA, plus vous serez surpris et plus elle pourra explorer elle-même pour comprendre ces éléments. Donc, au lieu de le voir comme un outil complexe nécessaire pour le connecter à un autre outil qui est là,

0:27:42 Mohit Kulamkolly : Par exemple, supposons que vous ayez besoin d’un serveur MCP qui doit être utilisé pour y connecter un outil, mais que vous n’ayez pas de serveur MCP pour cela. Vous devrez donc l’écrire de zéro puis le construire par-dessus. C’est donc une courbe d’apprentissage que vous devrez peut-être franchir pour atteindre ce côté. Donc pensez-y comme si même le serveur MCP n’était que les API exposées, vous les connectiez simplement à l’IA, c’est tout. Donc c’est juste du code simple. Essaie de comprendre ça. Et si vous pouvez connecter votre outil, sinon vous pouvez vous connecter aux outils, vous devez commencer à écrire vous-même ou utiliser l’IA pour les écrire. De cette façon, une fois que vous commencez à donner aux outils les choses sensorielles, les yeux, le nez, les oreilles. Et une fois que vous avez toutes ces informations, les outils commenceront à traiter ou l’IA commencera à traiter les informations comme vous le souhaitez, et cela vous donnera alors de meilleurs résultats.

0:28:37 Mohit Kulamkolly : Donc oui, c’est comme ça que je le vois.

0:28:40 Emily Wearmouth : Pensez-vous qu’une telle approche va changer de manière significative la manière dont les entreprises de logiciels ou de technologie livrent leurs logiciels ? Est-ce que cela va changer les chronologies ? Cela va-t-il changer les attentes ou les coûts ? Quelles pensez-vous que ces implications pourraient être ?

0:28:57 Mohit Kulamkolly : Absolument. Donc oui, comme je l’ai dit, ce qui va se passer, c’est que les vulnérabilités de sécurité vont devenir moins coûteuses à découvrir à mesure que l’IA progresse. Ce qui va se passer, c’est que la réparation deviendra plus coûteuse. Donc, avec le rythme auquel nous sommes en train de livrer le logiciel en ce moment. Ainsi, la correction de ces vulnérabilités va devenir coûteuse et sera plus difficile à exécuter. Donc, quand on a la façon dont Netskope a cela, même avant l’époque où l’IA l’avait, on a notre propre SDLC de développement. Donc, dans ce cas, le logiciel n’est pas une seconde pensée. Désolé, mais la sécurité n’est pas une seconde. C’est une pensée initiale tirée de votre tableau blanc lorsque vous commencez à penser à un produit lui-même. Donc, si vous adoptez cette approche particulière, demandez à l’IA de construire un modèle de menace pour un produit juste après avoir préparé un PRD ou un document d’exigence produit.

0:29:54 Mohit Kulamkolly : Cela vous donnera donc une idée de ce à quoi vous attendre pendant que vous développez le produit lui-même. Donc plus de contenu Contexte pour l’IA, bref, l’IA va construire tout ça. Vous pouvez donc donner plus de contexte à l’IA afin que de telles vulnérabilités n’existent pas dans la phase ultérieure de votre logiciel.

0:30:08 Emily Wearmouth : C’est une idée vraiment intéressante car, à travers ces expériences, on prenait quelque chose déjà construit dans toute sa complexité et demandait à l’IA de fouiller et de trouver des problèmes. Mais vous suggérez qu’en réalité, vous pourriez utiliser ces systèmes alors que vous n’avez qu’un concept de produit et quelques croquis de l’architecture et que vous commencez déjà à faire en sorte que les systèmes d’IA trouvent des failles dans vos plans afin que la rigueur de la sécurité soit vraiment en place dès le départ. Vous n’avez pas besoin de consacrer du temps et des efforts à construire quelque chose qui pourrait ne pas fonctionner. On peut commencer à trouver des problèmes avant qu’ils n’existent.

0:30:45 Mohit Kulamkolly : Exactement, exactement. Exactement.

0:30:47 Emily Wearmouth : Je n’y avais même pas pensé. Donc, si une équipe de sécurité veut faire quelque chose, et je pense que c’est spécifiquement une équipe de sécurité responsable d’une partie d’une propriété numérique quelconque, cela peut être parce qu’ils sont fournisseurs ou parce qu’ils développent des applications privées et des éléments privés dans leur stack. S’ils voulaient faire ce genre de chose pour la première fois, quelle est la toute première étape que vous craignez qu’ils ne sautent et que vous voudriez simplement les retirer ? Vous avez un peu parlé de certaines choses qu’ils pourraient commencer à faire eux-mêmes. Qu’est-ce que tu veux soulever mais faire ça d’abord ?

0:31:26 Mohit Kulamkolly : Oui. D’accord. Non, ça se tient. Ce que je ressens particulièrement pour ces découvertes, c’est que l’IA, ne pensons pas du tout à la partie hallucination. Disons que l’IA trouve toutes les vulnérabilités. Donc, si l’IA parvient à trouver 20 000 vulnérabilités, il n’est pas juste de lancer ces 20 000 résultats à vos développeurs et de leur demander simplement de corriger les choses. C’est donc la seule chose dont nous devons faire attention. Trouver des vulnérabilités est une chose, mais avoir un plan de remédiation est l’autre facteur important ici. Donc, avant même de commencer à aborder ces vulnérabilités, il faut commencer à discuter avec votre développeur pour comprendre par où commencer à examiner les vulnérabilités et quels sont les facteurs clés. Donc, ce n’est que lorsque vous avez cette synergie que ces vulnérabilités seront également utiles. Sinon, cela s’accumulera simplement dans votre longue liste de vulnérabilités comme non corrigées, soit 20 030 000.

0:32:26 Mohit Kulamkolly : C’est donc la seule chose que j’aurais en tête avant de plonger plus profondément dans ces outils sophistiqués ou de commencer à utiliser.

0:32:34 Emily Wearmouth : C’est un excellent point. Donc oui, mettez tous les détails corrects sur ce que vous faites, avec la rigueur et les garde-fous et approches, mais prenez un peu de recul et réfléchissez à l’impact que votre programme va avoir sur les autres, et ne commencez pas à multiplier la file d’attente de quelqu’un d’autre parce qu’il ne vous appréciera pas.

0:32:54 Mohit Kulamkolly :Exactement.

0:32:56 Emily Wearmouth : Génial. Eh bien, Mohit, merci beaucoup d’être venu avec moi pour parler de tout ça aujourd’hui. Dès que j’ai lu les articles, j’ai su que je devais te faire venir, alors je te remercie vraiment d’avoir pris le temps. Et je sens aussi que ce n’est pas votre expérience finale. Nous avons dit que c’était la phase un et la phase deux, et je vois à l’éclat dans votre œil qu’il y a peut-être déjà une phase trois en cours. Alors, où devraient aller nos auditeurs pour suivre le travail que vous faites et les découvertes que vous faites ?

0:33:23 Mohit Kulamkolly : Bien sûr. Oui. La plupart de ces travaux seront documentés sur le blog de la lentille sur le site web de Netskope lui-même. Et oui, s’il y a autre chose, d’autres choses, nous le publierons aussi sur les sites communautaires de Netskope. Mais oui, d’autres choses arriveront pour ces tests.

0:33:41 Emily Wearmouth : Fabuleux. Je pense qu’il faudra peut-être vous faire revenir sur le podcast et en entendre parler au fur et à mesure. Merci beaucoup, Mohit.

0:33:47 Mohit Kulamkolly : Merci, Emily.

0:33:48 Emily Wearmouth : Vous avez écouté le podcast Security Visionaries, et si cet épisode vous a plu, je vous recommande vivement de fouiller dans notre catalogue, que vous pouvez trouver sur l’une de vos plateformes de podcasts préférées. Et nos épisodes plus récents sont aussi disponibles sur YouTube si vous voulez voir nos visages souriants pendant que nous vous parlons. Alors profitez-en et on se revoit la prochaine fois.