Ingeniería de Sistemas

Ciberespacio y Seguridad Digital

Cód. Est:
201921005601 JOSE SEBASTIAN VEGA BARRAGAN
Fecha: 24/09/2020
201921010601 DIEGO FERNANDO HERRERA QUINTANA
201921003601 MICHAEL STEVEN URREGO ROSAS

Trabajo: Metodologías de modelado de amenazas

El objetivo de esta actividad es seguir profundizando en el modelado de amenazas, realizando un trabajo

que contenga al menos el siguiente contenido:

Introducción al modelado de amenazas.

Características del modelado de amenazas.
Metodologías.
Descripción de una metodología en profundidad. Se recomienda la metodología propuesta por
Microsoft o utilizar la explicada en clase magistral.
Herramienta de modelado, se recomienda Threat Modeling Tool (2009) - TMT. Disponible en
http://www.microsoft.com/en-us/download/details.aspx?id=2955
Modelar las amenazas, utilizando una herramienta de modelado como apoyo, del siguiente caso:

Aplicación Web de tres capas para un negocio de pago electrónico, con la siguiente arquitectura:

Servidor de
aplicaciones

Servidor base
de datos
 Introducción

Teniendo en cuenta las vulnerabilidades que tienen hoy en día las herramientas de software, es bastante
importante abordar el tema del Modelado de Amenazas, para evaluar el desarrollo del software seguro, el
acceso seguro a páginas web, así mismo, garantizar que los elementos clave de cualquier organización o
persona se salvaguarden lo más posible. De esta manera se hace una introducción sobre el término de
modelado de amenazas.

La práctica del modelado de amenazas se basa en varias prácticas de seguridad anteriores, en particular la
idea de “árboles de ataque” que se desarrollaron en la década de 1990. En 1999, Loren Kohnfelder y
Praerit Garg, empleados de Microsoft, distribuyeron un documento dentro de la compañía llamado «The
Threats to Our Products” que muchos consideran la primera descripción definitiva del modelado de
amenazas. Kohnfelder y Garg llamaron a su propuesta «el marco STRIDE”

El Modelado de Amenazas de Seguridad es un proceso para la evaluación y documentación de los riesgos

de seguridad de un sistema. El Modelado permite comprender el perfil de amenazas a las que se está
expuesto un sistema, mediante una evaluación a través de los ojos de los potenciales enemigos.

Con técnicas tales como la identificación de puntos de entrada, fronteras de privilegios y árboles de
amenazas, se pueden identificar estrategias para mitigar las posibles amenazas del sistema. El Modelado
de Amenazas también permite la justificación de la implementación de las características de seguridad
dentro del sistema, o las prácticas de seguridad para utilizarlo, para la protección de los activos de la
empresa.

Actualmente en los sistemas distribuidos el compartir datos sensibles a través de las redes ha significado
un aumento de la exposición a los atacantes con deseos de apoderarse de los datos compartidos a través
de los mismos sistemas, para sacar ventaja mayormente negativa sobre un usuario o una organización.
Para evitar este tipo de inconvenientes, la organización debe manejar un marco de referencia para saber
si se está listo o no para adoptar el modelado de amenazas de seguridad y son los siguientes:
• ¿Existe un referente de seguridad en la organización?
• ¿Está el proceso del Ciclo de vida de Desarrollo de Seguridad definido y seguido durante el
desarrollo?
• ¿Ha acordado la organización las contra-medidas para las vulnerabilidades más comunes?
• ¿Están los desarrolladores capacitados para evitar las vulnerabilidades más comunes?
• ¿Realizan los desarrolladores una revisión del código acerca de las vulnerabilidades de seguridad?
• ¿Existe un equipo de evaluación de la seguridad?
Al responder estas preguntas en la organización se tiene una idea mas clara si la misma está preparada
para adoptar el modelado de amenazas. En caso contrario se debe empezar a realizar los cambios
necesarios en cada cuestionamiento para preparar el modelado de amenazas de seguridad.

En esta imagen se puede validar el proceso del modelado de amenazas una vez se empieza a implementar
hasta el momento que se hacen las pruebas en el software o sistema modelado.

El modelado de amenazas va de la mano con una disciplina que trata sobre la construcción de sistemas
que deben permanecer funcionando como se espera ante la maldad, el error, o el azar; Ingeniería de
Sistemas Seguros. Como toda disciplina, se enfoca en los instrumentos, procesos, y métodos que se
emplean para diseñar, poner en práctica, y probar sistemas completos, y adaptar sistemas existentes a su
ambiente.

Características

Las actividades de ingeniería de sistemas involucradas en la construcción de sistemas seguros, son:

1. El desarrollo de requerimientos de seguridad de sistemas.
2. El desarrollo de diseños de sistemas seguros.
3. La integración de componentes de subsistema.
4. Las pruebas de sistemas y subsistemas.
La primera categoría incluye las funciones que ponen en práctica una política de seguridad
(funciones de control de acceso, identificación, autenticación y autorización, y las funciones que realizan
el cifrado y el descifrado, y la gestión de claves) y también las funciones que previenen la violación de las
propiedades de seguridad del sistema o la información que procesa, como el acceso no autorizado, la
modificación, la negación de servicio, descubrimiento, etc. Se conocen también como “requerimientos de
servicios de seguridad”.
La segunda categoría de requerimientos afecta directamente a la probabilidad que el software en sí
mismo sea seguro y, en general, son no funcionales (o propiedades). En conjunto, aseguran que el sistema
ha de permanecer funcionando correctamente incluso cuando se encuentre bajo amenaza; están
orientados a la reducción o eliminación de vulnerabilidades en el software y están vinculados
principalmente al plan de desarrollo de software y al control de gestión del proyecto. Se conocen como
“objetivos de seguridad”.
Durante la obtención de requerimientos se debe recolectar “información relativa a la seguridad” tal como:
a) Determinar y valorar los activos, definiendo qué se va a proteger (activos tangibles o intangibles) y
determinando su valor (económico y no económico).
b) Determinar los actores, dueños de los datos; (c) determinar los casos de uso, roles de cada actor.
c) Determinar los requerimientos legales y de negocios (restricciones legales y de negocios,
requerimientos de auditoría y no repudio, políticas de seguridad).
d) Determinarlas amenazas sobre los activos identificados, su probabilidad de ocurrencia y la política
de manejo.
e) Definir la arquitectura del sistema, entendiendo cómo se integran los mecanismos de seguridad al
sistema.
Respecto al modelado, en esta etapa se realiza una aproximación para descubrir y aprender sobre los
requerimientos del software, lo que proporciona un modo de prever los funcionamientos y las
interacciones del software propuesto dentro de su ambiente.
En el diseño de sistemas seguros, se deben incorporar varios rasgos claves de diseño para orientar la
identificación de vulnerabilidades típicas de sistemas. Son ejemplos ilustrativos: el diseño de protocolo de
seguridad, el diseño de control de acceso y contraseña, el control de publicaciones en sistemas
distribuidos, el control de concurrencia, la tolerancia a fallos, y la recuperación de fallos.
Para el diseño detallado se pueden identificar patrones de diseño. Así como existen patrones de diseño
para problemas recurrentes de sistemas de información, existen también patrones de diseño de
seguridad, que son esencialmente buenas prácticas puestas en forma de plantilla.
Los ‘patrones de ataques’ se estudian y documentan para sistemas operativos, dispositivos de
conectividad, sistemas de gestión de datos, usos y servicios de web, si bien aún no han sido establecidos
para ataques específicos.

Metodologías

Existen diversas metodologías que intentan ayudar en la medición y mitigación del riesgo inherente al
desarrollo de software, las más conocidas son:

• Ace Threat Analysis and modeling.

• CORAS.
• Trike
• PTA (Practical Threat Analysis).

Ace Threat Analysis and Modeling

Microsoft ha desarrollado una metodología de análisis y modelado de amenazas. Esta metodología ha ido
evolucionando y recogiendo ideas de diversos enfoques. La versión inicial, se basa en el uso de árboles de
ataques para luego extrapolar las amenazas y realizar una clasificación y un ranking de estas con el fin de
priorizarlas actuaciones necesarias para mitigar el riesgo. Mientras que, en la segunda versión de esta
metodología, han intentado aclarar los conceptos de amenaza, ataque y vulnerabilidad, actualizando su
herramienta de modelado y cambiando sustancialmente el punto de vista original.

Desde un punto de vista de un posible atacante se trata de identificar:

• Los puntos de entrada de la aplicación.

• Los activos a proteger.
• Los diferentes niveles de confianza.

Se establece cual es el nivel de seguridad del sistema:

• Mediante casos de uso.

• Conociendo las distintas dependencias.
• Utilizando modelos del sistema.

Se determina cuales son las amenazas:

• Se identifican las amenazas.

• Se analizan y clasifican.
• Se identifican las vulnerabilidades a las que se ve expuesto el sistema.

Pasos del modelado de amenazas según Microsoft Según la metodología propuesta por Microsoft, los
cinco pasos del proceso de modelado de amenazas son:

1. Identificar los objetivos de seguridad: Determinar cuáles son los objetivos ayudará a cuantificar el
esfuerzo se debe dedicar a los siguientes pasos.

2. Crear una descripción general de la aplicación: Identificar los actores involucrados y las
características más importantes de la aplicación facilitará la identificación de las amenazas más
importantes.

3. Descomponer la aplicación: Una vez que se conoce la arquitectura, es preciso identificar las
funcionalidades y los módulos susceptibles de provocar un mayor impacto en la seguridad.

4. Identificar amenazas: Con la información recopilada, y en función del contexto y el escenario de la

aplicación, se procede a la identificación de las amenazas más importantes.

5. Identificar vulnerabilidades: Revisar las diferentes capas de la aplicación para identificar los
puntos débiles.

Durante el desarrollo del modelado, se utilizan diferentes métodos, como los árboles de ataques y los
diagramas de flujo de datos. Para saber cuáles son las amenazas es preciso conocer cuáles son los puntos
de entrada, los niveles de confianza y los activos de mayor interés. Para ello se utilizan los diagramas de
flujo de datos, para comprender la lógica de la aplicación y saber cómo puede afectar el tratamiento de los
datos a la integridad de los activos.

CORAS
(Consultative Objective Risk Analysis System), es un proyecto creado por la unión europea con el objetivo
de proporcionar un framework orientado a sistemas donde la seguridad es crítica, facilitando el
descubrimiento de vulnerabilidades de seguridad, inconsistencias, y redundancias.

CORAS proporciona un método basado en modelos, para realizar análisis de riesgos, y se basa en el uso
de tres componentes:
• Un lenguaje de modelado de riesgos basado en el UML.
• La metodología CORAS, una descripción paso a paso del proceso de análisis con una directriz para
construir los diagramas CORAS.
• Una herramienta para documentar, mantener y crear los informes del análisis.

Aunque no es exactamente un framework para el modelado de amenazas, su uso orientado a tal fin, puede
contribuir a la reducción de riesgos y la adopción de unas correctas contramedidas, por lo que me ha
parecido interesante mencionarlo. Tan sólo trataré de dar una visión general sobre el mismo, sin
extenderme demasiado. Al final de este artículo se incluyen referencias a otra documentación que puede
ser de interés para quien desee profundizar en el uso de CORAS.

La metodología CORAS, hace un uso intensivo de los diagramas.

Existen 5 tipos diferentes:

• Diagrama superficial de activos: Muestra una visión general de los activos y cómo el daño sobre un
activo puede afectar al resto.
• Diagrama de amenazas: Muestra una visión completa de la secuencia de eventos iniciados por las
amenazas y las consecuencias que tienen éstas sobre los activos. Sus componentes básicos se muestran en
el ejemplo inferior, y son: amenazas deliberadas, amenazas accidentales, amenazas no-humanas,
vulnerabilidades, escenarios de amenazas, incidentes no deseados y activos.
• Diagrama superficial de riesgo: Es un resumen del diagrama de amenazas, mostrando los riesgos.
Tiene 5 componentes básicos: amenazas deliberadas, accidentales y no-humanas, riesgos y activos. A
cada riesgo se le asigna un valor.
• Diagrama de tratamiento: ofrece una visión completa de las contramedidas propuestas. Se basa en
el diagrama de amenazas, sustituyendo las consecuencias del impacto sobre los activos con los riesgos
procedentes del diagrama superficial de riesgo, y añadiendo los escenarios de contramedidas propuestos.
• Diagrama superficial de tratamiento: es un resumen de las contramedidas, añadiendo los distintos
escenarios posibles y mostrando las relaciones entre los distintos elementos propuestos para tratar el
riesgo.

Trike
Los creadores de Trike, aportan a la comunidad open source, un framework y una metodología
conceptual, acompañada por una herramienta que intenta facilitar el proceso de modelado. La
metodología, está diseñada con el propósito de permitir al analista describir de forma completa y precisa
las características de seguridad de un sistema, desde los detalles de alto nivel de la arquitectura, hasta la
implementación.

A día de hoy, la última versión disponible de la herramienta, data del 7 de Febrero de este año 2006, y el
borrador de la metodología es de 2005. Por lo que hace pensar que no están muy actualizados.

PTA (Practical Threat Analisys)

La empresa PTA Technologies ha desarrollado su propia metodología que trata de solventar las
limitaciones que según ellos tiene la versión 1 de la metodología propuesta por Microsoft. PTA CTMM
(Calculative Threat Modeling Methodology) es el nombre que recibe.
Antes de comenzar el proceso de modelado, el analista debe familiarizarse con la aplicación / sistema.
Resultando particularmente útil recopilar la siguiente documentación con el fin de que nos sirva de ayuda
en el momento de decidir si se aplican o no los distintos escenarios del sistema que vamos a modelar:

• Descripción funcional del sistema donde se incluyan casos de uso típicos.

• Diagrama de la arquitectura del sistema y documentación de los distintos módulos.
• Un diccionario de términos, donde se expliquen los distintos vocablos utilizados en los restantes
documentos.

Etapas de la metodología
1. Identificación de activos. Se determina cuales son los activos de mayor valor que deben ser
protegidos ante posibles daños, con el fin de determinar las prioridades.
2. Identificación de las vulnerabilidades. Dependiendo de la arquitectura, funcionalidad y la lógica
del negocio se determina de forma iterativa cuales son las vulnerabilidades.
3. Definición de contramedidas. Se establecen las contramedidas a adoptar en función de las
vulnerabilidades y del coste que supondrá su implementación.
4. Creación de escenarios de amenazas y planes de mitigación. Se identifican los distintos elementos
de las amenazas y los parámetros de la forma siguiente:

• Mediante una breve descripción del escenario.

• Identificando los activos que se ven amenazados y su nivel de daño potencial.
• Se calcula el nivel de riesgo de la amenaza de forma automática, basándose en el daño total que
podría ser ocasionado y en la probabilidad de ocurrencia de la amenaza.
• Identificando cuales son las vulnerabilidades del sistema que pueden ser explotadas para que la
amenaza exista. Automáticamente se genera una lista de contramedidas.
• Se selecciona la combinación de contramedidas más efectiva de acuerdo al plan de mitigación más
conveniente.

Para comenzar el proceso de análisis de las amenazas, se puede utilizar una serie predefinida de activos,
vulnerabilidades y contramedidas típicas. Como resultado del proceso de análisis obtendremos:

• Un listado de las amenazas, su riesgo y daño potencial sobre los activos si éstas se materializan.
• Una lista de activos y su riesgo financiero.
• Las contramedidas, junto con el efecto general de mitigación obtenido, así como el coste-
efectividad relativo a la contribución de cada contramedida a la reducción del riesgo del sistema.
• El máximo riesgo financiero del sistema, el riesgo final del sistema una vez que se hayan
implementado todos los planes de mitigación. El nivel actual de riesgo presente en el sistema en base al
nivel de implementación del plan de contramedidas.

La herramienta que acompaña a la metodología PTA permite el uso de etiquetas para describir las
diferentes áreas de la arquitectura del sistema. Un listado de etiquetas con información relevante nos
facilitará la clasificación de los diferentes elementos que componen el modelado.

Es recomendable también, examinar cómo se comporta el modelo en respuesta a los cambios que
hagamos en los distintos parámetros y realizar distintas pruebas de escenarios que puedan contribuir a
ajustar el modelado a un escenario lo más realista posible.

Herramienta de Modelado

Dentro del mundo de la informática existen herramientas que ayudan para el modelaje de amenazas para
la siguiente práctica se utilizara una de las herramientas que brinda la familia Microsoft llamada
ThreatModelingTool para ello se procede a realizar la descarga e instalación de la misma como se
podrá observar las siguientes ilustraciones:
Ilustración 1 Descarga Herramienta
Una vez instalado se procede a realizar el respectivo modelaje de datos para ello se abre la aplicación y se
selecciona la primera opcion de crear un modelo.
Para este ejemplo se creara un ejemplo de una casa inteligente para ello se crean las siguientes
conexiónes, dispositivos y demas, lo cual se podra ver en las siguientes ilustraciones.

Dispositivos de la casa inteligente

Conexión de la nube con la aplicación de la casa inteligente

Proveedor de Internet y su respectiva interaccion con cada secuencia y dispostivos

Base de Datos y la respectiva interaccion entre la aplicación web para el almacenamiento de los datos.
Interaccion Humana teniendo en cuenta los dispositivos moviles

Dentro de la secuencia del modelo existen conexiones HTTPS, Bluetooth, TCP, Wifi, 5G, Datos del flujo
de trabajo despues de crear las respectivas areas el modelo en general quedara así como se puede ver en
la siguiente ilustracion.

Gracias al uso de esta herramienta se puede generar un reporte del respectivo modelo creado para ello es
necesario realizar la siguiente accion;
En la barra de tareas, la opcion Reports se desplegan dos opciones para ello se seleccionara la primera la
cual genera un reporte completo
Luego saldra una ventana para confirmar la generacion del reporte en un formato HTML para ello se da
click en la opcion Generate Report y se le da una ruta para guardar dicho archivo.

Una vez descargado el reporte al ser un archivo HTML se puede ejecutar usando cualquier navegador
para el caso del reporte generado de esta secuencia se puede puntos de vista como diagramas en total
creados, intereacciones entre diagramas e interacciones de los tipos de conexiones ya sean HTTP, 5G,
Generic Flow Data, TCP etc.

Debido a que son varias ilustraciones se adjuntara el archivo en el documento.

Reporte.htm