La importancia del modelado de amenazas

Hace un tiempo, cuando estudiaba en el grado de ingeniería de software, veíamos cómo programar, cómo hacer aplicaciones, pero en ningún momento se interesaban en cómo hacer aplicaciones seguras, con que funcionará era suficiente.

Si es verdad que se habló de tener un Software de “buena calidad”, sin código espagueti, con buena complejidad diplomática, etc.  Algo es algo, pero solo calidad no nos da la seguridad… Por ejemplo, podemos refactorizar nuestro código, que sea legible, mantenible y eficiente, pero si no comprobamos que la aplicación haga solo lo que tiene que hacer, no tenemos seguridad… Buena calidad de código y no validamos las entradas del usuario, una gran idea, ¿no?

En este post no vengo a desprestigiar el mundo de la calidad, porque es algo más que necesario, vengo a mostrar la importancia de agregar seguridad a nuestros proyectos.

¿Y cómo metemos la seguridad en nuestros desarrollos? Desde el primer minuto, contando con arquitecturas de referencias seguras, pasando por la fase de diseño, contando con un buen modelado de amenazas, con ayudas al equipo de desarrollo y con pruebas de seguridad.  En este post me quiero centrar en el modelado de amenazas, y hacer ver el valor que aporta a nuestros desarrollos.

Un esquema a alto nivel (no se agregan todos los datos y procesos) desde el diseño con el modelado de amenazas, hasta las pruebas de seguridad.

Para hacer un buen modelado de amenazas, y como responsables de agregar seguridad en los proyectos, debemos hacer las siguientes tareas:

• Recogida de información: tenemos que reunirnos con el equipo de arquitectura y si es posible de negocio, para obtener la mayor información.
• Diagrama de flujo de datos (DFD): con la información obtenida, dibujamos el DFD, donde “pintamos” los distintos componentes, los flujos de datos y las zonas de confianza. Al terminar lo validamos con el equipo.
• Detectamos amenazas: cuando terminamos el DFD definitivo, detectamos las amenazas a las que se enfrenta el proyecto.
• Identificamos riesgos: analizamos y cuantificamos el riesgo.
• Establecemos contramedidas: para mitigar las amenazas necesitamos dispones de unos requisitos que los desarrolladores tengan en cuenta. Aquí no entramos en detalle, sino que son a alto nivel (por ejemplo, valida la entrada de los usuarios con los tipos de dato esperados). Algo que puede aportar mayor valor es el mapeo con diferentes "estándares" (CWE o ASVS por ejemplo).

Nos podemos quedar a ese nivel, pero si queremos aportar más valor al trabajo, entraríamos a estudiar la tecnología que se va a usar y aportamos posibles implementaciones para las contramedidas. Y si queremos tener un modelo completo y "automatizable", generamos un listado de pruebas para las contramedidas facilitadas.

Aquí ya entra el equipo de desarrollo a trabajar, que se puede beneficiar de las contramedidas y/o implementaciones que les vienen dadas. Además, es necesario agregar al desarrollo una herramienta SAST, que ayude a los desarrolladores a detectar posibles problemas.

Al finalizar el desarrollo, y antes de pasar a producción, entra en juego el equipo de validación, que comprobará la seguridad del proyecto desarrollado y tomará una decisión si pasa o no. Gracias al modelado de amenazas hecho previamente, los encargados de las pruebas de seguridad cuentan con una lista de contramedidas (con sus posibles pruebas) que pueden revisar. Aquí se volvería aplicar un SAST y también DAST, dicho de otra forma análisis estático y análisis dinámico.

No nos olvidemos de hacer un pentesting ;).

Todo esto que he venido a contar en el post de hoy es posible introducirlo en cualquier metodología de trabajo que usemos, es solo adaptarlo según el ciclo de vida que tengamos.

En mi experiencia, y trabajando con distintos equipos, he visto cómo la gente es reacia a meter un trabajo extra, piensan que los desarrollos llevarán más tiempo… pero al final se están dando cuenta de los grandes beneficios, y es que cuando llegan al paso a producción el software no es rechazado por sus numerosos problemas, lo que se traduce en reducción de tiempo y costes.

No dejemos la seguridad para el final. ¡Hasta la próxima!