Why Netskope Let AI Hack Its Own Software

0:00:02 Emily Wearmouth: Se ha hablado mucho sobre los posibles riesgos que podrían presentar los modelos de IA de Frontier, y el invitado de hoy nos va a ofrecer una perspectiva alternativa. Es un equipo de red team dentro de un equipo de seguridad, y ha sido modelo fronterizo de Usar con gran eficacia. Así que bienvenidos al pódcast Security Visionaries, Mohit Kulamkolly. Mohit es ingeniero senior en el equipo rojo dentro del equipo de seguridad de Netskope, y es un placer tenerte con nosotros, Mohit.

0:00:26 Mohit Kulamkolly: Gracias. Gracias por invitarme. Sí, encantado de estar en el podcast. Sí.

0:00:31 Emily Wearmouth: Así que has hecho un par de entradas en el blog, y me animaron a ponerme en contacto contigo porque lo que mencionabas en esos artículos era el trabajo que tú y tu equipo más amplio habéis estado haciendo usando estos modelos dentro de tus esfuerzos de red teaming. Quería hablar un poco de eso, y hay un par de experimentos diferentes, los llamaré experimentos. Espero que eso no los haga sonar demasiado pequeños. Hay un par de experimentos y modelos diferentes que has usado con Usar, y mi intención es hacerte muchas preguntas que, con suerte, revelen todos los detalles y descubrimientos que has ido haciendo a medida que has ido avanzando. Desde que obtuve acceso a los modelos de IA de Frontier, y creo que Netskope se unió a "Glasswing" en junio de este año, vuestro equipo ha estado realizando experimentos realmente informativos. Has estado poniendo esos modelos de frontera en el camino de los propios productos de seguridad de Netskope, si lo entiendo bien, y buscando si pueden encontrar errores graves de seguridad, y en particular, errores de corrupción de memoria.

0:01:26 Emily Wearmouth: Ahora, nuestros oyentes vienen de una iglesia muy amplia, así que ¿podrías despedirnos, Mohit, explicando a un oyente que quizás nunca ha tocado directamente la investigación de vulnerabilidades, qué es un error de corrupción de memoria y por qué podría considerarse una de las categorías de fallo de seguridad más peligrosas y difíciles de encontrar?

0:01:45 Mohit Kulamkolly: Sí, claro, claro. Sí, eso lo resume con precisión. Así que vamos a empezar con qué falla la corrupción de memoria, como bien has señalado. Así que un error de corrupción de memoria ocurre cuando un software gestiona mal su propio espacio de memoria asignado de forma incorrecta. Esto lo gestiona el sistema operativo, pero luego se asigna y decide el propio software. Así que cuando esto ocurre, genera vulnerabilidades que pueden desencadenar múltiples otros efectos dentro del sistema operativo, lo cual no es un comportamiento esperado. ¿Entonces por qué es peligroso? Porque, así que daremos un paso atrás en por qué es peligroso entenderlo mejor. Así que podemos dividir el sistema operativo en dos partes. Así que uno será el modo usuario y el otro será el modo kernel. Así que el modo usuario es donde se quedan todos los programas, todos nuestros programas, y el modo kernel es lo que está relacionado con el sistema operativo.

0:02:44 Mohit Kulamkolly: Y el modo usuario una y otra vez necesita cosas del kernel para ejecutar ciertas acciones y todo eso. Así que aquí es donde comienza la superficie de ataque. Así que si un programa se cierra dentro del modo usuario, se quedará dentro del propio modo usuario. Y cuando se inicia para pedir cosas al kernel, el atacante también puede verlo o puede usar con Usar. Así que, a través de ese camino, también puede bloquear cosas en el sistema operativo, lo que lleva a más vulnerabilidades. Por eso es muy peligroso en comparación con otras vulnerabilidades.

0:03:15 Emily Wearmouth: ¿Y qué intentabas averiguar apuntando estos modelos de IA a esos errores de corrupción de memoria?

0:03:22 Mohit Kulamkolly: Así que básicamente Netskope opera dentro del sistema dentro de la entidad del sistema operativo del cliente. Y a partir de ahí, si se activa una vulnerabilidad, eso es una vulnerabilidad por corrupción de memoria. Como he dicho, puede provocar inactividad del sistema o vulnerabilidades de escalada de privilegios y todas esas cosas. Así que el objetivo aquí era ver si una vulnerabilidad dentro de Netskope Client en particular podía escalarse a algo que afectara al sistema operativo. Así que estamos saliendo de nuestro programa hacia el conjunto, lo cual es más catastrófico comparado con el simple Netskope Client de colapso. Así que sí, ese era el objetivo.

0:04:03 Emily Wearmouth: Y antes de analizar cómo usar las herramientas de IA, ¿cómo solías buscar esas vulnerabilidades antes de tener Frontier AI?

0:04:13 Mohit Kulamkolly: Así que antes de que se aleje de intentar averiguar cuál es la superficie de ataque. Así que existen APIs escritas para este tipo de comunicación que ocurren desde el modo usuario hasta el modo kernel. Así que primero intentas averiguar qué APIs hay y cómo se está escribiendo el programa, totalmente desde una perspectiva de caja negra. Cuando digo caja negra, no tenemos código fuente, nada de eso. Así que ahí es cuando Inicio. Y a partir de ahí, intentaremos ver si una carga útil que enviamos o un Datos que enviamos provoca un fallo dentro de un sistema o de ese sistema operativo en particular. Y seguimos intentándolo una y otra vez para averiguar qué carga útil o instrucción es esta en el fallo. Así que es entonces cuando intentamos desarrollar fuzzers por nuestra cuenta. Eso es lo que hemos detallado, Ahora. Así que he desarrollado fuzzers que ayudan a identificar estas vulnerabilidades.

0:05:10 Mohit Kulamkolly: Pero tener la IA en este panorama escaló a un nivel completamente diferente de pruebas, donde se requiere mucha, mucha más experiencia para siquiera entrar en este ámbito. Y luego, gracias a la llegada de la IA, podemos escalarlo aún más.

0:05:29 Emily Wearmouth: Y voy a citar aquí tu entrada de blog. Así que en la primera fase de trabajo que hiciste, y fuiste Usar OpenAI 5.5, ¿lo he entendido bien?

0:05:38 Mohit Kulamkolly: Modelo cibernético.

0:05:39 Emily Wearmouth: Dijiste que tu punto de partida era que no puedes simplemente preguntar a la IA, encontrarme un error y confiar en la respuesta. Tienes que darle las mismas herramientas que un cazador de insectos humano real usaría y forzar que cada reclamación que haga se compare con un sistema real en funcionamiento. Así que, para tomar los puntos en orden, primero, ¿por qué es peligroso? Puede que lo sepamos. Dime explícitamente, ¿por qué es peligroso fiarse simplemente de la palabra de un modelo de que encontró una vulnerabilidad? ¿Y qué podría salir mal si te saltas esa fase de verificación?

0:06:09 Mohit Kulamkolly: Sí, claro. Así que antes de profundizar más, creo que acabaría contradiciendo la afirmación hace un tiempo porque eso fue lo que me enseñó el Mito con los experimentos de Nuevo. Entonces, lo que ocurre con estos modelos cibernéticos, OpenAI 5.5 o el modelo cibernético, es que se entrenan con una enorme cantidad de datos, todas vulnerabilidades y hallazgos de seguridad. Así que permite alucinar en situaciones donde tiene que hacer suposiciones en lugar de información. Así que si simplemente le pides al modelo que encuentre la vulnerabilidad por ti, lo que pasa es que eso es lo único que sabe. Así que tiene que concluir a partir de sus supuestos que ha hecho inicialmente. Así que, en cierto modo, es bueno, cosa que descubrimos más adelante. Inicialmente, cuando queríamos escribir, teníamos que asegurarnos de ser lo más deterministas posible respecto a nuestros hallazgos. Así que fue entonces cuando decidimos, vale, vamos a empezar con lo que sabemos.

0:07:11 Mohit Kulamkolly: Vamos a Intentar para ampliar eso, y luego pasaremos al capítulo de lo que no sabemos y lo que el modelo puede hacer.

0:07:17 Emily Wearmouth: Vale. Así que cuéntame qué has construido realmente aquí. ¿Cómo es realmente un laboratorio para un sistema así?

0:07:24 Mohit Kulamkolly: Sí, sin entrar en detalles muy específicos de cómo es, a un nivel muy general, simplemente le estás dando a un investigador de vulnerabilidades las herramientas que necesita hacer. Quiero decir, necesita tener que hacerlo para ejecutar ciertas acciones. Así que piénsalo, hay misiones virtuales en las que el software se ejecutará. Hay misiones virtuales en las que las herramientas se ejecutarán. Así que simplemente conecté todos los puntos, conecté los puntos y le di esto al modelo, y luego le pedí que buscara una vulnerabilidad de una forma muy específica que yo analizaría con mi experiencia en los esfuerzos de caza anteriores. Así es como lo iniciamos. Así es como es el laboratorio a un nivel muy general.

0:08:12 Emily Wearmouth: Voy a hacer una pregunta potencialmente complicada. Así que ha habido muchas historias en la última semana o dos sobre agentes e IA que han salido del Sandbox y han hecho cosas que quizás responden a la tarea que se les ha encomendado, pero desde luego no de una manera con la que nos sintamos cómodos. ¿Hay algún límite específico que estés poniendo en estos experimentos anticipando que pueda intentar y romperse? ¿Cómo te aseguras de que no lo haga?

0:08:36 Mohit Kulamkolly: Sí, esa es una muy buena pregunta porque, especialmente en este contexto, cuando se le pide a un agente que haga una tarea específica, no lo decimos de una forma muy concreta. Eso fue lo que hice al principio, y entendí que podía ser un limitante para el agente. Así que, para salir de eso, lo que creamos fue un entorno sandbox individual. Así que cada misión virtual tiene un entorno Sandbox, al que no se puede romper ni acceder si explícitamente no se lo permitimos. Especialmente en el caso de estas máquinas Windows probando y demás, en lugar de ejecutar un contenedor Docker o conceptos similares, las misiones virtuales funcionan mejor. Así que ese es el nivel de aislamiento que hemos creado para las herramientas individuales y el tipo de acceso que tienen a ellas. Y hacemos todas estas pruebas en un sistema y misión separados, sin acceso adecuado a internet.

0:09:34 Emily Wearmouth: Supongo que mantenerlo fuera de internet es una de las cosas clave para restringir su capacidad de volverse descontrolado. También mencionaste en el artículo que escribiste que construiste esto alrededor de una máquina objetivo que está específicamente permitida para fallar y otra máquina separada que la vigila con un depurador. ¿Por qué mantuviste esos sistemas separados y por qué es útil permitir que se bloquee en lugar de detenerlo antes de que eso ocurra?

0:09:58 Mohit Kulamkolly: Sí, ese es todo el concepto de esta vulnerabilidad por corrupción de memoria y por qué es interesante. Así que cada vez que un sistema intenta detectar que una memoria está siendo mal gestionada por un programa, pasa a una fase de seguridad de fallos. Así que eso es una fase de crash lo que ocurre. Así que cuando intentas probar un error individual, cuando intentas probar una carga útil individual a nivel microscópico, la mejor forma de confirmarlo inicialmente es que el error existe es ver si se bloquea o no. Y si hay un fallo absurdo, significa que está ocurriendo un mal manejo de la memoria. Luego podemos discutir cómo podemos escalarlo, qué producciones de sistemas necesitamos evitar, y así sucesivamente. Así que estas cosas surgen en una etapa posterior. Pero también, para añadir a algo interesante que mencionaste, ¿por qué no lo pausamos justo antes de que se bloquee?

0:10:53 Mohit Kulamkolly: Así que también existe un sistema así. Así que también lo hacemos internamente. Es una infraestructura de fuzzing de instantáneas que hemos construido, en la que intentamos recoger justo antes de que se bloquee para poder reproducirla millones de veces y encontrar variantes nuevas de nuestra vulnerabilidad. Así que sí, ese es todo el contexto.

0:11:12 Emily Wearmouth: Y tengo una pregunta más sobre esta fase del experimento. Me reservo el derecho de preguntar más, pero por ahora creo que tengo una. Parece que muchas de las primeras hipótesis del modelo sobre los errores resultaron ser erróneas. Que eran suposiciones desactualizadas de Usar sobre el software. Y me preguntaba por qué determinaste que eso estaba ocurriendo. ¿Y qué crees que aprendió el modelo de estar equivocado y pasar por esa fase de equivocarse?

0:11:43 Mohit Kulamkolly: Sí, lo que ocurre con este tipo de software es que es difícil probar este tipo de software porque depende mucho del entorno en el que se despliegue. Así que si se hacen pequeños ajustes en el sistema operativo, digamos que hay una función o un programa que debería estar ejecutándose en segundo plano, no se está ejecutando, el software no se comportará como debería. Esta es una de las razones por las que el sistema no solo necesita adaptarse al entorno que tenga para detectar vulnerabilidades, sino que al mismo tiempo también debe averiguar el siguiente paso en función del resultado que obtiene allí. Así que no es solo eso, vale, este es el procedimiento estándar, hazlo. Así que tienes que asegurarte de que el sistema acepta eso o que el software esté listo para aceptar ese procedimiento operativo estándar y que funcione antes de iniciar y añadir cargas útiles.

0:12:39 Mohit Kulamkolly: Porque si no estás implementando una IA aquí, lo que pasará es que enviaré muchas cargas útiles y luego la IA no o el software ni siquiera responderá. ¿Entonces, cómo puedo probarlo? Así que esa es una de las razones por las que el modelo hizo esa corrección. Sí.

0:12:54 Emily Wearmouth: Derecha. Así que lo que hemos estado hablando hasta ahora es la fase uno. Así que tenías a los humanos, tú, diseñando todos los pasos, y luego se le pidió a la IA que ejecutara tareas dentro de un proceso que tú habías diseñado. Quiero que sigamos Ahora a tu segunda fase. Ahora, para tu segunda fase, cambiaste de modelo y iniciaste jugando con Claude Mythos en su lugar. ¿Había alguna razón para cambiar eso o simplemente querías hacer experimentos con ambos? ¿O hubo algún beneficio que pensaste que obtendrías al cambiar de modelo?

0:13:30 Mohit Kulamkolly: No realmente. Acabamos de tener herramientas sofisticadas y análogos de Nuevo.

0:13:34 Emily Wearmouth: Todos hemos pasado por eso. Vale. Y en este segundo, voy a hacer un boceto de Intentar y qué fue diferente, y seguro que me iluminarás un poco más. Así que, en lugar de diseñar cada paso y luego pedirle al modelo que lo ejecute, le pediste al modelo que decidiera qué investigar. Luego le pediste que demostrara cualquier error que encontrara contra un sistema real. Y luego, lo que parece ser un elemento bastante crítico de este, también requería que tuviera una segunda copia independiente de sí mismo comprobada con esa prueba. Así que le das más parte del proceso, pero también estás incorporando más comprobaciones porque eliminas más humanos de la carga de trabajo allí. ¿Puedes explicarme qué te motivó, desde terminar y concluir sobre tus experimentos con OpenAI, qué te llevó a diseñarlo de esta manera?

0:14:30 Mohit Kulamkolly: Así que aprendimos nuestras lecciones de OpenAI cuando iniciamos las pruebas con Mythos. Así que, bajo el capó, toda la seguridad, todos los modelos. Así que básicamente todos son sistemas de predicción. Aunque decimos cosas como que desarrollaron el software Nuevo y todo eso, simplemente predicen lo que viene a continuación de forma muy eficiente según el contexto y lo que se le asigna. Así que cuanto más restringes el contexto o más lo pones con correa, lo que ocurrirá es que el tipo de información que puede producir también disminuirá. Así que cuando probábamos con OpenAI, le producimos un fuzzer. Le pedimos que construyera sobre eso. Ahora queríamos ver si, como le dimos el fuzzer, por eso lo único que pudo construir es una extensión de eso.

0:15:21 Mohit Kulamkolly: Así que quitamos el fuzzer de la imagen y luego le enseñamos cómo construimos el fuzzer y cómo puedes hacerlo tú mismo. O puedes hacerlo tú mismo o simplemente hacer lo que creas correcto para llegar a esta interfaz concreta del programa. Por eso queríamos intentarlo así. Así que en vez de protegerlo. Así que funcionó muy bien. Así que entendimos cómo se comportaba el modelo y las formas creativas que se necesitaban para descubrir una vulnerabilidad. Así que ahí está el meollo del asunto.

0:15:57 Emily Wearmouth: ¿Hubo alguna consideración extra que tuvieras que dar porque esta vez ibas a ceder más control? ¿Había diferentes formas en las que estructurabas las cosas o alguna barrera adicional que sentías que debías implementar?

0:16:10 Mohit Kulamkolly: Sí, más aislamiento. Creo que más aislamiento fue lo clave para ello. El modelo, no en nuestro sistema de trabajo. Así que teníamos un portátil aparte solo para probar esto. Estaba fuera de la red. Y luego sí, esta vez nos entregamos por completo. Así que, en vez de pedirle que usara las herramientas que hay en el sistema, simplemente nos aseguramos de que esté cada vez más aislado. Sí, eso es todo.

0:16:35 Emily Wearmouth: Vale. Y supongo que al incorporarlo con esa doble comprobación de lo que produce, también hay más barreras de seguridad alrededor de las conclusiones que está dibujando, supongo que lo estás incorporando en el modelo.

0:16:47 Mohit Kulamkolly: Sí, sí. Derecha.

0:16:49 Emily Wearmouth: ¿Cómo evitaste que se convenciera de que tenía razón? ¿Cómo mantuviste esa doble comprobación lo suficientemente separada para que no pudiera hacerlo? Quiero decir, una de las cosas que hemos visto la última semana fue un agente que literalmente llegó a crear deepfakes de empleados para conseguir la aprobación interna de algo. Así que sabemos que la IA sabe cómo convencer. ¿Cómo te aseguraste de que no solo se convencía a sí mismo o a esta comprobación secundaria de que lo que hacía era correcto?

0:17:21 Mohit Kulamkolly: Sí. Lo principal de esto es lo que discutimos antes, el modelo es un sistema de predicción y el contexto es una parte clave aquí. Me gustaría tomar el mismo concepto aquí también, el contexto. Así que casi siempre, el 100% de las veces que un modelo se equivoca es porque no tiene el contexto adecuado o tiene un contexto basura, diría yo. Así que la razón por la que hay dos sistemas separados es por la misma razón. Así que cada vez que un modelo mira un trabajo nuevo, simplemente significa que está mirando desde un contexto sencillo hacia una ventana. Así que, de esa manera, no hace suposiciones erróneas que se crearon previamente. Así que en el caso que mencionaste también, todo se reduce a lo que el modelo necesita lograr. Así que el objetivo para un agente puede no ser el objetivo del otro.

0:18:16 Emily Wearmouth: Ah, interesante.

0:18:18 Mohit Kulamkolly: Y basándome en lo que has dicho también, el objetivo inicial podría no ser crear deepfakes de ese empleado en particular, sino más bien sortear este sistema de aprobación. Así que hará lo que sea que pueda por el canal, pero el modelo no hizo nada dañino desde su contexto, pero desde el contexto externo sí lo hizo. Así que el contexto es un rey. Sí.

0:18:40 Emily Wearmouth: Así que supongo que has añadido un poco de fricción entre las dos fases: si no revisa su propio trabajo, es otro agente de IA quien revisa parte del trabajo para que no se unan y mantengas cierta diferencia entre ambos. Es un punto de diseño realmente interesante.

0:18:58 Mohit Kulamkolly: Exacto, exacto. Sí.

0:19:00 Emily Wearmouth: Cuéntanos algunas de las cosas que encontró esta vez. ¿Cómo funcionaba? ¿Qué resultó?

0:19:08 Mohit Kulamkolly: Así que sí, obtuvimos muchos buenos resultados de estos dos experimentos iniciales en particular que hicimos. Así que pudimos encontrar entre 17 y 18 vulnerabilidades solo en software de código abierto. Así que estos programas son algo que Netskope Usar para crear nuestros productos. Pero luego estas vulnerabilidades se encuentran en los paquetes upstream y se reportan al personal adecuado que las gestiona. Y luego descubrí estas vulnerabilidades de corrupción de memoria. Así que también había entre 15 y 20 vulnerabilidades de corrupción de memoria. Y finalmente tuvimos para la comprobación diferencial, encontramos cuatro o cinco de ellos. Así que esto no es una escala compartida, se encontraron 20.000 vulnerabilidades, y esto es solo una escala pequeña de la que hablo, de 15 a 20. La razón o la parte clave a tener en cuenta aquí es que cada vulnerabilidad, cuando se reporta por un cliente o en Netskope, tendrá cuentas a un FMI.

0:20:15 Mohit Kulamkolly: Así que esos incidentes con el FMI supondrán grandes pérdidas para esa entidad en particular que los haya sufrido. Así que encontrarlo en nuestros productos nos está ahorrando mucho dinero y asegurando la confianza en nuestros clientes sobre a qué nos están enfrentando.

0:20:35 Emily Wearmouth: Sí. Ahora he vuelto a escribir de tu artículo algo que quería explorar y que me pareció especialmente interesante. Hubo un error que el modelo encontró en el lado del kernel, y contaste una historia sobre un fallo que no ocurrió hasta que descubrió algo sutil sobre cómo se asigna la memoria tras bambalinas. ¿Quieres que nos expliquemos a un nivel general ese ejemplo en particular?

0:20:59 Mohit Kulamkolly: Sí, claro, claro. Así que creo que esta vulnerabilidad estaba en un analizador sintáctico de configuración. Así que este analizador de configuración básicamente copiaba el valor del registro a una asignación de pool de tamaño exacto Usar, una función de copia de longitud de cadena. Y esta función de copia enlazada por cadenas no tenía una comprobación saliente que estuviera ahí. Así que fuera de límite. Por esta razón, esto es una vulnerabilidad de libro de texto fuera de límite, y puede ser explotada con mucha facilidad. Así que, para llegar a esta vulnerabilidad, había casi cinco o seis precondiciones que debían cumplirse. Así que las condiciones previas serán tan simples como comprobar si el software acepta un tipo específico de nombre de servicio o si acepta algo diferente o una versión distinta. Todas estas son condiciones previas.

0:21:54 Mohit Kulamkolly: Así que, después de resolver todas las condiciones previas, el accidente no ocurrió. Así que tuvo que saltar al depurador, Intentar, para simplificar el asignador. Y luego descubrió que el sistema operativo aparentemente añadió algo llamado terminador nulo, que es muy común. Y luego el asignador redondeó ese buffer en una tabla completa básicamente. Esto hizo que un Lea fuera de límite no aterrizara donde nosotros lo teníamos. Entonces descubrió la geometría del asignador de cómo está ocurriendo, y cambió su exploit para que coincidiera exactamente con lo que se esperaba que desencadenara el fallo. Así que eso fue lo que ocurrió allí a un nivel muy general. Sí.

0:22:35 Emily Wearmouth: Parte de la razón por la que te pedí que me explicaras eso fue porque quería vivir el momento de alucinar la mente. Quiero decir, la complejidad y las capas de detalle en las que se está entrando, si imaginas un mundo en el que se alcanzase más manualmente ese resultado, ¿qué tipo de tiempo, cuántas horas de trabajo? ¿Cómo sería eso? ¿O simplemente crees que solo ocurriría por accidente?

0:23:02 Mohit Kulamkolly: Quiero decir, serían días y días de esfuerzo. Y como has dicho, también sería un accidente. Así que, como es muy difícil resolver estas cosas, ya que cuando miras un depurador y tratas de averiguar dónde falló el asignador, es complicado porque necesitas darle sentido a toda la información que hay. Puede que no seas experto en ese ámbito concreto que estás mirando, pero entonces tienes que saber todo esto para asegurarte de conectar los puntos. Así que, de nuevo, sí, puede ser un accidente que te encuentres con estos problemas o meses y horas de esfuerzo para encontrar esta vulnerabilidad.

0:23:40 Emily Wearmouth: Hubo otro que me pareció interesante en tu artículo. Fue un error que llevó varios días y miles de intentos para solucionarlo, incluso con la IA. Así que hablaste de que un equivalente humano llevaría días y días. Incluso con la IA funcionando, esta vez llevó varios días y miles de intentos. ¿Qué mantuvo ese proceso en marcha? ¿Qué cambió entre los intentos fallidos y el que finalmente funcionó? ¿Y por qué no se apagó el tiempo? Quiero decir, ¿cuánto tiempo, si hubiera tardado en vez de miles de intentos, si hubieras llegado a cientos de miles, simplemente se habría rendido y no habría encontrado eso? He hecho varias preguntas allí. Elige lo que quieras.

0:24:18 Mohit Kulamkolly: No, tiene sentido. Así que, en realidad, para esa vulnerabilidad o encontrar ese caso en particular, la razón por la que el proceso fue difícil fue porque no teníamos código fuente para ello. No teníamos tabla de símbolos, no teníamos nada. Fue una prueba completa de caja negra que hicimos. Así que lo que pasa es que para este tipo de vulnerabilidades, cuando intentas descubrirlas, hay múltiples matices ahí antes incluso de llegar a la vulnerabilidad en sí. Así que en la parte de la IA para el timeout, la forma en que fue diseñada es que vas a enfrentarte a muchas de estas consecuencias, que tu hipótesis inicial puede funcionar o no. No deberías estar esperando a que una hipótesis se complete y a que la otra pase a la siguiente. Así que, en lugar de una forma lineal, era mayormente una moda paralela.

0:25:09 Mohit Kulamkolly: Así que los agentes generan subagentes cuando sea necesario para explorar estas ideologías hasta que encuentres o descubras la forma correcta de abordarlo. Por eso no se agotaba casi todo el tiempo. Creo que se ejecutó durante unos días para encontrar este tipo de vulnerabilidades, especialmente por la complejidad y la disponibilidad de menos información. Pero sí, los subagentes funcionaron ahí.

0:25:34 Emily Wearmouth: Así que voy a alejarme un poco, y creo que vale la pena que, con suerte, los oyentes ya hayan entendido que estos dos artículos que has publicado merecen mucho la pena leerlos. Así que incluiremos detalles sobre dónde puedes aprender más de este detalle en las notas del programa. Pero vamos a dejar un momento de los experimentos exactos que has realizado y pensar qué significa esto en un contexto más amplio y qué significa para algunos de nuestros oyentes cuando piensan en sus propios entornos y quizás no tienen acceso a todos estos modelos de frontera en este momento. Supongo que lo primero que pienso es que si este tipo de capacidad no es exclusiva de Netskope. Hay una amplia lista de organizaciones que tienen acceso a estos modelos, e incluso los modelos que no se consideran modelos frontera están cada vez más ingeniosos.

0:26:17 Emily Wearmouth: Así que si esta técnica te ayuda a encontrar errores dentro de tu código y tus sistemas y están disponibles o herramientas similares están disponibles para cualquiera, ¿qué significa para el equipo de seguridad medio que quizás no tiene un equipo de investigación como el tuyo y está en el lado receptor de otras personas usando estos sistemas para atacar y encontrar estos problemas? Cuando observas ese reto al que se enfrenta el Sector, ¿cómo lo ves?

0:26:47 Mohit Kulamkolly: Sí, lo que va a pasar eventualmente es que los modelos se abaratarán cada vez más debido a cómo avanza en Caso de seguridad también, desde cualquier perspectiva de desarrollo. Así que creo que lo que va a pasar es que algunos de los otros modelos, todo el mundo puede acceder a los modelos open source de Ahora para explorar estas cosas. Así que lo que recomendaría a cualquier equipo de investigación en seguridad, sea lo que sea que intenten hacer y quieran que Inicio haga, es que Inicio proporcione a estas IAs las herramientas adecuadas. Y luego, las herramientas adecuadas que le des a la IA, más te sorprenderá y más exploración podrá hacer por sí misma para descubrir estas cosas. Así que, en vez de verlo como una herramienta compleja necesaria para conectarla a otra herramienta que ya existe.

0:27:42 Mohit Kulamkolly: Por ejemplo, imagina que necesitas un servidor MCP que necesita ser Usar para conectar una herramienta, pero no tienes un servidor MCP para eso. Así que tendrás que escribirlo desde cero y luego construirlo encima. Así que esa es una curva de aprendizaje que quizá tengas que saltar para llegar a ese lado. Así que piénsalo como si incluso el servidor MCP fuera cualquier API que se exponga, solo lo conectas a la IA, nada más. Así que es solo código simple. Intento averiguarlo. Y si puedes conectar tu herramienta, si no, puedes conectarte con las herramientas, tienes que empezar a escribir cosas por tu cuenta o usar usar IA para escribirlas. De esa manera, cuando inicias a las herramientas las cosas sensoriales, los ojos, la nariz, las orejas. Y una vez que tienes eso, una vez que tienes toda esta información, las herramientas procesarán Inicio o la IA procesará la información como quieras y entonces te darán mejores resultados.

0:28:37 Mohit Kulamkolly: Así que sí, así es como lo veo.

0:28:40 Emily Wearmouth: ¿Crees que un enfoque así va a cambiar de forma significativa la forma en que las empresas de software o tecnológicas lanzan su software? ¿Va a cambiar las líneas temporales? ¿Va a cambiar las expectativas o los costes? ¿Qué crees que podrían ser esas implicaciones?

0:28:57 Mohit Kulamkolly: Sin duda. Así que sí, como he dicho, lo que va a pasar es que las vulnerabilidades de seguridad serán más baratas de descubrir cuanto más avance la IA. Así que lo que va a pasar es que la solución se volverá más cara. Así que, con la tarifa, estamos enviando el software justo ahora. Así que la solución de estas vulnerabilidades va a ser cara y luego será más difícil de ejecutar. Así que cuando tenemos cómo Netskope tiene esto incluso antes de la época en que la IA lo tenía, tenemos nuestro propio SDLC de desarrollo. Así que en ese sentido el software no es una segunda opción. Lo siento, pero la seguridad no es un segundo. Es una idea que se plantea desde tu pizarra cuando empiezas a pensar en un producto en sí. Así que si sigues ese enfoque en particular, pide a la IA que construya un modelo de amenaza para un producto justo después de tener un PRD o un documento de requisitos de producto preparado.

0:29:54 Mohit Kulamkolly: Así que eso por sí solo te dará una idea de qué esperar mientras construyes el producto en sí. Así que más contenido Contexto para la IA, en fin, la IA va a construir estas cosas. Así puedes dar más contexto a la IA para que tales vulnerabilidades no existan en la fase posterior de tu software.

0:30:08 Emily Wearmouth: Es una idea realmente interesante porque, a través de estos experimentos, estabas tomando algo que ya estaba construido en toda su complejidad y pidiendo a la IA que rebuscara y encontrara a Problema con ello. Pero estás sugiriendo que en realidad podrías usar estos sistemas cuando solo tienes un concepto de producto y algunos bocetos de cómo podría ser la arquitectura y ya estás haciendo que los sistemas de IA detecten fallos en tus planes para que ese rigor de seguridad realmente funcione desde el principio. No tienes que dedicar tiempo y esfuerzo a construir algo que quizá no funcione. Puedes empezar a encontrar Problema antes de que exista.

0:30:45 Mohit Kulamkolly: Exacto, exacto. Exactamente.

0:30:47 Emily Wearmouth: Ni siquiera había pensado en eso. Así que si un equipo de seguridad quiere hacer algo, y creo que específicamente un equipo de seguridad responsable de una parte de una propiedad digital de algún tipo, ahora eso puede ser porque son proveedores o porque están construyendo aplicaciones privadas y elementos privados dentro de su stack. Si quisieran hacer algo así por primera vez, ¿cuál sería el primer paso que te preocuparía que se salten y que quieras simplemente retirarles? Has hablado un poco de algunas cosas que podrían hacer Inicio ellos mismos. ¿Qué es lo que quieres que te apetezca pero hacer esto primero?

0:31:26 Mohit Kulamkolly: Sí. Vale. No, tiene sentido. Así que lo que creo especialmente con estos hallazgos es que la IA, no pensemos en la parte de las alucinaciones en absoluto. Supongamos que la IA encuentra todas las vulnerabilidades. Así que si la IA es capaz de encontrar 20.000 vulnerabilidades, no está bien lanzar esos 20.000 hallazgos a tus desarrolladores y decirles: pídeles que simplemente lo arreglen. Así que eso es lo único con lo que debemos tener cuidado. Encontrar vulnerabilidades es una cosa, pero tener un plan de remediación para ello es otro factor importante aquí. Así que, antes incluso de que Inicio incluya estas vulnerabilidades, tienes que tener una conversación con tu desarrollador para entender dónde deberíamos analizar las vulnerabilidades y cuáles son los factores clave. Así que solo cuando tengas esa sinergia, estas vulnerabilidades también serán útiles. Si no, simplemente se acumulará en tu larga lista de vulnerabilidades como no corregidas, 20.030.000 de ellas.

0:32:26 Mohit Kulamkolly: Así que eso es lo único que tendría en mente antes de profundizar o empezar a usar estas herramientas sofisticadas.

0:32:34 Emily Wearmouth: Es un gran punto. Así que sí, acierta con todos los detalles de lo que haces y el rigor, los límites y el enfoque adecuados, pero da un poco de vista y piensa en el impacto que tu programa va a tener en los demás y no simplemente inicies creando un aumento de 500 veces en la cola de otra persona porque no les gustarás por ello.

0:32:54 Mohit Kulamkolly:Exacto.

0:32:56 Emily Wearmouth: Brillante. Bueno, Mohit, muchas gracias por acompañarme hoy para hablar de todo esto. En cuanto lea los artículos, supe que tenía que conseguirte, así que te agradezco mucho que hayas dedicado tiempo. Y también siento que este no es tu último experimento. Dijimos que era la fase uno y la fase dos, y puedo ver por el brillo en tus ojos que quizá ya está ocurriendo una fase tres. ¿A dónde deberían ir nuestros oyentes para seguir el trabajo que haces y los descubrimientos que estás haciendo?

0:33:23 Mohit Kulamkolly: Claro. Sí. La mayor parte de este trabajo se documentará en el blog de la lente en la propia web de Netskope. Y sí, si hay algo más, adicionales, también lo publicaremos en las páginas comunitarias de Netskope. Pero sí, habrá más cosas en camino para estas pruebas.

0:33:41 Emily Wearmouth: Fabuloso. Creo que tendremos que volver al podcast y escuchar sobre ellos a medida que ocurran. Muchas gracias, Mohit.

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

0:33:48 Emily Wearmouth: Has estado escuchando el podcast Security Visionaries, y si te ha gustado este episodio, te recomiendo sin duda que eches un vistazo a nuestro catálogo anterior, que puedes encontrar en cualquiera de tus podcasts favoritos, Plataforma. Y nuestros episodios más recientes también están en YouTube si quieres ver nuestras caras sonrientes mientras hablamos contigo. Así que disfruta de ellos y nos vemos la próxima vez.