Estudiando para la certificación de Amazon Certified Solutions Architect, he estado investigando más a fondo sobre cómo crear un Modelo de Amenazas (Threat Model) para una aplicación. Es uno de los requisitos para el examen y he encontrado que es una disciplina originada recientemente (2004) y que ha evolucionado con diferentes ópticas.

Encontré algunas buenas fuentes desde el Open Web Application Security Project OWASP - Threat Risk Modeling. Adicionalmente, de Microsoft, la herramienta de modelado de seguridad SDL de Microsoft y algunos casos prácticos

Veamos esto en mayor detalle.

¿Qué es un Modelo de Amenazas?

De acuerdo con la definición en español de MSDN:

El análisis de modelo de amenazas (TMA) es un análisis que ayuda a determinar los riesgos de seguridad que pueden afectar en un producto, aplicación, red o entorno, así como la forma en la que se aparecen los ataques. El objetivo consiste en determinar cuáles son las amenazas que requieren mitigación y los modos de hacerlo.

 Tipos de Análisis

Es conveniente comprender desde dónde hacemos un análisis de amenazas pues cada perspectiva nos dará diferentes puntos de partida:

• Centrado en el atacante: ¿Qué quiere el atacante, por qué y para qué? Conocer qué es lo que busca un atacante es esencial para saber lo que debemos proteger y cómo es probable que nos ataque.

• Centrado en el software: ¿Qué vulnerabilidades tiene el software que usamos en nuestra aplicación? Analizando capa por capa encontraremos una lista de vulnerabilidades por aplicación o componente. En casos de software muy débil, es muy probable recibir ataques solo porque es fácil atacarnos. Es el caso de los script kiddies, o ‘atacantes desocupados’ que usan herramientas para aprovechar vulnerabilidades conocidas en una aplicación y atacar a cuanto sitio puedan acceder.

• Centrado en los activos: ¿Qué activos de nuestra organización debemos proteger y a qué nivel? No es lo mismo proteger un blog con información pública que un sistema que almacena información financiera de una empresa transada en la bolsa. Entre más valiosos nuestros activos, más cuidado es necesario tener.

Defensivo o por Adversario

Actualmente se usan diferentes aproximaciones para la introducción de conceptos de seguridad en un proyecto.

Lo más común es hacer un análisis tipo adversario que ocurre antes de lanzar a producción una aplicación. Esto incluye pruebas de penetración y análisis de código. El problema es que estas actividades ocurren una vez está terminado el código, cuando puede ser demasiado tarde. Al encontrar fallas de seguridad, estas pueden ser mucho más costosas de corregir que una falla (bug) funcional pues es probable que afecten diversas partes de la aplicación y surjan de la arquitectura misma.

Por otro lado está un análisis complementario, conocido como defensivo. En este análisis se valoran los riesgos antes de escribir el código y, al compartirlos con el equipo de desarrollo es posible identificar los riesgos y tomar medidas tempranas.

Pasos

Estos son algunos pasos básicos par el modelo de amenazas, tomados de la página en inglés de Wikipedia sobre Threat Model:

Definir los requerimientos de la aplicación:

• Objetivos de negocio
• Roles de usuario que van a interactuar con la aplicación
• Identificar los datos que se van a manipular
• Establecer casos de uso en que se trabaja con los datos
• Modelar la arquitectura de la aplicación
• Modelar los componentes de la aplicación
• Modelar los roles bajo los cuales interactuan los componentes
• Modelar las dependencias externas
• Modelar los llamados de los roles a los componentes así como los conjuntos de datos de cada uno
• Indentificar amenazas de confidencialidad, disponibilidad e integridad de los datos y la aplicación de acuerdo con la matriz de acceso a datos que debe garantizar la aplicación
• Asignar valores a los riesgos y determinar las respectivas respuestas a los riesgos
• Determinar medidas de control basadas en las respuesta a los riesgos
• Actualizar el modelo de amenazas ante cambios de diseño en la aplicación o novedades en la seguridad

Conclusión

El Modelo de Amenazas nos da un marco organizado para identificar y mitigar la exposición de nuestra aplicación a incidentes de seguridad. Lo más importante es no esperar a que sea demasiado tarde y por lo tanto introducir el modelo de amenazas al inicio de un proyecto.