Modelado de Amenazas en Aplicativos

Vista previa del material en texto

IMPLEMENTACIÓN DEL MODELADO DE AMENAZAS PARA LA OPTIMIZACIÓN 
DE PROCESOS DE ASEGURAMIENTO DE APLICACIONES 
 
 
 
 
 
 
 
 
ANDRÉS FELIPE MELO HERNÁNDEZ 
 
 
 
 
 
 
 
 
UNIVERSIDAD SANTO TOMÁS DE AQUINO 
FACULTAD DE INGENIERÍA 
INGENIERÍA DE TELECOMUNICACIONES 
BOGOTÁ D.C 
2022 
 
 
IMPLEMENTACIÓN DEL MODELADO DE AMENAZAS PARA LA OPTIMIZACIÓN 
DE PROCESOS DE ASEGURAMIENTO DE APLICACIONES 
 
 
 
 
Presentado por: 
ANDRES FELIPE MELO HERNANDEZ 
CODIGO: 2163418 
 
 
Trabajo opción de grado Pasantías para optar por el título de Ingeniero de 
Telecomunicaciones 
 
 
Tutor: Gustavo Alonso Chica 
Ingeniero Electrónico 
 
 
 
UNIVERSIDAD SANTO TOMÁS DE AQUINO 
FACULTAD DE INGENIERÍA 
INGENIERÍA DE TELECOMUNICACIONES 
BOGOTÁ D.C 
2022 
 
RECTOR GENERAL 
Padre José Gabriel Mesa Angulo, O.P. 
 
VICERRECTOR ADMINISTRATIVO Y FINANCIERO GENERAL 
Padre, Wilson Mendoza Rivera, O.P. 
 
VICERRECTOR ACADÉMICO GENERAL 
P. Eduardo Gonzáles Gil, O.P 
 
SECRETARIA GENERAL 
Ingrid Lorena Campos Vargas 
 
SECRETARIA DE DIVISIÓN 
E. C. Luz Patricia Rocha Caicedo 
 
 
DECANO FACULTAD DE INGENIERÍA DE TELECOMUNICACIONES 
Ingeniero Germán Macías Muñoz 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Nota de Aceptación. 
_________________________________________________________________ 
_________________________________________________________________ 
_________________________________________________________________ 
_________________________________________________________________ 
 
 
 
__________________________ 
Firma Ingeniero. Gustavo Alonso Chica 
Tutor Asignado 
 
 
__________________________ 
Firma del Jurado 
 
 
__________________________ 
Firma del Jurado 
 
 
 
 
 
 
 
__________________________ 
Fecha 
 
 
 
 
 
 
 
 
 
 
Tabla de contenido 
 
INTRODUCCIÓN ......................................................................................................................... 12 
1. MARCO GENERAL .............................................................................................................. 13 
1.1 PLANTEAMIENTO DEL PROBLEMA ............................................................................. 13 
1.2 JUSTIFICACIÓN ................................................................................................................. 14 
1.3 OBJETIVOS .................................................................................................................... 15 
1.3.1 Objetivo General ............................................................................................................ 15 
1.3.2 Objetivos Específicos ..................................................................................................... 15 
1.4 ALCANCE ........................................................................................................................... 16 
1.5 METODOLOGIA ................................................................................................................. 17 
2. ACTUALIDAD DE LAS METODOLOGÍAS EXISTENTES PARA EL MODELADO DE 
AMENAZAS EN EL CIBERESPACIO. ....................................................................................... 18 
2.1 METODOLOGIAS DEL MODELADO DE AMENAZAS ................................................ 20 
2.1.1 STRIDE .......................................................................................................................... 20 
2.1.2 PASTA ........................................................................................................................... 21 
2.1.3 OCTAVE ....................................................................................................................... 23 
2.1.4 TRIKE ............................................................................................................................ 24 
2.1.5 NIST ............................................................................................................................... 24 
2.2 CASOS DE IMPLEMENTACION DEL MODELADO DE AMENAZAS ........................ 26 
3. CICLO DE VIDA DE DESARROLLO DE SOFTWARE ..................................................... 28 
3.1 DevOps ................................................................................................................................. 31 
4. PROPUESTA DE IMPLEMENTACION DE UNA METODOLOGIA DEL MODELADO 
DE AMENAZAS. .......................................................................................................................... 37 
4.1 Definir objetivos ................................................................................................................... 41 
4.2 Definir el alcance técnico ..................................................................................................... 41 
4.3 Descomposición de la aplicación.......................................................................................... 42 
4.4 Análisis de amenazas ............................................................................................................ 42 
4.5 Análisis de vulnerabilidades y debilidades ........................................................................... 45 
4.6 Modelado de ataque .............................................................................................................. 46 
4.7Análisis de riesgos e impacto de amenazas ........................................................................... 52 
5.HERRAMIENTAS COMPLEMENTARIAS PARA LA EJECUCIÓN DEL MODELADO DE 
AMENAZAS. ................................................................................................................................. 53 
5.1 MICROSOFT THREAT MODELING TOOL ..................................................................... 53 
5.2 THREAT MODELER .......................................................................................................... 55 
5.3 OWASP THREAT DRAGON ............................................................................................. 59 
5. CONCLUSIONES .................................................................................................................. 64 
BIBLIOGRAFIA........................................................................................................................................ 65 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
LISTA DE FIGURAS 
 
Figura 1 Etapas del diseño metodológico. ............................................................................ 17 
 
Figura 2. Fases de la Metodología PASTA .......................................................................... 22 
 
Figura 3 Ciclo de vida del desarrollo de software. ............................................................... 28 
 
Figura 4 Ciclo de vida DevOps. ........................................................................................... 31 
 
Figura 5 Etapas de la metodología PASTA. ......................................................................... 36 
 
Figura 6. Ejemplo de un diagrama de flujo de datos ............................................................ 38 
 
Figura 7. Ejemplo de aplicación del modelo DREAD ......................................................... 39 
 
Figura 8. Ejemplo de un árbol de ataques básico ................................................................. 40 
 
Figura 9. Common Vulnerability and Exposures (CVE) ..................................................... 41 
 
Figura 10. Framework MITRE ATT&CK parte 1 ............................................................... 42 
 
Figura 11. Framework MITRE ATT&CK parte 2 ............................................................... 42 
 
Figura 12. Framework MITRE ATT&CK parte 3 ............................................................... 43 
 
Figura 13. Framework MITRE ATT&CK parte 4 ...............................................................44 
 
Figura 14. Framework MITRE ATT&CK parte 5 ............................................................... 45 
 
Figura 15. Framework MITRE ATT&CK parte final .......................................................... 46 
 
Figura 16 Ejemplo de categorización de amenazas con el framework de MITRE. ............. 47 
 
Figura 17. Interfaz inicial del software Microsoft Threat Modeling Tool ........................... 48 
 
Figura 18. Componentes arquitectónicos del software ......................................................... 49 
 
Figura 19. Reporte genérico de amenazas del software ....................................................... 49 
 
Figura 20. Reporte de las amenazas resultantes en HTML .................................................. 50 
 
Figura 21. Etapas del cumplimiento del Threat Modeler ..................................................... 51 
 
Figura 22. Componentes arquitectónicos del software ........................................................ 51 
 
Figura 23. Interfaz inicial del software ................................................................................. 52 
 
Figura 24. Reporte de amenazas del software ...................................................................... 52 
 
Figura 25. Reporte de amenazas detallado de un componente ............................................. 53 
 
Figura 26. Reporte de requerimientos de seguridad de un componente ............................... 53 
 
Figura 27. Reporte resultante del diagrama construido ........................................................ 54 
 
Figura 28. Diagramas cuantitativos del resultado del análisis del software ......................... 54 
 
Figura 29. Interfaz inicial del software OWASP THREAT DRAGON ............................... 55 
 
Figura 30. Ejemplo de componentes y diagrama en el software .......................................... 56 
 
Figura 31. Reporte manual de amenazas del software ......................................................... 57 
 
Figura 32. Reporte automático de amenazas del software ................................................... 57 
 
Figura 33. Reporte resultante del análisis del software parte 1 ............................................ 58 
 
Figura 34. Reporte resultante del análisis del software parte 2 ............................................ 58 
 
 
 
 
 
 
 
 
LISTA DE TABLAS 
 
Tabla 1. Categorizacion de amenazas STRIDE ............................................................................. 20 
Tabla 2. Buenas prácticas de DevOps ............................................................................................ 35 
Tabla 3 Resumen de categorizacion de amenazas del framework STRIDE ..................................35 
 
 
 
 
 
 
 
 
 
 
 
 
 
10 
 
 
RESUMEN 
 
Banco popular es una entidad financiera con un largo trayecto en el país, perteneciente al grupo 
AVAL dedicada prestar servicios financieros a personas (naturales y jurídicas) y organizaciones, 
servicios como cuentas de ahorro, créditos, tarjetas de crédito, CDT entre otros. La organización 
se encarga día a día de mejorar el funcionamiento de sus productos, para ello buscan implementar 
y desarrollar múltiples tecnologías que permitan optimizar estas, paralelamente buscan garantizar 
el aseguramiento de cada tecnología que este implementada o se desee implementar. Para 
garantizar el aseguramiento de aplicaciones y soluciones es necesario establecer una metodología 
le permita a la organización identificar amenazas de manera anticipada y así mismo resolverlas de 
una forma eficaz. Es por esto que en este documento se brindara una propuesta que permita 
establecer una metodología que garantice un correcto plan estratégico para el aseguramiento de 
aplicaciones y soluciones. 
Para garantizar el cumplimiento de este propósito se debe abordar la problemática de la empresa, 
identificando la actualidad y las diferentes metodologías del modelado de amenazas, paralelamente 
identificar las etapas del ciclo de vida de desarrollo de software, elaborar una propuesta de 
implementación de una metodología especifica del modelado de amenazas e identificar 
herramientas que permitan complementar la ejecución de la técnica. 
Todo esto produce como resultado que la organización pueda lanzar aplicaciones a producción sin 
ningún tipo de amenaza o vulnerabilidad, mejorar la comunicación y entendimiento entre 
direcciones de interés involucradas en los proyectos, y lograr reducir los costos y esfuerzos 
asociados al aseguramiento de aplicaciones. 
 
 
 
 
 
 
 
11 
 
 
ABSTRACT 
 
Banco Popular is a financial institution with a long history in the country, belonging to the AVAL 
group dedicated to providing financial services to individuals (natural and legal) and 
organizations, services such as savings accounts, loans, credit cards, CDT among others. The 
organization is responsible every day to improve the performance of their products, for this they 
seek to implement and develop multiple technologies to optimize these, in parallel they seek to 
ensure the assurance of each technology that is implemented or want to implement. To guarantee 
the assurance of applications and solutions it is necessary to establish a methodology that allows 
the organization to identify threats in advance and solve them in an effective way. For this reason, 
this document will provide a proposal to establish a methodology that guarantees a correct 
strategic plan for the assurance of applications and solutions. 
To guarantee the fulfillment of this purpose, we will have to address the company's problems, 
identifying the current situation and the different threat modeling methodologies, identify the 
stages of the software development life cycle, elaborate a proposal for the implementation of a 
specific threat modeling methodology and identify tools to complement the execution of the 
technique. 
As a result, the organization will be able to launch applications into production without any type 
of threat or vulnerability, improve communication and understanding between stakeholders 
involved in the projects, and reduce the costs and efforts associated with securing applications. 
 
 
 
 
 
 
 
 
12 
 
INTRODUCCIÓN 
 
En la actualidad los ciberataques han crecido exponencialmente, se han presentado múltiples 
situaciones en las cuales organizaciones se han visto afectadas a causa de ciberataques, esto se debe 
a que encontramos en un entorno completamente digitalizado provocado por la actual pandemia, y 
las organizaciones solo se centran en garantizar que sus soluciones funcionen de manera eficaz. 
Las amenazas crecen y evolucionan con alta frecuenta, más aún con una sociedad que está 
altamente ligada a la tecnología. 
A pesar de esto el concepto de seguridad ha evolucionado en el transcurso de los años a tal punto 
que la seguridad es un aspecto que ya se le da importancia en el desarrollo del software. 
Organizaciones como la OWASP o la NIST plantean un concepto de aseguramiento diferente, pero 
ambos contemplan la aplicación del concepto de seguridad en cada etapa del ciclo de desarrollo de 
una aplicación. 
Desde las buenas prácticas de seguridad se pueden encontrar una forma de planificar y optimizar 
los procesos de seguridad, denominado el modelado de amenazas el cual es un proceso que tiene 
como propósito proporcionar una articulación clara y completa de los activos, amenazas y ataques 
para facilitar la determinación de nivel de riesgo y poder crear un plan estratégico para dar solución 
a los problemas que se puedan llegar a presentar dentro del aplicativo. 
Dentro del modelado de amenazas se pueden identificar metodologías como STRIDE, PASTA, 
VAST, entre otros, todas tienen el objetivo de cumplir el propósito mencionado anteriormente, 
pero cada una tienen un área de aplicación diferente, ya que contemplan diferentes etapas y 
métodospara implementarse, en complemento a cada metodología existen herramientas también 
que pueden ayudar a optimizar la realización de los procesos de la técnica, un ejemplo es la 
herramienta desarrollada por Microsoft (Microsoft Threat Modeling Tool). 
 
 
 
 
 
 
 
13 
 
1. MARCO GENERAL 
 
En el primer capítulo del documento se especificará la contextualización de la investigación a 
realizar, en donde se podrá encontrar el planteamiento del problema, justificación, objetivos, 
alcance y metodología propuesta para poder identificar una metodología que le permita a la 
organización optimizar los procesos de aseguramiento de aplicaciones 
 
1.1 PLANTEAMIENTO DEL PROBLEMA 
 
Dentro de la organización existen múltiples controles de seguridad establecidos, cada uno con una 
función específica de aseguramiento a nivel de infraestructura asociada en la empresa Banco 
Popular, así mismo existen pruebas a nivel de Red Team y Blue Team para identificar puntos 
débiles y procesos de Threat Intelligence que tiene la organización. Sin embargo, existe una 
carencia a nivel de seguridad en temas de aseguramiento de desarrollo de aplicaciones, ya que 
solamente se contempla una herramienta que tiene como propósito realizar escaneos de seguridad 
sobre el código una vez la aplicación es realizada y lanzada a producción, lo cual ha provocado la 
exposición de amenazas en las aplicaciones que se puesto en funcionamiento. 
En consecuencia, se han tenido problemas con alto impacto ya que, la aplicación al estar expuesta 
a amenazas, se compromete la infraestructura asociada a esta, y se deben tomar acciones como 
detener el aplicativo y tomar medidas inmediatas por la falta de un plan estratégico que pudiera dar 
una ruta de solución a la falla. De tal forma que lleva a plantear la siguiente pregunta ¿De qué 
forma se puede garantizar que una aplicación contemple el cumplimiento de los requerimientos de 
seguridad necesarios antes de ser lanzada a producción? 
 
 
 
 
 
 
 
14 
 
1.2 JUSTIFICACIÓN 
 
Este documento se realizará con el fin de poder dar una propuesta para la implementación de una 
técnica para el proceso de aseguramiento de aplicaciones, que permita identificar amenazas de 
manera preventiva, para poder así crear un plan estratégico que le permita a la organización dar 
solución a todas las posibles amenazas dentro de un sistema. Se buscará identificar las diferentes 
metodologías existentes en relación al modelado de amenazas, para poder así determinar cuál es la 
más apropiada en función de las necesidades de la organización. El resultado de una 
implementación de esta técnica lograra que la organización se anticipe a las amenazas en el 
desarrollo de sus aplicaciones, y pueda realizar de manera organizada y eficaz la ejecución de 
controles y buenas prácticas de seguridad sobre el aplicativo e infraestructura relacionada a este. 
Es importante resaltar que a pesar de que la técnica está enfocada a temas de seguridad, busca 
incluir a todo el equipo de trabajo que esté involucrado dentro de los proyectos de la organización 
y además de esto existen herramientas como lo es Microsoft Threat Modeling Tool que le permitirá 
al equipo de trabajo gestionar e identificar amenazas de manera mucho más eficaz y rápida. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
15 
 
1.3 OBJETIVOS 
 
1.3.1 Objetivo General 
Establecer una metodología que le permita a la empresa Banco Popular identificar amenazas y 
vulnerabilidades de manera preventiva, con el propósito de garantizar la construcción segura de 
aplicativos dentro de la organización. 
1.3.2 Objetivos Específicos 
 Identificar la actualidad de las metodologías existentes para el modelado de amenazas en el 
ciberespacio. 
 Identificar el ciclo de vida de desarrollo de un sistema (SDLC) 
 Plantear una propuesta de implementación de la metodología que mejor se ajuste a las 
necesidades de la empresa Banco Popular, teniendo en cuenta criterios. 
 Identificar herramientas que permitan la optimización de la metodología propuesta. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
16 
 
1.4 ALCANCE 
 
Con esta propuesta se busca garantizar que se ejecuten de manera correcta los procesos de 
aseguramiento de aplicaciones dentro de la organización, ya que actualmente se contemplan 
metodologías y controles que provocan que los sistemas se encuentren en un entorno de exposición 
a amenazas, debido a que no se realizan escaneos de manera anticipada y no se maneja una ruta de 
trabajo organizada. El modelado de amenazas le permitirá a la organización crecer como equipo 
de trabajo ya que es una metodología que busca la integración de las direcciones de trabajo, esto 
conlleva a que se los procesos se realicen de forma precisa, se logre tener una documentación 
precisa, se fortalezcan los canales de comunicación y se logren lanzar las aplicaciones desarrolladas 
de forma segura, garantizando el correcto funcionamiento de estas. 
Se ha definido el alcance de este trabajo de la siguiente forma: 
Objetivo 1: Un documento capitulo en el cual se buscará identificar las metodologías más 
utilizadas de modelado de amenazas y casos de implementación reales de la metodología, para 
poder determinar cuál es la que mejor se ajusta acorde a las necesidades de la organización 
Objetivo 2: Un documento capitulo en el cual se identificará el ciclo de vida del desarrollo de 
aplicaciones, profundizando modelos específicos existentes dentro de la organización, todo esto 
con el propósito de poder identificar de qué manera se puede conectar el modelado de amenazas 
con el ciclo de desarrollo de software. 
Objetivo 3: Un documento capitulo en el cual se hará el desarrollo de la propuesta de la 
metodología seleccionada, haciendo uso de diferentes frameworks y herramientas de apoyo que 
permitan la optimización del modelado de amenazas. 
Objetivo 4: Un documento capitulo que permita analizar diferentes herramientas del modelado de 
amenazas y así poder determinar cuál es la que mejor se acopla a los procesos de la propuesta de 
implementación. 
 
 
 
 
 
17 
 
1.5 METODOLOGIA 
 
Tipo de investigación 
El tipo de investigación que se contempla para el desarrollo de la monografía es una investigación 
aplicada, debido a que se busca recolectar un gran volumen de información para poder definir e 
identificar una metodología del modelado de amenazas que optimice los procesos de aseguramiento 
de aplicaciones en la empresa Banco Popular. 
Diseño Metodológico 
Este documento se desarrollará bajo la metodología cualitativa, con un enfoque descriptivo, ya que 
como se mencionó anteriormente se busca recolectar toda la información asociada al modelado de 
amenazas para lograr implementar la técnica de manera efectiva, la metodología se desarrolló en 
cuatro fases que se podrán identificar en la siguiente figura. 
 
 
Figura 1. Etapas del diseño metodológico Fuente: Autor 
• Se selecciono la 
metodologia de 
amenazas que mejor 
se acoplaba a las 
necesidades de la 
organizacion
• Se realizo la 
descripcion de cada 
paso para ejecutar la 
metodologia PASTA
• Se recolecto 
informacion de 
herramietnas del 
modelado de 
amenazas para 
determinar cual es 
mas optima para 
implementar.
• Se analizaron las etapas del 
ciclo de vida del desarrollo 
de software para vincularse 
con el modelado de 
amenazas
• Se recolecto informacion 
acerca de las diferentes 
metodologias del 
modelado de amenazas y 
su actualidad
Fase 1
Recopilación 
de información
Fase 2
Analisis de la 
informacion
Fase 3
Diseño de 
propuesta de 
implementacio
n
Fase 4
Analisis de 
herramientas
18 
 
2. ACTUALIDAD DE LAS METODOLOGÍAS EXISTENTES PARA EL MODELADO 
DE AMENAZAS EN EL CIBERESPACIO. 
 
En este capítulo se dará un contexto de la actualidad del modelado de amenazas, específicamente 
se identificarán las diferentes metodologías existentes asociadas a la técnica y casosde 
implementación reales del modelado de amenazas, para poder construir una ruta para la propuesta 
de implementación de un modelado de amenazas para el Banco Popular. 
El modelado de amenazas es el proceso para capturar, organizar y analizar toda la información que 
fluye sobre un sistema, todo esto con el propósito de poder identificar, comunicar y entender las 
amenazas que puedan presentarse y las posibles mitigaciones que se deban aplicar sobre el 
desarrollo de aplicaciones [1]. Además de esto este proceso le permite al equipo de trabajo tomar 
mejores decisiones para el concepto de seguridad que se deba aplicar sobre el desarrollo de 
aplicaciones, ya que generalmente la producción de un modelado de amenazas prioriza la 
categorización de las amenazas, y la creación de una lista de mejoras de seguridad aplicadas a los 
conceptos de diseño, requerimientos o implementación de una aplicación [2]. 
El modelado de amenazas se puede ejecutar sobre una amplia variedad de temas como lo pueden 
ser software, aplicaciones, redes, sistemas distribuidos, IoT (Internet de las cosas) y operaciones 
empresariales, un modelado de amenazas típicamente debe incluir [4]: 
 Descripción del objeto sobre el cual se va a aplicar el modelado de amenazas 
 Amenazas potenciales para el sistema 
 Supuestos que deben comprobarse o ser retados en el futuro a medida que cambie el 
panorama de las amenazas 
 Acciones que puedan llevarse a cabo para mitigar cada amenaza 
 Una forma para validad el modelo y las amenazas resultantes para poder identificar el éxito 
de las acciones propuestas 
Existen múltiples formas de poner en ejecución el modelado de amenazas, sin embargo, desde 
una de las principales entidades a nivel de Ciberseguridad (OWASP) plantean que el modelado 
de amenazas debe ejecutarse en tres pasos [5]: 
 Descomponer la aplicación: Este paso consiste en poder obtener la información posible 
sobre una aplicación, como se comporta y con qué componentes externos interactúa, esto 
se puede realizar a través del análisis de la arquitectura de la solución o análisis de la 
19 
 
documentación de esta. Para garantizar el cumplimiento de este paso se deben realizar 
tareas como: Crear casos de uso para el entendimiento de funciones de la aplicación, 
identificar los puntos de entrada puntos potenciales sobre los cuales un atacante podría 
entrar, identificar los activos de información que va a manejar en la aplicación e identificar 
los niveles de confianza que estarán representados en los derechos de acceso de los usuarios 
o entidades externas. Toda esta información deberá ser documentada y además de esto se 
deberá hacer uso de un diagrama de flujo de datos como resultado del análisis del primer 
paso [5]. 
 Determinar y categorizar riesgos: En este paso se buscan identificar las amenazas 
presentes en la aplicación, para ello es fundamental utilizar una metodología de 
categorización de estas, algunos ejemplos pueden ser la metodología STRIDE o el marco 
de seguridad de aplicaciones (ASF) el cual define categorías de amenazas como Auditoria 
y registro, autenticación, autorización, gestión de la configuración, protección de 
almacenamiento de datos , protección de transito de datos, validación de datos y gestión de 
excepciones. Todo esto se realiza con el objetivo de poder identificar las amenazas desde 
las perspectivas del atacante y el defensor, los diagramas de flujo de datos producidos en el 
anterior paso proporcionaran información para el atacante, ya que comprenderá la 
interacción de los componentes, el flujo de información, procesos y fuentes utilizadas en la 
aplicación. La determinación del riesgo para la seguridad de cada amenaza puede hacerse 
utilizando un modelo de riesgos basado en valores como DREAD, o un modelo de riesgo 
cualitativo menos subjetivo basado en factores de riesgo generales (por ejemplo, 
probabilidad o impacto) [5]. 
 Determinar contramedidas y mitigaciones: Una vez categorizadas las amenazas, 
dependiendo en la prioridad resultante del análisis, se deben empezar a tomar medidas de 
aseguramiento para dar solución a las amenazas resultantes de los anteriores pasos, la 
estrategia de mitigación de riesgos podría implicar la evaluación de estas amenazas a partir 
del impacto empresarial que suponen. Una vez realizada esta evaluación las opciones para 
abordar el riesgo son [5]: 
o Accept: Decidir si el impacto operacional es aceptable 
o Eliminate: Eliminar los componentes que hacen que se produzcan vulnerabilidades 
o Mitigate: Añadir chequeos o controles que busquen reducir el impacto de la 
amenaza, o la probabilidad de que se presente la amenaza. 
20 
 
2.1 METODOLOGIAS DEL MODELADO DE AMENAZAS 
 
2.1.1 STRIDE: El modelado de amenazas con la metodología STRIDE ofrece una categorización 
de las amenazas, la cual está dividida en 6 partes: 
Categoría Dominio de 
seguridad 
Descripción 
Spoofing Autenticidad Esta amenaza consiste en suplantar la identidad 
del usuario es decir intentar ser alguien que no es. 
Tampering Integridad Esta amenaza consiste en intentar modificar los 
datos que se intercambian entre la aplicación y un 
usuario legítimo. 
Repudiation No repudio Esta amenaza está asociada a la denegación de 
acciones de un sistema de tal forma que no exista 
método de verificación alguno de que esto 
sucedió. 
Information 
disclosure 
Confidencialidad Esta amenaza implica la exposición de 
información a personas que no deberían tener 
acceso. 
Denial of service Disponibilidad Esta amenaza consiste en la interrupción de un 
servicio a un usuario valido de la organización. 
Elevation of 
privileges 
Autorización Esta amenaza tiene como objetivo darle 
privilegios a un usuario que no debería tener 
ningún tipo de accesos, lo que en consecuencia 
provocaría que el sistema este en peligro a causa 
de las acciones que pudiera realizar este usuario 
 
Tabla 1. Categorización de amenazas STRIDE [7]. 
Esta metodología tiene como propósito identificar y categorizar las amenazas de seguridad 
informática después de realizar el respectivo análisis sobre la aplicación, es una metodología muy 
practica en el DevSecOps, ya que proporciona un marco de detección de vulnerabilidades, el cual 
21 
 
permitirá establecer una ruta de mitigación de amenazas a las cuales el sistema se enfrenta, es 
importante resaltar que STRIDE sirve para las primeras fases del DevSecOps, es decir la fase de 
análisis y diseño de aplicaciones [8]. 
En complemento a esta metodología se hace uso de un modelo de puntuación de amenazas 
denominada DREAD, este marco al igual que STRIDE proporciona una categorización de 
evaluación de riesgos, a través del análisis de estas cinco divisiones se puede un análisis profundo 
en el cual se pueda obtener el grado de criticidad y orden de priorización de la amenaza, sus siglas 
descomponen las siguientes definiciones [8]: 
 Damage: daño, impacto que tiene la explotación de la amenaza a causa de la vulnerabilidad 
 Reproducibility: Reproducción del incidente, probabilidad de repetirse el daño. 
 Exploitability: Explotación de la vulnerabilidad, que tan complejo es mitigarla y que costos 
están asociados a este proceso 
 Affected Users: Determinar el impacto de afectación del incidente, sobre qué cantidad de 
usuarios y recursos aplicados. 
 Discoverability: Grado de facilidad de exposición y descubrimiento de la vulnerabilidad 
2.1.2 PASTA: El proceso de simulación de ataques y análisis de amenazas (PASTA) es una 
metodología del modelado de amenazas centrada en la gestión de riesgos en el ciberespacio, 
tendencia de colaboración entre miembros de la organización, información de amenazas basada en 
pruebas y un enfoque para determinar la probabilidad de explotación de una amenaza [9]. 
PASTA habilita la colaboración entre diferentes direcciones involucradas en el desarrollo de 
aplicaciones en la organización, con el propósitode comprender la importancia de las amenazas 
expuestas, probabilidad de ejecución y que grado de criticidad tendrían en caso de ser explotadas. 
Además de esto la metodología proporciona un paso a paso para ejecutar el análisis de riesgos, el 
cual permitirá la creación de una ruta de trabajo centrada en el concepto de seguridad, y podrán 
trabajar todas las áreas interesadas en el desarrollo del proyecto [9]. 
Los pasos para ejecutar la metodología de PASTA son: 
22 
 
 
Figura 2. Fases de la metodología PASTA [9]. 
1. Definir objetivos: En este paso se buscan identificar los objetivos corporativos, identificar 
los requerimientos de seguridad y cumplimiento del proyecto, y analizar el impacto 
empresarial de los anteriores objetivos [9]. 
2. Definir el alcance técnico: En este paso se busca comprender la superficie de ataque de la 
aplicación definiendo su alcance técnico (es necesario saber que se está protegiendo), para 
cumplir correctamente este paso se debe entrar a profundizar cómo se comporta la 
aplicación, que limites tiene, que dependencias de software tiene y que infraestructura está 
asociada a este proyecto [9]. 
3. Descomponer la aplicación: Para este paso se debe crear diagramas de flujo de datos 
(DFD) que deben ser el resultado de un análisis en el cual se identifiquen si existen modelos 
de confianza implícitos es decir si existe algún modelo de roles y responsabilidades, o 
fuentes de entrada de información y servicios, todo esto para poder garantizar una visión 
clara del funcionamiento de la aplicación [9]. 
4. Analizar las amenazas: En esta etapa se debe realizar el análisis de las amenazas para 
poder comprender que hace la aplicación y que tipo de amenazas afectan a la superficie de 
ataque definida, es importante realizar la respectiva categorización y priorización de las 
amenazas expuestas, ya que esto permitirá ejecutar mejor la ruta de trabajo [9]. 
5. Analizar las vulnerabilidades y debilidades: En esta etapa se correlacionan las 
vulnerabilidades con los componentes implementados en la aplicación, para poder 
23 
 
determinar que buenas prácticas de seguridad se van a ejecutar, en donde entran escaneos 
de vulnerabilidades hasta implementación de controles de seguridad, todo esto priorizando 
la estabilidad de las operaciones del negocio [9]. 
6. Modelado de ataque: En esta etapa se busca demostrar que las vulnerabilidades y 
amenazas son relevantes, para poder así utilizar un árbol de ataques el cual permitirá 
establecer un buen modelo de mitigación de vulnerabilidades [9]. 
7. Análisis de riesgo e impacto: En el paso final se buscan crear medidas de mitigación que 
den solución a las amenazas resultantes de todo el proceso, teniendo en cuenta toda la 
información que fue recolectada en los anteriores pasos de la metodología [9]. 
2.1.3 OCTAVE: La metodología OCTAVE (Operational Critical, Threat, Asset and Vulnerability 
Evaluation) tiene como objetivo analizar y gestionar riesgos, priorizando el correcto 
funcionamiento de los sistemas informáticos existentes. Para la implementación de esta 
metodología se deben considerar tres fases, las cuales contienen diferentes procesos para el 
cumplimiento de esta, las cuales son [11]: 
 La primera fase busca identificar todas las amenazas, activos y vulnerabilidades existentes, 
también las normas y políticas de seguridad establecidas en la organización, esta fase se 
compone de cuatro procesos, el primer proceso tiene como finalidad recopilar toda la 
información de seguridad y activos que se tengan desde las altas directivas, el segundo 
proceso consiste en recopilar toda la información corporativa para entender los procesos 
que se ejecuten en la organización, el tercer proceso tiene como propósito identificar la 
estrategia y plan que se tiene para el cumplimiento de requerimientos de seguridad y por 
último se debe hacer la creación de indicadores de riesgo, a través de la creación de perfiles 
de amenazas los cuales permitirán una visión clara de la priorización y categorización de 
las vulnerabilidades [10]. 
 La segunda fase involucra todas las vulnerabilidades técnicas y componentes claves de la 
organización, dando continuación a los procesos realizados anteriormente y permitiendo un 
desarrollo eficaz del análisis y gestión de riesgos implementados, en esta fase se contemplan 
dos procesos: el primero de ellos se deben identificar los componentes y activos que sean 
importantes para el sostenimiento del sistema, y el segundo proceso se encargara de evaluar 
cada componente del anterior paso, para poder identificar las vulnerabilidades que estén 
presentes dentro de estas [10]. 
 La tercera fase busca desarrollar un plan y estrategia de seguridad, se deberá evaluar los 
riesgos en base a la priorización establecida anteriormente, esta fase contempla dos 
24 
 
procesos, el primero de ellos se encargará de evaluar cada riesgo identificado y en el 
segundo proceso se construirán las estrategias de aseguramiento, las cuales contemplarán 
las acciones y planes que se deban ejecutar [10]. 
2.1.4 TRIKE: TRIKE es un modelo conceptual unificado para el concepto de auditoria de 
seguridad desde la perspectiva de riesgos mediante la generación de modelados de amenazas, 
dando cumplimiento a necesidades de seguridad presentadas de la organización, para esta 
metodología se contempla la ejecución de cuatro pasos los cuales son [13]: 
1. Comunicar acciones ejecutadas y efectos de las mismas a áreas involucradas en el 
desarrollo del proyecto 
2. Ser capaz de verificar si las acciones ejecutadas se han realizado correctamente 
3. Involucrar a todas las áreas interesadas en el desarrollo del proyecto, para llegar a consensos 
grupales que permitan optimizar la toma de decisiones y aceptación de riesgos. 
4. Capacitar a todas las áreas involucradas para que comprendan el funcionamiento del 
sistema y puedan aportar a la reducción de riesgos del proyecto, 
2.1.5 NIST: El modelado de amenazas propuesto por una de las entidades pioneras en marcos de 
seguridad tiene como objetivo enfocarse en los sistemas de centrado de datos, recopilando 
información desde la perspectiva de ataque como de defensa para poder establecer un modelo 
estandarizado, que tiene ventajas para la toma de decisiones, gestión del cambio y análisis de 
requerimientos de seguridad. Para esta metodología se implementan cuatro pasos: 
I. El primer paso es identificar y caracterizar el sistema y los datos sensibles, estos deben ser 
definidos estrictamente, una vez realizado esto se debe reconocer el funcionamiento del 
sistema y el impacto operacional que tiene el uso de este, para dar un enfoque exacto al 
modelado de amenazas, como mínimo la caracterización debe contemplar lo siguiente: las 
personas y procesos que están autorizadas para acceder a los datos, los objetivos de 
seguridad de los datos, flujo de información sobre el sistema y las ubicaciones de los datos 
[12]. 
II. El segundo paso es identificar y seleccionar los vectores de ataque de deben ser incluidos 
en el modelo, el criterio de selección se basará en el impacto negativo que tenga sobre los 
objetivos de seguridad planteados, una vez identificados los vectores se deben seleccionar 
subconjuntos ya que uno entero desviaría el enfoque del modelo [12]. 
25 
 
III. El tercer paso será la caracterización de controles de seguridad para mitigar los vectores 
de ataques seleccionados en el anterior paso, una vez identificados los controles que 
pueden reducir el impacto de los vectores de ataque, se debe hacer la documentación del 
por qué se selecciona el control, con el propósito de optimizar la toma de decisiones [12]. 
IV. El cuarto y último paso de la metodología consiste en realizar un análisis de toda la 
información que se logró recopilar de los anteriores pasos, debido a que se deben establecer 
decisiones que sean optimas de implementar, ya que un control puede garantizar elcumplimiento de mitigación de una amenaza, pero puede provocar que se eleven los costos 
de la empresa, y que pueda afectar los procesos internos de la empresa [12]. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
26 
 
2.2 CASOS DE IMPLEMENTACION DEL MODELADO DE AMENAZAS 
 
El primer acaso de implementación del modelado de amenazas fue en una empresa conocida de 
tecnología financiera, la cual migro de manejar sus datos onpremise a manejarlos en los datacenters 
de AWS, en un inicio implementaron métodos manuales del modelado de amenazas teniendo en 
cuenta el modelo de responsabilidad compartida con AWS, utilizaban tablas para documentar e 
identificar las posibles vulnerabilidades que se puedan presentar y luego de esto asociaban en un 
ticket, el método de mitigación de la vulnerabilidad. Sin embargo, empezaron a darse cuenta que 
las diferentes áreas de la organización presentaban distintas necesidades y la metodología aplicada 
no permitirá involucrar las áreas de interés. 
Es ahí cuando empiezan a utilizar una herramienta de apoyo la cual era Microsoft Threat Modeling 
Tool, esta herramienta permitió optimizar un poco los procesos del modelado de amenazas ya que 
permitiría estructurar mejor el modelado y permitía involucrar a las áreas de interés, sin embargo 
al ser una sola persona manejando esta herramienta existían problemas de comunicación, lo cual 
los llevo nuevamente a trasladarse a otra herramienta la cual era Threat Modeler, a diferencia de la 
herramienta de Microsoft, esta permitía la interacción de múltiples usuarios en un solo modelado, 
lo que trajo como resultado producir más de 1000 modelados de amenazas al año cuando 
anteriormente solamente se producían en promedio 150, además de esto se logró involucrar el 
proceso en el ciclo de desarrollo de aplicaciones, lo que conllevo a la reducción de esfuerzos de los 
profesionales, la reducción de costos, precisión del modelado y simplifico la toma de decisiones de 
seguridad [3]. 
El segundo caso se identificó en una de las instituciones financieras pertenecientes a Fortune 500, 
las entidades financieras están constantemente bajo ataques, y los atacantes día a día exploran 
nuevos caminos para poder infiltrarse. La institución tomo la decisión de empezar a anticiparse de 
los posibles ataques para ello empezaron a realizar evaluaciones mensuales de prácticas de 
seguridad implementadas en ese tiempo, en donde incluyeron el modelado de amenazas, el 
problema que presentaban era que no podían manejar de forma paralela la ejecución de procesos y 
desarrollo de aplicaciones con temas de aseguramiento, por falta de conocimiento y metodología 
que les permitiera esto. 
Para solucionar el problema empezaron una etapa de transición de procesos manuales a 
automatización del modelado de amenazas, emplearon la metodología PASTA ya que necesitaban 
garantizar el correcto funcionamiento de sus servicios financieros para evitar problemas con los 
clientes y luego de esto implementaron la herramienta de Threat Modeler en apoyo a la migración 
a la nube de AWS en la cual se encontraban trabajando, lo cual trajo como resultados la reducción 
27 
 
de costos, tiempos de ejecución de prácticas de aseguramiento y aumento en el porcentaje de 
velocidad de funcionamiento de los servicios [3]. 
El tercer caso de implementación del modelado de amenazas se desarolla en un entorno diferente 
a los que se mencionaron anteriormente, se trata de una industria de sistemas de control industrial, 
este tipo de industrias son una parte importante de muchas organizaciones ya que representan un 
grado de criticidad muy alto, y con el transcurso del tiempo han tomado tan alta relevancia que ya 
son víctimas de constantes ciberataques, es por esto que la compañía presenta la necesidad de 
ejecutar un sistema de seguridad para la protección de sus servicios, en el desarrollo de la propuesta 
encuentran que la mayoria de modelados de amenazas no tienen un enfoque adecuado para las 
funciones de sus sistemas, por lo tanto deben tomarse primeramente en la tarea de determinar cual 
es la metodologia que mejor se acopla a las necesidades de la compañía y luego de esto acoplar la 
metodologia de tal forma que les permita garantizar el concepto de seguridad ante el gran volumen 
de ciberataques. 
La metodologia seleccionada por parte de la compañía fue STRIDE, en un primer concepto 
eligieron esta por que deseaban implementar una metodologia agil y que no tuviera una alta 
complejidad debido a que nunca habian tratado con temas de cibersegridad, el primer paso 
realizado fue con ayuda de la herramienta Microsoft Threat Modeling crear el diseño de los 
sistemas de la manera mas eficaz posible, ya que a pesar de que la herramienta no tenia mucha 
compatibilidad con sistemas de control industrial, lograron resultados eficazes, esto les permitio 
establecer un proceso de priorizacion y categorizacion de amenazas optimo 
 
 
 
 
 
 
 
 
 
28 
 
3. CICLO DE VIDA DE DESARROLLO DE SOFTWARE 
 
En este capítulo del documento se entrará a profundizar cuales son las fases sobre las cuales se 
desarrolla una aplicación, y paralelamente se identificará algún modelo del ciclo de vida de 
desarrollo de software existente en la organización. 
El ciclo de vida de desarrollo de software (SDLC) es un proceso utilizado por las organizaciones 
con el propósito de desarrollar, diseñar y testear aplicaciones de alta calidad. Este proceso tiene 
como propósito garantizar el desarrollo de software de alta calidad, el cual supere con eficiencia 
los objetivos planteados por el cliente y así mismo se complete dentro de los plazos y 
requerimientos a nivel operativo y financiero establecidos, para este proceso se debe considerar 
[14]: 
 Es considerado también como el proceso de desarrollo de software 
 El SDLC es un marco que proporciona las tareas que se deben realizar en cada paso del 
proceso de desarrollo de software en las organizaciones 
 El marco esta regido bajo las normas ISO/IEC 12207 las cuales son normas internacionales 
que definen las tareas de desarrollo y sostenimiento de las aplicaciones en el ciclo de vida 
de desarrollo de software 
El SDLC es un proceso sumamente popular ya que se encuentra implementado en todo tipo de 
organización que desarrollé aplicaciones, el proceso consiste en la construcción de un plan 
detallado que describe como desarrollar, modificar, sustituir y mantener las aplicaciones lanzadas 
a producción, todo esto se garantiza gracias a que el SDLC tiene una metodología establecida que 
busca optimizar los procesos de desarrollo y mejorar continuamente la calidad del software. El 
ciclo de vida de desarrollo de software se compone de seis fases las cuales son: 
29 
 
 
Figura 3. Ciclo de vida del desarrollo de software [14]. 
FASE 1: Planeación y análisis de requerimientos 
La fase de planeación y análisis de requerimientos es la etapa más importante del ciclo de vida de 
desarrollo de software, debe ser realizada por el personal con mas experiencia del equipo ya que 
se encargarán de planificar la ruta de trabajo del proyecto, en la cual deberán definir los enfoques 
de la aplicación y determinar la viabilidad de este a nivel económico, operativo y técnico. Se debe 
tener en cuenta los requerimientos establecidos desde el cliente, área financiera de la organización 
y expertos de las áreas de interés del proyecto. 
Como resultado de los estudios de viabilidad se iniciarán los procesos de planificación del 
cumplimiento de calidad de los requisitos e identificación de los riesgos asociados al proyecto, 
todo esto para que pueda ser ejecutado con precisión y un mínimo de riesgos [14]. 
FASE 2: Definición de requerimientos 
Después de culminar el anterior paso, se debe definir y documentar minuciosamente los resultados 
del paso anterior y los requisitos del proyecto, para poder realizar una presentación al cliente y 
poder obtener su aprobación,también es importante añadir que este paso se realiza también 
internamente, ya que algunas veces se realizan aplicaciones para uso interno y se debe obtener un 
aval de las altas directivas. Esta fase se realiza a través de un SRS (Software requirement 
specification) el cual contiene todos los requisitos establecidos del proyecto para que sean 
diseñados y desarrollados por el equipo de profesionales [14]. 
FASE 3: Diseño de la arquitectura del proyecto 
30 
 
El SRS es la referencia para que los desarrolladores planteen la mejor arquitectura para que el 
proyecto que se va a desarrollar, ya que, a partir de los requisitos especificados en este, se pueden 
plantear varios enfoques de diseño para la arquitectura del proyecto, todo esto debe ser 
documentado en un nuevo artefacto llamado DDS (Design Document Specification). Un enfoque 
de diseño tiene como objetivo definir todos los módulos a nivel de arquitectura junto con la 
representación de comunicación y flujo de datos entre los componentes internos, externos y 
tercerizados (en caso de haberlos), toda esta información debe ir documentada en el DDS con la 
mayor profundidad posible. 
Este nuevo artefacto debe ser evaluado por todas las áreas de interés del proyecto bajo diversos 
parámetros como la solidez del producto, evaluación de riesgos, modularidad del diseño, 
presupuesto y limitaciones de tiempo, todo esto para que se pueda seleccionar el mejor enfoque de 
diseño para el proyecto [14]. 
FASE 4: Desarrollo del proyecto 
En esta etapa se da inicio al desarrollo del proyecto para poder dejarlo construido, el DDS 
proporcionara una ruta sobre el código que se va a programar en función de los requerimientos, si 
el diseño del anterior paso se realizó de forma detallada y organizada, la construcción del código 
puede llevarse a cabo sin ningún tipo de limitación. 
Los desarrolladores deben seguir las políticas de desarrollo establecidas en la organización y 
también herramientas de programación como lo son compiladores, depuradores, interpretadores, 
entre otros. Lenguajes de programación de alto nivel como C, C++, Python, PHP, Java, entre 
muchos más, son usados para el desarrollo de aplicaciones, el criterio de selección de un lenguaje 
es basado en el tipo de funciones que va a desempeñar el software [14]. 
 
FASE 5: Testeo del proyecto 
Esta etapa es considerada como un subproceso de todas las etapas mencionadas anteriormente ya 
que, en los modelos modernos del ciclo de desarrollo de software, las actividades de prueba suelen 
ser realizadas en todas las etapas del SDLC. Sin embargo, esta fase consiste a realizar pruebas del 
proyecto, en la que se buscan identificar las fallas, rastrearlas, corregirlas y volver a realizar 
pruebas, hasta que el proyecto alcance los estándares de calidad definidos en el SRS [14]. 
FASE 6: Despliegue y sostenimiento del proyecto 
31 
 
Una vez que el anterior paso es culminado con éxito, se debe determinar si el proyecto esta listo 
para su despliegue, una vez determinado esto se lanza formalmente al mercado correspondiente. 
Algunas veces, la estrategia de lanzamiento suele realizarse por etapas, todo esto depende de la 
estrategia empresarial de la organización, el producto puede lanzarse primero con un segmento de 
funciones especificas y someterse a un entorno de pruebas real (mejor denominado pruebas de 
aceptación UAT). Dependiendo de los feedback del cliente se van incorporando las nuevas 
funciones, o mejoras de los defectos que se puedan presentar, es importante tener siempre presente 
el mantenimiento de la aplicación desde que es lanzada a producción [14]. 
Existen diversos modelos definidos del ciclo de vida de desarrollo de software los cuales han sido 
diseñados en función de los procesos de desarrollo de software, cada modelo sigue una serie de 
pasos exclusivos con el propósito de garantizar el éxito del proceso de desarrollo de software, los 
modelos más relevantes que se pueden encontrar son [15]: 
- Agile 
- Lean 
- Waterfall 
- Iterative 
- Spiral 
- DevOps 
Solamente se profundizará el modelo DevOps ya que, de los modelos mencionados, es el único 
que se encuentra implementado dentro de la empresa Banco Popular, es fundamental conocer este 
modelo ya que permitirá identificar una integración de este con el modelado de amenazas. 
3.1 DevOps 
 
El modelo DevOps es un marco de trabajo enfocado al desarrollo de software en las 
organizaciones, además de esto tiene el objetivo de promover una cultura ágil de entrega y rápida 
implementación de actualizaciones sobre los productos que se desarrollen. Es una metodología 
moderna que surgió gracias a modelos como Agile y Lean, y a raíz de la necesidad de 
colaboración entre equipos de desarrollo y equipos de operaciones de TI en el desarrollo de 
software [16]. 
32 
 
 
Figura 4. Ciclo de vida DevOps 
En un modelo DevOps la comunicación entre equipos de desarrollo y operaciones es fundamental, 
ya que deben ayudarse mutuamente, y algunas veces trabajar como un solo equipo para poder 
garantizar el cumplimiento de entrega rápida de aplicaciones, despliegue de actualizaciones y 
acelerar el proceso de innovación de estas, es importante fomentar en el equipo de trabajo la cultura 
de la disciplina, retroalimentación continua, mejora y automatización de procesos de desarrollo 
[16]. 
Como se puede observar en la anterior ilustración la metodología DevOps contempla un ciclo de 
vida segmentado en ocho etapas las cuales son: 
1. Planificación: En la primera etapa del ciclo de vida se deben definir los requerimientos 
del proyecto, para poder establecer una ruta de trabajo, es necesario realizar seguimiento 
a este plan y llevar a cabo la gestión del proyecto [17]. 
2. Codificación: En esta fase el equipo de desarrollo se encargará de iniciar el desarrollo 
del software, teniendo en cuenta las tecnologías de Frontend, Backend establecidas en la 
fase de planificación, es importante el uso de un repositorio para optimizar el trabajo en 
equipo y seguimiento del proyecto [17]. 
3. Construcción: En esta fase se gestionan las actualizaciones y compilaciones de los 
sistemas, es necesario la implementación de herramientas que permitan optimizar estas 
tareas [17]. 
33 
 
4. Testeo: En esta fase se buscan realizar pruebas continuas sobre el software, ya sea de 
forma manual o de forma automatizada, es importante cumplir esta etapa para garantizar 
la calidad del funcionamiento del proyecto [18]. 
5. Lanzamiento: En esta fase se debe realizar un análisis e implementación sobre que 
herramientas permitirán coordinar, programar y automatizar el funcionamiento del 
proyecto [18]. 
6. Despliegue y mantenimiento: En esta fase el equipo de desarrollo debe gestionar el 
funcionamiento de la aplicación en su etapa de producción, paralelamente debe 
garantizar el servicio de mantenimiento para que se sostenga el proyecto [18]. 
7. Operate: En esta fase el equipo de desarrollo y operaciones administran las plataformas 
e infraestructura asociadas al proyecto [17]. 
8. Monitoreo: En esta fase se debe identificar las incidencias que se presenten en el 
proyecto, es indispensable notificar de manera inmediata y establecer una metodología de 
mitigación inmediata al incidente expuesto [17]. 
Dentro de la metodología DevOps también se puede encontrar un catálogo de buenas prácticas 
que son indispensables en la implementación de esta, las cuales son: 
Practica DevOps Descripción Beneficios 
Automatización 
de procesos 
Implementación de una herramienta 
compatible con el lenguaje de 
programación, para el correcto 
despliegue de código automatizado en 
entornos reales 
 Rápido, consistente y 
repetitivo 
 Fácil de adaptar 
 Mas confiable que la 
creación de un manual 
Integración 
continua (CI) 
Establecer un proceso que permita una 
frecuente transición de código y 
unidades de pruebas, 
 Detección temprana de 
errores 
 Mantieneel código en un 
estado en el cual puede 
ser lanzado a producción 
con el mínimo esfuerzo 
34 
 
 Fomenta el uso de un 
código modular 
Despliegue 
continuo 
Establecer un proceso frecuente para el 
despliegue de pequeños cambios en el 
código 
 Optimización de tiempos 
de comercialización 
 Dependiente de los 
procesos de despliegue 
 Retrocesos Fiables 
Infraestructura 
como código 
Administra y provisiona servicios de la 
infraestructura de IT a través de código 
y automatización 
 Consistente creación y 
administración de 
recursos 
 Reusable 
 Documentación 
automatizada de la 
infraestructura 
 Simplifica la complejidad 
de la infraestructura (DB, 
métodos de autenticación, 
servidores de 
aplicaciones) 
Gestión de 
configuración 
Administra y cambia los estados de la 
infraestructura en constantes caminos de 
sostenimiento 
 Optimización de tiempo 
 Provisiona documentación 
detallada de la 
infraestructura 
 Sostenibilidad ante los 
cambios del sistema 
 Minimiza los procesos de 
configuración 
35 
 
Orquestación Automatizar los procesos de soporte y 
flujo de trabajo 
 Escalabilidad 
 Optimización de tiempo 
 Estabilidad, la cual 
incrementa con un 
correcto sistema de 
respuesta a incidentes 
Monitoreo Recopila y presenta información del 
desempeño y estabilidad de los servicios 
e infraestructura asociados al proyecto, 
también detecta incidentes. 
 Rápida recuperación 
 Mayor volumen de 
información a analizar 
para identificar y analizar 
la raíz de los incidentes 
 Respuesta automatizada 
 Visibilidad entre las áreas 
de interés 
Microservicios Arquitectura de servicios que 
descompone una aplicación en pequeños 
segmentos. 
 La modularidad reduce la 
complejidad 
 Flexibilidad de la 
tecnología escogida para 
cada servicio 
 Es altamente eficiente en 
costos-producción cuando 
se usan contenedores 
 
Tabla 2. Buenas prácticas de DevOps [16]. 
 
 
 
36 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
37 
 
4. PROPUESTA DE IMPLEMENTACIÓN DE UNA METODOLOGÍA DEL 
MODELADO DE AMENAZAS. 
 
En este capítulo se seleccionará una de las metodologías de amenazas analizadas en anteriores 
pasos, el criterio de selección de la metodología de esta dependerá de los siguientes factores: 
Enfoque y ejecución de la metodología, compatibilidad de integración con otros modelados y 
frameworks existentes en el ciberespacio y la flexibilidad de aplicación de la metodología en 
múltiples campos organizacionales. Paralelamente se iniciará el desarrollo de la propuesta de 
implementación, haciendo uso de distintos frameworks que pueden complementar la eficacia de la 
técnica. 
Una vez definidas las distintas metodologías existentes del modelado de amenazas, es hora de 
entrar a detallar cual es la que mejor se ajusta a las necesidades de la organización. Banco Popular 
es una entidad financiera que maneja un gran volumen de clientes, por lo tanto, es indispensable 
velar por la protección de los datos de cada uno de ellos y así mismo garantizar que tengan una 
cálida experiencia en el uso de sus servicios, esto conlleva a que la organización aparte de 
implementar mecanismos, procesos, estrategias y controles de seguridad, deban cumplir ciertas 
normativas pautadas a nivel nacional como lo es la norma PCI DSS así como normas 
organizacionales que busquen preservar la seguridad de la información de la organización y de los 
clientes. Es importante considerar también la actual situación que se presenta en el mundo, la 
pandemia del Covid-19 ha provocado que la mayoría de organizaciones atraviesen por un proceso 
de transformación digital y paralelamente ha desatado el incremento de ciberataques, 
especialmente en entidades financieras, ya que existen múltiples formas de extraer información 
interna o externamente de una entidad que maneja un alto volumen de información sensible. 
 
 STRIDE PASTA OCTAVE TRIKE NIST 
Ámbito de 
aplicación 
Clasificació
n de 
amenazas 
en 
pequeñas, 
medianas o 
grandes 
empresas 
Análisis y 
gestión de 
riesgos, activos 
y tecnologías 
en todo tipo de 
empresa 
Análisis y 
gestión de 
riesgos en 
PYMES 
Procesos de 
auditoria en 
PYMES 
No contempla 
un enfoque de 
aplicación 
especifico 
38 
 
Característica
s 
Clasifica las 
amenazas 
en seis 
categorías 
(Spoofing, 
Tampering, 
Repudiation
, Denial of 
service, 
Elevation of 
Privileges.) 
Metodología 
altamente 
robusta que 
busca realizar 
análisis 
profundos de 
amenazas 
sobre la 
construcción 
de 
aplicaciones, se 
contempla la 
gestión de 
riesgos y 
activos, para la 
correcta 
caracterización 
de controles de 
seguridad, 
buenas 
prácticas y 
simulaciones 
de ataques. 
Busca 
concientizar a 
la 
organización 
respecto a 
temas de 
aseguramiento
, involucrar a 
toda la 
organización 
para temas de 
aseguramiento
, priorización 
segmentada en 
dos 
componentes, 
sistemas y 
personas 
Integración 
con normas 
de auditoria 
como lo es la 
ISO 27001, 
se 
caracteriza 
además por 
el amplio 
monitoreo a 
la ejecución 
de sus 
procesos 
para 
garantizar el 
correcto 
cumplimient
o del 
concepto de 
seguridad 
Esta 
metodología 
se caracteriza 
principalment
e ya que fue el 
primer 
modelado de 
amenazas 
planteado en 
el 
ciberespacio, 
por lo tanto 
todas las 
metodologías 
existentes 
tomaron como 
punto de 
partida esta 
metodología. 
Desventajas Metodologí
a altamente 
básica. 
Difícil de 
adaptar a corto 
plazo, carencia 
de 
documentación 
en la ejecución 
de los 
procesos. 
Documentació
n excesiva, 
personal 
altamente 
capacitado, 
excluye 
amenazas de 
repudiación de 
sus objetivos. 
Campo de 
aplicación 
altamente 
limitado. 
No tiene un 
enfoque de 
aplicación 
definido. 
Ventajas Fácil de 
implementa
r, 
proporciona 
Procesos 
adaptables a 
cualquier tipo 
de empresa, 
Integración de 
la gestión de 
procesos, 
recursos, 
Evita la 
tercerización 
de servicios 
de auditoría, 
Plantea una 
estrategia 
estándar, lo 
que permite la 
39 
 
una 
articulación 
clara de los 
detalles de 
cada 
amenaza. 
procesos 
altamente 
estructurados y 
enfocados a las 
nuevas 
tendencias de 
los ataques en 
el ciberespacio. 
activos, datos, 
entre otros. 
Busca mejoras 
las 
comunicacione
s internas. 
se puede 
establecer 
una ruta de 
trabajo 
interna en 
caso de 
fallas en la 
auditoria. 
adaptación a 
cualquier 
entorno de 
trabajo 
Fases Solo 
contempla 
una fase 
para su 
ejecución 
Contempla 
siete pasos para 
ejecución 
involucrando 
tareas 
relevantes 
como 
simulación de 
ataques, 
análisis de 
amenazas, 
componentes y 
vulnerabilidad
es 
Contempla tres 
pasos para su 
ejecución, 
destacando la 
importancia 
que le brinda la 
metodología a 
las políticas de 
la compañía. 
Contempla 
cuatro pasos 
para la 
ejecución de 
la 
metodología
, destacando 
el constante 
monitoreo 
en el 
despliegue 
de cada 
paso. 
Contempla 
cuatro pasos 
para la 
ejecución de 
la 
metodología, 
se destaca la 
importancia 
que le dan a la 
documentació
n de cada paso 
y la creación 
de vectores de 
ataques. 
Gestión de 
riesgos 
No aplica Aplica Aplica Aplica Aplica 
Gestión de 
activos 
No aplica Aplica Aplica Aplica No aplica 
Integración 
con 
frameworks 
No aplica Aplica Aplica No aplica No Aplica 
Integración 
con otros 
modelados de 
amenazas 
No aplica Aplica No aplica No aplica No aplica 
40 
 
Integración 
de las 
unidades de 
interés para el 
desarrollo del 
proyecto 
Aplica Aplica Aplica Aplica Aplica 
 
Dicho esto, es necesario implementar una metodología centrada en la gestión de riesgos que tenga 
múltiples campos de aplicación (Auditorias, Categorización de amenazas, Simulaciónde ataques, 
entre otros), se puede identificar que la mayoría de metodologías del modelado de amenazas velan 
por el cumplimiento de un solo objetivo, es por este motivo que se seleccionara la metodología 
PASTA ya que aparte de velar por el cumplimiento de múltiples procesos de aseguramiento, es una 
metodología bastante completa que permite la integración de todas las áreas de interés involucradas 
en el desarrollo de aplicaciones y así mismo permite la interacción entre metodologías y marcos de 
seguridad como lo es STRIDE, DREAD, el framework de MITRE ATT&CK o la CVE [19]. 
Para el inicio del desarrollo de esta propuesta de implementación se deben aclarar algunos puntos, 
el primero de ellos es que en cada paso de la metodología se debe realizar un proceso de 
documentación detallado para simplificar la complejidad de los procesos, y el otro punto es que los 
modelados de amenazas existentes son metodologías estándar, que quiere decir esto que ningún 
método especifico se va a acoplar directamente con los procesos de la organización, se debe buscar 
la forma de adaptarlo para poder solucionar las necesidades que se presenten. 
En la siguiente ilustración se recordarán los anteriores pasos definidos de la metodología PASTA, 
para poder así empezar a profundizar de qué forma se va a empezar a aplicar cada paso dentro de 
la organización. 
41 
 
 
Figura 5. Etapas de la metodología PASTA [9]. 
4.1 Definir objetivos: Lo primero que se debe tener en cuenta para la aplicación del primer paso 
es el principio de DevOps el cual es la integración del equipo de desarrollo con el de operaciones 
de TI, que, para nuestro caso, más específicamente seria el equipo de ciberseguridad y seguridad 
de la información, para poder establecer un espacio en el cual puedan definir en conjunto con las 
áreas de interés (Por ejemplo, Auditoria, Contraloría, ADL, Arquitectura, entre otros) los 
requerimientos del proyecto, es decir que funciones debe de tener el software solicitado, este primer 
espacio debe ser liderado por la área que solicite el desarrollo de la aplicación.. 
Paralelamente se debe definir qué tipo de información va a procesar la aplicación para que se 
puedan empezar procesos de aseguramiento ya que dependiendo de qué tipo de información se va 
a manejar, sobre qué servicios se va a exponer esta información y como va a ser el flujo de datos 
del proyecto, pueden aparecer políticas organizacionales que deben ser cumplidas y así mismo se 
podrá realizar un análisis de que controles de seguridad existentes en la organización pueden ayudar 
a proteger la información que se va a exponer. Todo esto debe ser documentado detalladamente, 
desde la lista de funciones que van a describir la aplicación, hasta que políticas y controles se deben 
aplicar para el cumplimiento de seguridad de la organización, siempre involucrando y manteniendo 
informado a todas áreas involucradas en el desarrollo del proyecto [9]. 
4.2 Definir el alcance técnico: En esta etapa de la metodología PASTA se deben definir los 
componentes tecnológicos y tipos de tecnologías que se van a implementar para garantizar el 
cumplimiento de los requerimientos establecidos en el anterior paso, como resultado se obtendrá 
42 
 
la documentación de la arquitectura de la aplicación. Este proceso debe ser liderado por el área de 
arquitectura digital de la organización y aunque no sea un proceso del área de desarrollo o 
ciberseguridad, deben involucrarse en la definición de este alcance, para dar cumplimiento al 
principio de comunicación de la metodología y también se puedan llegar a consensos grupales [9]. 
4.3 Descomposición de la aplicación: La arquitectura resultante del anterior paso será la ruta de 
trabajo de esta etapa del modelado de amenazas, ya que con la información de este artefacto se 
dará inicio a la construcción de un diagrama de flujo de datos, un DFD también se representa en 
una arquitectura, pero la diferencia es que se busca detallar a profundidad cosas como que 
protocolos se van a usar para el funcionamiento de la aplicación, cuales son los agentes y flujos de 
comunicación de los datos en la aplicación, que límites de confianza existen, que tecnologías 
adicionales se pueden contemplar dentro de la aplicación [9]. 
 
Figura 6. Ejemplo de un diagrama de flujo de datos [7]. 
Para la construcción de este diagrama es esencial representar a profundidad los detalles que se 
mencionaron anteriormente, ya que un buen diagrama de flujo de datos permitirá identificar los 
activos que se van a manejar, los tipos de usuarios que van a interactuar con la aplicación, servicios, 
tareas y fuentes de datos que van a estar presentes, toda esta información será de suma importancia 
para el análisis de amenazas que será liderado por parte del equipo de ciberseguridad y seguridad 
de la información de la organización. 
4.4 Análisis de amenazas: Se da inicio a una de las fases más importantes del modelado de 
amenazas ya que en esta etapa se busca empezar un proceso de análisis de las amenazas que se 
pueden presentar en la aplicación, es importante dentro de este proceso categorizar y priorizar las 
amenazas para establecer un proceso de threat intelligence altamente eficaz. Existen frameworks 
altamente robustos, es por esto que es importante resaltar que se desea que la metodología sea ágil 
y no sea un proceso altamente complejo, por esta razón para la parte de categorización de amenazas 
se empleara STRIDE, uno de los frameworks del modelado de amenazas que se identificó 
43 
 
anteriormente, el cual tiene el objetivo de proporcionar una categorización de las amenazas 
resultantes del análisis que se realizó en cada componente del diagrama del flujo de datos por parte 
del equipo de seguridad de la organización [8]. 
Amenaza Dominio de Seguridad 
Spoofing Autenticidad 
Tampering Integridad 
Repudiation No repudio 
Information Disclosure Confidencialidad 
Denial of Service Disponibilidad 
Elevation of Privilege Autorización 
 
Tabla 3. Resumen de categorización de amenazas del framework STRIDE [8]. 
Una vez categorizadas las amenazas se debe iniciar el proceso de evaluación y priorización de 
riesgos, para esto se hará uso del modelo DREAD en el cual se podrá identificar los impactos de 
riesgo de las amenazas según los criterios de evaluación del modelo y así mismo se podrá 
identificar con que probabilidad se puede producir la amenaza que se identificó, a continuación, se 
lograra ver un ejemplo de aplicación de este modelo. 
44 
 
 
Figura 7. Ejemplo de aplicación del modelo DREAD [8]. 
La construcción de toda esta información le permitirá al equipo de seguridad de la organización 
empezar diseñar un proceso de threat intelligence, en el cual se puedan recrear escenarios de 
amenazas para poder establecer estrategias de mitigación acorde a los resultados de este 
proceso. Una herramienta altamente eficaz y que muchas veces es usada en una metodología 
del modelado de amenazas son los arboles de ataque, este artefacto tiene el propósito de 
representar a través de un diagrama los posibles escenarios que pueden provocar la explotación 
de una vulnerabilidad en un entorno especifico, se debe tener en cuenta también el criterio de 
complejidad de la construcción del diagrama, ya que se debe construir un diagrama por cada 
componente que presente una amenaza. El objetivo de esta herramienta es poder identificar 
bajo que eventos se puede explotar una amenaza, para que el equipo de ciberseguridad pueda 
construir un plan estratégico de mitigación que permita solucionar la exposición de las 
amenazas. 
Attack DREAD risk
Damage Potential Reproducibility Exploitability Affected users Discoverability Risk (Max =3)
Real attack
3 3 2 2 3 2.6
2 2 2 1 2 1.8
1 2 2 1 2 1.6
1 2 2 1 1 1.4
2 2 1 1 1 1.4
3 2 2 2 2 2.2
3 2 2 1 2 2
1 2 1 1 3 1.6
1 2 1 1 1 1.2
3 2 1 2 1 1.8
2 3 3 3 2 2.6
2 3 2 2 2 2.2
2 2 2 3 2 2.2
2 2 2 2 2 2
13 2 1 2 1.8
3 3 2 2 2 2.4
2 3 3 3 3 2.8
Fake services
Reputation attack
3.High risk, 2. medium risk, 1. low risk
Agent flooding
DoS
Logical DoS
Repudiation
Deception
Fake agents
Agent log modification
Injection
Message injection
Knowledge injection
Flooding
Link flooding
Interception
Access to agents
Provenance
Probing
Ontology Attack
Active probing
Altering
Interaction modification
Agent code modification
45 
 
 
Figura 8. Ejemplo de un árbol de ataques básico [8]. 
4.5 Análisis de vulnerabilidades y debilidades: En esta etapa de la metodología PASTA, se 
deberá presentar los resultados de los dos anteriores pasos, ya que estos fueron realizados por 
parte de los profesionales de seguridad sin concepto alguno del área de desarrollo y las áreas 
de interés, es por esto que se debe concretar un espacio en el cual se preserve el principio de 
comunicación de la metodología y se expongan las amenazas resultantes del análisis, para que 
se puedan iniciar un nuevo proceso análisis, pero esta vez sobre el diseño realizado, ya que si 
existen defectos de comunicación entre componentes, implementación de protocolos erróneos 
sobre la arquitectura es necesario realizar el ajuste pertinente. 
Además de esto también se debe realizar un análisis de cada componente y tecnología usada en 
la arquitectura de la aplicación, para ello se hará uso de una base de datos altamente conocida 
llamada la CVE (Common Vulnerability and Exposures) que proporciona información 
detallada sobre las vulnerabilidades actuales de las tecnologías y componentes, describiendo 
en que consiste la vulnerabilidad y el impacto que tiene en caso de ser explotada la 
vulnerabilidad, este proceso se realiza con el propósito de iniciar la construcción de la ruta de 
trabajo de aseguramiento de la aplicación [9]. 
46 
 
 
Figura 9. Common Vulnerability and Exposures (CVE) [17] 
 
4.6 Modelado de ataque: En esta etapa se busca demostrar que las vulnerabilidades y 
amenazas son relevantes, este proceso se realizara a través de la búsqueda de ataques asociados 
a la categorización e identificación de amenazas resultante de los anteriores procesos, esta tarea 
puede aportar al descubrimiento de nuevas amenazas ya que al identificar nuevos métodos de 
ejecución de amenazas se pueden presentar nuevas vulnerabilidades. Para el desarrollo de esta 
etapa se usara como herramienta el framework MITRE ATT&CK, la cual es una de las bases 
de datos más grande del mundo que contiene información acerca de los distintos ataques que 
realizan los ciberdelincuentes, como se puede observar en la imagen la base de datos la 
categoriza en varias secciones, así mismo dentro de cada sección la base de datos, proporciona 
datos de alta relevancia como lo es la descripción del ataque, a qué tipo de organización está 
dirigido el ataque, nombres de grupos criminales que suelen realizar el ataque y métodos de 
mitigación y detección a implementar dentro del marco de trabajo. 
En las siguientes imágenes se podrá observar las categorías que componen la base de datos del 
MITRE ATT&CK, así mismo se puede identificar que cada técnica tiene sub técnicas para su 
ejecución. En la primera figura se podrá ver las secciones de ataques de reconocimiento que 
tienen como objetivo recopilar información confidencial de organizaciones y ataques de 
desarrollo de recursos que tienen como propósito infiltrarse en componentes de un sistema para 
usarlos en beneficio propio [19]. 
47 
 
 
Figura 10. Framework MITRE ATT&CK parte 1 [19]. 
Las siguientes secciones del framework de MITRE muestran ataques de acceso inicial que tienen 
como objetivo identificar puntos de entrada sobre diferentes sistemas y ataques de ejecución que 
básicamente son ataques de ejecución de código malicioso para controlar sistemas de una 
organización [19]. 
 
Figura 11. Framework MITRE ATT&CK parte 2 [19]. 
48 
 
Las siguientes secciones corresponden a ataques de persistencia que básicamente consisten en la 
ejecución de técnicas para mantener el acceso sobre un sistema que ya ha sido anteriormente 
atacado y ataques de escalación de privilegios que son ataques que tienen como propósito obtener 
privilegios de administrador para realizar cambios sobre el sistema [19]. 
 
 
Figura 12. Framework MITRE ATT&CK parte 3 [19]. 
Los ataques de ex filtración e impacto son las siguientes categorías de ataques que componen esta 
base de datos, los ataques de exfiltración tienen el objetivo de robar información de la red existente 
en la organización y los de impacto tienen el propósito de interrumpir, manipular o destruir la 
información y sistemas implementados [19]. 
49 
 
 
Figura 13. Framework MITRE ATT&CK parte 4 [19]. 
Los ataques de colección, comando y control, movimiento lateral y descubrimiento son también 
hacen parte de esta fuente de conocimiento, los ataques de colección son aquellos que buscan reunir 
información específica de interés de un sistema, los de comando y control buscan establecer 
comunicación con las aplicaciones para poder tomar el control de estas, los ataques de movimiento 
lateral son aquellos que buscan infiltrarse en el entorno organizacional para poder así identificar 
posibles puntos de entrada, y finalmente los ataques de descubrimiento son aquellos que buscan 
explotar los resultados de las vulnerabilidades que se encontraron en los ataques de movimiento 
lateral [19]. 
50 
 
 
Figura 14. Framework MITRE ATT&CK parte 5 [19]. 
El componente final de este framework de MITRE ATT&CK lo componen los ataques de evasión 
de defensas (esta categoría contiene la cantidad más grande de técnicas) y los ataques de 
credenciales de acceso, el primero tiene como objetivo evadir todos los controles de seguridad de 
una organización y el segundo tipo de ataque busca robar las cuentas empresariales con sus 
respectivas contraseñas [19]. 
51 
 
 
Figura 15. Framework MITRE ATT&CK parte final [17]. 
La tarea que se debe realizar para sacar el máximo provecho a esta base de datos, es poder 
identificar toda la base de datos y poder relacionar cuales son los ataques que más se ejecuten sobre 
la organización, que para nuestro caso sería identificar ciberataques a entidades financieras. Con la 
información recolectada del análisis es necesario establecer medidas de seguridad mínimas que 
permitan garantizar la protección de los ataques resultantes del proceso de análisis realizado 
anteriormente. 
52 
 
 
Figura 16. Ejemplo de categorización de amenazas con el framework de MITRE [19]. 
Suponiendo que la anterior ilustración es el resultado del análisis de los ataques más comunes a 
entidades financieras, el paso a seguir es empezar a relacionar cada uno de estos ataques con las 
vulnerabilidades y amenazas resultantes de los anteriores pasos de la metodología, para poder así 
empezar determinar la relevancia y descubrimiento de nuevas amenazas en caso de presentarse. 
4.7 Análisis de riesgos e impacto de amenazas: Para el desarrollo de la etapa final del modelado 
de amenazas, se concretará nuevamente un espacio con todas las áreas involucradas del proyecto 
para presentar los resultados finales que se obtuvieron de los anteriores pasos, para que 
paralelamente en conjunto se puedan realizar tareas como calcular el riesgo, pero esta vez a nivel 
económico y empresarial ya que a nivel técnico se pueden tomar los resultados del modelo 
DREAD, todo esto relacionando las amenazas resultantes. Además de esto el equipo de seguridad 
debe dar su concepto sobre los controles de seguridad que se deban implementar para que se cumpla 
el concepto de seguridad en el proyecto y en complemento presentar las buenas prácticas de 
aseguramiento de las tecnologías a implementar en el proyecto, en donde busquen implementar 
estrategias de colaboración mutua con los equipos que participen en el despliegue de la aplicación, 
y para finalizar se debe calcular los riesgos