Asignatura Datos del alumno Fecha

Nombre de la asignatura Apellidos:
Desarrollo Seguro de
Sofware y
Sofware  y Auditoría Nombre:

Metodologías de modelado de amenazas

Objevos

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

ene el potencial de causarle daño o a sus datos, servicios y recursos. Con la
presente acvidad se pretende conseguir los siguientes objevos:

 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
Analizar y det
detec
ectar
tar ame
amenaz
nazas
as de se
segur
gurida
idad
d y de
desar
sarrol
rollar
lar técn
técnica
icass par
paraa su
prevención.
 Aprender a diseñar e implantar sios, servicios y aplicaciones con garanas de
seguridad.
 Facilitar la idenfcación de las condiciones o aquellas vulnerabilidades que, una
vez eliminadas o contrarresta
contrarrestadas,
das, aectan a la existencia de múlples amenazas.
 Proporcionar inormación relevante sobre cuáles serían las contramedidas más
efcaces para contrarrestar una posible amenaza y/o migar los eectos de la
presencia de una vulnerabilidad en el diseño de una aplicación.

Pautas de elaboración

Para seguir proundizando 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.

 Ejercici
Ejercicio
o prác
prácco
co de mode
modelado
lado de amen
amenazas
azas ulizando
ulizando una herr
herramie
amienta
nta de

modelado como Threat Analysis and Modeling Tool 2016, del siguiente caso que

1
 Acvidades
 

Asignatura Datos del alumno Fecha

Nombre de la asignatura Apellidos:
Desarrollo Seguro de
Sofware y
Sofware  y Auditoría Nombre:

se describe a connuación (incluir los fcheros generados por la herramienta

 junto con el del
del trabajo en un fchero a subir
subir en la plataorma).
plataorma).

Caso prácco

Con el objevo de afanzar los conocimientos adquiridos sobre el modelado de

amenazas, se pide defnir, modelar y medir las posibles amenazas de una enda de
libros online, llamada Librería On-Line S. A.

Úlmamente, surió un ciberataque que ha compromedo 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 rente a sus compedores.

Con el objevo 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 unción del
nivel
nivel de rie
riesgo
sgo y la dis
dispon
ponibi
ibilid
lidad
ad eco
económ
nómica
ica.. Se le est
establ
ablec
ecee los sig
siguie
uiente
ntess
requisitos de negocio y técnicos:

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

de ventas.
 Los clientes deben poder buscar productos y gesonar sus pedidos ulizando la
enda web o llamando a la ofcina 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 traserencia
traserencia
bancaria.
 Los clientes deben iniciar sesión antes para poder personalizar sus preerenc
preerencias.
ias.

2
 Acvidades
 

Asignatura Datos del alumno Fecha

Nombre de la asignatura Apellidos:
Desarrollo Seguro de
Sofware y
Sofware  y Auditoría Nombre:

 Los clientes deben ser capaces de revisar y modifcar sus pedidos realizados.
 Los agentes de ventas pueden conceder descuentos a los clientes.

Los administradores pueden modifcar y eliminar clientes, así como productos e
inormación.
 La enda web de la librería tendrá que ser accesible desde Intranet e Internet.
 La enda web deberá diseñarse con una arquitectura distribuida por razones de
escalabilidad.
 El cliente necesitará autencarse en la enda 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 interaz de servicios
web.
 La inormación
inormación de la cuenta del usua
usuario
rio y la inor
inormaci
mación
ón del producto
producto debe
deberán
rá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 enda web se almacenan en un servidor
de log interno de la organización.
 La bas
basee de dat
datos
os deb
deberá
erá cop
copiar
iarse
se per
periódi
iódica
camen
mente
te en una ubi
ubicac
cación
ión de un
proveedor de servicios TI de terceros, para propósitos de recuperación ante

desastres.
 El si
sio
o we
webb se dis
diseñar
eñaráá lóg
lógica
icamen
mente
te com
como
o una apl
aplica
icació
ción
n cli
client
ente/s
e/ser
ervid
vidor
or
distribuida conorme a un modelo de tres capas: presentación, proceso y datos.
 Los clientes accederán a la aplicación ulizando navegadores web de escritorio y
disposivos móviles.
El sio
© 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ísica
Físicamen
mente,
te, la apl
aplica
icación
ción es
estar
taráá por com
comple
pleto
to alo
alojad
jadaa en un ser
servid
vidor
or 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
 Acvidades
 

Asignatura Datos del alumno Fecha

Nombre de la asignatura Apellidos:
Desarrollo Seguro de
Sofware y
Sofware  y Auditoría Nombre:

 La tecnología usada en el desarrollo de la aplicación web es [Link], que uliza C

#, y la base de datos del backend de la compañía está implementada en base al

producto Microso SQL Server.

Los objevos de seguridad establecidos para la enda web de Librería On-Line S. A.

son los siguientes objevos:

 OB-1. Mantener confdencialidad, integridad y disponibilidad de la inormación

almacenada y trasmida.
 OB-2. Proporcionar un servicio seguro a los clientes existentes
existentes y potenciales.
 OB-3.  Pro
Propor
porcio
cionar
nar un ser
servic
vicio
io ini
ininte
nterru
rrumpi
mpido
do a los cli
client
entes
es ex
exist
istent
entes
es y
potenc
potencial
iales.
es. Se apl
aplica
icarán
rán té
técni
cnicas
cas de mon
monito
itoriz
rizaci
ación,
ón, equ
equili
ilibr
brio
io de car
carga,
ga,
replicación, recuperación ante desastres y connuidad del negocio y copias de
seguridad recuperables.
 OB-4.  Est
Establ
ablec
ecer
er pro
proce
cesos
sos de au
auten
tenca
cació
ción,
n, au
autor
toriza
izació
ción
n y aud
audito
itoría
ría que
mejoran la seguridad de la aplicación.

El sistema estará basado en una pica arquitectura de una aplicación web de tres
capas, donde el cliente es un navegador que accede a los servicios proporcionados

por el sio web de la librería, que conene 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 ase análisis de requisitos del
SDLC,deidenfcando
© Universidad Internacional La Rioja (UNIR) requisitos uncionales y de seguridad. Una vez idenfcados y
comprendidos los objevos de seguridad, procederemos a realizar el modelado de
amenaz
amenazas
as con
conor
orme
me al mét
método
odo Model
Modelado
ado de Amenazas,  que se resume en el
Amenazas,

siguiente diagrama:

4
 Acvidades
 

Asignatura Datos del alumno Fecha

Nombre de la asignatura Apellidos:
Desarrollo Seguro de
Sofware y
Sofware  y Auditoría Nombre:

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

Modelado de la aplicación

  Idencación de actores y sus niveles de conanza

Los requisitos que se establecen para los actores, tanto humanos como de otro po,
son los siguientes:

• Los clientes deben poder buscar productos y realizar sus pedidos ulizando la
enda web o llamando a la ofcina de ventas.
• Los agentes de ventas pueden conceder descuentos a los clientes.
• Los administradores pueden modifcar y eliminar la inormación del cliente y
del producto.
• La base de datos deberá copiarse periódicamente a una ubicación de un
© Universidad Internacional de La Rioja (UNIR)
tercero,
tercero, proveedor
proveedor de serv
servicio
icioss IT, para propósitos
propósitos de recu
recupera
peración
ción ante
desastres.

5
 Acvidades
 
 

Asignatura Datos del alumno Fecha

Nombre de la asignatura Apellidos:
Desarrollo Seguro de
Sofware y
Sofware  y Auditoría Nombre:

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

log  centralizado de la compañía. Se transmirán de orma cirada y con

protección de su integridad.

Esto nos ayuda a idenfcar tres actores humanos del sistema: clientes, agentes de
ventas y administradores. Entre los actores no humanos se pueden incluir procesos
administradores.
que respaldan periódicamente los datos a la ubicación de proveedor de servicios IT,
procesos de almacenamiento de log, etc.

Se asigna un idenfcador único a cada actor y se uliza para poder realizar una
reerencia cruzada de los actores y su nivel de confanza con los puntos de entrada y
los acvos.

Id Nombre Descripción

1 Cliente anónimo usuario del Cliente que se ha conectado al sio web de la compañía, pero no
sio web ha proporcionado credenciales válidas.
2 Usuario con credenciales de Usuario que se ha conectado al sio web de la compañía y ha
inicio de sesión válidas iniciado sesión ulizando credenciales válidas.
3 Usuario con credenciales de Usuario que se ha conectado al sio 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 sio web de la compañía

y ver su inormación personal.

5 Administrador del servidor de El administrador del servidor de bases de datos administra la
base de datos base de datos del sio web de la compañía.
6 Admini
Administr
strado
adorr del sio
sio web
web El admin
administ
istrad
rador
or del sio
sio web
web que
que puede
puede confg
confgura
urarr y admini
administr
strar
ar
el sio 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 autenca contra el servidor de base de datos.
© Universidad Internacional de La Rioja (UNIR)
8 Usuario de lectura de la base Cuenta de usuario ulizada para acceder a la base de datos en
de datos modo lectura.
9 Usuario de lectura/escritura Cuenta de usuario ulizada 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
 Acvidades
 
 

Asignatura Datos del alumno Fecha

Nombre de la asignatura Apellidos:
Desarrollo Seguro de
Sofware y
Sofware  y Auditoría Nombre:

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 [Link] de actores.

El estudiante, si lo considera, puede completar más la tabla con nuevos acvos que
considere en su diseño. Se tendrá en cuenta en la nota fnal.

  Idencar acvos:

En la siguiente tabla se presentan los acvos idenfcados en el sistema.

Tipo Id Nombre Descripción Actores

1 Ser
ervvicio de
de ve
venta de Servicio a disposición de los clientes para la venta de
libros. libros
2 Dato
Datoss de la ta
tarj
rjet
etaa de Datos exigidos en la aplicación a la tarjeta de crédito,
crédito. como su número, echa de caducidad, etc.
3 Dato
Datoss in
inic
icio
io de se
sesi
sión
ón de
dell Los credenciales
credenciales que el clien
cliente
te uliza
ulizará
rá para iniciar (2), (4), (5), (7),

   s cliente. sesión en el sio web de la compañía Librería On-Line S. (8), (9)
   o
   i
   c
   i A.
   v
   r
   e
   s Datos inicio de sesión del Los credenciales que el agente de ventas ulizará para
   y
   n
    ó
   i 4 agente de ventas. iniciar sesión en el sio web de la compañía Librería On-
   c
   a
   m
   r
Line S. A.
   o
    f
   n
   i Datos inicio de sesión del Los credenciales
credenciales que el admin
administra
istrador
dor uliza
ulizará
rá para
   e
    d 5 administrador. iniciar sesión en el sio web de la compañía Librería On-
   s
   o
   i
   r Line S. A.
   a
   m
   i
   r Dato
Datoss de lo
loss pe
pedi
dido
dos.
s. Todo
Todoss los
los dat
datos
os aso
asoci
ciad
ados
os al
al pedi
pedido
do de
de libr
libros
os rea
reali
liza
zado
do
   p
   s 6
   o por un cliente.
   v
   
   c
   A Dato
Datoss de lo
loss pr
prod
oduc
ucto
tos.
s. El sio
sio we
web
b de la co
comp
mpañ
añía
ía Libre
Librerí
ríaa On
On-L
-Lin
inee S. A.
7 Rioja (UNIR)
© Universidad Internacional de La almacenará
almacenará inormación
inormación de los productos en el sio
web
Datos personales. El s i
io web d e l a co
compañía Librería O n-
n-Line S. A .
8 almace
almacenar
naráá in
inorm
ormaci
ación
ón per
person
sonal
al rel
relaci
aciona
onada
da con
clientes, agentes de ventas y administrador.

   v 9 Disp
Dispon
onib
ibil
ilid
idad
ad del
del si
sio
o El sio web de la compañía Librería On-Line S. A. debe
   
   c
   A web. estar disponible en régimen de 24x7 para los clientes.

7
 Acvidades
 

Asignatura Datos del alumno Fecha

Nombre de la asignatura Apellidos:
Desarrollo Seguro de
Sofware y
Sofware  y Auditoría Nombre:

Capacidad realizar Capacidad realizar peciones de pago a un procesador

10
peciones de pago. de tarjetas de crédito externo
Capacidad ejecutar Repres
Representa
enta la cap
capaci
acidad
dad de eje
ejecut
cutar
ar cód
código
igo 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
datos,, para recuperar cualquier inormación
inormació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
   n consultas SQL a la base de leer, insertar y actualizar base de datos de la compañía
    ó
   i
   c 13
   a datos como un usuario de Librería On-Line S. A., como un usuario de lectura y
   c
   i
    l
   p
   a lectura y escritura. escritura.
   y
   a
   m Capacidad de Capacidad de realizar un back up de la base de datos en
   e
   t 14
   s
   i recuperación de datos. un proveedor de servicios externo a la compañía.
   s
   e
    d Inicio de Sesión. Sesión d e ac
acceso d e un
un u su
suario a l si
sio w eb
eb d e la
la
   s
   o
   i
   r
   a
    d 15 compañía Librería On-Line S. A. El usuario podría ser un
   n
   u cliente, el agente de ventas o el administrador.
   c
   e
   s
   s Acceso al servidor de Acceso al servidor de base de datos para administrarlo y
   o 16
base de datos. demás usuarios en unción de sus permisos
Capacidad de crear Capaci
Capacidad
dad de cre
crear
ar usu
usuari
arios
os en el sis
sistem
tema.
a. Es
Estos
tos
17 usuarios. podr
podría
ían
n se
serr cl
clie
ient
ntes
es,, el ag
agen
ente
te de ve
vent
ntas
as 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
Capacidad para audita
auditarr todos los evento
eventoss audit
auditables
ables
18 sistema. que ocurrier
ocurrieron
on den
dentro
tro del sis
sistem
temaa de vent
ventas
as de la
Librería On-Line S. A.

Tabla 2. Tabla de Acvos.

El estudiante debe rellenar la columna de la derecha, «actores», con el idenfcador

asignado a los actores en la tabla «actores y niveles de confanza» del anterior
apartado.
© Universidad Internacional de La Rioja (UNIR)

Si lo considera puede completar más la tabla con nuevos acvos que considere en
su diseño. Se tendrá en cuenta en la nota fnal.

Denir la arquitectura

8
 Acvidades
 

Asignatura Datos del alumno Fecha

Nombre de la asignatura Apellidos:
Desarrollo Seguro de
Sofware y
Sofware  y Auditoría Nombre:

  Matriz de control de acceso a los datos:

Los datos de la aplicación comprenden la inormación del cliente (cuenta, dirección

de acturación, dirección de envío, etc.), producto (datos del producto, etc.), pedido
(datos de pedido, lista de materiales, echa de envío, etc.) y tarjeta de crédito
(número de tarjeta de crédito, código de verifcación, mes y año de vencimiento,
etc.). Dado que la enda web procesará inormación de tarjetas de crédito, la
inormació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 dierentes
pos de datos del sistema.

Usuarios (roles)

Administrador Cliente Agente ventas

Datos de Clientes C,R,U,D

   s
   o
   t Datos de productos
   a
   D 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 dierentes pos

de datos del sistema.

© Universidad Internacional de La Rioja (UNIR)

  Determinar los componentes, servicios,
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

(hps). La aplicación web se conectará a la base de datos del servidor SQL a través

9
 Acvidades
 

Asignatura Datos del alumno Fecha

Nombre de la asignatura Apellidos:
Desarrollo Seguro de
Sofware y
Sofware  y Auditoría Nombre:

del puerto 1433 (mediante TCP / IP). Cuando los usuarios usan un protocolo HTTPS
sobre el puerto 443, el cerfcado SSL también se considera un componente y

necesitará
necesitará estar protegido contra amenazas de alsifcación, robo e integridad.

Diseño de la autencación de las endades:

El usuario se autencará en la aplicación web mediante ormulario (nombre de

usuario y contraseña), que a su vez se autencará contra la base de datos de SQL
Server (implementada internamente) a través de una aplicación de servicios web,
ulizando una idendad de la aplicación web.

  Idencación de tecnologías:

La aplicación web está desarrollada en [Link] usando C # mientras que la base de

datos se ha implementado en base al producto Microso SQL Server en su úlma
versión. El servidor web se implementa en base al producto Internet Inormaon
Server (ISS) para dar soporte a la tecnología [Link] y la elección de SQL Server
como base de datos del backend. Con [Link] ulizará el rame .Net 3.5 o .Net 4.0.

  Determinar la topología lógica:

La topología lógica del sistema es conorme a la siguiente fgura:

© Universidad Internacional de La Rioja (UNIR)

10
 Acvidades
 

Asignatura Datos del alumno Fecha

Nombre de la asignatura Apellidos:
Desarrollo Seguro de
Sofware y
Sofware  y Auditoría Nombre:

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

Descomponer la aplicación

  Idencar las fronteras de conanza:

Un límite de confanza es el punto en el que cambia el nivel de seguridad. Para la
enda web de este ejercicio tenemos las siguientes ronteras de confanza.
• Entre el exterior (Internet) y la DMZ.
• Entre la DMZ y las zonas internas (Intranet).

  Denir los puntos de entrada:

Los puntos de entrada son aquellos elementos que incorporan la entrada del
usuari
usuario
o y de
defne
fnen
n las int
inter
erace
acess a tra
través
vés de las que los pot
potenc
encial
iales
es ag
agent
entes
es
maliciosos pueden interactuar con la aplicación con el objevo de introducir datos
con carácter
© Universidad Internacional de La Riojamalicioso.
(UNIR) Para atacar una aplicación, deben exisr puntos de entrada,
por lo tanto, constuyen una uente potencial de amenaza. Cada uno debe ser
explí
explícit
citame
amente
nte ide
idenf
nfcad
cado
o y sal
salvag
vaguar
uardad
dado.
o. Los pun
puntos
tos de ent
entra
rada
da en una
aplicación web pueden incluir cualquier página que tenga en cuenta la entrada del
usuario.

11
 Acvidades
 

Asignatura Datos del alumno Fecha

Nombre de la asignatura Apellidos:
Desarrollo Seguro de
Sofware y
Sofware  y Auditoría Nombre:

Algunos de los puntos de entrada idenfcados en la enda web del ejercicio

pueden ser los siguientes:

Puntos de entrada

ID Nombre Descripción Actores

1 Puer
Puerto
to HT
HTTP
TPSS El si
sio
o we
web
b de la co
comp
mpañ
añía
ía “L
“Lib
ibre
rerí
ríaa On
On-L
-Lin
inee SA
SA”” es (1), (2), (3), (4)
solame
solamente
nte acc
accesi
esible
ble a tra
través
vés del pro
protoc
tocolo
olo TLS
TLS..
Todas las páginas dentro del sio web están en
capas desde este punto de entrada.
1.1 Página Página de presentación del sio web de la compañía
principal de la “Librería On-Line SA”. Es el punto de entrada para
enda todos los usuarios, tanto los maliciosos como los
que no.

1.2 Página de Los clientes y agentes de ventas ulizan esta página

Inicio de para iniciar sesión en el sio web de la compañía
Sesión “Librería On-Line SA”.
1.2
1.2.1 Func
ncio
iona
nali
lida
dad
d La un
unci
ció
ón de in
inic
icio
io de ses
esió
ión
n ac
acep
epta
ta la
lass
de In
Inic
icio
io de creden
credencia
ciales
les sum
sumin
inist
istrad
radas
as por el usu
usuari
ario
o y las
Sesión compara con las de la base de datos.
1.3 Página de La página ulizada para realizar búsquedas.
búsqueda
1.4 Página de Página donde se confguran las preerencias de los
preerencias usuarios
1.5 Página de Págin
Páginaa par
paraa la adm
admini
inistr
straci
ación
ón del cat
catálo
álogo
go 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 idenfcador

asignado a los actores en la tabla «Actores y niveles de confanza» del siguiente
apartado.
© Universidad Internacional de La Rioja (UNIR)

Si lo considera, puede completar más la tabla con nuevos acvos que considere en
su diseño. Se tendrá en cuenta en la nota fnal.

  Idencar puntos de salida:

12
 Acvidades
 

Asignatura Datos del alumno Fecha

Nombre de la asignatura Apellidos:
Desarrollo Seguro de
Sofware y
Sofware  y Auditoría Nombre:

Los puntos de salida son aquellos elementos que muestran inormación desde el

sistema.
sistema. Ta
Tambi
mbiénén inc
incluy
luyen
en pro
proce
cesos
sos que ex
extra
traen
en dat
datos
os del sis
sistem
tema.
a. Ade
Además
más,,
pueden ser la uente de uga de inormación y deben estar igualmente protegidos.
Algunos de los puntos de salida idenfcados en la enda 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
de re
resultados La página ulizada para presentar los resultados
de búsqueda de las búsquedas.
2 Página de Página donde se muestran las preerencias de los

preerencias usuarios.
3 Página de Catalogo Pági
Página
na qu
quee pr
pres
esen
enta
ta lo
loss re
resu
sult
ltad
ados
os de la
de producto administración del catálogo de productos.
4 Procesos tarjetas de Procesos de verifcación de tarjetas de crédito y
crédito realización de pagos.
5 Procesos de
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 idenfcador

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

© Universidad Internacional de La Rioja (UNIR)

Si lo considera, puede completar más la tabla con nuevos acvos que considere en
su diseño. Se tendrá en cuenta en la nota fnal.

  Idencar dependencias externas:

13
 Acvidades
 

Asignatura Datos del alumno Fecha

Nombre de la asignatura Apellidos:
Desarrollo Seguro de
Sofware y
Sofware  y Auditoría Nombre:

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

pueden suponer una amenaza para la misma. Las dependencia
dependenciass externas serían:

Dependenciass Externas
Dependencia

I Descripción

1 Servicio
Servicio de copia
copia perió
periódica
dica de la base de datos
datos a una ubica
ubicación
ción de un
un tercero.
tercero.
2 Servidor
Servidor que
que almacena
almacena de
de los eventos
eventos del
del sistema
sistema en el servidor
servidor centra
centralizad
lizado
o de almacena
almacenamient
miento
o de log
de la compañía.
3 Servic
Servicio
io de veri
verifca
fcació
ción
n de tarj
tarjeta
etass de créd
crédito
ito y rea
realilizac
zación
ión de
de pagos
pagos

Tabla 6. Dependencias externas.

  Realización del diagrama de ujo de datos (DFD).

Una vez re
recop
copila
ilada
da tod
todaa la in
inorm
ormaci
ación
ón sob
sobre
re la apl
aplica
icació
ción
n en los apa
aparta
rtados
dos
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
obtene
obtenerr una me
mejor
jor com
compre
prensi
nsión
ón de com
como
o la apl
aplica
icació
ción
n ace
acepta
ptará,
rá, pro
proces
cesará
ará y
manejará los datos a medida que se distribuyen a través de sus dierentes límites de
confanza. Hay una serie de símbolos que se ulizan en este po de diagramas, en la
siguiente fgura os muestro un resumen de los más importantes
importantes::

© Universidad Internacional de La Rioja (UNIR)

14
 Acvidades
 
 

Asignatura Datos del alumno Fecha

Nombre de la asignatura Apellidos:
Desarrollo Seguro de
Sofware y
Sofware  y Auditoría Nombre:

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

Para la realización del DFD se ulizará la herramienta Threat Análisis and Modeling
Tool 2016 de la compañía Microso, descargable
descargable en el siguiente enlace:

hps://[Link].com/es-es/az
hps://[Link].com/es-es/azure/security/de
ure/security/develop/threat-mod
velop/threat-modeling-tool
eling-tool

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

herramienta.. Además, como ayuda se aconseja visionar estos dos videos:
herramienta

• AppSecEU 16 - Mahias Rohr - Praccal Threat Modeling with Microsos

Threat Modeling Tool 2016: hps://[Link]/watch?
v=C5IPkuDnOGs

© Universidad Internacional de La Rioja (UNIR)

• Mi
Miccro
rosso SDLL
SD Unit
Unit0
04 - Thr
hreeat Mode
Modeli
lin
ng Prin
Princcip
iple
less (Leeve
(L vell 100
00)):
hps://[Link]/watch?v=WGz2JQ1OlGQ 

15
 Acvidades
 

Asignatura Datos del alumno Fecha

Nombre de la asignatura Apellidos:
Desarrollo Seguro de
Sofware y
Sofware  y Auditoría Nombre:

Una vez instalada la herramienta, para la realización de DFD hay que trabajar en la
vista de diseño, que se obene al pulsar el en menú View/Desing View, tal y como
View/Desing

se muestra en la siguiente fgura:

Figura 4. Vista de Diseño de la herramienta Threat Analysis and Modeling Tool [Link]: elaboración
propia.

Os pro
propon
pongo
go mod
modela
elarr la apl
aplica
icació
ción
n me
media
diante
nte el sig
siguie
uiente
nte dia
diagra
grama
ma DFD que
const
constuye
uye una rep
repres
resent
entaci
ación
ón grá
gráfca
fca que agi
agiliz
lizaa el pro
proces
ceso
o de mod
modela
elado
do de
requerimientos
requerimientos y al mismo.

En la siguiente fgura 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
ene mucho margen de mejora. El alumno que lo mejore se le tendrá en cuenta en
la nota.
© Universidad Internacional de La Rioja (UNIR)

16
 Acvidades
 

Asignatura Datos del alumno Fecha

Nombre de la asignatura Apellidos:
Desarrollo Seguro de
Sofware y
Sofware  y Auditoría Nombre:

Figura 5. Modelo básico de diagrama DFD.

Una vez en esta vista hay que empezar a realizar el diagrama DFD conorme a todos
los datos obtenidos en las etapas anteriores de orma que sea acorde a la topología
lógi
lógica
ca indi
indica
cada
da en la Figu
Figura
ra 2. En el cua
cuadr
dro
o de la de
dere
rech
cha,
a, stencil ,  están los
dierentes 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 confgurar las propiedades de cada elemento del diagrama, por ejemplo,
confgurar autencació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 repedas. Es decir, se tendrán menos amenazas. Un ejemplo
puededeser
© Universidad Internacional el siguiente,
La Rioja (UNIR) aunque el alumno lo puede modelar de orma dierente
según considere:

17
 Acvidades
 

Asignatura Datos del alumno Fecha

Nombre de la asignatura Apellidos:
Desarrollo Seguro de
Sofware y
Sofware  y Auditoría Nombre:

Idencació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ácamente
View/Analysis automácamente
las amenazas sugeridas para el diagrama de ujo de datos dibujado. Al cliquear en
cada una de ellas vemos inormación en detalle de las mimas y algún ormulario
para introducir más inormación como podría ser las salvaguardas que la miguen y
su jusfcación.

Figura 6. Vista de análisis de la herramienta Threat Analysis and Modeling Tool 2016.

La herramienta idenfca las amenazas a nivel de red, host  y

 y aplicación ulizando el
© Universidad Internacional de La Rioja (UNIR)
método STRIDE (Spoofng, Tampering, Repudiaon, Inormaon disclosure, Denial
o ser
servic
vice,
e, Ele
Eleva
vaon
on o pri
privil
vilege
ege),
), en cas
caste
tella
llano
no Sup
Suplan
lantac
tación
ión de Ide
Idend
ndad,
ad,
Manipulación maliciosa de datos, Repudio, Divulgación de inormación, Denegación
de servicio y Escalado de privilegios. Este método se aplica, por cada elemento de la

18
 Acvidades
 
 

Asignatura Datos del alumno Fecha

Nombre de la asignatura Apellidos:
Desarrollo Seguro de
Sofware y
Sofware  y Auditoría Nombre:

aplica
aplicació
ción
n ide
idenf
nfca
cado
do en la eta
etapa
pa an
anter
terior
ior,, ana
analiz
lizand
ando
o a que cat
catego
egoría
ríass 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 ujo 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.

© Universidad Internacional de La Rioja (UNIR)

Figura 7. Vista análisis Threat Analysis and Modeling Tool. Fuente: elaboración propia.

19
 Acvidades
 
 

Asignatura Datos del alumno Fecha

Nombre de la asignatura Apellidos:
Desarrollo Seguro de
Sofware y
Sofware  y Auditoría Nombre:

Antess es nece
Ante necesario
sario cargar
cargar la plan
planlla
lla caso1.tb7, descargable de la plataorma, y
cargarla mediante el menú aply template, según la fgura:

Aplicación de Planlla

El archivo se dejará en el oro, se les enviará a sus carpetas de descarga o también

puede descargarse desde el siguiente enlace:
hp://[Link]/escuela
hp://[Link]/escueladeingenieria/05
deingenieria/05
Seguridad_del_Soware/[Link]

Figura 8. Aplicación de planlla.

  Documentar las amenazas

Una vez realizado el análisis automáco de las amenazas, hay que documentarlas;
para ello se deberá rellenar la tabla siguiente. Hay rellenarla manualmente con cada
© Universidad Internacional de La Rioja (UNIR)
una de las amenazas obtenidas con la herramienta, indicando su objevo y las
técnicas de ataque. Se adjunta un ejemplo.

20
 Acvidades
 

Asignatura Datos del alumno Fecha

Nombre de la asignatura Apellidos:
Desarrollo Seguro de
Sofware y
Sofware  y Auditoría Nombre:

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

Objevo Componente de acceso a base de datos

El atacante introduce comandos SQL en el campo usuario ulizado para ormar

Técnicas de ataque
una nueva sentencia SQL.
Patrón ataque CAPEC CAPEC-66: SQL Injecon
CWE-89: Improper Neutralizaon o Special Elements used in an SQL Command
Código CWE (si aplica)
('SQL Injecon')
Descripción de la

amenaza

Objevo
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 idenfcar el patrón de CAPEC y código CWE,
pues proporcionan inormación para poder realizar una valoración de riesgos más
efcaz y efciente y una mejor elección de salvaguardas y medidas de migació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 idenfcada la lista de amenazas, el siguiente paso consiste en
puntuarlas de acuerdo con el riesgo que suponen. Esto nos permirá priorizar las
© Universidad Internacional de La Rioja (UNIR)
actuaciones a eectuar para migar el riesgo.

Para ello ulizaremos el método DREAD (Damage, Reproducibility, Exploitability,

Aected,
Aect ed, Dis
Discov
covera
erabil
bility
ity),
), en cas
caste
tella
llano:
no: Dañ
Dañoo pot
potenc
encial
ial,, Re
Repro
produc
ducvi
vidad
dad,,
Explotabilidad, Usuarios aectados, Descubribilidad. El riesgo se puede cuanfcar

21
 Acvidades
 

Asignatura Datos del alumno Fecha

Nombre de la asignatura Apellidos:
Desarrollo Seguro de
Sofware y
Sofware  y Auditoría Nombre:

como el resultado de mulplicar 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 cuanfca con un valor entre 1 y 3.

Figura 9. Signifcado 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 migació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 [Link]ón de las amenazas.

El alumno deberá rellenar la tabla con al menos 15 amenazas obtenidas de la de la

herr
herram
amie
ient
ntaa Th
Thre
reat
at An
Anal
alys
ysis
is an
and
d Mo
Mode
deliling
ng To
Tool
ol 20
2016
16.. Se va
valo
lora
rará
rá qu
quee se

implemente en idioma español y se incluyan más amenazas de las indicadas.

22
 Acvidades
 

Asignatura Datos del alumno Fecha

Nombre de la asignatura Apellidos:
Desarrollo Seguro de
Sofware y
Sofware  y Auditoría Nombre:

Migación

  Decidir cómo responder a las amenazas:

Fren
Frente
te a la
lass am
amen
enaz
azas
as se pu
pued
eden
en da
darr di
die
ere
rent
ntes
es re
resp
spue
uest
stas
as,, ba
basá
sánd
ndos
ose,
e,
principalmente,
principalmente, en el riesgo asociado a cada una. Una amenaza puede ser eliminada
(implica eliminar la uncionalidad del sistema donde se presenta) cuando esta es
opcional o cuando el riesgo que ene 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

mig
migac
ació
ión
n u
ueese de
dema
masi
siad
ado
o co
cost
stos
osaa co
comp
mpar
arad
adaa co
con
n el ri
ries
esgo
go as
asoc
ocia
iado
do..
Gene
Genera
ralm
lmen
ente
te,, se op
opta
tará
rá po
porr mi
mig
gar
arla
la me
medi
dian
ante
te al
algu
guna
na co
cont
ntra
rame
medi
dida
da o
salvaguarda. Por úlmo, se puede transerir el riesgo a una tercera parte, por
ejemplo, al usuario u otra aplicación que interactúe con la nuestra.

  Iden
Idencar
car la
lass téc
técni
nicas
cas y tec
tecnol
nologí
ogías
as nec
necesa
esaria
riass par
para
a mi
miga
garr los ri
riesg
esgos
os
idencados:

Para las amenazas idenfcadas hay que seleccionar una serie de salvaguardas que
miguen
mig uen su riesg
riesgo
o asoc
asociado
iado a la mism
misma:
a: rest
restricc
ricciones
iones arquitectóni
arquitectónicas,
cas, téc
técnicas
nicas
criptogr
criptográfca
áfcas,
s, meca
mecanismo
nismoss de aute
autencac
ncación,
ión, algor
algoritmos
itmos segu
seguros,
ros, 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 migació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
 Acvidades
 

Asignatura Datos del alumno Fecha

Nombre de la asignatura Apellidos:
Desarrollo Seguro de
Sofware y
Sofware  y Auditoría Nombre:

……

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 migar
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.

© Universidad Internacional de La Rioja (UNIR)

También se puede usar la siguiente tabla:
Amenazas Propiedad Salvaguardas

Spoong identy   (Suplantación Autencación    Procesos de Autencación, Autorización y

Auditoría (AAA): hash, frma digital.
de Idendad)
 Protección de secretos

No almacenamiento de secretos
 Single Sign On

24
 Acvidades
 
 

Asignatura Datos del alumno Fecha

Nombre de la asignatura Apellidos:
Desarrollo Seguro de
Sofware y
Sofware  y Auditoría Nombre:

 IPSEC
Tamp
Tamper
erin
ing
g with
with Data
Data Integridad    Procesos de AAA: hash, frma digital.
 Códigos de autencación de mensajes.
(Manipulación
(Manipulación de datos)
 Firmas digitales.

Protocolos resistentes a la manipulación.
 Listas control de acceso ACL
Repudiaon (Repudio)
Repudiaon (Repudio) No Repudio    Procesos de Autencación: hash, frma digital.
 Procesos de Auditoría.
 Sellado de empo.
Ino
Inorm
rma
aon
on Disc
Disclo
losu
sure
re Confdencialida  Procesos de AAA: hash, frma digital.
 Protección de secretos
(Revelación de información) d
 No almacenamiento de secretos.
 Protocolos seguros.
 Encriptado.
Denial
Denial o Se
Servi
rvice
ce   (Denegación Disponibilidad    Procesos de AAA: hash, frma digital.
 Listas control de acceso ACL.
de servicio)
 Calidad de servicio.
Elevaon o Privilege (Elevación
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.

MAGERIT. (2012).
Metodología de Análisis y Gesón de Riesgos de los Sistemas de Información, Libro

II - Catálogo de Elementos. Ministerio de Hacienda y Administracione

Elementos. Administracioness Públicas:
hp://administracionelectronica
hp://[Link]/pae_Hom
.[Link]/pae_Home/pae_Document
e/pae_Documentacion/
acion/
pae_Metodolog/pae_Magerit.h
pae_Metodolog/pae_Magerit.html#.U2_oe2CKB
tml#.U2_oe2CKB2E
2E

Validación

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

reeja con fdelidad el diseño de la aplicación y las amenazas potenciales a las que
se debe enrentar. Una vez idenfcadas las amenazas, en una ase temprana del
desarrollo
© Universidad Internacional (especif
(especifcación
de La Rioja (UNIR)cación y diseño de la aplicación), se puede pensar en la orma de
arontarlas:
• Rediseñar.
• Usar salvaguardas estándar.
• Usar salvaguardas personalizadas
personalizadas..

25
 Acvidades
  

Asignatura Datos del alumno Fecha

Nombre de la asignatura Apellidos:
Desarrollo Seguro de
Sofware y
Sofware  y Auditoría Nombre:

• Aceptar el riesgo de acuerdo con las polícas de la organización y requisitos

del sistema.

En este apartado, el estudiante no ene que realizar nada, es solo inormavo.

Presentación
Presentación de la memoria

Pres
Presen
enta
tarr un
unaa me
memo
mori
riaa co
con
n lo
loss re
resu
sult
ltad
ados
os pe
pedi
dido
dos.
s. In
Incl
clui
uirr el fc
fche
hero
ro co
con
n
extensión .tm7 que genera la herramienta y el inorme 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 acvidad. La extensión máxima de la acvidad 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 Acvos 0,5 5%
Criterio 2 Matriz de control de accesos 0,5 5%
Criterde
© Universidad Internacional ioLa
3 Rioja (UNIR)
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
 Acvidades
 

Asignatura Datos del alumno Fecha

Nombre de la asignatura Apellidos:
Desarrollo Seguro de
Sofware y
Sofware  y Auditoría Nombre:

10 100 %

© Universidad Internacional de La Rioja (UNIR)

27
 Acvidades