Podcast: Presentación de las pruebas de penetración con IA: qué son, cómo funcionan y dónde encajan
Presentación de las Pruebas de Penetración con IA
31 Marzo – 32 minutos
En este episodio, nos acompañan Chris Oakley (Vicepresidente Sénior de Servicios de Aseguramiento para América, LRQA), Dave Parsons (Consultor Principal de Seguridad, LRQA) y David Greene (Alianzas Estratégicas, Simbian) para presentar las Pruebas de Penetración con IA, una nueva funcionalidad de LRQA desarrollada en colaboración con Simbian. Juntos, exploran qué son las Pruebas de Penetración con IA, cómo funcionan en la práctica y cómo se integran con las pruebas de penetración tradicionales realizadas por consultores.
La conversación aborda la presión por acelerar los programas de pruebas de seguridad, cómo la IA puede respaldar pruebas más frecuentes y repetibles, y por qué la credibilidad, la gobernanza y la supervisión experta siguen siendo fundamentales. También se tratan aspectos prácticos relacionados con la confianza, el manejo de datos, la soberanía, la retención y la seguridad operativa.
Síganos en Spotify
Josh Flanagan:
Hola a todos y gracias a nuestros oyentes de todo el mundo. Bienvenidos al podcast Future in Focus de LRQA. Mi nombre es Josh Flanagan y hoy presentamos una nueva solución de LRQA: Pruebas de Penetración con IA.
Me acompañan Chris Oakley, vicepresidente sénior de Servicios de Aseguramiento de LRQA; Dave Parsons, consultor principal de seguridad de LRQA; y David Greene, de Alianzas Estratégicas de Simbian, quien ha colaborado con nosotros en el desarrollo de esta capacidad. Chris, Dave y David, muchas gracias por acompañarnos.
Hoy analizaremos qué significan las Pruebas de Penetración con IA en la práctica, cómo funcionan junto con las pruebas dirigidas por consultores y por qué las pruebas continuas se están volviendo esenciales. También abordaremos la gobernanza y los controles de datos que las respaldan.
Para empezar, Chris, te cedo la palabra. Para contextualizar, ¿qué son las pruebas de penetración basadas en IA y por qué LRQA las lanza ahora?
Chris Oakley:
Claro que sí, Josh. El principal problema que nos comentaban nuestros clientes era que sus entornos cambiaban más rápido de lo que sus programas de pruebas podían seguir el ritmo. Quizás realizaban una prueba de penetración una o dos veces al año, pero su superficie de ataque evoluciona constantemente con elementos como nueva infraestructura en la nube, nuevas integraciones y nuevas implementaciones de código.
Nuestra solución de pruebas de penetración con IA es la respuesta a esta necesidad. Combina las capacidades de pruebas basadas en IA de Simbian con la supervisión experta de LRQA, lo que nos permite ofrecer pruebas de seguridad consistentes y repetibles a un ritmo y con una frecuencia que la consultoría tradicional por sí sola no puede igualar.
No estamos reemplazando a los consultores. Estamos ampliando sus capacidades y posibilidades. El momento era idóneo porque la tecnología está lo suficientemente madura como para ofrecer resultados fiables. En los últimos dos años, este sector ha experimentado un crecimiento enorme, por lo que ahora podemos proporcionar resultados prácticos. Al mismo tiempo, la demanda de los clientes de una mayor frecuencia de garantías ha llegado a un punto en el que necesitábamos una solución real, no solo un concepto.
Josh Flanagan:
Perfecto, gracias Chris. Mencionaste a Simbian. ¿Podrías explicarnos brevemente la colaboración y por qué empezamos a trabajar con Simbian en esta solución?
Chris Oakley:
Por supuesto. Teníamos varias opciones, y la verdad es que podíamos desarrollar algo nosotros mismos, comprar una solución ya existente o asociarnos con otra empresa. Al analizar el mercado, nos dimos cuenta de que en ese momento no había nada que nos convenciera del todo.
Si bien podríamos haber desarrollado algo nosotros mismos, y contamos con un equipo de hackers expertos capaces de crear todo tipo de prototipos interesantes, existe un gran salto entre eso y ofrecer software de nivel empresarial. En el proceso, encontramos a Simbian.
Simbian ya tenía un producto en el ámbito de la detección y respuesta, y estaban muy interesados en desarrollar algo con nosotros en el ámbito de la seguridad ofensiva. Tras varias conversaciones y demostraciones tecnológicas, quedamos impresionados con lo que vimos y supimos casi de inmediato que eran el socio ideal para lanzar este tipo de producto al mercado.
Josh Flanagan:
Ahora te toca a ti, David. Para quienes no conozcan a Simbian, ¿podrías hacernos una breve introducción a la colaboración desde tu perspectiva?
David Greene:
Por supuesto, Josh. Simbian es una empresa centrada en el uso de la IA para automatizar la seguridad empresarial. Creemos que, en un panorama de seguridad cada vez más dominado por amenazas y ataques basados en IA, la única forma en que las empresas pueden protegerse es mediante el uso de herramientas de IA. Estas herramientas operan con rapidez, ofrecen una respuesta coordinada y se basan en la información y el contexto internos de la empresa.
Como mencionó Chris, ya contábamos con experiencia en el desarrollo de herramientas de este tipo para prácticas de seguridad. Inicialmente, nos centramos en aspectos como el SOC de IA y el procesamiento de alertas, y ahora, gracias a la colaboración con LRQA, hemos tenido la oportunidad de aplicar esa experiencia a las pruebas de penetración.
El valor de esta colaboración reside en que Simbian aporta su experiencia en la aplicación de la IA a la automatización y las operaciones de seguridad, mientras que LRQA posee una amplia experiencia en la correcta ejecución de pruebas de penetración. La combinación de ambas nos permite ofrecer un único producto y una única solución, que es precisamente de lo que hablaremos hoy.
Josh Flanagan:
Ahora vuelvo contigo, Chris. ¿Qué cambios en el panorama de amenazas y tecnología están ejerciendo tanta presión sobre los programas de pruebas de seguridad en este momento?
Chris Oakley:
Buena pregunta. Los programas de pruebas suelen tener dificultades para mantenerse al día, y la respuesta honesta radica en la frecuencia y la cobertura. Muchos programas se basan en evaluaciones puntuales. Se completa el ciclo de pruebas, se corrigen los errores y se vuelve a probar a los 12 meses. Sin embargo, el entorno probado en enero puede ser ligeramente diferente, o incluso completamente distinto, en marzo o abril.
Observamos con frecuencia que las organizaciones confían en lo que se probó, pero tienen poca visibilidad de los cambios posteriores. Repetir las pruebas es otro punto débil. Consume mucho tiempo y a menudo se le resta prioridad cuando hay mucha demanda de consultores. La cobertura también puede ser una brecha silenciosa. Siempre hay más alcance que presupuesto, por lo que se toman decisiones sobre qué se prueba y qué no, y ahí es donde el riesgo comienza a acumularse rápidamente.
Las pruebas de penetración con IA abordan directamente estas brechas. Ofrecen ciclos de pruebas más frecuentes, repeticiones de pruebas más rápidas tras la corrección de errores y una mayor cobertura sin aumentar proporcionalmente el coste.
Josh Flanagan:
Gracias, Chris. Son puntos muy interesantes. Si profundizamos un poco más, ¿en qué aspectos suelen tener dificultades los programas de pruebas para mantenerse al día, incluso cuando los equipos hacen lo correcto?
Chris Oakley:
Actualmente, confluyen tres factores. La superficie de ataque se está expandiendo a un ritmo vertiginoso. Existen API en la nube, integraciones con terceros e incluso TI en la sombra. El perímetro tradicional ya no existe como antes, al menos no de forma significativa.
Además, los ciberdelincuentes están adoptando la IA para actuar con mayor rapidez. Se mueven más rápido, iteran con mayor agilidad y, a menudo, encuentran vulnerabilidades antes que los proveedores. A esto se suma que el entorno regulatorio también se está volviendo más estricto. Ya sean requisitos de divulgación, de pruebas u obligaciones contractuales, a muchas organizaciones se les exige que demuestren su nivel de seguridad con mayor frecuencia y rigor.
Por lo tanto, hay más que proteger, amenazas más rápidas y una mayor responsabilidad. Esta combinación está ejerciendo una gran presión sobre los programas de pruebas de seguridad diseñados para una época diferente
Josh Flanagan:
Gracias, Chris. Ahora me dirijo a ti, Dave. Por lo que Chris comentaba, queda claro que las cosas han cambiado mucho últimamente. Desde tu perspectiva, cuando la gente oye hablar de pruebas de penetración con IA, ¿qué suponen que es y qué debemos corregir desde el principio?
Dave Parsons:
Gracias, Josh. Cuando la gente oye hablar de pruebas de penetración con IA, suele pensar en dos cosas: o bien se trata de un escáner automatizado con una nueva etiqueta, o bien es un sistema que afirma hacerlo todo y reemplazar por completo al consultor humano. Creo que ninguna de estas suposiciones es del todo correcta.
Lo que realmente estamos intentando crear, y lo que representa, es una capacidad de IA eficaz, moldeada por la experiencia operativa de LRQA. Hemos colaborado estrechamente con Simbian en el diseño de la herramienta, incorporando décadas de experiencia en pruebas de penetración realizadas por consultores a su funcionamiento.
Esto no es poca cosa. La diferencia fundamental con una herramienta de escaneo tradicional es que esta verifica mediante la explotación, en lugar de la detección basada en firmas. No se limita a señalar posibles problemas, sino que confirma que esos problemas son reales, y esa decisión surgió directamente de la metodología de trabajo de nuestros consultores. Es la diferencia entre una herramienta creada por personas que entienden cómo son las buenas pruebas de penetración y una que no. No pretendemos replicar un escáner con esta herramienta. Estamos intentando replicar lo que haría un ser humano.
El valor añadido de nuestros consultores reside en la contextualización, las vulnerabilidades de la lógica de negocio y su mitigación. Las vulnerabilidades no existen de forma aislada. Su gravedad depende del entorno en el que se encuentran, los datos que afectan y los controles de seguridad que las rodean.
Los clientes seguirán necesitando ese nivel de análisis experto en cuanto a riesgo y contexto, y nos complace proporcionárselo. Nuestros consultores pueden revisar los hallazgos, priorizarlos según el riesgo y traducir los resultados técnicos en directrices de mitigación que las organizaciones puedan implementar.
En definitiva, se trata de una herramienta que mejora el trabajo de nuestros consultores y amplía el alcance de nuestros programas de pruebas, pero nunca pretende sustituir las pruebas de penetración realizadas por consultores.
Josh Flanagan:
Teniendo esto en cuenta, Dave, sería útil explicar cómo funciona el servicio en la práctica. ¿Cómo funciona la prueba de penetración con IA y qué beneficios obtiene un cliente al contratar nuestros servicios?
Dave Parsons:
Desde la perspectiva de la experiencia del cliente, buscamos la máxima simplicidad. Contamos con un portal de clientes al que se accederá a través de él, donde los clientes ya pueden gestionar sus actividades de aseguramiento de la seguridad. La capacidad de pruebas de penetración con IA, proporcionada mediante la colaboración con Simbian, está integrada directamente en ese entorno.
No es necesario gestionar ni configurar una plataforma independiente. Una vez dentro de la plataforma, los clientes pueden ejecutar pruebas de forma autónoma, sin tener que esperar a que se programe un consultor. Pueden iniciar las pruebas cuando les resulte relevante, ya sea después de un lanzamiento, tras la corrección de vulnerabilidades o como parte de un ciclo de pruebas regular.
El resultado es donde esta herramienta se diferencia realmente de las herramientas de escaneo tradicionales. Los clientes recibirán informes de pruebas de penetración lo más parecidos posible a los informes elaborados por un consultor humano, con hallazgos estructurados, contexto de riesgo y capturas de pantalla que documentan con precisión lo que la herramienta observó.
No se trata de una herramienta de escaneo tradicional que proporciona un volcado de vulnerabilidades sin procesar. Es una herramienta que realmente facilita la toma de decisiones.
Dos de las funciones que más nos gustan y que queremos destacar son, en primer lugar, el botón de repetición de pruebas. Una vez detectadas y corregidas las vulnerabilidades, el cliente puede validar la corrección al instante, sin tener que esperar a que intervenga un consultor. Esto agiliza considerablemente el proceso en comparación con los ciclos de repetición de pruebas tradicionales.
En segundo lugar, la plataforma incluye el seguimiento del razonamiento de la IA. Este seguimiento muestra el proceso de razonamiento detrás de cada hallazgo, cómo la IA llegó a una conclusión, qué pruebas realizó y qué ruta siguió. Esta transparencia es fundamental, ya que proporciona a nuestros consultores el contexto necesario para validar los hallazgos cuando sea preciso, y también genera confianza en los clientes, quienes pueden ver qué hizo la herramienta y cómo llegó a sus conclusiones.
Josh Flanagan:
Gracias por la descripción, Dave. Es una información muy útil sobre cómo funciona. Voy a hablar contigo a continuación, David, porque sería interesante saber, desde la perspectiva de Simbian, qué sucede internamente cuando se ejecuta una prueba.
David Greene:
Excelente pregunta, Josh. Lo que intentamos hacer, basándonos en los comentarios de Dave, fue lograr que el agente de IA se comportara como lo haría un probador de penetración humano, siguiendo un flujo de trabajo y una metodología muy similares.
Para quienes estén considerando esta solución, pueden pensar en el agente de IA como un miembro más del equipo. Hay un paso inicial en el que un humano especifica el objetivo, el alcance y el nivel de las pruebas necesarias, y luego el agente comienza su trabajo.
El primer paso es el mapeo autónomo, donde el agente escanea la aplicación utilizando las URL y las credenciales proporcionadas, identifica los componentes de la aplicación, inicia sesión y explora su funcionamiento.
Luego, pasa a un proceso de descubrimiento adaptativo. Este proceso verifica si hay fallos en la lógica de la aplicación, el flujo de trabajo entre pantallas y cómo los procesos se mueven de una parte de la aplicación a otra. Este descubrimiento adaptativo se basa en el contexto, en la información que el agente tiene sobre el entorno y las aplicaciones. A medida que los clientes realizan más pruebas, ese contexto se vuelve más útil para guiar la prueba de penetración.
A partir de ahí, el tercer paso es la explotación y validación. El agente intenta activamente explotar las vulnerabilidades que ha identificado. Todo esto se documenta exhaustivamente y la transparencia es fundamental. Capturamos información como capturas de pantalla como evidencia de lo que se encontró.
Todo esto se incluye en un informe. En el cuarto paso, presentamos una guía detallada para la corrección. El objetivo es proporcionar a los desarrolladores suficiente información para que puedan reproducir el problema por sí mismos. El agente documenta sus pasos exactos, de modo que un desarrollador pueda seguirlos y comprobar la vulnerabilidad.
El agente también evalúa el riesgo potencial en función de la vulnerabilidad específica y de fuentes de datos más amplias del mercado, para determinar si algo tiene una prioridad alta, media o baja.
Una vez definidos los pasos de corrección, también existe la opción de integrarlos en un sistema de gestión de casos, de modo que el agente pueda trabajar con cualquier herramienta que se utilice para el seguimiento. Todo esto se registra en un conjunto de métricas que muestran el rendimiento general del programa.
En resumen, nuestro objetivo es replicar el proceso que seguiría un humano al realizar una prueba de penetración, pero de forma autónoma y automática. Normalmente, todo esto se puede completar en cuestión de horas, en lugar de los días o semanas que requeriría una prueba de penetración realizada por un humano.
Josh Flanagan:
Siguiendo con eso, David, ¿cuáles son los controles clave que te gustaría que un responsable de seguridad comprendiera para que tuviera la seguridad de que la herramienta se está utilizando de forma responsable?
David Greene:
Otro tema crucial, Josh. En este aspecto, hemos recibido una excelente orientación del equipo de LRQA, quienes están acostumbrados a trabajar en entornos seguros.
Cuando les digo a las personas que mi agente intentará hackear su aplicación, es comprensible que se pongan un poco nerviosas. Por eso, hemos establecido algunas medidas de seguridad importantes para el funcionamiento del agente.
La primera es cómo utilizamos los modelos de lenguaje grandes. Todo el trabajo con modelos de lenguaje grandes (LLM) realizado por el agente utiliza instancias privadas de los modelos. En ningún momento se utilizan ni se comparten datos de clientes en modelos públicos, ni se utilizan para entrenar LLM públicos. Se trata de un entorno restringido y limitado, utilizado exclusivamente para este propósito.
Otro aspecto que hemos intentado lograr es generar confianza manteniendo la transparencia en el trabajo del agente. Puedes ver lo que el agente está haciendo. Puedes decidir por ti mismo si actuó correctamente y puedes proporcionarle comentarios.
Si en algún momento el agente interrumpe el funcionamiento de una aplicación, puede detenerlo inmediatamente.
También hemos integrado un conjunto completo de capacidades de seguridad empresarial. Esto incluye la integración con sistemas SSO, la aplicación de los controles de acceso existentes en el entorno y la segregación total de datos cuando varias organizaciones o unidades de negocio realizan pruebas. Todos los datos están cifrados en el sistema, tanto en reposo como en tránsito.
Además, podemos implementar la solución en diferentes geografías y regiones si existen requisitos de cumplimiento específicos en cada región; por ejemplo, si todos los datos deben permanecer en la UE o en Oriente Medio.
Estas son algunas de las medidas que hemos tomado para garantizar que pueda confiar en la herramienta, tener seguridad en sus resultados y no preocuparse por el destino de sus datos. Asimismo, respaldamos todo esto mediante acuerdos contractuales, ya sean acuerdos de procesamiento de datos, acuerdos de seguridad o cláusulas de confidencialidad.
Josh Flanagan:
Ahora vuelvo contigo, Dave. Una vez que la gente entiende la mecánica de lo que las pruebas de penetración con IA pueden hacer y cómo funcionan, la siguiente pregunta que solemos escuchar de los clientes es cómo pueden confiar en los resultados y actuar en consecuencia. ¿Cómo se garantiza la credibilidad y utilidad de los resultados, y qué papel desempeñan los expertos en LRQA en la revisión y validación de los hallazgos?
Dave Parsons:
Desde el principio, cuando iniciamos la conversación con Simbian, tuvimos muy claro que la confianza en los resultados era lo más importante. Era prácticamente innegociable, y eso influyó en el diseño de la herramienta.
Esto implicó alejarnos de las herramientas de escaneo tradicionales que solemos ver. La mayoría de los escáneres funcionan mediante la detección basada en firmas, buscando patrones asociados a vulnerabilidades conocidas. La plataforma de Simbian está diseñada para verificar mediante la explotación. No se limita a señalar un posible problema, sino que intenta confirmar su existencia. Solo esto reduce significativamente el problema de los falsos positivos, que dificulta el análisis de los resultados de los escaneos tradicionales.
Además, hemos trabajado intensamente en el desarrollo de mecanismos de validación y sistemas de puntuación para filtrar el ruido antes de que los resultados lleguen al cliente. Los resultados que reciben los clientes ya han pasado por un proceso de control de calidad. No se trata simplemente de una lista sin procesar que requiere una revisión exhaustiva.
Aquí es donde entran en juego nuestros consultores de LRQA. Este soporte está disponible bajo petición. Los clientes pueden escalar los hallazgos para su revisión, para obtener contexto adicional, para priorizar riesgos, para recibir asistencia en la remediación o simplemente para obtener ayuda para comprender los resultados de la herramienta de pruebas de penetración de Simbian.
Esto significa que no tenemos que revisar cada hallazgo como paso obligatorio, lo que mantiene el servicio ágil y rentable, al tiempo que garantiza la supervisión experta donde realmente se necesita.
El rastreo de IA también respalda este proceso. Cuando un consultor realiza una revisión, puede ver la prueba de concepto de la herramienta de Simbian y la lógica que la sustenta. Por lo tanto, la credibilidad de los resultados no depende únicamente de la revisión humana. Está integrada en la herramienta desde su concepción, y hemos trabajado extensamente en ello. Tenemos mucha confianza en los resultados y en que los clientes puedan confiar en ellos.
Josh Flanagan:
Genial. Voy a incluir a Chris de nuevo en esto. Hemos hablado bastante sobre la confianza y la gobernanza en las preguntas anteriores, y creo que lo hemos hecho porque, para la mayoría de los compradores, ahí es donde se toma la decisión. ¿Por qué debería un comprador confiar en LRQA para ofrecer pruebas de penetración con IA como parte de su programa?
Chris Oakley:
Tienes toda la razón, Josh. La confianza es fundamental. En este contexto, la confianza proviene tanto de la trayectoria y la gobernanza como de la tecnología.
En LRQA, llevamos décadas ofreciendo servicios de aseguramiento, incluyendo servicios de seguridad ofensiva como pruebas de penetración y ejercicios de red teaming. Entendemos cómo deben ser las pruebas de seguridad responsables. Comprendemos las estructuras de rendición de cuentas y las necesidades de los clientes cuando algo se ejecuta en sus entornos.
Estos son factores cruciales. No nos limitamos a añadir IA a un servicio, darlo por terminado y lanzarlo. Lo que hicimos fue diseñar esta nueva capacidad con la misma rigurosidad que aplicamos en el trabajo tradicional dirigido por consultores.
Mantenemos un alcance definido, una ejecución controlada, registros de evidencia claros y supervisión experta en cada etapa.
Los compradores no solo adquieren acceso a una herramienta. Se involucran con nuestro marco de aseguramiento en su totalidad. Esto significa que hay un socio responsable designado. Llevamos mucho tiempo haciendo esto. Somos responsables. No somos solo una plataforma impersonal.
Esa distinción es muy importante cuando las pruebas afectan a los sistemas de producción desde una perspectiva de confianza y seguridad.
Josh Flanagan:
Gracias, Chris. Estoy de acuerdo contigo en esto también. ¿Hay algún aspecto innegociable que te venga a la mente, algo que consideramos al desarrollar esto con Simbian y en lo que simplemente no estaríamos dispuestos a ceder?
Chris Oakley:
Sí, sin duda. Hay ciertas cosas sin las que simplemente no podríamos salir al mercado.
La seguridad es primordial. Nos regimos por el principio de no causar daño. Esto significa que no debe ejecutar nuestra herramienta y encontrar impactos en la disponibilidad o integridad del sistema bajo prueba. Esto es fundamental para nosotros.
Como parte de esto, el control del alcance se incluye dentro del mismo marco de seguridad. La prueba se ejecutará exactamente según lo acordado. Se ejecutará con respecto a lo que usted solicite y nada más allá de esos límites. Se mantendrá dentro del alcance en todo momento.
También hay otros aspectos innegociables, como la confidencialidad. Los datos del cliente se mantienen dentro de los períodos de retención acordados y se manejan con el mismo rigor que aplicamos a cualquier proyecto sensible.
La evidencia y la rendición de cuentas también son fundamentales. Cada hallazgo debe tener un registro de auditoría claro. ¿De dónde proviene? ¿Cuáles fueron los pasos para llegar a la conclusión? ¿Por qué existe? Los clientes quieren saber qué se ejecutó, cuándo se ejecutó y por qué.
Luego, más que en materia de gobernanza, y más en cuanto a la eficacia del producto, la consistencia también era fundamental. Una vez que se han resuelto los aspectos de seguridad, la pregunta es si se mantiene la consistencia. Si se realiza la misma prueba varias veces, ¿se obtienen resultados muy diferentes o un conjunto de resultados comparables?
Esto puede ser difícil con las tecnologías de IA, ya que son no deterministas por naturaleza, pero hemos dedicado mucho esfuerzo a garantizar la consistencia, e incluso a lograr que supere la consistencia que se podría obtener entre dos evaluadores humanos diferentes.
Josh Flanagan:
David, aprovechando esta pregunta, ¿qué sucede con los datos de los clientes durante una prueba? ¿Dónde se almacenan, cuánto tiempo se conservan y se utilizan para mejorar los modelos?
David Greene:
El punto de partida es lo que Chris acaba de mencionar. Respetamos los plazos de retención y las directrices de gestión de datos que LRQA ya tiene establecidas. Esa es la base del agente.
Luego, añadimos capas adicionales debido a la presencia de IA. Todo el procesamiento de datos se realiza dentro de la región geográfica especificada por el cliente para cumplir con los requisitos de cumplimiento normativo. Esto incluye el uso de los propios modelos de lógica descriptiva (LLM).
Los datos que se envían a los LLM se procesan únicamente dentro de instancias privadas de dichos modelos. Nunca se utilizan como datos de entrenamiento. Lo último que se desea es que un LLM se entrene con las vulnerabilidades del cliente, por lo que esto nunca sucede.
Los resultados que se presentan en la interfaz del producto se rigen por los mismos controles de acceso que existen para otros productos de LRQA. Como cliente, usted decide quién puede ver esa información, cuándo puede verla y durante cuánto tiempo permanece disponible.
Todo esto se basa en lo que Simbian denomina nuestra arquitectura LLM de confianza, donde mantenemos una capa aislante entre los datos del cliente y los propios LLM. El software Simbian se sitúa entre ambos, evalúa qué información debe enviarse, la divide para mantenerla segura y minimiza la cantidad de datos que deben transmitirse.
Todo esto contribuye a que obtengamos el máximo provecho de la información generada por la IA sin exponer los datos de los clientes. Reiteramos que estaremos encantados de ofrecer garantías contractuales si los clientes las necesitan para cumplir con sus propios requisitos de cumplimiento normativo.
Josh Flanagan:
Dave, y basándonos en lo que Chris y David han compartido, ¿cómo se ve ahora una operación segura en la práctica, especialmente al realizar pruebas en entornos de producción? ¿Hay alguna situación en la que desaconsejarías su uso en producción?
Dave Parsons:
Sí, sin duda. Esta es otra área donde hemos aplicado directamente nuestra experiencia en pruebas de penetración. Los incidentes se producen al ejecutar herramientas automatizadas en entornos de producción sin los controles adecuados. Llevamos años viendo las consecuencias de esto en todo el sector, y eso influyó en cómo abordamos la arquitectura de seguridad de Simbian.
En la práctica, la plataforma opera en dos modos. Tiene un modo seguro, diseñado específicamente para entornos de producción, que limita las acciones de la herramienta. Limita la agresividad de las pruebas y las acciones que puede realizar. También proporciona un informe impreso de las operaciones que no se realizaron debido al modo seguro, para que se puedan apreciar claramente las ventajas y desventajas.
Para la mayoría de los clientes, especialmente aquellos en sectores regulados o con menor tolerancia al riesgo, esta es la opción correcta. También contamos con un modo estándar para entornos aislados o que no son de producción. En este modo, se pueden eliminar esas restricciones y la herramienta puede comportarse de forma más invasiva. Esto implica realizar acciones como ejecutar ataques de inyección, extraer el contenido de bases de datos, descifrar hashes y demostrar una cadena de ataque completa de principio a fin, de forma similar a como lo haría un atacante humano en una prueba de penetración.
Este nivel más profundo de validación ofrece una visión mucho más clara de lo que un atacante real podría hacer. Estamos aquí para ayudar a tomar decisiones sobre qué modo es el más adecuado para cada entorno, teniendo en cuenta la sensibilidad de los datos involucrados, el posible impacto en caso de que algo salga mal y el objetivo general de la prueba.
En la gran mayoría de los casos, el modo seguro es precisamente eso: una reducción segura. Pero, como en cualquier actividad de prueba, siempre hay entornos donde conviene hablar primero. Si se trata de una infraestructura crítica de alta disponibilidad o que maneja información personal especialmente sensible, es una buena práctica comprender exactamente qué está incluido en el alcance, cuáles son las medidas de seguridad y qué expectativas deben establecerse.
Esto no difiere de cómo abordaríamos cualquier proyecto dirigido por un humano. El sentido común sigue siendo fundamental, y así es como hemos abordado toda la implementación.
Josh Flanagan:
Perfecto, gracias Dave. Ahora te toca a ti, Chris, para concluir. Según las primeras conversaciones con los clientes y los comentarios que hemos recibido hasta ahora sobre la herramienta, ¿qué es lo que más ha impactado y qué nos indica esto sobre el futuro de las pruebas de seguridad?
Chris Oakley:
Buena pregunta. Es evidente que existe un gran interés en esta tecnología en diversos sectores. La realidad es que las pruebas están cambiando y seguirán haciéndolo.
No creo que los pentesters humanos vayan a desaparecer pronto. Lo que probablemente cambie rápidamente es la forma en que realizan su trabajo.
Observamos que muchos clientes responden positivamente a la idea de la garantía continua. Les resulta atractiva. Entienden que las pruebas de seguridad son más que un evento anual con un largo intervalo entre ellas. Las primeras conversaciones giran constantemente en torno a un tema similar: los clientes saben que sus entornos están cambiando, que las pruebas puntuales tienen una vida útil limitada y que cuentan con presupuestos limitados.
Lo que buscan es una solución que les permita cubrir ese período de tiempo de forma más eficaz, dentro de un presupuesto realista. También existe un gran interés por ciclos de validación más rápidos tras la corrección de vulnerabilidades. Los clientes quieren saber, si creen haber solucionado un problema, si pueden confirmarlo rápidamente.
Es una petición sencilla, pero los programas tradicionales a menudo tienen dificultades para satisfacerla. Todavía nos encontramos con situaciones en las que se especifica un día para las pruebas de validación en los programas tradicionales, lo cual no se ajusta a la forma en que funcionan el desarrollo de software moderno y la evolución de los sistemas.
Para mí, esto indica que los compradores consideran cada vez más la garantía de seguridad como una capacidad continua, en lugar de un proyecto único o periódico. Las pruebas de penetración con IA encajan perfectamente en este modelo.
Estoy bastante seguro de que este cambio se acelerará en los próximos uno o dos años. Dentro de un par de años, las pruebas de penetración tradicionales, tal como las conocemos, probablemente serán muy diferentes, y la forma en que las organizaciones las abordan será significativamente distinta a la actual.
Josh Flanagan:
Gracias, Chris. Es una excelente manera de concluir el programa, y con esto finaliza el episodio de hoy.
Gracias a todos nuestros invitados por la conversación y gracias a todos por escuchar. Hoy presentamos Pruebas de Penetración con IA, una nueva solución de LRQA diseñada para ayudar a las organizaciones a mantener sus pruebas de seguridad alineadas con el ritmo del cambio, conservando la gobernanza y la credibilidad que caracterizan a LRQA.
Si desea obtener más información, visite LRQA.com y no dude en contactarnos.
Gracias por escucharnos y nos vemos en el próximo episodio.