Este artículo fue publicado por Hamid Kashfi en X
Durante los últimos 22 años, he llevado a cabo un amplio número de pruebas de penetración y auditorías (más de 400 proyectos), así que tengo algo de experiencia en el tema. Sin embargo, sigo creyendo que las pruebas de penetración automatizadas están obsoletas, aunque no de la manera que podrías pensar. Empecé a escribir un borrador extenso, pero finalmente decidí dejar que Gemini lo resumiera y mejorara, ¿por qué no?
¿Por qué las pruebas de penetración automatizadas están obsoletas?
Estas herramientas se han vuelto obsoletas, al igual que hace una década lo eran las herramientas automatizadas como Nessus y Core Impact con sus informes de 50 páginas. La nueva era de automatización impulsada por IA está reviviendo un enfoque de bajo valor.
No estoy en contra de la IA; con el tiempo mejorará. Yo mismo gasto más de 1.000 dólares al mes en tokens. Actualmente, la IA tiene muchas aplicaciones, pero aún no es escalable para pruebas de penetración eficientes. No se debe solo al costo de los tokens (que caerán) o a la fiabilidad de los modelos (que mejorarán; XBow es un ejemplo). Hay razones más complejas.
1. El ruido y la fatiga
Así como en el pasado se ignoraban informes con numerosas vulnerabilidades válidas, ahora el ruido generado por la IA también será desestimado. Un informe típico puede tener 2 o 3 hallazgos clave, pero pronto los agentes de IA analizarán a fondo las redes y generarán 100 problemas serios y válidos.
Si llevas cinco años realizando pruebas a clientes de grandes corporaciones y obtienes resultados similares repetidamente, sabes lo que digo. Priorizar las correcciones genera fatiga y revela que lo que ofrecemos (hacking, pruebas, seguridad) no es la prioridad para las grandes empresas; es más bien una obligación, usualmente por temas de cumplimiento.
No juzgues a un CISO que archiva un informe lleno de vulnerabilidades rojas y corrige solo cinco al día siguiente o durante meses. Tu «hallazgo crítico» es simplemente una decisión de negocio.
Su lógica es: «¿Nos costará un millón de dólares si se explota?». Si la respuesta es no, no se categoriza ni se gestiona como crítico, ya que esto desencadenaría procesos internos que consumen tiempo y dinero.
En muchos casos, la ineficiencia de las pruebas de penetración no radica en la falta de pruebas, sino en la falta de una verdadera prioridad empresarial. No necesitas una prueba de concepto para abordar esto.
Acceder a una shell en un sistema que no es crítico para el negocio no lo convertirá automáticamente en una prioridad. Las startups de pruebas de penetración automatizadas con IA hacen grandes promesas; logran generar accesos constantes, pero no resuelven los problemas que ya se han abordado con métodos tradicionales.
2. El verdadero cuello de botella
La industria de la seguridad ha empezado a ofrecer a sus clientes un alivio del ruido generado por las pruebas automatizadas, enfocándose en una investigación manual exhaustiva. Lo normal ahora es entregar solo un puñado de hallazgos realmente relevantes, en vez de detalles como la falta de una cabecera HSTS.
No espero que esta nueva ola de pruebas automatizadas con IA reviva informes como los de Nessus o Core Impact; solo será más precisa. Ya hemos vivido la fase centrada en la detección automática y la validación basada en exploits. No digo que estamos dirigidos al mismo resultado, pero se parece demasiado.
Es mucho más eficaz y entretenido que un script de Python con un simple bucle IF para decidir si se debe explotar un exploit. Eso no significa que debamos dejar de buscar y notificar usando este método. No obstante, el principal problema no es la precisión de los resultados, sino que los que manejan estas automatizaciones no se han adaptado de la misma manera que las herramientas. No importa cuántos problemas críticos se detecten; siguen siendo gestionados por personas que los tratan caso a caso.
3. La ineficiencia de las pruebas de caja negra
Generar 50 hallazgos válidos con Nessus o Burp Scanner hoy resulta ineficiente. Una prueba de caja negra inherentemente no encuentra ni reporta problemas en su fuente, solo síntomas que se repiten. ¿Has revisado las plataformas de gestión de vulnerabilidades como Qualys o Tenable? La imagen no es agradable; esos son los resultados típicos de las pruebas de penetración automatizadas.
Siempre que repitas una prueba de caja negra, descubrirás problemas nuevos y recurrentes. ¿No me crees? Pregúntale a Fortinet, que publica parches mensuales para vulnerabilidades básicas de SQLi y CMDi desde hace años.
Estos problemas son detectados y explotados por tus APT favoritos que no comparten sus hallazgos. Fortinet no es un caso único. Si la solución fuera simplemente automatizar, las plataformas de recompensas por errores no prosperarían tanto.
Este criterio de mercado genera grandes beneficios para todos involucrados, explotando la ineficiencia de nuestra industria en solucionar problemas fundamentales.
Si una empresa ha seguido el camino correcto hacia la madurez en seguridad antes de acceder a estas plataformas, ya ha realizado múltiples pruebas de penetración. Aun así, la gente sigue encontrando vulnerabilidades nuevas.
No entremos en el tema de que «ya estábamos al tanto del problema.» Además, si las pruebas automatizadas basadas en IA son tan eficaces y son el futuro (lo serán), surge la pregunta de por qué se les limita en plataformas de recompensas por errores. ¿Es por el ruido? ¿Están monopolizando el mercado para sus propias implementaciones de agentes?
4. La solución eficiente: Ingeniería de seguridad
Entonces, ¿cómo procedemos? La respuesta se encuentra en la ingeniería de seguridad. Pregunta a cualquier consultoría y verás que la mayoría de sus proyectos no son pruebas de caja negra.
Las consultoras suelen preferir auditorías de caja blanca: revisan el código, las configuraciones y la infraestructura en la nube. En esencia, vendemos ingeniería de seguridad como servicio.
El objetivo es maximizar el rendimiento en poco tiempo, típicamente una o dos semanas. No se les contrata para arreglar problemas menores, sino para profundizar en ellos y detectar problemas lógicos o cadenas complejas de problemas.
Curiosamente, los informes centrados en ingeniería de seguridad generalmente no incluyen pruebas de concepto ni demostraciones de explotación. La prueba ya está en el código. La explotación es redundante y consume tiempo sin valor añadido real para el cliente. ¿Para un equipo rojo? Por supuesto. Pero para pruebas de penetración, no tanto.
Por mi experiencia, se encuentran más y mejores vulnerabilidades al leer el código o realizar ingeniería inversa que explorando al azar algo expuesto en la red.
Te enfocas en los componentes clave y localizas la causa raíz. Al detectar un patrón, pasas de informar problemas individuales a describir prácticas inseguras repetitivas.
Si hay tiempo y el cliente lo permite, puedes ofrecer soluciones a largo plazo: una herramienta de fuzzing, consultas CodeQL, recomendaciones para mejorar CI/CD, etc.
Las pruebas de penetración típicas de caja negra, en cambio, se reducen a: parchea tus sistemas, actualiza tus dependencias y sigue las recomendaciones de seguridad. Luego, corrige esto, eso, y varios otros problemas, y estarás bien hasta la próxima prueba.
5. IA + SAST: El verdadero cambio
Aquí es donde las cosas empiezan a ser prometedoras. ¡Nunca hemos sido tan eficientes y razonablemente confiables en el análisis y comprensión del código y la configuración!
Hemos implementado diversas soluciones SAST (Pruebas de Seguridad de Aplicaciones Estáticas) y DAST (Pruebas de Seguridad de Aplicaciones Dinámicas). Aunque estas soluciones han mejorado su escalabilidad, también han incrementado los falsos positivos y la necesidad de recursos humanos para validar los resultados. Herramientas como CodeQL y Semgrep han evolucionado considerablemente y son parte integral de muchos proyectos.
¿Qué distingue al SAST impulsado por IA de las pruebas de penetración automatizadas? En las pruebas de penetración tradicionales, operábamos con una solución que escalaba pero no resolvía causas raíz; solo señalaba síntomas. En el SAST guiado por IA, aprovechamos la naturaleza de pruebas de caja blanca, lo que permite un análisis profundo a un costo y tiempo razonables: identificar causas raíz, variantes y ofrecer soluciones. Aunque aún requiere cierta intervención humana, el valor es enorme.
Empresas como Google y OpenAI utilizan sistemas que consumen gran cantidad de tokens. Muchos han experimentado procesos similares, obteniendo retornos de inversión considerablemente mayores en comparación con el costo de tokens.
Esto contrasta con el enfoque de caja negra: «Tras varias horas de pruebas aleatorias, envié 100 solicitudes para comprobar una inyección SQL. Aquí tienen un enlace a OWASP y una prueba de concepto en Python. Les dejo a ustedes encontrar las otras variantes del problema.»
Con 200 dólares en tokens, puedes optar por ejecutar un agente de caja negra que encontrará errores a ciegas, o invertir el mismo monto y el mismo tiempo para encontrar, clasificar, explotar y reportar vulnerabilidades en el código.
Estos sistemas de alta demanda de tokens crean sus propios cuellos de botella y problemas de ruido. Seguramente has oído o participado en debates sobre FFMPEG versus Google AI. Afortunadamente, ya contamos con una solución (casi) funcional; es menos arriesgado dejar que un LLM haga una solicitud de extracción que manejar la infraestructura de red y posiblemente eliminar datos en el proceso.
Conclusión
Por favor, no te ofendas cuando digo que las pruebas de penetración, en su forma clásica, incluso con la intervención de IA, están obsoletas.
No están completamente muertas. Diferentes enfoques de pruebas seguirán coexistiendo, y las plataformas de recompensas por errores continuarán creciendo. Pero, considerando los resultados y el rumbo de las pruebas SAST y DAST impulsadas por IA, será difícil que el enfoque de caja negra logre alcanzar el mismo nivel de eficiencia e impacto a largo plazo.
En 2025, si aún te preguntas si tu red es vulnerable a ataques, deberías reflexionar sobre ello. La respuesta es SIEMPRE sí. Estarás en mejor posición si te concentras en el CÓMO, analizando cada caso con el método de caja negra. Pero si buscas una solución más eficaz y duradera para identificar y resolver problemas, las pruebas de caja negra probablemente sean uno de los métodos menos eficientes.
Ser consciente de que estamos destinados a experimentar una brecha de seguridad no hace que las pruebas sean irrelevantes. Simplemente sugiere que es mejor enfocarse en lo que sucede después de una brecha y mejorar en ello. ¿SOC impulsado por LLM? ¿XDR que consumen tokens? ¿Usar IA en despliegues con prácticas de seguridad adecuadas? Google ha introducido su Agentic SOC, lo que debería indicar algo sobre la dirección futura.
Me intriga lo que está por venir. No apostaría por agentes LLM que utilicen Nmap y ejecuten payloads al azar hasta que uno funcione. Si pueden identificar automáticamente el objetivo, obtener una copia local para ingeniería inversa, encontrar una vulnerabilidad y luego explotarla (¿Hola, XBow?), me apunto. Pero, pensándolo bien, ¿no se está acercando a la ingeniería de seguridad?
Como un dato adicional, pedí a ChatGPT que revisara la historia de OWASP TOP 10 desde su inicio. Al parecer, las clases de errores cambian de posición, aparecen nuevas, pero nunca desaparecen. ¿Cuántas pruebas de penetración más necesitamos para enseñar a las personas a manejar un ../../.. correctamente?
Fuente: Hamid Kashfi
Con Información de blog.segu-info.com.ar