Introducción
Más allá del escaneo de vulnerabilidades
¿Cómo puede detectarse con precisión la exposición de un sistema a ciberataques exitosos? Esto no es posible únicamente mediante el escaneo de vulnerabilidades. Las pruebas de seguridad realizadas por pentesters (i.e., pentesting) siguen siendo necesarias. Aunque las herramientas automatizadas se han vuelto indispensables para identificar vulnerabilidades potenciales debido a su potencia y velocidad de procesamiento, presentan altas tasas de falsos positivos y falsos negativos, y suelen encontrar menos de la mitad de la exposición al riesgo de las aplicaciones. Parte de la razón de esto es que las herramientas no pueden detectar vulnerabilidades cuando su descubrimiento implica un uso complejo e inesperado de los productos de software por parte de un usuario externo. Aquí es donde entra en juego la experiencia de los pentesters.
Reconociendo de antemano, por nuestra experiencia empresarial, la superioridad del pentesting sobre el escaneo de vulnerabilidades (ambos parte del espectro de application security testing, AST), tratamos de confirmar esta idea con un estudio en el que incluimos múltiples herramientas de terceros, no sólo la nuestra. Inicialmente definimos un objetivo de evaluación y, a continuación, algunas herramientas para probar. Prestamos atención a sus resultados, incluidos los verdaderos positivos, los falsos positivos y los falsos negativos, y determinamos los F-scores. Además de destacar las vulnerabilidades identificadas, hicimos hincapié en la exposición al riesgo (CVSSF) detectada.
CVSSF es una métrica que establecimos para superar las limitaciones de la puntuación CVSS, como la segmentación, la agregación y la comparación, y para contribuir mejor a la priorización de vulnerabilidades. Por ejemplo, diez vulnerabilidades de severidad 1,0 no equivalen a una vulnerabilidad de severidad 10,0. A partir de la ecuación CVSSF = 4 ^ (CVSS - 4), podemos determinar valores con diferencias mucho más marcadas que reflejen mejor la realidad de los riesgos. Así, para las vulnerabilidades del ejemplo, los resultados en unidades de CVSSF serían 0,2 (i.e., 10 x 0,02) y 4.096 (i.e., 1 x 4.096), respectivamente.
Metodología
Medición de la precisión en la detección de vulnerabilidades
FECHA DE INICIO
2023
Diciembre
Evaluadores
36 herramientas de terceros* (código abierto o demo/prueba gratuita) para SAST, DAST y/o SCA (algunas de estas herramientas están incluidas en el Cuadrante Mágico de Gartner)
Herramienta de Fluid Attacks para SAST, SCA y DAST (de ahora en adelante, "nuestro escáner")
Pentester de Fluid Attacks
Objetivo de evaluación (ToE*)
Una aplicación web moderna, realista y vulnerable por defecto con las siguientes características:
Modelo-vista-controlador (MVC)
Aplicación de una sola página (SPA)
API RESTful
En NodeJS, principalmente con TypeScript
*Por motivos de seguridad y confidencialidad, los nombres de las herramientas y ToE fueron anonimizados (las herramientas siguen un orden alfabético de la "A" a la "Z" y de "AA" a "AJ").
Universo de vulnerabilidades
Nuestro equipo (escáner y pentester) detectó 93,9% del universo de vulnerabilidades (UV); algunas herramientas externas identificaron el el porcentaje restante.
1.201
vulnerabilidades
105
categorías CWE
461.500
unidades CVSSF
80%
en el código base, 13% en el backend y el resto en dependencias y frontend.
73,2%
requirió autenticación.
Análisis de datos
A partir de los verdaderos positivos (VP) y los falsos positivos (FP), determinamos los valores de "precision" ("¿cuántos elementos identificados son relevantes?") y "recall" ("¿cuántos elementos relevantes son identificados?"):
A continuación, establecimos relaciones entre estas dos variables mediante el F-score:
Fᵦ = (1 + β²) · {[precision · recall] / [(β² · precision) + recall]}
F1 es la media armónica de ambas variables, mientras que F0,5 da más importancia a precision que a recall, y F2 da más importancia a recall que a precision.
Resultados
Replanteando la evaluación de seguridad
Top 10 para VPs, "precision" y "recall"
*Este valor no es 125 (valor necesario para completar, en suma con los VPs, el UV) porque en la metodología definimos que el pentester no revisaría secciones ya evaluadas por nuestro escáner.
**En esta tabla sólo figuran, además del pentester, las herramientas que ocuparon el top 4 en las métricas resaltadas.
La herramienta que identificó el mayor porcentaje de vulnerabilidades (i.e., nuestro escáner) detectó el 22,7%, lo que corresponde sólo al 8,8% de la exposición al riesgo (CVSSF) total del ToE.
Entre las herramientas de esta tabla, nuestro escáner estuvo muy cerca del pentester en FPs, con solo tres. De todas las herramientas que detectaron al menos 50 vulnerabilidades, esta fue la que obtuvo la mejor precision; de hecho, esas otras seis herramientas tuvieron un promedio de alrededor de 130 falsos positivos.
Mientras que los mejores valores de recall entre las herramientas automatizadas evaluadas se situaron entre el 21% y casi el 23%, la media de recall entre las otras 34 herramientas fue de un pésimo 1,7%. De hecho, 17 herramientas no identificaron ni siquiera diez vulnerabilidades de las 1.201 presentes en el ToE.
Aún más sorprendente es el recall en términos de CVSSF. Como hemos dicho, la mejor herramienta ni siquiera alcanzó el 9%. Aún así, si tomamos todos los porcentajes alcanzados por las 37 herramientas, suponiendo que son valores correspondientes a conjuntos que no se intersectan y que se pueden sumar, ni siquiera acumularían el 60% de la exposición al riesgo total del ToE. Mientras tanto, ¡el pentester consiguió detectar casi el 99%!
Además, 743 de las 1.201 vulnerabilidades, es decir, el 61,9% del UV, fueron detectadas exclusivamente por el pentester en las pruebas manuales, lo que corresponde al 86,8% de la exposición al riesgo total.
Top 5 para F-scores (CVSSF)
Todos los F-scores (CVSSF) del pentester superaron el 99%.
Aunque los F-scores (CVSSF) de nuestro escáner siempre estuvieron por delante de los de las demás herramientas, eran muy bajos en comparación con los F-scores del pentester. Su mejor resultado fue un F0,5 score (CVSSF) de 32,6%, un valor que da más relevancia a precision que a recall. Aunque este F0,5 representó casi un tercio de lo obtenido por el pentester, duplicó el F0,5 promedio de las diez herramientas siguientes en ese top.
Los F2 scores (CVSSF) fueron consistentemente inferiores a los F0,5 scores (CVSSF). Las medias de estos dos valores para todas las herramientas automatizadas fueron del 1,9% y el 6,3%, respectivamente, lo que refleja la preponderancia de precision sobre recall.
F0,5 vs F1 vs F2 scores (CVSSF)
El tamaño de la burbuja representa la magnitud del F1 score (CVSSF). Cuanto más cerca esté una herramienta del cuadrante superior derecho, mejor es su rendimiento.
Tiempo de ejecución por evaluador
La diferencia entre los tiempos de ejecución del pentester y las herramientas automatizadas es abrumadora. Si sumamos los tiempos recogidos para las herramientas (no pudimos registrar tiempos para ocho de ellas), encontramos que el total no llega ni al 2% del tiempo empleado por el pentester (49 días). Su tiempo promedio fue de 2.652 segundos (i.e, algo más de 44 minutos). De ahí la importancia que solemos conceder al escaneo de vulnerabilidades (i.e., pruebas de seguridad mediante herramientas automatizadas).
No se encontró ningún patrón al comparar los F-scores con los tiempos de ejecución. Por ejemplo, lo ideal sería que, a medida que aumentan los tiempos de evaluación del ToE, crecieran los F1 scores de las herramientas. Pero si tomamos como punto de referencia central el F1 score de 37% logrado por nuestro escáner en 429 segundos, encontramos que a su derecha, con tiempos de ejecución más cortos, el F1 promedio fue de 3,5%, mientras que a su izquierda, con tiempos de ejecución más largos, el F1 promedio fue de 2,3% (ambos lados con casi el mismo número de herramientas).
Conclusiones
Lo ideal es combinar pruebas automatizadas con pruebas manuales
Las herramientas automatizadas son bastante rápidas a la hora de evaluar la seguridad de las aplicaciones, pero sus tasas de falsos positivos suelen ser altas, aunque no tanto como sus tasas de falsos negativos.
Los valores de precision y recall del pentester son mucho más altos, pero requieren una inversión de tiempo mucho mayor. Sin embargo, esto puede cambiar considerablemente cuando el ToE es evaluado por todo un equipo de pentesters y no solo por un experto (como fue el caso de este estudio).
Múltiples vulnerabilidades de seguridad pueden pasar desapercibidas a las herramientas automatizadas, por lo que complementar su trabajo con pruebas manuales continuas es indispensable. Pero no se trata sólo de detectar un mayor número de vulnerabilidades sino, sobre todo, de descubrir aquellas que, a menudo más complejas, representan los riesgos más críticos para las organizaciones y sus usuarios.
Una buena herramienta proporcionará rapidez y resultados aceptables desde el principio del ciclo de vida de desarrollo de software, pero el pentesting continuo aumentará significativamente la precisión de las pruebas de seguridad de las aplicaciones. Por este motivo, lo mejor para una empresa responsable con una postura de seguridad madura es trabajar con ambos.
Aunque este estudio se limitó a un único ToE, Fluid Attacks continuará con este tipo de investigación. Pronto añadiremos nuevos objetivos que nos permitirán seguir insistiendo en la necesidad de integrar herramientas con humanos.
Fluid Attacks ofrece una solución ASPM integral que permite a sus clientes identificar, priorizar y remediar vulnerabilidades de seguridad en sus productos a lo largo del SDLC. Las pruebas de seguridad se llevan a cabo mediante herramientas automatizadas, IA y un equipo de pentesters, reportando en una única plataforma con diversas integraciones, lo que facilita la gestión de vulnerabilidades basada en riesgos. La GenAI apoya la remediación de vulnerabilidades y los expertos ayudan a comprender problemas complejos, lo que contribuye significativamente a acelerar la mitigación de la exposición al riesgo de las empresas y a reforzar su postura de ciberseguridad.
