it-swarm-es.com

Caja blanca versus caja negra

¿Cuáles son las ventajas y desventajas relativas de cada forma de prueba?
Es decir. ¿Cuál es la diferencia entre el análisis de código estático y las pruebas de tiempo de ejecución/penetración dinámica?
¿Cuáles son los pros y los contras de cada uno? ¿Hay situaciones en las que una es preferible a la otra?

21
AviD

Aquí hay algunas respuestas realmente buenas, pero creo que es importante agregar algunos puntos adicionales:

  • Como @atdre mencionó, no debería ser una o dos, estas son dos criaturas diferentes y miden cosas diferentes. Si es posible, debes hacer ambas cosas.
  • Además, como dijo @atdre, las pruebas, incluso whitebox + blackbox, no son suficientes. Hay otras cosas que debe hacer para estar seguro, incluido todo un SDL holístico, con una adecuada gestión de riesgos, análisis, etc.
  • Hasta el punto ... Blackbox suele ser más rápido, a menudo por orden de magnitud. Whitebox (incluida la revisión de código) generalmente requiere mucho más trabajo.
  • Blackbox (es decir, pentesting) generalmente tiene un costo más barato que el whitebox, no solo en total sino también por hora.
  • Hay más proveedores externos de blackbox de calidad que whitebox, no en total, pero contando solo aquellos que realmente saben lo que están haciendo. (¿O es solo mi percepción?)
  • WB a menudo encuentra vulnerabilidades mucho más profundas que BB.
  • WB a menudo puede encontrar filtros defectuosos, que BB no pudo omitir (hasta saber cómo se construye el filtro; otro punto hacia recuadro gris prueba).
  • Hay muchos tipos de fallas que BB ni siquiera puede probar, p. Ej. registros de auditoría, fallas de cifrado, endurecimiento de backend, etc.
  • BB puede probar todo el sistema, con todas las protecciones sin código establecidas (por ejemplo, WAF, IPS, endurecimiento del sistema operativo, etc.) donde WB solo está en el nivel de la aplicación (por ejemplo, código/diseño, etc.). Tenga en cuenta que esto puede ir en ambos sentidos: a veces se le impide completar un escaneo BB, aunque una vez que conoce el vector podría evitar el protecciones.
  • Del mismo modo, BB puede descubrir interacciones defectuosas entre subsistemas, donde WB generalmente lo perderá. Considere esto como prueba unitaria versus prueba del sistema.
  • El WB a menudo se puede realizar mucho antes de que el sistema esté completo, BB necesita ser construido, compilado, en funcionamiento (y preferiblemente la mayoría de los errores funcionales eliminados). Esto puede hacer que un SDL sea más eficiente, cuando las revisiones se pueden realizar temprano en el ciclo de vida.
  • Por otro lado, si un sistema ya está en funcionamiento, es simple iniciar un BB, pero si desea hacer WB (hacerlo bien) debe comenzar a buscar todo el código fuente, bibliotecas, herramientas, etc. A menudo, Ni siquiera tiene el código fuente porque es un tercero, COTS, etc.
7
AviD

Creo que esta pregunta se aborda mejor en el capítulo 4 de The Art of Software Security Assessment, un libro de Mark Dowd, Justin Schuh y John McDonald.

Sin ella como referencia, puedo decirle con seguridad que el mejor método es usar datos de tiempo de ejecución junto con el código fuente al determinar "hits" (o trazas, también conocida como cobertura) usando pruebas de recuadro negro, pero solo después de un modelo de amenaza y la arquitectura general del sistema es bien conocida.

A los autores también parece gustarles el análisis de código estático seguro cuando se combina con estrategias de puntos candidatos, aunque es mi opinión que estos pueden variar enormemente en valor, suponiendo que lo siguiente no sea cierto:

  • El lenguaje y sus bibliotecas de clase base deben ser compatibles con la herramienta segura de análisis estático.
  • El sistema completo generalmente debe estar disponible. Es decir. debe incluir código fuente compilable que incluya todos los componentes de terceros/contrib y bibliotecas externas, posiblemente incluso para incluir el compilador del sistema, la máquina virtual u otros artefactos del sistema original
  • Todos los componentes/bibliotecas externas que no forman parte de las bibliotecas de clases base deben tener fuentes y sumideros definidos en la base de datos de la herramienta de análisis estático seguro source-sink-passthru. Las complejidades de algunos passthrus (es decir, filtros) pueden variar según la implementación o el implementador y, por lo tanto, casi siempre requieren una configuración personalizada
  • El uso adicional de ciertos patrones o elementos de código arquitectónico podría causar otras variaciones, lo que podría requerir una personalización que no es posible con la mayoría de las herramientas modernas de análisis estático seguro

Por los motivos anteriores, así como los motivos expuestos en los estudios NIST SATE (realizados por NIST SAMATE), me resulta difícil recomendar muchas herramientas seguras de análisis estático para su uso en el análisis de recuadro blanco. Casi siempre es simplemente mejor usar estrategias de comprensión de código que probablemente impliquen leer el código fuente de arriba a abajo, lo cual es realmente muy importante si está buscando rootkits de código administrado y similares.

En lugar de probar y auditar/evaluar aplicaciones, adoptaría un enfoque diferente que es en gran medida muy independiente de la tecnología. Mi sugerencia sería implementar un portal de administración de riesgos de seguridad de aplicaciones que incluya un inventario de aplicaciones junto con los controles de seguridad de aplicaciones implementados actualmente de cada aplicación. Después de una línea de base inicial, los controles de seguridad de la aplicación deben evaluarse según los estándares de la industria como MITER CWE, SAFEcode y OWASP ASVS. Un análisis de brechas (tenga en cuenta que este es un término estándar de gestión de riesgos y funciona mejor cuando se implementa en un programa de gestión de seguridad de la información basado en ISO 27001 o similar) se puede utilizar para determinar los controles óptimos de seguridad de la aplicación, así como una ruta para obtener desde los controles implementados actualmente hasta los requeridos.

Debe implementar este portal de gestión de riesgos antes de realizar una actividad de evaluación de riesgos como pruebas de caja blanca o caja negra para obtener mejores resultados y medir el éxito de su programa.

9
atdre

cuadro negro

  • pros: pruebas fáciles, rápidas y simples
  • contras: a veces no es posible probar algunas partes de la aplicación (para verificar algoritmos de hash, entropía de id de sesión, ...); no puede estar seguro si se probó toda la aplicación

cuadro blanco

  • pros: capacidad de verificar los códigos fuente (ahorra tiempo; no es necesario probar la inyección de SQL si puede ver que los parámetros se usan de manera segura en todas partes); puede probar partes de la aplicación que no son accesibles/comprobables utilizando la GUI
  • contras: las pruebas pueden volverse realmente complejas

En general, la prueba de caja blanca le permite sumergirse en el código fuente y realizar pruebas de penetración completas, pero puede llevar mucho tiempo, mientras que la caja negra es fácil, rápida y simple. Prefiero prueba de recuadro gris - utilizando métodos de recuadro negro y entrevistando a desarrolladores/comprobando el código fuente solo en partes específicas de la aplicación (autenticación, administración de sesión, administración de configuración, ...).

5
bretik