¡Hello world! Hoy venimos a hablar del modelado de amenazas, concretamente sobre la importancia de incluir esta metodología en las primeras fases de diseño de una aplicación.
Para los que os preguntéis que es esto del modelado de amenazas, se trata de una metodología para identificar y mitigar lo antes posible los riesgos de seguridad en una aplicación. Esta metodología consiste en identificar las posibles amenazas de seguridad, evaluar su impacto y probabilidad de ser explotadas.
Es recomendable incluir el modelado de amenazas dentro del ciclo de vida del desarrollo de software (SDLC), ya que permite recopilar con precisión toda la información necesaria para la toma de requisitos de seguridad. De esta manera, se pueden gestionar de manera más eficaz los riesgos detectados y realizar tareas de prevención/mitigación incluso antes de iniciar el desarrollo, lo que se traduce en un ahorro significativo de tiempo y recursos.
A continuación, vamos a evaluar un caso práctico muy simple de modelado de amenazas. Nuestro objeto de estudio será una página web que constará de un servidor web, una base de datos y también permitirá alojar ficheros en un bucket de s3.
Para llevar a cabo este modelado, seguiremos los siguientes pasos:
- Identificar los activos del sistema: En primer lugar, identificaremos los componentes de la arquitectura de la aplicación y como se comunican entre sí. En este caso, los activos serían el navegador que utilizan los usuarios para conectarse a la página, el servicio de la aplicación web, la base de datos y el bucket de s3.
- Identificar la información sensible: De esta manera podremos catalogar la criticidad de las amenazas que afecten a la información que viaja entre los diferentes componentes de la aplicación.
- Identificar posibles amenazas en cada activo del sistema o en las comunicaciones entre ellos: Para ello, es posible apoyarnos en guías como OWASP ASVS para la detección de amenazas y por otro lado, basarnos en metodologías que nos ayuden a definir amenazas de manera estructurada. Las más utilizadas son:
- STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of Service Elevation of privilege)
- CIA (confidentiality, integrity and availability)
- LINDDUN (Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, and Non-compliance).
- Identificar medidas de seguridad adecuadas: Una vez que hayamos evaluado las amenazas, tendremos que identificar medidas de seguridad adecuadas para mitigar cada una de ellas. Por ejemplo, identificar que cualquier query que se implemente deberá realizarse con datos sanitizados y prepared statement para evitar ataques SQLi.
- Implementar las medidas de seguridad: Finalmente, tendríamos que implementar las medidas de seguridad identificadas para proteger el sistema contra las amenazas detectadas desde el inicio del desarrollo.
Existen diferentes herramientas que facilitan la realización del modelado de amenazas, por ejemplo, Cairis, IriusRisk, Microsoft Threat Modeling tool, OWASP Threat Dragon, etc. Para el ejemplo de hoy utilizaremos solo la herramienta de OWASP.
 |
| Threat
Dragon |
Mediante esta herramienta, podemos realizar un diagrama de la aplicación de manera muy sencilla, permitiéndonos incorporar las posibles amenazas a cada uno de los componentes del proyecto. Además, Threat Dragon integra las metodologías STRIDE, LINDDUN y CIA anteriormente mencionadas para facilitar y guiar nuestra clasificación de amenazas.
Basándonos en los pasos indicados anteriormente, primero identificaríamos los componentes de nuestra aplicación:
 |
| Componentes de la aplicación |
Una vez identificados los componentes, vemos los flujos de datos por identificar información sensible que viaja entre ellos:
 |
| Flujos
de datos |
Tras el paso anterior, vamos a identificar las posibles amenazas y los límites de confianza dentro de nuestra arquitectura:
 |
| Diagrama
de amenazas de la aplicación |
Threat Dragon también permite diferenciar entre amenazas abiertas y amenazas mitigadas. De esta manera, se puede llevar un control de que amenazas han sido mitigadas y cuáles no.
 |
| Amenazas
abiertas y mitigadas |
Una vez desarrollado el modelado, la aplicación nos facilita un reporte completo con toda la información acerca de las amenazas detectadas con lo que podremos elaborar una lista de requisitos de seguridad.
Como conclusión, todos sabemos que pese a que la toma de requisitos de seguridad es uno de los elementos clave dentro del ciclo de vida de desarrollo de una aplicación, no siempre se realiza de la mejor manera posible. Mediante metodologías como el modelado de amenazas, se puede facilitar y estructurar esta tarea para obtener un listado de requisitos más completo.
English
