X
BLOG

La seguridad de las aplicaciones ES un problema de calidad: 6 consejos de prueba para beneficiar tanto la calidad como la seguridad

La seguridad de las aplicaciones ES un problema de calidad: 6 consejos de prueba para beneficiar tanto la calidad como la seguridad Tiempo de leer: 4 minutos

Recientemente, estaba leyendo una publicación en LinkedIn en la que alguien preguntaba la diferencia entre varios proveedores de seguridad de análisis estático. Una persona, como era de esperar, un proveedor, respondió que su solución era mejor porque, mientras que otras empresas se centraban en la calidad y la seguridad, se dedicaban estrictamente a la seguridad.

Por supuesto, esa fue una declaración ridícula. Y tal vez este tipo de pensamiento sea indicativo del actual problema desenfrenado con la seguridad de las aplicaciones en la industria; por ejemplo, organizaciones que intentan ejecutar su grupo de seguridad completamente separado del resto del SDLC (esfuerzos de desarrollo y prueba). En este modelo, el equipo de seguridad ejecuta sus propias pruebas, en su mayoría tratando de romper el software, luego envía los errores de seguridad al equipo de desarrollo. En otras palabras, intentar probar la seguridad en su código. Puedo asegurarles que esto no es más efectivo que probar la calidad en su código.

Claro, este tipo de prueba de seguridad es necesaria, pero simplemente no es suficiente. Si bien romper el software es realmente útil, confiar en él como método para mejorar la seguridad conduce a que se encuentren errores en un punto que sea demasiado tarde, y terminen siendo suprimidos. En particular, los problemas de causa raíz, como marcos y algoritmos inadecuados, se esconden debajo de la alfombra, ya que el cronograma gana el conflicto entre reescribir el código y hacer que la versión salga por la puerta.

En el comentario de Linkedin que mencioné anteriormente, el proveedor está engañando peligrosamente a un posible cliente desprevenido al afirmar que su software es de alguna manera mejor, sin decir nada útil sobre cómo o por qué es mejor. No me refiero a elegir a ningún proveedor de herramientas en particular, especialmente porque trabajo para uno. Sin embargo, estoy frustrado por esos argumentos de hombre de paja, que dan la apariencia de vender aceite de serpiente. En este caso, el producto del proveedor puede tener características únicas interesantes, pero nos queda la impresión de que la seguridad es de alguna manera mágicamente diferente a la calidad, lo que reduce nuestra comprensión de la seguridad de las aplicaciones y nos hace a todos un poco menos seguros.

La seguridad debe tratarse como calidad y la calidad debe basarse en prácticas de ingeniería maduras, porque la verdad es que si tienes un problema de calidad, tienes un problema de seguridad. Los estudios demuestran que desde cualquier lugar 50-70% de los defectos de seguridad son defectos de calidad. En otras palabras, los buenos errores de calidad pasados ​​de moda se están convirtiendo en vulnerabilidades que los intrusos / piratas informáticos / malos actores utilizan para penetrar en su aplicación (los llamamos "cero dias").

"El consenso de los investigadores es que al menos la mitad, y tal vez hasta el 70% de las vulnerabilidades de software comunes, son problemas fundamentales de calidad del código que podrían prevenirse escribiendo un mejor software. Codificación descuidada."

- Jim Bird "Construyendo software real"

Si aún no está seguro de cómo se superponen la calidad y la seguridad, eche un vistazo a un par de ejemplos del CWE Top 25. Los siguientes posibles resultados de seguridad son de la Impacto técnico de CWE trabajo:

  • #3 CWE 120 Copia de búfer sin comprobar el tamaño de la entrada ("Desbordamiento de búfer clásico") - puede conducir a la ejecución de códigos o comandos no autorizados, posible acceso no autorizado a datos, posible Negación de servicio (DoS)
  • #20 CWE 131 , Cálculo incorrecto del tamaño del búfer (que provoca un desbordamiento del búfer) - posible DoS, ejecución de código o comandos no autorizados, posible lectura / modificación de memoria no autorizada
  • #25 CWE 190 , Integer Overflow o Wraparound (que conduce a un comportamiento indefinido y, por lo tanto, se bloquea) - posible DoS, posible modificación de la memoria, posible ejecución de código o comandos no autorizados, posible ejecución de código arbitrario

Si profundiza en la lista completa de CWE (más de 800 elementos), encontrará muchos otros, es decir, todas las formas de desbordamiento / desbordamientoinicializaciónrecursividad incontrolada, etc. Todos estos son ataques de seguridad comunes, así como también problemas de calidad obvios.

Constrúyalo en

La complejidad de los sistemas de software crece muy rápidamente. Intentar probar todas las variaciones posibles rápidamente se vuelve casi imposible. Como Richard Bender lo dice, "El número de pruebas potenciales excede el número de moléculas en el universo", que es una forma más divertida de decir que nunca lo conseguirás. O de Jim Bird, "para un sistema grande, necesitaría un número infinito de probadores de lápiz en un número infinito de teclados trabajando durante un número infinito de horas para tal vez encontrar todos los errores".

Por lo tanto, tanto la seguridad como la confiabilidad deben diseñarse y diseñarse. No puede probarlas. Mientras la seguridad sea algo “adicional”, se verá afectada.

¿Qué se puede hacer?

Aquí hay algunas cosas que puede hacer para comenzar a mejorar la calidad de su software y  seguridad al mismo tiempo.

  1. Capacite a los desarrolladores en el desarrollo seguro. Capacitar adecuadamente a sus desarrolladores en prácticas de desarrollo seguro significa que pueden prevenir, o al menos encontrar y solucionar, problemas de seguridad.
  2. Diseñe y construya su sistema con un enfoque deliberado en la calidad y la seguridad. Evite el código que “funciona” pero que en realidad no es una buena opción porque tiene posibles problemas de seguridad. (O problemas de seguridad, para el caso). El análisis estático lo ayudará a hacer esto al verificar su código no solo para detectar errores, sino también para verificar el cumplimiento de las mejores prácticas conocidas.
  3. Deje de depender de las herramientas de borde. Reconozca su exposición real y las superficies de ataque. El cortafuegos y el antivirus no compensarán el código inseguro; debe reforzar su aplicación.
  4. Recopile / mida datos de defectos y utilícelos para evaluar y mejorar sus prácticas de desarrollo. ¿Qué código o componentes producen más problemas? ¿Qué código es el mejor? ¿Cómo se probaron? Repita las buenas ideas y elimine las malas.
  5. Utilice un análisis estático estricto. No acepte simplemente la evaluación de alguien de que un defecto informado no es un problema importante o un falsos positivos. Obtenga un buen conjunto de reglas que incluyan tanto la detección como la prevención, y cumpla con ellas. La mejor manera de hacer esto es a partir de un enfoque de ingeniería en torno a las mejores prácticas (el papel de los estándares de codificación como CWECERTOWASP). El análisis estático es la forma de asegurarse de que se sigan las mejores prácticas.
  6. Utilice el análisis en tiempo de ejecución. Encontrará problemas reales (especialmente problemas de memoria desagradables) y le mostrará exactamente dónde y qué salió mal sin falsos positivos.

Por tanto, debemos empezar a incorporar la seguridad en nuestro código. Esta es la mejor manera de endurecerlo realmente, en lugar de simplemente parchear los agujeros conocidos. Tener todos los resultados de desarrollo de software de la codificación, la construcción y las pruebas integrados en un repositorio central proporciona control, medición y trazabilidad. Ésta es la base para futuras mejoras.

Y recuerde, el costo de una prevención sólida es menor que el costo de lidiar con software malo o inseguro. Entonces realmente no hay excusa.

Escrito por

Arthur Hicken

Arthur ha estado involucrado en seguridad de software y automatización de pruebas en Parasoft durante más de 25 años, ayudando a investigar nuevos métodos y técnicas (incluidas 5 patentes) mientras ayuda a los clientes a mejorar sus prácticas de software.

Reciba las últimas noticias y recursos sobre pruebas de software en su bandeja de entrada.

Prueba Parasoft