¿Pueden los resultados de las herramientas DAST (Pruebas de seguridad de aplicación dinámica) ser falsos positivos?

4

Sé que los resultados de Static Application Security Testing (SAST) pueden ser falsos positivos o reales y depende del desarrollador y analista de seguridad decidir qué vulnerabilidad es real según el escenario y el contexto.

¿Lo mismo se aplica a los resultados del análisis DAST?

Hasta ahora, creía que los resultados de las herramientas DAST (Dynamic Application Security Testing) son reales / verdaderos positivos y deben abordarse. ¿Pueden algunos resultados DAST ser falsos positivos también? ¿DAST necesita el mismo tiempo y esfuerzo del desarrollador y analista de seguridad para filtrar falsos positivos?

    
pregunta Puja 10.05.2018 - 01:07
fuente

2 respuestas

3

DAST puede tener absolutamente falsos positivos. Depende de la herramienta que esté utilizando, pero hay algunas que le pueden dar cientos de falsos positivos.

Por ejemplo, una herramienta puede verificar la inyección de SQL insertando una comilla simple y buscando un mensaje de error de SQL, pero un mensaje de error que esté presente no significa necesariamente que exista una vulnerabilidad de inyección de SQL.

Al igual que con SAST, debe verificar que realmente existe una vulnerabilidad antes de programar el tiempo de desarrollo para solucionarlo.

    
respondido por el Brian Williams 10.05.2018 - 05:03
fuente
3

Oh, sí, literalmente, acabo de leer un informe lleno de falsos positivos (saqué un ticket legítimo de un informe DAST de 20 páginas). Y con eso quiero decir que, como en el ejemplo de @BrianWilliams, la herramienta es correcta para informarlos porque pueden ser reales en algunos escenarios, pero se necesita un analista experto para decidir si se aplica o no en este escenario. Algunos ejemplos que vi en la última hora:

  • Por defecto umask demasiado ancho . Mi análisis: irrelevante porque este es un dispositivo IoT donde la aplicación se ejecuta como root de todos modos.
  • X-Frame ClickJacking no está establecida . Mi análisis: irrelevante porque está en páginas web estáticas, no interactivas.
  • Falta la protección CSRF . Mi análisis: incorrecto, una vez que hayas iniciado sesión, el token de autenticación (sin cookie) cuenta, pero la herramienta está buscando a ciegas un encabezado llamado "CSRF".
  • TLS 1.0 está habilitado . Mi análisis: Sí, lo necesitamos por compatibilidad.
  • Partición montada con opciones débiles Mi análisis: irrelevante porque si puedes entrar en el dispositivo para infectar la partición, entonces ya estás dentro del dispositivo ...

Sí, podríamos (y probablemente deberíamos) corregirlos para que sean menos descuidados, pero no son explotables en esta aplicación, por lo que ya no es un problema de seguridad y se acumulan con otras tareas técnicas de limpieza de deuda / código.

A tu pregunta:

  

¿DAST necesita el mismo tiempo y esfuerzo del desarrollador y analista de seguridad para filtrar falsos positivos?

¡Quieres que los desarrolladores formen parte del proceso para que mejoren constantemente sus habilidades de seguridad y escriban códigos más seguros! La cantidad de participación depende de las habilidades del desarrollador.

Con algunos equipos necesito hacer el 100% del informe de triaje y abrir tickets para cosas específicas que necesitan ser cambiadas. Para otros equipos, hago triaciones con los desarrolladores, y para un equipo de desarrolladores veteranos, ellos realizan casi el 100% de los triaging y firmo su análisis antes de cada lanzamiento.

Para mí, un analista de seguridad que exige ciegamente que todo en un informe SAST / DAST sea reparado es perezoso o no comprende las tecnologías que se supone que deben proteger.

Parece que necesita poner un poco más de esfuerzo en su proceso de triaje y, como analista de seguridad, profundice un poco más para comprender qué es cada una de las vulnerabilidades informadas a punto de decidir si realmente necesita ser reparada (lo que tendrá el efecto secundario de expandir tus propias habilidades).

Parafraseando a la gran Tanya Janca :

  

"La forma más fácil de crear hostilidad entre los equipos de desarrollo y de seguridad es lanzar informes automáticos a ciegas a los desarrolladores y decir: ¡SOLICITUD!" - Tanya Janca

    
respondido por el Mike Ounsworth 01.08.2018 - 04:10
fuente

Lea otras preguntas en las etiquetas