¿Cómo debe encajar la seguridad en el ciclo de vida del desarrollo de software?

1. Lo primero que haría es asegurarme de que un equipo no siga el popular antipatrón: comenzar con la funcionalidad. ¡Vamos a hacerlo funcionar primero, mal! Siempre debe analizar varios aspectos del software, incluida la seguridad y el rendimiento.
2. La palabra ‘prueba’ significa cualquier cosa que pueda salir mal, lo hayamos pensado o no. No significa verificar si funciona. Aparte: la mayoría de la gente no entiende la palabra ‘prueba’.
3. Es muy difícil anticipar qué puede salir mal en el software. Debe tener urgencia y agresividad para anticipar problemas. Creo que hay mucho interés en los algoritmos y la programación. Deseo que la gente entienda los desafíos de la tecnología, los sistemas y los usuarios. Todo esto puede morderte en la parte trasera.
4. Tiene que haber un cerebro detrás del uso de herramientas. Por supuesto, debe usar herramientas, pero no de manera mecánica y esperar grandes resultados.

Estos son los pasos concretos que seguiría:

1. Me aseguraría de que el equipo tenga una capacitación en vulnerabilidades de seguridad básicas, es decir, XSS, concepto de hash, etc.
2. Me aseguraría de que el equipo use la heurística para encontrar vulnerabilidades, por ejemplo, rastrear el flujo de datos en toda la aplicación. El punto es ser creativo sobre lo que puede salir mal.
3. Debe haber acceso a alguien que entienda la seguridad, por ejemplo, que pueda buscar los algoritmos actuales para el cifrado.
4. Cada persona debe seguir haciendo preguntas sobre seguridad, durante todo el ciclo de vida del desarrollo, no al final.

Resumen

Realmente lo que propongo es dar un entrenamiento básico. Pídale a las personas que sean creativas sobre lo que puede salir mal durante el ciclo de desarrollo.

Estoy seguro de que algunas personas propondrán contratar consultores. Puedes hacerlo si te lo puedes permitir. Sin embargo, siempre debe hacer lo mejor con sus recursos, es decir, los desarrolladores. Creo que la mayoría de los equipos son negligentes hacia la seguridad y siempre esperan que un caballero con una armadura brillante los rescate.

Con respecto al SDLC, es un enfoque recomendado que los aspectos de seguridad de un sistema tengan importancia en cada etapa.

Desde el inicio del ciclo de vida del software, las características de seguridad deben incorporarse dentro de la aplicación.

Miremos cada fase de SDLC y veamos las posibles actividades que se pueden incluir para desarrollar una aplicación segura.

Fase de recopilación de requisitos:
Durante esta fase, al enumerar varios requisitos funcionales, es esencial que los requisitos de seguridad también necesiten ser enumerados.
Por ejemplo, mientras discute sobre la funcionalidad de inicio de sesión, presenta los requisitos como la complejidad de la contraseña, máx. no de intentos fallidos de inicio de sesión.

Fase de diseño:
Durante esta fase, incluya los principios de diseño seguro, como Integridad y No repudio. Para validar el diseño desde la perspectiva de seguridad, un grupo selecto de expertos puede realizar revisiones de diseño de seguridad y prescribir recomendaciones de seguridad.

Fase de implementación:
En esta fase, se deben emplear los principios de codificación segura para garantizar que no haya vulnerabilidades de seguridad dentro de la aplicación. Se puede hacer una revisión segura del código para garantizar que el código esté libre de vulnerabilidades.

Fase de prueba:
A medida que se realizan pruebas funcionales para verificar los requisitos funcionales, se deben realizar pruebas de seguridad / evaluación de vulnerabilidad. Este VA garantiza que la existencia de la aplicación esté segura y libre de vulnerabilidades.

Fase de implementación / mantenimiento:
Asegúrese de que durante el despliegue, el entorno de preparación / producción esté asegurado por el endurecimiento de la plataforma y el sellado de los puertos no deseados. Además, cualquier código de mantenimiento agregado debe inducir un poco a las nuevas lagunas de seguridad.

La mayoría de los equipos de proyectos cometen un error al introducir la seguridad solo durante la etapa de prueba o más tarde. Esta no es una práctica recomendada ya que el costo incurrido para encontrar vulnerabilidades de reparación en la etapa posterior de SDLC es mucho mayor. Por lo tanto, es más sabio y seguro incluir principios de seguridad desde las primeras etapas y todas las etapas de SDLC.