Efectividad de las pruebas de seguridad de aplicaciones interactivas

Cada método (DAST vs SAST) tiene sus fortalezas y debilidades.

Por ejemplo, el método DAST está mucho mejor posicionado para evaluar las vulnerabilidades de tipo XSS porque en realidad es capaz de ejecutar "en el lado del cliente" para validar si la ejecución es realmente posible (en lugar de una reflexión benigna). SAST en este caso, en su mayor parte, se limita a demostrar que la entrada lo hizo (o tiene una ruta posible) desde la fuente hasta el sumidero y puede reflejarse en la salida, pero normalmente no podría confirmar que la reflexión puede ejecutarse para entregar la carga útil XSS. En este caso, DAST tiene algunas ventajas sobre SAST.

OTOH, la detección de vulnerabilidades, como la introducción de una contraseña que se escribe en texto sin cifrar en el archivo de registro del backend, resultaría casi imposible para el escáner DAST, pero es un trabajo manejable para el análisis SAST.

Por lo tanto, IAST (o algunas veces denominado híbrido) puede aprovechar los puntos fuertes de ambos métodos y ayudar a controlar / reducir las debilidades inherentes del otro. También puede ayudar a reducir las tasas de detección de falsos positivos haciendo que un método confirme al otro (por ejemplo, en las pruebas dinámicas de SQLI que tiene confirmación de que el ataque llegó a la base de datos); ayude a acelerar las pruebas reduciendo la superficie de ataque (por ejemplo, no es necesario probar una página para SQLI si la página no tiene ningún SQL), en realidad descubra la superficie de ataque que puede estar oculta (es decir, subaplicación o páginas que no están vinculadas y están no es fácil de descubrir en los ciegos), etc.

Descargo de responsabilidad: solía trabajar para desarrollar uno de estos escáneres.

  

¿Qué tan efectivas son las herramientas IAST para encontrar vulnerabilidades?

HP WIRT, Acunetix con Acusensor, Contrast Security, Quotium y Appscan Enterprise pueden encontrar más vulnerabilidades cuando se encuentran en el mejor escenario. Sí, he usado Contrast Security y WIRT para encontrar vulnerabilidades más rápido que sin las capacidades del lado SAST (tenga en cuenta que WIRT proporciona información tanto a WebInspect en la herramienta a través de los ganchos de SecurityScope como también hace que Fortify sea compatible con la salida de registro de SecurityScope) , pero yo (y he) solo utilizo sus capacidades al apuntar a aplicaciones JEE. Para Acusensor, obtienes incluso menos resultados y solo contra las aplicaciones PHP. Quotium y Appscan Enterprise no necesariamente agregan más valor a .NET, JEE ni a ningún otro idioma que haya encontrado, pero ciertamente también tienen sus nichos allí, bajo la configuración y configuración correctas.

HP WIRT/SecScope vs. JEE: 9/10
Contrast Security vs. JEE: 9.5/10
Acusensor vs. PHP: 6/10
Quotium or Appscan benefits: 7 or 8 out of 10
HP WIRT vs. ASP.NET: 8.5 out of 10

  

¿Existe alguna evidencia de que estos puedan encontrar más o menos que un negro?   ¿Prueba de lápiz de aplicación de caja (DAST) o por revisión de código fuente (SAST)?

Hay evidencia absolutamente concluyente de esto, especialmente teniendo en cuenta el tiempo y las limitaciones de recursos asignados a cualquier evaluación DAST. Permítanme ser un gigante vocal cuando se trata de este tema: IAST, ya sea estricto (Contraste, Coto) o bien definido (WIRT / SecScope, et al.) Es una ayuda enorme al configurar los casos de prueba de inyección de fallas después de una herramienta cerebral híbrida. comprensión del código (que normalmente implica, al menos, caminar y rastrear el flujo de ejecución de la aplicación).

En el caso de WIRT / SecScope, pude configurar y encontrar las vulnerabilidades que definitivamente habría pasado por alto en varios escenarios: contra aplicaciones JEE y .NET, especialmente aplicaciones que superaban los 20 MLOC con un montón de complejidad, y especialmente cuando incluían servicios web que eran interfaces SOAP y / o REST.

Personalmente, ni siquiera tocaría una evaluación contra aplicaciones desarrolladas por JEE, .NET o PHP sin considerar a IAST como un enfoque primario de primera ejecución. Ahorra mucho tiempo y proporciona mucho enfoque.

Comparando SAST con IAST: IAST es más rápido que SAST y se enfoca en la gestión de riesgos. Incluso si solo un IAST encuentra que SAST puede o no encontrar un futuro, esto puede ser de gran valor cuando se analizan los análisis de brechas de control o problemas similares de administración de riesgos. El hecho de que se haya encontrado un error de seguridad en IAST hace que una debilidad del software se encuentre en una posición única para una mayor priorización. Además, los hallazgos de IAST, cuando se combinan con los hallazgos de SAST (especialmente basados en reglas personalizadas) son sorprendentes ahorradores de tiempo cuando se trata de una mayor personalización de las vistas, la comprensión del código, el diseño del código y la combinación de recursos.

Comparando DAST con IAST: En mis manos, IAST simplemente encontrará más y comprenderá las vulnerabilidades más profundas, lo que probablemente conducirá a la explotación o aprovechamiento del encadenamiento más fácil / más rápido también.

En resumen: use IAST siempre que sea posible, tan pronto como sea posible, y proporcione artefactos IAST para futuras evaluaciones de SAST (y SAST personalizado).

¿Cuál es mejor? ¿Un martillo o un destornillador? Todo depende del problema. Dado que no conoce las debilidades de antemano, el enfoque recomendado por IARPA 'STONESOUPUP es para utilizar múltiples herramientas con múltiples enfoques.

Paul Black de NIST destaca las ventajas y desventajas del análisis estático en su CrossTalk March / Abril 2009 artículo . "Se deben desarrollar nuevas pruebas cuando se descubren nuevos ataques o modos de falla. Los analizadores estáticos tienen alguna ventaja en este caso ..." Lo más importante es que los analizadores estáticos tienen el potencial de encontrar ocurrencias raras o puertas traseras ocultas. Dado que consideran el código independientemente de cualquier ejecución particular, pueden enumerar todas las interacciones posibles. El número de interacciones tiende a aumentar exponencialmente, desafiando el análisis estático integral y la ejecución de pruebas por igual. El análisis estático puede centrarse en la interacción sin necesidad de realizar pruebas para restablecer las condiciones iniciales o restringir artificialmente el sistema para producir la interacción deseada. Peor aún, no se puede esperar realísticamente que las pruebas de caja negra descubran, digamos, una puerta trasera accesible cuando el ID de usuario es "JoshuaCaleb", ya que hay un número casi infinito de cadenas arbitrarias para probar ".

"Las pruebas y el análisis estático se complementan entre sí. Las pruebas tienen la ventaja de posiblemente revelar fallas completamente inesperadas. Los sistemas integrados se pueden probar, incluso cuando no es práctico analizar ningún software que pueda estar escondido en un componente."

"El análisis estático no es una panacea. Las vulnerabilidades complejas y sutiles siempre pueden derrotar el razonamiento en un analizador estático. La falta absoluta de un requisito importante, como la auditoría o el cifrado, no se puede deducir razonablemente del examen de los artefactos de postproducción. El software sin capacidad de recuperación o autocontrol está abierto a errores en la instalación u operación, pero el análisis estático puede ser una de las últimas líneas de defensa contra las vulnerabilidades ". ... Trabajo de la Exposición de la herramienta de análisis estático de junio de 2008 [3] , [4] muestra que los analizadores actuales varían ampliamente. Un analizador puede producir pocas falsas alarmas para algunas debilidades, pero muchas falsas alarmas para otras debilidades. Del mismo modo, la tasa de debilidades perdidas es muy diferente. Los analizadores también cubren solo un subconjunto de debilidades documentadas [5] . Por lo tanto, el análisis estático más completo resultaría de una combinación de analizadores cuidadosamente utilizada.

Dr. Black lidera el proyecto SAMATE - Evaluación de herramientas y métricas de Software Assurance de NIST. Consulte Encuesta sobre herramientas de SAMATE y la página SecTool de Shay Chen para Comparación de precios y características de los escáneres de aplicaciones web. Revelación completa: Soy un investigador invitado que apoya el Proyecto SAMATE.

Estoy trabajando para la compañía que escribió el estudio de caso Quotium ( enlace ), ¡pero intentaré ser objetivo en mi respuesta!

El punto no es encontrar vulnerabilidades, sino poder hacer que los desarrolladores solucionen rápidamente aquellas que suponen un riesgo real para su empresa y, específicamente, sus datos (ámbito principal de los piratas informáticos).

¿Por qué?

Cuando se está desarrollando en un entorno Agile con ciclos de lanzamiento cortos. No puede detener el proceso para realizar SAST + DAST, analizar informes, evaluar resultados, solucionar problemas en funciones no utilizadas, analizar código (en algún momento ubicado en terceros) para identificar la fuente, comprender falsos ecc positivos ... ¡No hay tiempo!

El problema principal con SAST y DAST es tiempo y experiencia . Para ambos, necesita análisis de impacto y análisis de corrección de código. SAST + DAST no es ágil.

SAST y DAST solo conocen un lado del sistema, no miran las vulnerabilidades en un contexto de amenaza general y contexto de datos. IAST lo hace, ya que rastrea los datos desde el front-end al back-end.

Un IAST real es una herramienta que se ha creado desde cero específicamente para actuar desde el punto de vista del pirata informático hasta el código.

IAST le ofrece la posibilidad de integrarse mejor en el proceso de desarrollo.

Por ejemplo, conectas tu herramienta IAST donde tienes tus servidores de compilación ... en un lado conectas tus scripts de prueba automatizados (selenio para ej.) en el otro lado, tu herramienta de seguimiento de errores. Tiene un proceso de prueba de seguridad automatizado que se ejecuta por la noche.

Por la mañana, sus desarrolladores encuentran su lista de códigos vulnerables con la solución a aplicar, un video de repetición del ataque en la aplicación probada, la ruta al código vulnerable en los diferentes componentes para poder parchear las interfaces de terceros si el código fuente no está disponible.

• Los desarrolladores se centran solo en vulnerabilidades probadas
• Los evaluadores tienen una visión clara de los riesgos de vulnerabilidades diseñados por OWASP Top 10, SANS / CWE, PCI ecc ... para GO / NO GO

¡Una gran ganancia de tiempo en el proceso!

Bueno, aquí no soy objetivo, pero es cómo funciona :)

Para ser objetivo:

Solo hay 2 herramientas que se han creado para ser IAST: Buscador de Quotium y Contraste de Aspecto.

Todos los demás proveedores intentaron fusionar herramientas separadas para marketing , ¡pero son DAST + SAST no IAST!

Tenemos clientes que implementaron IAST como un proceso continuo y continúan teniendo una herramienta SAST para auditoría.

SAST te ayuda a tener una mejor práctica de codificación segura. IAST aún encuentra vulnerabilidades después de SAST, pero IAST no resaltará la práctica de codificación no segura si la pieza de código no es tocada por un proceso vulnerable.

¡Así que es mejor que hagas IAST + SAST que DAST + SAST!