Asignatura Datos del alumno Fecha

Apellidos:
Seguridad en el
Software
Nombre:

Actividades

Trabajo: Metodologías de modelado de amenazas

Objetivos

Una amenaza para cualquier sistema es cualquier actor, agente, circunstancia o evento
que tiene el potencial de causarle daño o a los datos y recursos del mismo. Con la
presente actividad a 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 sistemas basados en la Web 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.

Descripción de la actividad

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

que contenga al menos el siguiente contenido:

» 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 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).

TEMA 3 –Actividades © Universidad Internacional de La Rioja (UNIR)

 Asignatura Datos del alumno Fecha
Apellidos:
Seguridad en el
Software
Nombre:

Caso práctico

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

se pide el definir, modelar y medir las posibles amenazas de una tienda de libros online,
llamada Librería On-Line SA.

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

clientes. El incidente ha trascendido en los medios de comunicación, lo que ha
producido 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 recurar 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 que un cliente pueda realizar un pedido el cliente debe, con anterioridad,
registrase para crearle 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.
» 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 y 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.

TEMA 3 –Actividades © Universidad Internacional de La Rioja (UNIR)

 Asignatura Datos del alumno Fecha
Apellidos:
Seguridad en el
Software
Nombre:

» 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 web 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á completamente 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).
» La tecnología utilizada en el desarrollo de la aplicación web es ASP.Net utilizando
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 SA son
los siguientes objetivos:

OB-1. Recuperar la imagen de la compañía deteriorada tras el ciberincidente ocurrido.

OB-2. Obtener la posición líder de mercado en venta de libros online.
OB-3. Mantener confidencialidad, integridad y disponibilidad de la información
almacenada y trasmitida.
OB-4. Proporcionar un servicio seguro a los clientes existentes y potenciales.
OB-5. Proporcionar un servicio ininterrumpido a los clientes existentes y potenciales.
Se aplicarán técnicas de monitorización, equilibrio de carga, replicación,

TEMA 3 –Actividades © Universidad Internacional de La Rioja (UNIR)

 Asignatura Datos del alumno Fecha
Apellidos:
Seguridad en el
Software
Nombre:

recuperación ante desastres y continuidad del negocio y copias de seguridad

recuperables
OB-6. Proporcionar una experiencia de usuario mejorada a los clientes existentes y
potenciales.
OB-7. Se establecerán procesos de autenticación, autorización y auditoría.

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.

Tener en cuenta que nos encontramos en la fase análisis de requisitos del SDLC,
identificando 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 explicado en la clase magistral (Modelado de amenazas)
de este tema, que se resume en el diagrama siguiente (figura 1).

Figura 1. Proceso de Modelado de Amenazas.

TEMA 3 –Actividades © Universidad Internacional de La Rioja (UNIR)

 Asignatura Datos del alumno Fecha
Apellidos:
Seguridad en el
Software
Nombre:

1. Modelado de la Aplicación

1.2. 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.
» 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. 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 Cliente que se ha conectado al sitio web de la compañía,

del sitio web pero no ha proporcionado credenciales válidas.

2 Usuario con credenciales Usuario que se ha conectado al sitio web de la compañía y

de inicio de sesión válidas ha iniciado sesión utilizando credenciales válidas.

3 Usuario con credenciales Usuario que se ha conectado al sitio web de la compañía y

de inicio de sesión no está intentando iniciar sesión con credenciales no válidas.

TEMA 3 –Actividades © Universidad Internacional de La Rioja (UNIR)

 Asignatura Datos del alumno Fecha
Apellidos:
Seguridad en el
Software
Nombre:

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 El administrador del servidor de bases de datos administra

de base de datos la base de datos del sitio web de la compañía.

6 Administrador del sitio Administrador del sitio web que puede configurar y
web administrar el sitio web de la compañía.

7 Proceso del usuario del Proceso que en el servidor web ejecuta código de usuario y
servidor web se autentica contra el servidor de base de datos.

8 Usuario de lectura de la Cuenta de usuario utilizada para acceder a la base de datos

base de datos en modo lectura.

9 Usuario de Cuenta de usuario utilizada para acceder a la base de datos

lectura/escritura de la base en modo lectura y escritura.
de datos

10 Proceso de back-up Proceso que realiza una copia periódica de la base de datos
en una ubicación de un tercero.

11 Proceso de realización de Proceso que realiza el pago de los pedidos con tarjeta de
pagos. crédito.

12 Proceso de Proceso que realiza el almacenamiento de los eventos del

almacenamiento log sistema en el servidor centralizado de almacenamiento de
log de la compañía.
Tabla 2. Tabla de actores.
El alumno, 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

Activos Primarios
de Información y

libros venta de libros.

Servicios

2 Datos de la tarjeta Datos exigidos en la aplicación a la tarjeta

de crédito de crédito, como su número, fecha de
caducidad, etc.

3 Datos inicio de Las credenciales que el cliente utilizará para (2), (4), (5),
iniciar sesión en el sitio web de la compañía

TEMA 3 –Actividades © Universidad Internacional de La Rioja (UNIR)

 Asignatura Datos del alumno Fecha
Apellidos:
Seguridad en el
Software
Nombre:

sesión del cliente «Librería On-Line SA». (7), (8), (9)

Datos inicio de Las credenciales que el agente de ventas

sesión del agente de utilizará para iniciar sesión en el sitio web
4
ventas de la compañía «Librería On-Line SA».

Datos inicio de Las credenciales que el administrador

5 sesión del utilizará para iniciar sesión en el sitio web
administrador de la compañía «Librería On-Line SA».

Datos de los pedidos Todos los datos asociados al pedido de

6
libros realizado por un cliente.

Datos de los El sitio web de la compañía «Librería On-

7 productos Line SA» almacenará información de los
productos en el sitio web.

Datos personales El sitio web de la compañía «Librería On-

Line SA» almacenará información personal
8
relacionada con clientes, agentes de ventas
y administrador.

Disponibilidad del El sitio web de la compañía «Librería On-

9 sitio web Line SA» debe estar disponible en régimen
de 24 x 7 para los clientes.

Capacidad realizar Capacidad realizar peticiones de pago a un

10
peticiones de pago procesador de tarjetas de crédito externo.

Capacidad ejecutar Representa la capacidad de ejecutar código

Activos Secundarios Sistema y aplicación

11 código en el en el servidor web como un usuario de este.

servidor web

Capacidad de Representa la capacidad de ejecutar

ejecutar consultas consultas SQL a la base de datos, para
SQL a la base de recuperar cualquier información
12
datos como un almacenada dentro de la base de datos de la
usuario de solo compañía «Librería On-Line SA», como un
lectura usuario de lectura.

Capacidad de Representa la capacidad de ejecutar

ejecutar consultas consultas SQL para leer, insertar y
SQL a la base de actualizar base de datos de la compañía
13
datos como un «Librería On-Line SA», como un usuario de
usuario de lectura y lectura y escritura.
escritura

Capacidad de Capacidad de realizar un back-up de la base

14 recuperación de de datos en un proveedor de servicios
datos externo a la compañía.

Inicio de Sesión Sesión de acceso de un usuario al sitio web

de la compañía «Librería On-Line SA». El
15
usuario podría ser un cliente, el agente de
ventas o el administrador.

TEMA 3 –Actividades © Universidad Internacional de La Rioja (UNIR)

 Asignatura Datos del alumno Fecha
Apellidos:
Seguridad en el
Software
Nombre:

Acceso al servidor Acceso al servidor de base de datos para

16 de base de datos administrarlo y demás usuarios en función
de sus permisos.

Capacidad de crear Capacidad de crear usuarios en el sistema.

17 usuarios Estos podrían ser clientes, el agente de
ventas o el administrador.

Capacidad de enviar Capacidad de enviar los log de servidor web

18 los eventos del y el de la base de datos a un servidor
sistema. centralizado de log de la compañía.

Accesos a los log del Capacidad para auditar todos los eventos
sistema auditables que ocurrieron dentro del
18
sistema de ventas de la «Librería On-Line
SA».
Tabla 1. Tabla de Activos.

El alumno 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 su
diseño. Se tendrá en cuenta en la nota final.

1.2. Definir la arquitectura

1.2.1. 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 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.

TEMA 3 –Actividades © Universidad Internacional de La Rioja (UNIR)

 Asignatura Datos del alumno Fecha
Apellidos:
Seguridad en el
Software
Nombre:

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 alumno 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.

1.2.2. 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 443 (https). La
aplicación web se conectará a la base de datos del servidor SQL a través 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.

1.2.3. 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.

1.2.4. 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

TEMA 3 –Actividades © Universidad Internacional de La Rioja (UNIR)

 Asignatura Datos del alumno Fecha
Apellidos:
Seguridad en el
Software
Nombre:

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.

1.2.5. Determinar la topología lógica

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

Información Back-up datos a un

almacenada en tercero
base de datos
Puerto 1433
TCP/IP
Autenticación
Puerto 443
Agente de Aplicación Web Información
HTTP Formulario
Ventas en transito
autenticación
SQL
Server

Puerto 443 Información

TLS en transito
Envió log
Cliente
Servidor ISS
Administrador Servidor de log Procesador
Central de la de tarjetas
Compañia Datos Proceso Presentación de crédito
externo

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

1.3. Descomponer la aplicación

1.3.1. 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).

TEMA 3 –Actividades © Universidad Internacional de La Rioja (UNIR)

 Asignatura Datos del alumno Fecha
Apellidos:
Seguridad en el
Software
Nombre:

1.3.2. 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 cuales los potenciales agentes maliciosos
pueden interactuar con la aplicación con el objetivo de introducir datos con carácter
malicioso. 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.

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- (1), (2), (3), (4)
Line SA» es 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

principal de la compañía «Librería On-Line SA». Es el
tienda punto de entrada para todos los usuarios,
tanto los maliciosos como los que no lo son.

1.2 Página de Los clientes y agentes de ventas utilizan esta

Inicio de página para iniciar sesión en el sitio web de
Sesión la compañía «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
Sesión las 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

preferencias de los usuarios.

1.5 Página de Página para la administración del catálogo

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

TEMA 3 –Actividades © Universidad Internacional de La Rioja (UNIR)

 Asignatura Datos del alumno Fecha
Apellidos:
Seguridad en el
Software
Nombre:

El alumno 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 su
diseño. Se tendrá en cuenta en la nota final.
1.3.3. Identificar puntos de salida

Los puntos de salida son aquellos elementos que muestran información desde el
sistema. Los puntos de salida también incluyen procesos que extraen datos del
sistema. Los puntos de salida 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 SA» son los siguientes:

Puntos de salida

ID Nombre Descripción Actores

1 Página de La página utilizada para presentar los

resultados de resultados de las búsquedas.
búsqueda

2 Página de Página donde se muestran las preferencias

preferencias de los 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 Procesos de verificación de tarjetas de

de crédito crédito y realización de pagos.

5 Procesos de copia Proceso que realiza una copia periódica de

de seguridad la base de datos a una ubicación de un
tercero.

6 Proceso de Proceso que realiza el almacenamiento de

almacenamiento los eventos del sistema en el servidor
log centralizado de almacenamiento de log de
la compañía.
Tabla 5. Puntos de salida de la aplicación.

TEMA 3 –Actividades © Universidad Internacional de La Rioja (UNIR)

 Asignatura Datos del alumno Fecha
Apellidos:
Seguridad en el
Software
Nombre:

El alumno 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 su
diseño. Se tendrá en cuenta en la nota final.

1.3.4. Identificar dependencias externas

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

ID Descripción

1 Servicio de copia periódica de la base de datos a una ubicación de un tercero.

2 Servidor que almacena 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.

1.3.5. 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 diagramas nos permiten
obtener una mejor comprensión de cómo 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
figura siguiente se muestra un resumen de los más importantes).

TEMA 3 –Actividades © Universidad Internacional de La Rioja (UNIR)

 Asignatura Datos del alumno Fecha
Apellidos:
Seguridad en el
Software
Nombre:

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, accesible desde el aula virtual o a través del
siguiente enlace: https://www.microsoft.com/en-us/download/details.aspx?id=49168

Como ayuda a su manejo, aparte de los manuales que se pueden descargar con esta
herramienta, se aconseja visionar estos dos vídeos:

» 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

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 «View → Design View» en el menú, tal y
como se muestra en la figura siguiente:

TEMA 3 –Actividades © Universidad Internacional de La Rioja (UNIR)

 Asignatura Datos del alumno Fecha
Apellidos:
Seguridad en el
Software
Nombre:

Figura 4. Vista de diseño de la herramienta Threat Analysis and Modeling Tool 2016.

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 figura siguiente os muestro un modelo básico
como ayuda a la realización del diagrama DFD de la aplicación propuesta. No debéis
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
puede ser el siguiente, aunque el alumno lo puede modelar de forma diferente según
considere:

TEMA 3 –Actividades © Universidad Internacional de La Rioja (UNIR)

 Asignatura Datos del alumno Fecha
Apellidos:
Seguridad en el
Software
Nombre:

Figura 5. Posible diagrama DFD de la aplicación.

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.

TEMA 3 –Actividades © Universidad Internacional de La Rioja (UNIR)

 Asignatura Datos del alumno Fecha
Apellidos:
Seguridad en el
Software
Nombre:

2. Identificación de amenazas

2.1. Determinar las amenazas a cada componente de la aplicación

Una vez realizado el diagrama DFD pasamos a la vista de análisis, pulsando «View
→ Analysis View» en el menú. Al pasar a esta, la herramienta calcula
automáticamente las amenazas sugeridas para el diagrama de flujo de datos
dibujado. Al clicar en cada una de ellas vemos información en detalle de estas y
algún formulario para introducir más información, como podrían 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

Método 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
aplicación identificado en la etapa anterior, analizando a qué categorías de amenazas
mencionadas es sensible.

TEMA 3 –Actividades © Universidad Internacional de La Rioja (UNIR)

 Asignatura Datos del alumno Fecha
Apellidos:
Seguridad en el
Software
Nombre:

Figura 7. 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, se nos permite introducir las salvaguardas que consideremos y el análisis
DREAD del paso de la metodología.

Figura 8. Vista análisis Threat Analysis and Modeling Tool.

TEMA 3 –Actividades © Universidad Internacional de La Rioja (UNIR)

 Asignatura Datos del alumno Fecha
Apellidos:
Seguridad en el
Software
Nombre:

Antes es necesario cargar la plantilla, descargable de la plataforma, «caso1.tb7» (este

archivo se dejará en el foro, se les enviará a sus carpetas de descarga o se descarga
desde el enlace que se indica a continuación).

Accede al enlace a través del aula virtual o desde la siguiente dirección web:
ftp://descargasescueladeingenieria@ftp01.unir.net/uploads/05%20Seguridad_del_Sof
tware/caso1.tb7

Y cargarla mediante el menú Aply Template, según la figura siguiente:

Aplicación de Plantilla

Figura 9. Aplicación de plantilla.

2.2. Documentar las amenazas

Una vez realizado el análisis automático de las amenazas, hay que documentarlas.
Para ello hay que rellenar la tabla siguiente: hay que 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.

TEMA 3 –Actividades © Universidad Internacional de La Rioja (UNIR)

 Asignatura Datos del alumno Fecha
Apellidos:
Seguridad en el
Software
Nombre:

Descripción de
Inyección de comandos SQL
la amenaza

Objetivo Componente de acceso a base de datos.

Técnicas de El atacante introduce comandos SQL en el campo usuario utilizado para

ataque formar una nueva sentencia SQL.

Descripción de
la amenaza

Objetivo

Técnicas de
ataque
Tabla 7. Documentación de las amenazas.

El alumno deberá rellenar una tabla con quince amenazas, obtenidas de la

herramienta Threat Analysis and Modeling Tool 2016. Se valorará que se
implemente en idioma español.

2.3. 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
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.

TEMA 3 –Actividades © Universidad Internacional de La Rioja (UNIR)

 Asignatura Datos del alumno Fecha
Apellidos:
Seguridad en el
Software
Nombre:

Figura 10. Significado de cada componente valoración del método DREAD.

Se rellena despues para cada amenaza la siguiente tabla, en la que se incluye un

ejemplo:

Probabilidad de Impacto P I Riesgo

Ocurrencia (P) Potencial (I)

Amenaza R E DI D A (R+E+DI) (D+A) PxI

Inyección de 3 2 2 3 3 7 6 42
comandos SQL

Tabla 8. Calculo el riesgo.

El alumno deberá rellenar la tabla con quince amenazas, obtenidas de la

herramienta Threat Analysis and Modeling Tool 2016. Se valorará que se
implemente en idioma español.

3. Mitigación

3.1. 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 la misma) cuando
esta es opcional o cuando el riesgo que tiene asociado es tan alto que no se puede

TEMA 3 –Actividades © Universidad Internacional de La Rioja (UNIR)

 Asignatura Datos del alumno Fecha
Apellidos:
Seguridad en el
Software
Nombre:

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 a otra aplicación que interactúe con la nuestra.

3.2. 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.

Descripción de
Inyección de comandos SQL
la amenaza

Validar la entrada, filtrando el contenido del campo usuario, utilizar un

Medidas
procedimiento almacenado que utilice parámetros para acceder a la base
mitigación
de datos.

Descripción de
la amenaza

Medidas
mitigación

Tabla 9. Salvaguardas.

El alumno deberá rellenar una tabla con quince amenazas, obtenidas de la

herramienta Threat Analysis and Modeling Tool 2016 y sus salvaguardas. Se
valorará que se implemente en idioma español.

Como ayuda para seleccionar las salvaguardas a incluir en la aplicación para mitigar
las amenazas, se incluye el dibujo siguiente (figura 11).

TEMA 3 –Actividades © Universidad Internacional de La Rioja (UNIR)

 Asignatura Datos del alumno Fecha
Apellidos:
Seguridad en el
Software
Nombre:

Figura 11. Salvaguardadas aplicación web.

También se puede usar la siguiente tabla:

Amenazas Propiedad Salvaguardas

Spoofing identity Autenticación » Procesos de Autenticación, Autorización

(Suplantación de y Auditoría (AAA): hash, firma digital.
Identidad)
» Protección de secretos.
» No almacenamiento de secretos.
» Single Sign On.
» IPSEC.

Tampering with Data Integridad » Procesos de AAA: hash, firma digital.

(Manipulación de
datos) » Códigos de autenticación de mensajes.
» 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 Confidencialidad » Procesos de AAA: hash, firma digital.

(Revelación de
información) » Protección de secretos.

TEMA 3 –Actividades © Universidad Internacional de La Rioja (UNIR)

 Asignatura Datos del alumno Fecha
Apellidos:
Seguridad en el
Software
Nombre:

» No almacenamiento de secretos.
» Protocolos seguros.
» Encriptado.

Denial of Service Disponibilidad » Procesos de AAA: hash, firma digital.

(Denegación de
servicio) » Listas control de acceso ACL.
» Calidad de servicio.

Elevation of Privilege Autorización » Listas control de acceso ACL.

(Elevación de
privilegios) » Control de acceso basado en roles.
» Trabajar con el mínimo privilegio.
» Validación de entradas.
Tabla 10. Salvaguardas método STRIDE.

Si se quiere un catálogo más completo de salvaguardas se puede consultar el Libro II

de la Metodología MAGERIT:

Dirección General de Modernización Administrativa, Procedimientos e Impulso de la

Administración Electrónica. (2012). Libro II: Catálogo de Elementos. En MAGERIT-
versión 3.0: Metodología de Análisis y Gestión de Riesgos de los Sistemas de
Información. Madrid: Ministerio de Hacienda y Administraciones Públicas.

Accede al documento desde el aula virtual o a través del siguiente enlace:

http://administracionelectronica.gob.es/pae_Home/pae_Documentacion/pae_Metod
olog/pae_Magerit.html#.U2_oe2CKB2E

4. Validación

Finalmente, se debe validar que el modelado de amenazas que se ha llevado a cabo

refleja fielmente 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
(especificación y diseño de la aplicación), se puede pensar en la forma de afrontarlas:

» Rediseñar.
» Usar salvaguardas estándar.

TEMA 3 –Actividades © Universidad Internacional de La Rioja (UNIR)

 Asignatura Datos del alumno Fecha
Apellidos:
Seguridad en el
Software
Nombre:

» Usar salvaguardas personalizadas.

» Aceptar el riesgo de acuerdo con las políticas de la organización y requisitos del
sistema.

En este apartado el alumno 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 esta.

Rúbrica

Para la evaluación de la actividad se empleará la siguiente rubrica:

Título de la
Puntuación
actividad Peso
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%
Relleno de la Tabla: Puntos de entrada
Criterio 3 1 10%
de la aplicación
Criterio 4 Relleno de la Tabla: Puntos de salida
1 10%
de la aplicación
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%
10 100 %

Extensión de la actividad: En la solución 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.

TEMA 3 –Actividades © Universidad Internacional de La Rioja (UNIR)