Muciber06 Estandar Act1

Asignatura Datos del alumno Fecha
Nombre de la asignatura Apellidos:

Desarrollo Seguro de
Software y Auditoría Nombre:
Metodologías de modelado de amenazas
Objetivos
Una amenaza a un sistema es cualquier actor, agente, circunstancia o evento que

tiene el potencial de causarle daño o a sus datos, servicios y recursos. Con la
presente actividad se pretende conseguir los siguientes objetivos:
 Estudio y análisis de la arquitectura de una aplicación para poder determinar el

nivel de riesgo y seguridad de las soluciones técnicas a incluir en su diseño.
 Analizar y detectar amenazas de seguridad y desarrollar técnicas para su
prevención.
 Aprender a diseñar e implantar sitios, servicios y aplicaciones con garantías de
seguridad.
 Facilitar la identificación de las condiciones o aquellas vulnerabilidades que, una
vez eliminadas o contrarrestadas, afectan a la existencia de múltiples amenazas.
 Proporcionar información relevante sobre cuáles serían las contramedidas más
eficaces para contrarrestar una posible amenaza y/o mitigar los efectos de la
presencia de una vulnerabilidad en el diseño de una aplicación.
Pautas de elaboración
Para seguir profundizando en el modelado de amenazas se propone realizar este

trabajo que contenga al menos el siguiente contenido:
© Universidad Internacional de La Rioja (UNIR)
 Introducción al modelado de amenazas.

 Ejercicio práctico de modelado de amenazas utilizando una herramienta de
modelado como Threat Analysis and Modeling Tool 2016, del siguiente caso que
1
Actividades
se describe a continuación (incluir los ficheros generados por la herramienta

junto con el del trabajo en un fichero a subir en la plataforma).
Caso práctico
Con el objetivo de afianzar los conocimientos adquiridos sobre el modelado de

amenazas, se pide definir, modelar y medir las posibles amenazas de una tienda de
libros online, llamada Librería On-Line S. A.
Últimamente, sufrió un ciberataque que ha comprometido las credenciales de sus

clientes. El incidente ha trascendido en los medios de comunicación, lo que produjo
una pérdida de cuota de mercado importante frente a sus competidores.
Con el objetivo de mantener su actual posición en el mercado de venta electrónica

de libros y volver a recuperar, e incluso superar, la que tenía, ha contratado a la
empresa InfoSecurity para llevar a cabo un trabajo de modelado de amenazas a sus
sistemas TI e implementar las salvaguardas que se deriven del mismo en función del
nivel de riesgo y la disponibilidad económica. Se le establece los siguientes
requisitos de negocio y técnicos:
 Habrá tres tipos de usuarios en la aplicación: clientes, administrador TI y agente

de ventas.
 Los clientes deben poder buscar productos y gestionar sus pedidos utilizando la
tienda web o llamando a la oficina de ventas.
 Para
© Universidad Internacional que
de La un(UNIR)
Rioja cliente pueda realizar un pedido debe, con anterioridad, registrase
para crearse una cuenta.
 El cliente puede pagar con una tarjeta de crédito, débito o mediante trasferencia
bancaria.
 Los clientes deben iniciar sesión antes para poder personalizar sus preferencias.
2
Actividades
 Los clientes deben ser capaces de revisar y modificar sus pedidos realizados.
 Los agentes de ventas pueden conceder descuentos a los clientes.
 Los administradores pueden modificar y eliminar clientes, así como productos e
información.
 La tienda web de la librería tendrá que ser accesible desde Intranet e Internet.
 La tienda web deberá diseñarse con una arquitectura distribuida por razones de
escalabilidad.
 El cliente necesitará autenticarse en la tienda web con las credenciales de la
cuenta de usuario, que a su vez se comprobarán contra la base de datos
implementada en el backend de la compañía a través de una interfaz de servicios
web.
 La información de la cuenta del usuario y la información del producto deberán
mantenerse en una base de datos relacional.
 El procesamiento de tarjetas de crédito será subcontratado a un procesador de
terceros.
 Las interacciones de los usuarios con la tienda web se almacenan en un servidor
de log interno de la organización.
 La base de datos deberá copiarse periódicamente en una ubicación de un
proveedor de servicios TI de terceros, para propósitos de recuperación ante
desastres.
 El sitio web se diseñará lógicamente como una aplicación cliente/servidor
distribuida conforme a un modelo de tres capas: presentación, proceso y datos.
 Los clientes accederán a la aplicación utilizando navegadores web de escritorio y
dispositivos móviles.
 El sitio
© Universidad Internacional web(UNIR)
de La Rioja se desplegará en Internet protegido por una DMZ de dos capas con
acceso tanto para usuarios internos como externos.
 Físicamente, la aplicación estará por completo alojada en un servidor de
aplicaciones (frontend) alojado en la DMZ, con acceso a un servidor de base de
datos que estará en la red interna de la compañía (backend).
3
Actividades
 La tecnología usada en el desarrollo de la aplicación web es ASP.Net, que utiliza C

#, y la base de datos del backend de la compañía está implementada en base al
producto Microsoft SQL Server.
Los objetivos de seguridad establecidos para la tienda web de Librería On-Line S. A.

son los siguientes objetivos:
 OB-1. Mantener confidencialidad, integridad y disponibilidad de la información

almacenada y trasmitida.
 OB-2. Proporcionar un servicio seguro a los clientes existentes y potenciales.
 OB-3. Proporcionar un servicio ininterrumpido a los clientes existentes y
potenciales. Se aplicarán técnicas de monitorización, equilibrio de carga,
replicación, recuperación ante desastres y continuidad del negocio y copias de
seguridad recuperables.
 OB-4. Establecer procesos de autenticación, autorización y auditoría que
mejoran la seguridad de la aplicación.
El sistema estará basado en una típica arquitectura de una aplicación web de tres
capas, donde el cliente es un navegador que accede a los servicios proporcionados
por el sitio web de la librería, que contiene una base de datos de los clientes,
cuentas y publicaciones disponibles, alojada en un servidor de bases de datos y un
servidor web que implementa toda la lógica de negocio.
Se debe tener en cuenta que nos encontramos en la fase análisis de requisitos del
SDLC, deidentificando
© Universidad Internacional La Rioja (UNIR) requisitos funcionales y de seguridad. Una vez identificados y
comprendidos los objetivos de seguridad, procederemos a realizar el modelado de
amenazas conforme al método Modelado de Amenazas, que se resume en el
siguiente diagrama:
4
Actividades
Figura 1. Modelado de Amenazas. Fuente: elaboración propia.
Modelado de la aplicación
 Identificación de actores y sus niveles de confianza
Los requisitos que se establecen para los actores, tanto humanos como de otro tipo,
son los siguientes:
• Los clientes deben poder buscar productos y realizar sus pedidos utilizando la
tienda web o llamando a la oficina de ventas.

• Los agentes de ventas pueden conceder descuentos a los clientes.
• Los administradores pueden modificar y eliminar la información del cliente y

del producto.
• La base de datos deberá copiarse periódicamente a una ubicación de un
tercero, proveedor de servicios IT, para propósitos de recuperación ante
desastres.
5
Actividades
• Los eventos del sistema se almacenarán de forma periódica en un servidor de
log centralizado de la compañía. Se transmitirán de forma cifrada y con

protección de su integridad.
Esto nos ayuda a identificar tres actores humanos del sistema: clientes, agentes de
ventas y administradores. Entre los actores no humanos se pueden incluir procesos
que respaldan periódicamente los datos a la ubicación de proveedor de servicios IT,
procesos de almacenamiento de log, etc.
Se asigna un identificador único a cada actor y se utiliza para poder realizar una
referencia cruzada de los actores y su nivel de confianza con los puntos de entrada y
los activos.
Id Nombre Descripción
1 Cliente anónimo usuario del Cliente que se ha conectado al sitio web de la compañía, pero no
sitio web ha proporcionado credenciales válidas.
2 Usuario con credenciales de Usuario que se ha conectado al sitio web de la compañía y ha
inicio de sesión válidas iniciado sesión utilizando credenciales válidas.
3 Usuario con credenciales de Usuario que se ha conectado al sitio web de la compañía que está
inicio de sesión no válidas intentando iniciar sesión con credenciales no válidas.
4 Agente de ventas Usuario que puede crear usuarios en el sitio web de la compañía
y ver su información personal.
5 Administrador del servidor de El administrador del servidor de bases de datos administra la
base de datos base de datos del sitio web de la compañía.
6 Administrador del sitio web El administrador del sitio web que puede configurar y administrar
el sitio web de la compañía.
7 Proceso del usuario del Proceso que en el servidor web que ejecuta código de usuario y
servidor web se autentica contra el servidor de base de datos.
8 Usuario de lectura de la base Cuenta de usuario utilizada para acceder a la base de datos en
de datos modo lectura.
9 Usuario de lectura/escritura Cuenta de usuario utilizada para acceder a la base de datos en
de la base de datos modo lectura y escritura
10 Proceso de back up Proceso que realiza una copia periódica de la base de datos en
una ubicación de un tercero.
6
Actividades
11 Proceso de realización de Proceso que realiza el pago de los pedidos con tarjeta de crédito.
pagos.
12 Proceso de almacenamiento Proceso que realiza el almacenamiento de los eventos del
log. sistema en el servidor centralizado de almacenamiento de logs de
la compañía.
Tabla 1.Tabla de actores.
El estudiante, si lo considera, puede completar más la tabla con nuevos activos que
considere en su diseño. Se tendrá en cuenta en la nota final.
 Identificar activos:
En la siguiente tabla se presentan los activos identificados en el sistema.
Tipo Id Nombre Descripción Actores

1 Servicio de venta de Servicio a disposición de los clientes para la venta de
libros. libros
2 Datos de la tarjeta de Datos exigidos en la aplicación a la tarjeta de crédito,
crédito. como su número, fecha de caducidad, etc.
3 Datos inicio de sesión del Los credenciales que el cliente utilizará para iniciar (2), (4), (5), (7),
cliente. sesión en el sitio web de la compañía Librería On-Line S. (8), (9)
Activos primarios de información y servicios
A.
Datos inicio de sesión del Los credenciales que el agente de ventas utilizará para
4 agente de ventas. iniciar sesión en el sitio web de la compañía Librería On-
Line S. A.
Datos inicio de sesión del Los credenciales que el administrador utilizará para
5 administrador. iniciar sesión en el sitio web de la compañía Librería On-
Line S. A.
Datos de los pedidos. Todos los datos asociados al pedido de libros realizado
6
por un cliente.
Datos de los productos. El sitio web de la compañía Librería On-Line S. A.
7 Rioja (UNIR)
© Universidad Internacional de La almacenará información de los productos en el sitio
web
Datos personales. El sitio web de la compañía Librería On-Line S. A.
8 almacenará información personal relacionada con
clientes, agentes de ventas y administrador.
9 Disponibilidad del sitio El sitio web de la compañía Librería On-Line S. A. debe
Activ
web. estar disponible en régimen de 24x7 para los clientes.
7
Actividades
Capacidad realizar Capacidad realizar peticiones de pago a un procesador

10
peticiones de pago. de tarjetas de crédito externo
Capacidad ejecutar Representa la capacidad de ejecutar código en el
11 código en el servidor servidor web como un usuario de este.
web.
Capacidad de ejecutar Representa la capacidad de ejecutar consultas SQL a la
consultas SQL a la base de base de datos, para recuperar cualquier información
12
datos como un usuario de almacenada dentro de la base de datos de la compañía
sólo lectura. Librería On-Line S. A., como un usuario de lectura.
Capacidad de ejecutar Representa la capacidad de ejecutar consultas SQL para
consultas SQL a la base de leer, insertar y actualizar base de datos de la compañía
os secundarios de sistema y aplicación
13
datos como un usuario de Librería On-Line S. A., como un usuario de lectura y
lectura y escritura. escritura.
Capacidad de Capacidad de realizar un back up de la base de datos en
14
recuperación de datos. un proveedor de servicios externo a la compañía.
Inicio de Sesión. Sesión de acceso de un usuario al sitio web de la
15 compañía Librería On-Line S. A. El usuario podría ser un
cliente, el agente de ventas o el administrador.
Acceso al servidor de Acceso al servidor de base de datos para administrarlo y
16
base de datos. demás usuarios en función de sus permisos
Capacidad de crear Capacidad de crear usuarios en el sistema. Estos
17 usuarios. podrían ser clientes, el agente de ventas o el
administrador.
Capacidad de enviar los Capacidad de enviar los log de servidor web y el de la
18 eventos del sistema. base de datos a un servidor centralizado de log de la
compañía.
Accesos a los log del Capacidad para auditar todos los eventos auditables
18 sistema. que ocurrieron dentro del sistema de ventas de la
Librería On-Line S. A.
Tabla 2. Tabla de Activos.
El estudiante debe rellenar la columna de la derecha, «actores», con el identificador

asignado a los actores en la tabla «actores y niveles de confianza» del anterior
apartado.
Si lo considera puede completar más la tabla con nuevos activos que considere en
su diseño. Se tendrá en cuenta en la nota final.
Definir la arquitectura
8
Actividades
 Matriz de control de acceso a los datos:
Los datos de la aplicación comprenden la información del cliente (cuenta, dirección

de facturación, dirección de envío, etc.), producto (datos del producto, etc.), pedido
(datos de pedido, lista de materiales, fecha de envío, etc.) y tarjeta de crédito
(número de tarjeta de crédito, código de verificación, mes y año de vencimiento,
etc.). Dado que la tienda web procesará información de tarjetas de crédito, la
información de los datos de la tarjeta del cliente deberá protegerse de acuerdo con
los requisitos de la norma PCI DSS.
La matriz de control de acceso a los datos indica los derechos y privilegios (Create
[C], Read [R], Update [U] o Delete [D]) que los actores tendrán sobre los diferentes
tipos de datos del sistema.
Usuarios (roles)
Administrador Cliente Agente ventas

Datos de Clientes C,R,U,D
Datos de productos
Datos
Datos de pedidos
Datos de tarjeta de crédito
Tabla 3. Matriz de control de acceso.
El estudiante deberá completar la tabla con los derechos y privilegios (Create [C],
Read [R], Update [U] o Delete [D]) que los actores tendrán sobre los diferentes tipos
de datos del sistema.

 Determinar los componentes, servicios, protocolos y puertos de la aplicación:
Los usuarios se conectarán a la aplicación web a través del puerto del puerto 443
(https). La aplicación web se conectará a la base de datos del servidor SQL a través
9
Actividades
del puerto 1433 (mediante TCP / IP). Cuando los usuarios usan un protocolo HTTPS
sobre el puerto 443, el certificado SSL también se considera un componente y
necesitará estar protegido contra amenazas de falsificación, robo e integridad.
 Diseño de la autenticación de las entidades:
El usuario se autenticará en la aplicación web mediante formulario (nombre de

usuario y contraseña), que a su vez se autenticará contra la base de datos de SQL
Server (implementada internamente) a través de una aplicación de servicios web,
utilizando una identidad de la aplicación web.
 Identificación de tecnologías:
La aplicación web está desarrollada en ASP.Net usando C # mientras que la base de

datos se ha implementado en base al producto Microsoft SQL Server en su última
versión. El servidor web se implementa en base al producto Internet Information
Server (ISS) para dar soporte a la tecnología ASP.Net y la elección de SQL Server
como base de datos del backend. Con ASP.Net utilizará el frame .Net 3.5 o .Net 4.0.
 Determinar la topología lógica:
La topología lógica del sistema es conforme a la siguiente figura:
10
Actividades
Figura 2. Topología lógica de la aplicación.
Descomponer la aplicación
 Identificar las fronteras de confianza:

Un límite de confianza es el punto en el que cambia el nivel de seguridad. Para la
tienda web de este ejercicio tenemos las siguientes fronteras de confianza.
• Entre el exterior (Internet) y la DMZ.
• Entre la DMZ y las zonas internas (Intranet).
 Definir los puntos de entrada:
Los puntos de entrada son aquellos elementos que incorporan la entrada del
usuario y definen las interfaces a través de las que los potenciales agentes
maliciosos pueden interactuar con la aplicación con el objetivo de introducir datos
con carácter
© Universidad Internacional de La Riojamalicioso.
(UNIR) Para atacar una aplicación, deben existir puntos de entrada,
por lo tanto, constituyen una fuente potencial de amenaza. Cada uno debe ser
explícitamente identificado y salvaguardado. Los puntos de entrada en una
aplicación web pueden incluir cualquier página que tenga en cuenta la entrada del
usuario.
11
Actividades
Algunos de los puntos de entrada identificados en la tienda web del ejercicio

pueden ser los siguientes:
Puntos de entrada
ID Nombre Descripción Actores
1 Puerto HTTPS El sitio web de la compañía “Librería On-Line SA” es (1), (2), (3), (4)
solamente accesible a través del protocolo TLS.
Todas las páginas dentro del sitio web están en
capas desde este punto de entrada.
1.1 Página Página de presentación del sitio web de la compañía
principal de la “Librería On-Line SA”. Es el punto de entrada para
tienda todos los usuarios, tanto los maliciosos como los
que no.
1.2 Página de Los clientes y agentes de ventas utilizan esta página
Inicio de para iniciar sesión en el sitio web de la compañía
Sesión “Librería On-Line SA”.
1.2.1 Funcionalidad La función de inicio de sesión acepta las
de Inicio de credenciales suministradas por el usuario y las
Sesión compara con las de la base de datos.
1.3 Página de La página utilizada para realizar búsquedas.
búsqueda
1.4 Página de Página donde se configuran las preferencias de los
preferencias usuarios
1.5 Página de Página para la administración del catálogo de
administración productos
Tabla 4. Puntos de entrada de la aplicación.
El estudiante debe rellenar la columna de la derecha «actores» con el identificador

asignado a los actores en la tabla «Actores y niveles de confianza» del siguiente
apartado.
Si lo considera, puede completar más la tabla con nuevos activos que considere en
 Identificar puntos de salida:
12
Actividades
Los puntos de salida son aquellos elementos que muestran información desde el
sistema. También incluyen procesos que extraen datos del sistema. Además,
pueden ser la fuente de fuga de información y deben estar igualmente protegidos.
Algunos de los puntos de salida identificados en la tienda web de la compañía
Librería On-Line S. A., son los siguientes:
Puntos de entrada
ID Nombre Descripción Actores
1 Página de resultados La página utilizada para presentar los resultados
de búsqueda de las búsquedas.
2 Página de Página donde se muestran las preferencias de los
preferencias usuarios.
3 Página de Catalogo Página que presenta los resultados de la
de producto administración del catálogo de productos.
4 Procesos tarjetas de Procesos de verificación de tarjetas de crédito y
crédito realización de pagos.
5 Procesos de copia de Proceso que realiza una copia periódica de la
seguridad base de datos a una ubicación de un tercero.
6 Proceso de Proceso que realiza el almacenamiento de los
almacenamiento log eventos del sistema en el servidor centralizado
de almacenamiento de log de la compañía.
Tabla 5. Puntos de salida de la aplicación.
El estudiante debe rellenar la columna de la derecha «actores» con el identificador

asignado a los actores en la tabla «Actores y niveles de confianza» del siguiente
apartado.

Si lo considera, puede completar más la tabla con nuevos activos que considere en
 Identificar dependencias externas:
13
Actividades
Las dependencias externas son elementos externos al código de la aplicación que

pueden suponer una amenaza para la misma. Las dependencias externas serían:
Dependencias Externas
I Descripción
D
1 Servicio de copia periódica de la base de datos a una ubicación de un tercero.
2 Servidor que almacena de los eventos del sistema en el servidor centralizado de almacenamiento de log
de la compañía.
3 Servicio de verificación de tarjetas de crédito y realización de pagos
Tabla 6. Dependencias externas.
 Realización del diagrama de flujo de datos (DFD).
Una vez recopilada toda la información sobre la aplicación en los apartados

anteriores estamos en disposición de modelar con precisión la aplicación mediante
el uso de Diagramas de Flujo de Datos (DFD). Estos desgramas nos permiten
obtener una mejor comprensión de como la aplicación aceptará, procesará y
manejará los datos a medida que se distribuyen a través de sus diferentes límites de
confianza. Hay una serie de símbolos que se utilizan en este tipo de diagramas, en la
siguiente figura os muestro un resumen de los más importantes:
14
Actividades
Figura 3. Símbolos de los diagramas de flujo de datos (DFD).
Para la realización del DFD se utilizará la herramienta Threat Análisis and Modeling
Tool 2016 de la compañía Microsoft, descargable en el siguiente enlace:
https://docs.microsoft.com/es-es/azure/security/develop/threat-modeling-tool
En el anterior sitio web hay guías de ayuda y documentación del uso de la

herramienta. Además, como ayuda se aconseja visionar estos dos videos:
• AppSecEU 16 - Matthias Rohr - Practical Threat Modeling with Microsofts
Threat Modeling Tool 2016: https://www.youtube.com/watch?

v=C5IPkuDnOGs

• Microsoft SDL Unit04 - Threat Modeling Principles (Level 100):
https://www.youtube.com/watch?v=WGz2JQ1OlGQ
15
Actividades
Una vez instalada la herramienta, para la realización de DFD hay que trabajar en la
vista de diseño, que se obtiene al pulsar el en menú View/Desing View, tal y como
se muestra en la siguiente figura:
Figura 4. Vista de Diseño de la herramienta Threat Analysis and Modeling Tool 2016.Fuente: elaboración
propia.
Os propongo modelar la aplicación mediante el siguiente diagrama DFD que

constituye una representación gráfica que agiliza el proceso de modelado de
requerimientos y al mismo.
En la siguiente figura os muestro un modelo básico como ayuda a la realización del

diagrama DFD de la aplicación propuesta. Como se indica en un modelo básico que
tiene mucho margen de mejora. El alumno que lo mejore se le tendrá en cuenta en
la nota.
16
Actividades
Figura 5. Modelo básico de diagrama DFD.
Una vez en esta vista hay que empezar a realizar el diagrama DFD conforme a todos
los datos obtenidos en las etapas anteriores de forma que sea acorde a la topología
lógica indicada en la Figura 2. En el cuadro de la derecha, stencil, están los
diferentes elementos que se pueden elegir para realizar el diagrama, con más
extensión que lo indicado en el resumen de la Figura 3.
No olvidar configurar las propiedades de cada elemento del diagrama, por ejemplo,
configurar autenticación y autorización en el servidor web protegerá de posibles
amenazas y la herramienta lo tendrá en cuenta a la hora de calcularlas. Además,
saldrán amenazas repetidas. Es decir, se tendrán menos amenazas. Un ejemplo
puededeser
© Universidad Internacional el siguiente,
La Rioja (UNIR) aunque el alumno lo puede modelar de forma diferente
según considere:
17
Actividades
Identificación de Amenazas
 Determinar las amenazas a cada componente de la aplicación:
Una vez realizado el diagrama DFD pasamos a la vista de análisis pulsando en el

menú View/Analysis View. Al pasar a esta, la herramienta calcula automáticamente
las amenazas sugeridas para el diagrama de flujo de datos dibujado. Al cliquear en
cada una de ellas vemos información en detalle de las mimas y algún formulario
para introducir más información como podría ser las salvaguardas que la mitiguen y
su justificación.
Figura 6. Vista de análisis de la herramienta Threat Analysis and Modeling Tool 2016.
La herramienta identifica las amenazas a nivel de red, host y aplicación utilizando el

© Universidad Internacional
método de La Rioja (UNIR)
STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial
of service, Elevation of privilege), en castellano Suplantación de Identidad,
Manipulación maliciosa de datos, Repudio, Divulgación de información, Denegación
de servicio y Escalado de privilegios. Este método se aplica, por cada elemento de la
18
Actividades
aplicación identificado en la etapa anterior, analizando a que categorías de

amenazas mencionadas es sensible.
Figura 6. Relación entre las amenazas del método STRIDE y los elementos de un diagrama DFD.
Cuando se selecciona la vista de análisis, la herramienta mostrará las amenazas

sugeridas para el diagrama de flujo de datos dibujado, donde al clicar en cada una
de ellas nos permite introducir las salvaguardas que consideremos y el análisis
DREAD del paso de la metodología.
Figura 7. Vista análisis Threat Analysis and Modeling Tool. Fuente: elaboración propia.
19
Actividades
Antes es necesario cargar la plantilla caso1.tb7, descargable de la plataforma, y

cargarla mediante el menú aply template, según la figura:
Aplicación de Plantilla
El archivo se dejará en el foro, se les enviará a sus carpetas de descarga o también

puede descargarse desde el siguiente enlace:
http://descargas.unir.net/escueladeingenieria/05
Seguridad_del_Software/caso1.rar
Figura 8. Aplicación de plantilla.
 Documentar las amenazas
Una vez realizado el análisis automático de las amenazas, hay que documentarlas;
para ello se deberá rellenar la tabla siguiente. Hay rellenarla manualmente con cada
una de las amenazas obtenidas con la herramienta, indicando su objetivo y las
técnicas de ataque. Se adjunta un ejemplo.
20
Actividades
Descripción de la
Inyección de comandos SQL
amenaza
Objetivo Componente de acceso a base de datos
El atacante introduce comandos SQL en el campo usuario utilizado para formar
Técnicas de ataque
una nueva sentencia SQL.
Patrón ataque CAPEC CAPEC-66: SQL Injection
CWE-89: Improper Neutralization of Special Elements used in an SQL Command
Código CWE (si aplica)
('SQL Injection')
Descripción de la
amenaza
Objetivo
Técnicas de ataque
Patrón ataque CAPEC
Código CWE (si aplica)
Tabla 7. Documentación de las Amenazas.
Hay que recordar que es importante identificar el patrón de CAPEC y código CWE,
pues proporcionan información para poder realizar una valoración de riesgos más
eficaz y eficiente y una mejor elección de salvaguardas y medidas de mitigación.
El alumno deberá rellenar una tabla con 15 amenazas obtenidas de la herramienta

Threat Analysis and Modeling Tool 2016. Se valorará que se implemente en idioma
español y se incluyan más amenazas de las indicadas.
 Valorar las amenazas
Una vez que tenemos identificada la lista de amenazas, el siguiente paso consiste en
puntuarlas de acuerdo con el riesgo que suponen. Esto nos permitirá priorizar las
actuaciones a efectuar para mitigar el riesgo.
Para ello utilizaremos el método DREAD (Damage, Reproducibility, Exploitability,

Affected, Discoverability), en castellano: Daño potencial, Reproductividad,
Explotabilidad, Usuarios afectados, Descubribilidad. El riesgo se puede cuantificar
21
Actividades
como el resultado de multiplicar la probabilidad de que la amenaza se produzca por

el daño potencial de esta.
Riesgo = Probabilidad x Impacto potencial= (R+E+DI) x (D+A) = PxI
Cada valor se cuantifica con un valor entre 1 y 3.
Figura 9. Significado de cada componente valoración del método DREAD. Fuente: elaboración propia.
Se rellena después, para cada amenaza, la siguiente tabla (excepto la columna

salvaguarda), en la que se incluye un ejemplo:
Prob. Impacto P I Riesg

Salvaguardas/medidas
Ocurr. (P) Pot. (I) o
de mitigación
Nº Amenaza R E DI D A (R+E+DI) (D+A) PxI
Inyección de 3 2 2 3 3 7 6 42
1
comandos SQL
2
……
15
© Universidad Internacional de La Rioja (UNIR) Tabla 8.Valoración de las amenazas.
El alumno deberá rellenar la tabla con al menos 15 amenazas obtenidas de la de la

herramienta Threat Analysis and Modeling Tool 2016. Se valorará que se
implemente en idioma español y se incluyan más amenazas de las indicadas.
22
Actividades
Mitigación
 Decidir cómo responder a las amenazas:
Frente a las amenazas se pueden dar diferentes respuestas, basándose,

principalmente, en el riesgo asociado a cada una. Una amenaza puede ser eliminada
(implica eliminar la funcionalidad del sistema donde se presenta) cuando esta es
opcional o cuando el riesgo que tiene asociado es tan alto que no se puede asumir.
Puede decidirse no hacer nada y aceptar el riesgo, cuando el impacto es bajo o si la

mitigación fuese demasiado costosa comparada con el riesgo asociado.
Generalmente, se optará por mitigarla mediante alguna contramedida o
salvaguarda. Por último, se puede transferir el riesgo a una tercera parte, por
ejemplo, al usuario u otra aplicación que interactúe con la nuestra.
 Identificar las técnicas y tecnologías necesarias para mitigar los riesgos

identificados:
Para las amenazas identificadas hay que seleccionar una serie de salvaguardas que
mitiguen su riesgo asociado a la misma: restricciones arquitectónicas, técnicas
criptográficas, mecanismos de autenticación, algoritmos seguros, etc. que nos
permitan solucionar los problemas planteados.
© Universidad Internacional de La Rioja (UNIR) Prob. Impacto P I Riesg

Salvaguardas/medidas
Ocurr. (P) Pot. (I) o
de mitigación
Nº Amenaza R E DI D A (R+E+DI) (D+A) PxI
Inyección de 3 2 2 3 3 7 6 42
1
comandos SQL
2
23
Actividades
……
15
Tabla 9. Salvaguarda.
El estudiante deberá rellenar la columna salvaguardas de la tabla con 15 amenazas

obtenidas de la de la herramienta Threat Analysis and Modeling Tool 2016 y sus
salvaguardas. Se valorará que se implemente en idioma español y se incluyan más
amenazas de las indicadas.
Como ayuda para seleccionar las salvaguardas a incluir en la aplicación para mitigar
las amenazas, se incluye como ayuda el siguiente dibujo (son ayudas básicas que
hay que mejorar en el ejercicio con más detalle):
Figura 12. Salvaguardas Aplicación WEB.

También se puede usar la siguiente tabla:
Amenazas Propiedad Salvaguardas
Spoofing identity (Suplantación Autenticación  Procesos de Autenticación, Autorización y
Auditoría (AAA): hash, firma digital.
de Identidad)
 Protección de secretos
 No almacenamiento de secretos
 Single Sign On
24
Actividades
 IPSEC
Tampering with Data Integridad  Procesos de AAA: hash, firma digital.
 Códigos de autenticación de mensajes.
(Manipulación de datos)
 Firmas digitales.
 Protocolos resistentes a la manipulación.
 Listas control de acceso ACL
Repudiation (Repudio) No Repudio  Procesos de Autenticación: hash, firma digital.
 Procesos de Auditoría.
 Sellado de tiempo.
Information Disclosure Confidencialida  Procesos de AAA: hash, firma digital.
 Protección de secretos
(Revelación de información) d
 No almacenamiento de secretos.
 Protocolos seguros.
 Encriptado.
Denial of Service (Denegación Disponibilidad  Procesos de AAA: hash, firma digital.
 Listas control de acceso ACL.
de servicio)
 Calidad de servicio.
Elevation of Privilege (Elevación Autorización  Listas control de acceso ACL.
 Control de acceso basado en roles.
de privilegios)
 Trabajar con el mínimo privilegio.
 Validación de entradas
Figura 13. Salvaguardas método STRIDE.
Si se quiere un catálogo más completo de salvaguardas, consultar MAGERIT. (2012).

Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información, Libro
II - Catálogo de Elementos. Ministerio de Hacienda y Administraciones Públicas:
http://administracionelectronica.gob.es/pae_Home/pae_Documentacion/
pae_Metodolog/pae_Magerit.html#.U2_oe2CKB2E
Validación
Finalmente, se debe validar que el modelado de amenazas que se ha llevado a cabo

refleja con fidelidad el diseño de la aplicación y las amenazas potenciales a las que
se debe enfrentar. Una vez identificadas las amenazas, en una fase temprana del
desarrollo
© Universidad Internacional (especificación
de La Rioja (UNIR) y diseño de la aplicación), se puede pensar en la forma de
afrontarlas:
• Rediseñar.
• Usar salvaguardas estándar.

• Usar salvaguardas personalizadas.
25
Actividades
• Aceptar el riesgo de acuerdo con las políticas de la organización y requisitos
del sistema.
En este apartado, el estudiante no tiene que realizar nada, es solo informativo.
Presentación de la memoria
Presentar una memoria con los resultados pedidos. Incluir el fichero con
extensión .tm7 que genera la herramienta y el informe que se puede generar con la
misma.
Extensión y formato
En la solución a enviar, solo se deberán incluir las tablas que se piden rellenar a lo
largo del enunciado de la actividad. La extensión máxima de la actividad será de 10
páginas.
Rúbrica
Metodologías
de modelado Puntuación
Peso
de amenazas Descripción máxima
%
(valor real: 4 (puntos)
puntos)
Criterio 1 Relleno de la Tabla de Activos 0,5 5%
Criterio 2 Matriz de control de accesos 0,5 5%
Criterio
© Universidad Internacional 3 Rioja (UNIR)
de La Puntos de entrada de la aplicación 1 10%
Criterio 4 Puntos de salida de la aplicación 1 10%
Criterio 5 Documentación de las Amenazas 2 20%
Criterio 6 Valoración de las amenazas 2 20%
Criterio 6 Diseño de las salvaguardas 2 20%
Criterio 6 Calidad de la memoria 1 10%
26
Actividades
10 100 %
27
Actividades

Muciber06 Estandar Act1

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Muciber06 Estandar Act1

Cargado por

Copyright:

Formatos disponibles

Asignatura Datos del alumno Fecha

Nombre de la asignatura Apellidos:

Metodologías de modelado de amenazas

Una amenaza a un sistema es cualquier actor, agente, circunstancia o evento que

 Estudio y análisis de la arquitectura de una aplicación para poder determinar el

Para seguir profundizando en el modelado de amenazas se propone realizar este

 Introducción al modelado de amenazas.

se describe a continuación (incluir los ficheros generados por la herramienta

Con el objetivo de afianzar los conocimientos adquiridos sobre el modelado de

Últimamente, sufrió un ciberataque que ha comprometido las credenciales de sus

Con el objetivo de mantener su actual posición en el mercado de venta electrónica

 Habrá tres tipos de usuarios en la aplicación: clientes, administrador TI y agente

 La tecnología usada en el desarrollo de la aplicación web es ASP.Net, que utiliza C

Los objetivos de seguridad establecidos para la tienda web de Librería On-Line S. A.

 OB-1. Mantener confidencialidad, integridad y disponibilidad de la información

Figura 1. Modelado de Amenazas. Fuente: elaboración propia.

 Identificación de actores y sus niveles de confianza

tienda web o llamando a la oficina de ventas.

• Los administradores pueden modificar y eliminar la información del cliente y

• Los eventos del sistema se almacenarán de forma periódica en un servidor de

log centralizado de la compañía. Se transmitirán de forma cifrada y con

Tabla 1.Tabla de actores.

En la siguiente tabla se presentan los activos identificados en el sistema.

Tipo Id Nombre Descripción Actores

web. estar disponible en régimen de 24x7 para los clientes.

Capacidad realizar Capacidad realizar peticiones de pago a un procesador

Tabla 2. Tabla de Activos.

El estudiante debe rellenar la columna de la derecha, «actores», con el identificador

 Matriz de control de acceso a los datos:

Los datos de la aplicación comprenden la información del cliente (cuenta, dirección

Administrador Cliente Agente ventas

Tabla 3. Matriz de control de acceso.

© Universidad Internacional de La Rioja (UNIR)

 Diseño de la autenticación de las entidades:

El usuario se autenticará en la aplicación web mediante formulario (nombre de

La aplicación web está desarrollada en ASP.Net usando C # mientras que la base de

 Determinar la topología lógica:

La topología lógica del sistema es conforme a la siguiente figura:

© Universidad Internacional de La Rioja (UNIR)

Figura 2. Topología lógica de la aplicación.

 Identificar las fronteras de confianza:

• Entre la DMZ y las zonas internas (Intranet).

 Definir los puntos de entrada:

Algunos de los puntos de entrada identificados en la tienda web del ejercicio

Tabla 4. Puntos de entrada de la aplicación.

El estudiante debe rellenar la columna de la derecha «actores» con el identificador

 Identificar puntos de salida:

Tabla 5. Puntos de salida de la aplicación.

El estudiante debe rellenar la columna de la derecha «actores» con el identificador

© Universidad Internacional de La Rioja (UNIR)

 Identificar dependencias externas:

Las dependencias externas son elementos externos al código de la aplicación que

Tabla 6. Dependencias externas.

 Realización del diagrama de flujo de datos (DFD).

Una vez recopilada toda la información sobre la aplicación en los apartados

© Universidad Internacional de La Rioja (UNIR)

Figura 3. Símbolos de los diagramas de flujo de datos (DFD).

En el anterior sitio web hay guías de ayuda y documentación del uso de la

• AppSecEU 16 - Matthias Rohr - Practical Threat Modeling with Microsofts

Threat Modeling Tool 2016: https://www.youtube.com/watch?

© Universidad Internacional de La Rioja (UNIR)

Os propongo modelar la aplicación mediante el siguiente diagrama DFD que

En la siguiente figura os muestro un modelo básico como ayuda a la realización del