caja blanca vs. caja negra

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

• Como lo mencionó @atdre, no debería ser ninguno de los dos o estos, son dos criaturas diferentes y miden cosas diferentes. Si es posible, deberías hacer ambas cosas.
• También como dijo @atdre, las pruebas, incluso whitebox + blackbox, no son suficientes. Hay otras cosas que debe hacer para estar seguro, incluidos todos los SDL holísticos, 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 la caja blanca, no solo en total sino también por hora.
• Hay más proveedores de Blackbox de terceros 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 la prueba caja gris ).
• Hay muchos tipos de fallas que BB ni siquiera puede probar, p. ej. registros de auditoría, fallas de cifrado, endurecimiento del backend, etc.
• BB puede probar todo el sistema, con todas las protecciones sin código implementadas (por ejemplo, WAF, IPS, fortalecimiento 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 de BB, aunque una vez que conozca el vector podrá evitar las protecciones.
• De manera similar, BB puede descubrir interacciones defectuosas entre subsistemas, donde WB generalmente lo echará de menos. Considere esto como prueba de unidad vs. prueba de sistema.
• WB a menudo se puede realizar mucho antes de que se complete el sistema, BB debe ser compilado, en funcionamiento y en funcionamiento (y preferiblemente la mayoría de los errores funcionales son eliminados). Esto puede hacer que una SDL sea más eficiente, cuando las revisiones se pueden hacer al principio del ciclo de vida.
• Por otro lado, si un sistema ya está activo, es sencillo iniciar un BB, pero si quieres hacer WB (hazlo bien) tienes que 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.

Creo que esta pregunta se aborda mejor en el capítulo 4 de El arte de la evaluación de seguridad del software , un libro de Mark Dowd, Justin Schuh y John McDonald.

Sin que sea una referencia, puedo decirle con seguridad que el mejor método es usar los datos de tiempo de ejecución junto con el código fuente mientras se determinan los "aciertos" (o rastros, también conocido como cobertura) mediante pruebas de caja negra, pero solo después de un El modelo de amenazas y la arquitectura general del sistema son bien conocidos.

Parece que a los autores también les gusta el análisis de código estático seguro cuando se combinan con estrategias de puntos candidatos, aunque opino que pueden variar enormemente en cuanto a su valor, suponiendo que lo siguiente no sea cierto:

• El idioma y sus bibliotecas de clase base deben ser compatibles con la herramienta de análisis estático seguro
• Por lo general, todo el sistema 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 externos que no forman parte de las bibliotecas de clase base deben tener fuentes y sumideros definidos en la base de datos source-sink-passthru de la herramienta de análisis estático seguro. 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 las razones anteriores, así como por las razones expuestas en los estudios NIST SATE (realizados por NIST SAMATE), me resulta difícil recomendar muchas herramientas de análisis estático seguro para usar en el análisis de caja blanca. Casi siempre es simplemente mejor utilizar estrategias de comprensión de código que probablemente impliquen leer el código fuente de arriba a abajo, lo que 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 agnóstico a la tecnología. Mi sugerencia sería implementar un portal de administración de riesgos de seguridad de la aplicación que incluya un inventario de la aplicación junto con los controles de seguridad de la aplicación actualmente implementados 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 MITRE CWE, SAFEcode y OWASP ASVS. Un análisis de brechas (tenga en cuenta que este es un término estándar de administración de riesgos y funciona mejor cuando se implementa en un programa de administración de seguridad de la información basado en ISO 27001 o similar) se puede usar para determinar los controles óptimos de seguridad de la aplicación, así como una ruta para obtener desde los controles actualmente implementados hasta los requeridos.

Debe implementar este portal de administració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.

Caja negra

• pros: pruebas sencillas, rápidas y sencillas
• contras: a veces no es posible probar algunas partes de la aplicación (para verificar algoritmos de hashing, entropía de id de sesión, ...); no puede estar seguro de que toda la aplicación haya sido probada

Caja blanca

• ventajas: 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 / verificables utilizando la GUI
• contras: las pruebas pueden llegar a ser realmente complejas

En general, las pruebas de caja blanca le permiten sumergirse en el código fuente y realizar pruebas de penetración completas, pero pueden consumir mucho tiempo, mientras que la caja negra es fácil, rápida y simple. Prefiero las pruebas de caja gris : utilizar métodos de caja negra y entrevistar a desarrolladores / verificar el código fuente solo en partes específicas de la aplicación (autenticación, gestión de sesión, gestión de configuración, ...).