Cómo gestionar los riesgos y deficiencias de seguridad de las aplicaciones

La seguridad de la aplicación es posiblemente la parte más crítica de un programa de seguridad general.

El software es donde ocurren las transacciones comerciales. Es donde se captura, procesa y almacena la información confidencial. Es donde existe una gran cantidad de amenazas y fallas de seguridad, posiblemente las más grandes, para crear escenarios de riesgo perfectos para los delincuentes.

Aún así, las organizaciones luchan para encontrar, y corregir, los grandes riesgos de seguridad de las aplicaciones. Esto incluye cosas como inyección SQL en la capa de aplicación para aplicaciones web y móviles, parches faltantes que facilitan el acceso remoto en la capa del servidor e incluso contraseñas predeterminadas o débiles en la capa de la base de datos.

Sin embargo, no podemos culpar a los fallos o los piratas informáticos por lo que está sucediendo, ya que va mucho más profundo. En primer lugar, hay una gran falta de pruebas de aplicaciones adecuadas. Las tres áreas principales de preocupación son las siguientes:

• Ninguna prueba de seguridad, incluidas las aplicaciones críticas. Este es el problema más común en gran parte a las suposiciones de que alguien más se está ocupando de las cosas;
• Escaneos de vulnerabilidad básicos que no abordan adecuadamente la capa de aplicación; y
• No mirar el código fuente. Un ejercicio que a menudo revela fallas que no aparecerán con la vulnerabilidad tradicional y las pruebas de penetración.

En segundo lugar, existe una falta de comunicación entre los desarrolladores y los analistas de control de calidad (QA), los equipos de seguridad y la administración en general. Los principales vacíos que veo son los siguientes:

• Se hacen suposiciones: Esto puede involucrar estándares de seguridad, modelado de amenazas y cumplimiento general de la política durante el ciclo de vida del desarrollo de software y hasta la fase de implementación de la aplicación.
• La apatía de los espectadores: Semejante a la suposición anterior de que un proveedor externo o proveedor de servicios en la nube está haciendo las pruebas adecuadas, en muchos casos, los desarrolladores y los profesionales de control de calidad suponen que se descubrirán fallas de seguridad posteriores a sus funciones, como cuando su código entra en producción En ese momento, puede ser demasiado tarde para encontrar y corregir los defectos.
• Prioridades equivocadas: Por ejemplo, cuando el personal técnico solicita los recursos adecuados para realizar su diligencia debida de seguridad y la gerencia los silencia. Sin embargo, si una parte externa independiente, como un auditor de seguridad o un cliente que realiza sus propias pruebas en su entorno, menciona algo en su informe, de repente llama la atención de la gerencia. Los ejecutivos quieren saber por qué estos problemas no se descubrieron sin ver la imagen más amplia de sus acciones como obstáculos en el camino.

Finalmente, descubrí que muchos desarrolladores, analistas de control de calidad y equipos de seguridad carecen de información sobre las mejores prácticas y marcos de seguridad de software puestos a nuestra disposición, como el Top 10 de OWASP, Common Enumeration Enumeration e ISO 27034. O no pueden tomarse el tiempo de integrar dichos estándares y prácticas en su programa de seguridad de aplicaciones debido a las demandas de tiempo de comercialización de otras partes del negocio.

Además de esto, muchas de las personas a cargo de la seguridad de las aplicaciones con las que hablo nunca han tomado un curso sobre el tema. Dicho esto, es fácil quedar atrapado buscando los mejores estándares y que otros le digan lo que debe hacer para que pueda pasar por alto los enormes defectos que tiene justo debajo de la nariz. Tenga cuidado, piense por si mismo y use el sentido común.

Al final, los riesgos de seguridad de la aplicación se pueden reducir a través de tres métodos.

• Conozca su entorno: Desde aplicaciones críticas hasta aplicaciones de bajo riesgo, y toda la información y los procesos en los que se vinculan, tanto interna como externamente. El descuido de las superficies de ataque es uno de los descuidos más peligrosos de la administración de seguridad. La regla de oro de la seguridad siempre ha sido, y siempre será, que no puedes asegurar lo que no reconoces.
• Comprenda los riesgos de seguridad de su aplicación: Las vulnerabilidades técnicas, brechas de procesos y oportunidades de políticas en todo el espectro de amenazas que enfrentan sus sistemas. Hacer que otros participen aquí para ayudar a determinar las prioridades es clave, ya que mantener el análisis de riesgos dentro de los círculos de TI funciona bien, hasta que falla. Una vez que se produce un incidente o una infracción y se involucran la dirección ejecutiva y los abogados, ya es demasiado tarde. ¿Por qué no involucrarlos desde el primer momento?
• Haga algo al respecto: Primero gestione los problemas urgentes en sus sistemas más importantes y, finalmente, administre los problemas en todos los sistemas a los que se puede acceder a través de la web, el móvil o el código fuente. No importa cuánto analice esas situaciones, no puedo proponer una sola excusa para no hacer algo acerca de los defectos conocidos que pueden crear riesgos comerciales tangibles. Los dedos pueden apuntar a la gerencia por no proporcionar suficientes recursos o a los equipos de TI/seguridad por no tener suficiente tiempo, o disciplina, para hacer las cosas. Al final, nadie quiere escucharlo. Corte las tonterías. Deje de tener reuniones que generen más reuniones y, por lo tanto, les dan a las personas una excusa para echar a rodar la lata de la seguridad de la aplicación por el barranco. Haga lo que hay que hacer, y hágalo ahora.

Ya sea en las primeras fases de diseño o desarrollo, fases de producción o mantenimiento continuo de aplicaciones heredadas, debe desarrollar una estructura en torno al programa de seguridad de su aplicación con todas las personas adecuadas para ayudar a eliminar los riesgos de seguridad de las aplicaciones. Nada más y nada menos.

Ya sea un programa independiente o parte de sus esfuerzos generales de seguridad de la información, si trata la seguridad de las aplicaciones como la función de negocios crítica que es, obtendrá buenos resultados. Si no lo hace, bueno, será más de lo mismo una y otra vez.