INGENIERÍA EN DESARROLLO DE SOFTWARE

JHON FREDY VELEZ LONDOÑO

CÓDIGO:1911023172

HECTOR DANILO PRIETO ZORRO

CODIGO 100239497

MARIA ALEY LANDAZURI CAICEDO

CODIGO 1821021402

SEGURIDAD EN EL CICLO DEL DESARROLLO

ACTIVIDAD EN CONTEXTO SEMANA 2

DOCENTE
PENA DAZA ALEXANDRA

MAYO 2022
Contenido
INTRODUCCION............................................................................................................................... 4
OBJETIVO GENERAL......................................................................................................................... 5
OBJETIVO ESPECIFICO .................................................................................................................. 5
ANTECEDENTES ............................................................................................................................... 6
MODELOS EXISTENTES................................................................................................................. 8
OWASP ......................................................................................................................................... 8
Marco Teórico .......................................................................................................................... 8
Inyección SQL ........................................................................................................................... 8
Perdida de autenticacion y gestion de sesiones ...................................................................... 9
Secuencia de comandos en sitios cruzados XSS..................................................................... 10
Referencia directa insegura a objetos (Direct Object Re-ference) ........................................ 11
Configuracion de seguridad incorrecta .................................................................................. 12
Exposicion de datos sensibles ................................................................................................ 12
Ausencia de control de accesos a las funciones .................................................................... 13
Falsificación de peticiones en sitios cruzados CSRF ............................................................... 13
Uso de componentes con vulnerabilidades conocidas .......................................................... 14
Redirecciones y reenvios no validos ...................................................................................... 15
Ventajas y Desventajas del Modelo OWASP .......................................................................... 15
Conclusiones del Modelo OWASP.......................................................................................... 16
OPENSAMM - OPEN SOFTWARE ASSURANCE MATURIRY MODEL ........................................... 17
Marco Teorico ........................................................................................................................ 17
Principios bajo los cuales fue construido el Modelo SAMM:................................................. 17
Acercamiento a la mejora iterativa........................................................................................ 19
SAMM visto desde el Ciclo de Desarrollo de software .......................................................... 20
Planes a futuro ....................................................................................................................... 21
Otros acercamientos modernos............................................................................................. 21
Resumen descriptivo de las Funciones de Negocio y las Practicas de seguridad OPENSAMM
................................................................................................................................................ 22
Niveles de Madurez................................................................................................................ 22
Recomendaciones .................................................................................................................. 23
 Donde encontrar la ultima version de SAMM?...................................................................... 23
Ventajas y Desventajas del Modelo OPENSAMM .................................................................. 24
Conclusiones del Modelo OPENSAMM .................................................................................. 24
NIST 800-64 - SECURITY CONSIDERATIONS IN THE SYSTEM DEVELOPMENT LIFE CYCLE ......... 25
Objetivo .................................................................................................................................. 25
Introduccion ..............................................................................¡Error! Marcador no definido.
Ciclo de vida de desarrollo de Software (SDLC) ..................................................................... 25
SDLC del NIST 800-64 ............................................................................................................. 26
Fase Inicializacion ................................................................................................................... 27
Fase de Adquisicion / Desarrollo............................................................................................ 28
Fase de Implementacion /Evaluacion .................................................................................... 31
Fase Operaciones y mantenimiento ...................................................................................... 33
Fase Disposicion ..................................................................................................................... 34
Conclusiones del Modelo NIST 800-64................................................................................... 35
MICROSOFT SECURITY DEVELOPMENT LIFE CYCLE ................................................................... 36
Seguridad en Analisis y De nicion de Requerimientos ........................................................... 38
Seguridad en el Dise~no ......................................................................................................... 39
Seguridad en la Codificación .................................................................................................. 40
Pruebas de Seguridad............................................................................................................. 41
Seguridad en la Implementacion ........................................................................................... 42
Ventajas y Desventajas del Modelo SSDLC ............................................................................ 43
Conclusiones del Modelo SSDLC ............................................................................................ 43
Recomendacion el modelo a implementar al del Grupo Consultor a Z-Software....................... 44
REFERENCIAS................................................................................................................................. 46
INTRODUCCION
El presente informe detalla la recomendación del consultor para la implementación del modelo
de seguridad en el ciclo de desarrollo para la empresa Z-Software, basados en la investigación de
los 4 modelos de seguridad en ciclos de desarrollo más comunes.
Las actividades para la realización de este Informe Final han sido las siguientes:

1. Revisión de literatura, análisis y conclusiones de los modelos:

• Modelo Open Web Application Security Project - OWASP
• Modelo Security considerations in the system development life cycle NIST 800-64
• Security considerations in the system development life cycle NIST 800-64
• Microsoft security development lifecycle

2. Interacción del grupo consultor sobre temas relevantes para el diseño ini-cial del proyecto.

3. Preparación del Informe Final.

De acuerdo con los Términos de Referencia, el objetivo central es Recomen-dar un Modelo de
Seguridad en el ciclo de Desarrollo que permita a la empresa Z-Software que permita:

• Evaluar los impactos tanto económicos como técnicos dentro de los proyectos de
desarrollo para los cuales la empresa es contratada.
• Implementar instrumentos que permitan a la empresa el seguimiento periódico de la
calidad.
• Identificar eventos críticos del proyecto para decidir sobre ajustes necesarios y asegurar
la continuidad de cada proyecto.
• En cada proyecto de desarrollo generar procesos de aprendizaje y retroalimentación
útiles a replicar en los futuros desarrollos de la empresa Z-Software

Este documento consta de 4 secciones, la primera sección detalla características, antecedentes

y plantea los objetivos, en la segunda se presenta la revisión de la literatura realizada, la tercera
sección evidencia el análisis realizado y en la cuarta sección se presenta la Recomendación de
modelo a implementar.
OBJETIVO GENERAL
Validar, evaluar y aprender de los distintos modelos de seguridad en ciclo de desarrollo a n de
emitir una recomendación a la empresa Z-Sofwtare que le permita implantar un modelo con éxito
y asegurando el resultado esperado

OBJETIVO ESPECIFICO
• Recomendar un Modelo de Seguridad que permita a la empresa Z-Software
garantizar la entrega de proyectos de desarrollo de alta calidad, proporcionando
fuertes controles de gestión y maximizando la productividad.

• Determinar el modelo que permita a Z-Software producir más proyectos en

menos tiempo, con menor uso de recursos y de manera predecible con altos
estándares de seguridad y calidad.
ANTECEDENTES
En la actualidad las empresas dependen de software para funcionar correctamente hoy en da en
tiempos de crisis se incrementa esta necesidad directamente relacionada a suplir necesidades de
negocio, se utiliza software para manejar datos conciénciales y de alto valor de los que dependen
la privacidad, los medios de vida y las vidas de los usuarios.

Cada vez más la seguridad a nivel individual y colectivo dependen de sistemas de información
cada vez más complejos e interconectados pero que a su vez se encuentran expuestos en la red
global, incluso un software también protege otro software.

Es debido a esto la gran relevancia que tiene el desarrollo del software, es por lo que los
diferentes atacantes maliciosos y recreativos cada d a se especializan más para atacar y extraer
información de esta creciente multiplicidad de sistemas de software, las amenazas de hoy en d a
cuentas con más recursos y están altamente motivadas para descubrir y explotar
vulnerabilidades en el software.

En una del Instituto Nacional de Estándares y Tecnóloga (NIST), se resume el desafío: muchos
ataques exitosos explotan errores en el código de software utilizado en computadoras y redes
toma as una gran relevancia la seguridad del software, en medida que más y más funciones
críticas se vuelven cada vez más dependientes del software, ese software se convierte en un
objetivo de alto valor.

El objetivo de los modelos de seguridad en los ciclos de desarrollo es informar a todas las partes
que intervienen en un proyecto de desarrollo sobre los procesos, métodos y técnicas existentes
que pueden ayudarlos a especificar, diseñar, implementar, configurar, actualizar y mantener
software que pueda lograr lo siguiente:

• Resistir o resistir muchos ataques anticipados.

• Recuperarse rapidamente y mitigar el da~no de los ataques que no pueden ser resistidos.

La clave para asegurar el software es el proceso de desarrollo, incluyendo prácticas que no solo
ayuden a los desarrolladores a erradicar y eliminar defectos explotables a corto plazo, sino que
también, con el tiempo, aumentan la probabilidad de que dichos defectos no se introduzcan en
el primer lugar. Se pretende también abordar los riesgos asociados con la cadena de suministro
de software, incluidos los riesgos asociados con la selección y el uso de componentes de software
comerciales y de código abierto y la subcontratación de desarrollo de software.

Muchos de los defectos o vulnerabilidades en la seguridad en el software podran evitarse si los

desarrolladores estuvieran mejor equipados para reconocer las implicaciones de seguridad de
sus elecciones de diseño e implementación, toda iniciativa de calidad reduce el número de
defectos generales en el software, pero, los métodos basados en la calidad que se centran solo
en mejorar la corrección del software rara vez dan como resultado un software seguro. Esto se
debe a que, en términos de calidad, la corrección significa la corrección del funcionamiento del
software en condiciones normales previstas.

Se ha podido evidenciar que los ataques al software generalmente se crean en condiciones

anormales no anticipada, adicionalmente en lugar de atacar defectos

únicos, los atacantes a menudo aprovechan combinaciones de lo que parecen ser

funcionalidades e interacciones correctas en el software aquellas que individualmente suelen ser
una vulnerabilidad y cuando se combinan manifiestan un error a explotar.

La seguridad del software depende de la capacidad del equipo de desarrollo y de todas las partes
implicadas en el proyecto para anticipar lo inesperado, todo programa de seguridad de software
debe incluir la capacitación y la educación de los desarrolladores para hacer exactamente eso y
reconocer las implicaciones de seguridad no solo de defectos simples, sino también de series
anormales y combinaciones de funciones e interacciones dentro de su software, y entre su
software y otras entidades.

La compañía a Z-Software ha recibido quejas y reclamos de los clientes por la calidad del software
que desarrolla, evidenciando vulnerabilidades de seguridad, por lo cual nace la necesidad de dar
solución de nativa a estos inconvenientes mediante la implementación de un modelo que
permita asegurar la de seguridad en el ciclo de desarrollo.
MODELOS EXISTENTES

OWASP

Marco Teórico
OWASP es un proyecto que se dedica principalmente a ampliar, adquirir y a conservar
aplicaciones que son con cables para los dispositivos en los que se ejecute, en el 2013 se lanzó el
\top 10" que permite establecer un margen de seguridad en las aplicaciones por medio de la
identificación y exaltación de los riesgos más críticos que desafían la seguridad de las
organizaciones. Para establecer el proyecto top 10 se llevó a cabo un estudio por medio de
fuentes bibliógrafa cas, libros y diferentes herramientas, se tomaron datos estandariza-dos
incluyendo PCI, DISA, FTC entre otras; el top 10 fue denominado con este

nombre debido a la conmemoración número 10 del proyecto, teniendo en cuenta la importancia

de adquirir seguridad en las aplicaciones web. Las técnicas OWASP permiten idéntica por medio
de una comparación si las pruebas de penetración son efectivas al momento de encontrar la
vulnerabilidad en el estado de seguridad de las aplicaciones web, ayudando a mitigar los riesgos
de privacidad dentro de las aplicaciones

Inyección SQL
La inyección directa de los comandos SQL es una habilidad maliciosa donde el atacante daña los
comandos SQL exhibiendo dentro de ellos datos etéreos y ocultos ubicando as peligrosos
comandos en la base de datos, donde el atacante logra ajustar de forma directa los parámetros
de nidos en el momento que se realiza una consulta SQL.

Ejemplo donde la inyección directa de SQL es efectiva. Existe un acoplamiento de caracteres que
tienen un significado específico para el manejador de la base de datos teniendo en cuenta que
estos caracteres hacen parte de dicho lenguaje del manejador; entre ellos encontramos algunos
ejemplos claros de los ataques de la inyección SQL:

1. ‘o \(caracteres que indican cadenas de texto)

2. # (l nea simple comentada)
3. /* . . . */ (varias l neas comentadas)
4. + (suma o concatenación)
5. % (indicador para varios caracteres)

Por medio de estos caracteres un atacante puede acceder a la manipulación total de la

información de las aplicaciones enviando dichos comandos mencionados anteriormente.
Protección contra Blind SQL Injection. Esta actividad se realiza evaluan-do la seguridad en las
aplicaciones realizando un análisis contra la inyección de código, los impulsadores de los
lenguajes de programación y ejecución de las aplicaciones web ofrecen mejores técnicas para la
protección de la inyección de código, estableciendo varias recomendaciones para evitar un
posible ataque, teniendo en cuenta que los datos pueden ser modi cados al principio, se realiza
la ejecución de tratamiento para los posibles casos de ataques maliciosos, es recomendable usar
códigos que permitan la ejecución de consultas precompiladas y asi evitar que los atacantes
extraigan la información que esta almacenada en las aplicaciones; es trascendental examinar y
poseer control sobre todas las posibilidades que generan error, escalizando esta acción por
medio de un procedimiento seguro y con able as se evita que el atacante logre tener control y
manejo de la información de las aplicaciones. De esta forma, tenien-do un registro total de la
margen de error establecida se procede a auditar los errores de la aplicación para evitar un
posible ataque.

En la figura 1 podemos observar la estructura del Ataque Blind SQL Injection recreado por Panda
Security bajo un entorno posible.

Figura 1: Ataque Blind SQL Injection, Autor: Panda Security

Perdida de autenticación y gestión de sesiones

Se basa en la mala ejecución de técnicas de autenticación o gestión de sesiones que pueden

comprometer los elementos utilizados para encontrar el acceso a las herramientas como las
contraseñas, llaveros cifrados entre otros.

Encontrar vulnerabilidades en este método se puede realizar de la siguiente manera

dependiendo del tipo de usuario si es interno o externo con la ejecución de las herramientas
adecuadas para su identi cacion, la seguridad en la web es poco importante para algunos usuarios
lo que conlleva a la vulnerabilidad, en relacion con la perdida de autenticación y gestión de
sesiones las aplicaciones Web se vuelven indefensas cuando un atacante accede a sus
herramientas, ya que el atacante posee control de realizar suplantaciones de usuarios para llegar
a estropear los registros de la aplicación, debido a este tipo de acciones se originan accesos no
autorizados a la información que se encuentra entrelazada y recopilada en el servidor y los
servicios de las aplicaciones que han sido afectadas.

Este tipo de ataque se encuentra principalmente en la gestión de las contraseñas o en el

momento de cerrar las sesiones de las aplicaciones, este ataque esta enfocado a la recuperacion
automatica de las contraseñas en nuestras cuen-tas.

Secuencia de comandos en sitios cruzados XSS

En esencia la secuencia de comandos en sitios cruzados es un tipo de inyec-cion HTML, este tipo
de ataque es el mas perjudicial en cuanto a la seguridad que requieren las aplicaciones, esta
acción maliciosa se efectua en el momento en que una aplicación adquiere información
producida por un usuario y es enviada a un navegador web sin ser aprobada o validada por su
contenido.

Los atacantes tienen el poder de realizar ejecuciones en cuanto a las secuen-cias de comandos
en un navegador Web perteneciente al usuario que en este caso es la v clima del ataque, XSS
permite al atacante realizar ciertos cambios en sus aplicaciones ya que puede modi car datos,
realizar cambios en diferentes sitios web que con gran frecuencia utiliza la v clima, también
pueden colocar dentro de las aplicaciones contenido incompatible con la información que all se
tenga registrada, por medio de comandos maliciosos el atacante toma el control total de las
busquedas que se realizan en el equipo de la v clima por medio de los navegadores, los atacantes
utilizan JavaScript para sus ataques aunque existen varios comandos que son usados para los
ataques web sin ser aprobada o validada por su contenido.

En términos generales esta acción ocurre cuando el atacante recurre a una apli-cacion web para
enviar un código malicioso por medio de un Script dentro del navegador a la v clima; es dif cil
identificar si el Script contiene contenido ma-licioso porque la victima puede pensar que este
proviene de un sitio que es con able y lo ejecuta, cuando el script malicioso es ejecutado este
obtiene acce-so a los tokens de sesion, a las cookies entre otras como se evidencia en la gura 2.

Figura 2: Ataque Cross Site cripting -XSS

No todas las herramientas de la web estan protegidas contra los ataques, aunque estas se
encuentren automatizadas es posible encontrar problemas XSS.

En cuanto a las aplicaciones web cada una genera paginas de salida diferentes a su contenido del
lado del navegador como ActiveX, JavaScript, Silverlight entre otras, este tipo de acciones hace
que sea mas ardua la deteccion automatizada.

Proteccion contra XSS

En cuanto a la protección contra XSS se llega a la conclusion que por medio de la combinacion de
validación de listas blancas se permite veri car la direc-cion de los ataques y estas listas tienen la
capacidad de prevenir los ataques maliciosos.

Una de las formas para prevenir los ataques en las aplicaciones es estandari-zar un mecanismo
de validación de entrada que permita revisar la información que es ingresada o almacenada y
omitir la información maliciosa teniendo en cuenta aquellos mensajes de errores; se debe realizar
la codi cacion fuente de salida que permite que toda la información que el usuario suministra sea
debida-mente codi cada por medio de XML o HTML teniendo en cuenta el mecanismo de salida
de esta.

Tambien se debe realizar un proceso de especi cacion de la codi cacion de salida como (UTF8) y
denegar al atacante que coloque esta codi cacion en el nombre de los usuarios, es importante no
utilizar la validación de lista negra (blacklist) ya que los atacantes reemplazan los caracteres (\<"
\>") o las frases como script y les es posible atacar sigilosamente.

Referencia directa insegura a objetos (Direct Object Re-ference)

Esta acción sucede cuando un programador muestra una referencia destinada a un punto interno
de la aplicación, como por ejemplo al registro de la base de datos o a la URL, los atacantes
acceden a este tipo de herramientas para sacar in-formacion con dencial sin autorizacion del
usuario, como medida de prevencion se recomienda colocar un control de accesos para que no
se efectue dicho ataque.

Como es bien sabido las aplicaciones muestran a sus usuarios objetos internos y el atacante
puede acceder a estos objetos internos y realizar modificaciones, saltandose un control de
accesos malintencionadamente, en el siguiente caso se establece que el código utiliza la entrada
del usuario para modi car y cambiar nombres de chero, el atacante ingresa a otros recursos y
secciones mas privadas de la aplicación obteniendo toda su información.

Prevención del ataque.

Se debe proceder a usar referencias indirectas por usuario y por las sesiones a las que ingrese,
esta acción le impide al atacante acceder a la información y a los recursos no autorizados.
Un ejemplo claro es que en vez de usar la clave del recurso de bases de datos se procede a utilizar
los números de acceso y as revelar el valor que el usuario eligió, entonces la aplicación deber a
realizar una similitud entre la clave de la base de datos y la referencia indirecta, después se
procede a comprobar el acceso, ya que si no hay una previa comparación de control de acceso
para veri car si el usuario esta registrado, es posible que exista vulnerabilidad y por consiguiente
un posible ataque.

Configuración de seguridad incorrecta

Se denomina como una mala con configuración de seguridad en lo que compete a las aplicaciones
web, ya que va desde la aplicación hasta el servidor, si no se efectúa una correcta configuración
de la base de datos de la aplicación, de los marcos de trabajo y del servidor de la aplicación este
se encuentra vulnerable a los ataques, por lo que se recomienda actualizar el software
seguidamente.

Por consiguiente, las aplicaciones usan el nombre real de las mismas para crear paginas web en
cuanto a su promoción, las aplicaciones se confían de la poca seguridad que hay en ellas y no con
si el usuario que accede esta autorizado para realizar dicha acción, este es un punto de referencia
para los atacantes ya que por ah pueden establecer los diferentes métodos de ataque a las
aplicaciones, obteniendo los valores de los parámetros y conseguir los códigos de acceso a las
aplicaciones.

prevención del ataque. Es importante realizar periódicamente escaneos y hacer auditorias para
encontrar las falencias de las aplicaciones y prevenir posibles ataques, puertos abiertos o
servicios innecesarios.

exposición de datos sensibles

Se encuentran falencias en las aplicaciones ya que dentro de su manejo operacional no se

resguardan datos sensibles como las credenciales de autenticación o los números de las tarjetas
de crédito de los usuarios, cuando los atacantes detectan este tipo de falencias en las
aplicaciones ingresan sigilosamente y modificación los datos para obtener varias identidades y as
efectuar millonarios robos; para proteger los datos sensibles es primordial utilizar el cifrado de
datos y ciertas reservas o mesuras cuando se produce un intercambio de información por medio
de los navegadores.

Las aplicaciones almacenan su información con un cifrado inseguro, ya que carece de algoritmos
o simplemente se asignan contraseñas débiles por parte de los usuarios, los cuales no están
cambiando las claves. Las aplicaciones tienden a con ar en la seguridad perimetral que se
implementen con ando en su fortaleza, también tienen de ciencias en la capa de transporte y por
consiguiente en la protección de del taco de peticiones y no poseen un adecuado uso de SSL/TLS.
Dentro de las aplicaciones se encuentran diferentes fallas debido a la exposición de datos
sensibles ya que estos datos deber estar protegidos, una posible solución para la protección de
los datos almacenados es utilizar módulos criptograma autorizados como FIPS 140, otra de las
viables soluciones es deshabilitar el cacheado de las páginas web que almacenen datos sensibles.

Un ejemplo claro donde se presenta este tipo de casos es el siguiente:

Una aplicación utiliza el cifrado automático para los números de tarjetas de crédito en la base de
datos local, lo que nos da a entender que automaticamente se descifran cuando se rescatan los
datos accediendo por este medio a una posible vulnerabilidad donde se produce un ataque de
inyección SQL per-mitiendo al atacante obtener especespecifica mente la información de las
tarjetas de
crédito; la aplicación deber a cifrar los números y acceder luego por medio de procedimiento de
descifrado utilizando una clave privada.

Ausencia de control de accesos a las funciones

La ausencia de control, de accesos surge debido a que las aplicaciones no realizan los
procedimientos de seguridad de manera e cliente, a pesar de que estas confirman los derechos
de acceso a nivel de orden o función en la zona de comunicación con el usuario es necesario rati
car el control de acceso que se produce en el servidor al momento de cada función; si este
procedimiento no se realiza adecuadamente el atacante establecer control en las autorizaciones
y manejara a su antojo la aplicación; en consecuencia la acción del atacante es sacar datos
sensibles de las aplicaciones y enviarlas a paginas que se encuentran ocultas, ya que la
información ejecutada no es validada en el procesamiento de la URL.

Los atacantes pueden utilizar maniobras para conseguir su objetivo enviando una petición como
un usuario anónimo y as tener ingreso a la funcionalidad de privilegios en las aplicaciones, lo que
hace el atacante es modificar el URL a una función de privilegios, como no se tiene la su cliente
seguridad cualquier usuario anónimo puede acceder a funciones privadas en las aplicaciones que
no se encuentran protegidas ante las amenazas de los posibles ataques.

La protección dentro de las aplicaciones es fundamental porque estas en algunos casos no

protegen de la mejor manera las funcionalidades establecidas dentro de las mismas, lo que
ocasiona un punto de referencia para que el ata-cante pueda realizar los cambios que desee, en
algunos casos se llega a observar que el sistema se encuentra conjurado incorrectamente y no se
registran chequeos por código lo que ocasiona mas vulnerabilidad; es fundamental establecer
cuales son las (URLs) que son afectadas en gran medida por los atacantes para tener un control
sobre ellas, posiblemente los atacantes irán directamente a las funciones administrativas de las
aplicaciones.
Falsificación de peticiones en sitios cruzados CSRF

Los ataques CSRF exige realizar al navegador de la v clima el envio de una petición HTTP, pero
esta viene falso cada entrelazando información del usuario y es enviada a una pagina web que se
encuentra vulnerable, esta acción permite al atacante exigir al navegador del usuario victima
realizar pedidos como peticiones legitimas del usuario victima.

Este ataque se fundamenta en la familiaridad que posee la web en el usuario v clima del ataque,
estas acciones hacen que la v clima realice operaciones maliciosas sin ser consciente de lo que
esta haciendo, obteniendo datos por me-dio de la modificación de estos, en ese momento el
atacante accede a observar ese tipo de cambios y es donde toma control de la aplicación y por
consiguiente de la transferencia de información.

Los servicios de las aplicaciones web contienen las credenciales de los usuarios registrados y
autorizados a través de la IP, credenciales de dominio, entre otras; es posible que si la aplicación
no tiene manera de anular CSRF le es muy difícil diferenciar cuales son las peticiones legitimas
del usuario v clima y las peticiones CSRF que vendrán siendo un ataque para la aplicación.

prevención del ataque. Para prevenir estos posibles ataques se deben realizar métodos de
autenticación agregados para todas las peticiones que se realicen as es posible identificar cuáles
son las peticiones que no se encuentran autorizadas, existen varias técnicas para encontrar este
tipo de ataques como Synchronizer token pattern este tipo de técnica contiene un token secreto
para identificar el tipo de petición, por medio del servidor el token se genera y es comprobado
satisfactoriamente, as el atacante no podrá tener acceso al valor indicado de la petición y no
puede efectuar su ataque.

Uso de componentes con vulnerabilidades conocidas

Específicamente los atacantes encuentran un componente que se encuentre vulnerable por

medio de una búsqueda manual, donde se incorpora el exploit y es ejecutada la acción de ataque,
en los sistemas operativos encontramos diferentes librerías que para su funcionamiento
necesitan de la mayor a de privilegios que tiene la aplicación y si en este tipo de componentes el
atacante encuentra cierto tipo de vulnerabilidad accede en el servidor y por consiguiente los
datos almacenados se perder concediéndole dominio total al atacante y debilitando la aplicación.

Esta acción se produce a consecuencia de que en conjunto la mayor a de las aplicaciones no

resguardan la seguridad en sus componentes y se conforman aun sabiendo que hay atacantes a
la vista; como ya se mención anteriormente las bibliotecas son las mas afectadas principalmente
porque el usuario no actualiza la aplicación y sigue usando versiones anteriores por donde se
pueden filtrar los atacantes, el impacto que puede causar el atacante con su inyección va desde
lo mas minimo a lo mas alto, sigilosamente el atacante va ingresando hasta apoderarse de toda
la información que quiera sacar, una posible solución para contrarrestar este tipo de daños es no
utilizar aquellos componentes que no se encuentren codificados ya que si el componente no
tiene o crea un parche por ah se puede el atacante, el usuario debe estar revisando periódica-
mente la seguridad en las bases de datos, igualmente en las listas de correos y actualizarlos.
Redirecciones y reenvíos no validos

Es común que las aplicaciones web por medio de links envían a los usuarios a otras páginas web
con su información, pero este procedimiento acarrea datos que no son netamente con cables
para poder acceder al destino de la pagina web, ya que si la validación no es adecuada el
procedimiento que utilizan los atacantes es enviar a los usuarios a otros sitios como malware y
por consiguiente realizan reenvíos ingresando a paginas que no son compatibles.

Los atacantes son muy hábiles en cuanto a las técnicas que utilizan ya que pueden tergiversar la
información haciéndole creer a los usuarios que realicen varias peticiones a su aplicación web
siendo estas de carácter malicioso. Hay que tener en cuenta que los códigos HTML al que el
usuario accede pensando que es con abre podrá a ser atacado, en ese momento el código
malicioso roba los datos del usuario y sus contraseñas, esta acción de ataque permite el acceso
total al equipo de la victima.

Una posible solución a estos ataques es que los valores de los parámetros de destino sean valores
de mapeo, también se recomienda utilizar ESAPI para rectificar car el método sendRedirect()
posteriormente el usuario puede asegurarse que los destinos son con cables.

Ventajas y Desventajas del Modelo OWASP

Figura 3: Ventajas y Desventajas OWASP

Conclusiones del Modelo OWASP

Se debe tener en cuenta la arquitectura del sistema, as como los mecanismos de autenticación y
sus respectivas sesiones de usuarios, controles de acceso, registros de actividad y
consideraciones de seguridad a nivel de criptografía.
OPENSAMM - OPEN SOFTWARE ASSURANCE MATURIRY MODEL

Marco Teórico

Este es una Metodología a que sirve para evaluar las practicas actuales de desarrollo seguro en
una organización, cuyas practicas pueden ser utilizadas para implementar un programa de
seguridad de aplicaciones en forma iterativa, donde se demuestra mejoras concretas en un
programa de aseguramiento de seguridad de aplicaciones y que además de ne y mide actividades
relacionadas a la seguridad en una organización.

Este modelo SAMM fue de nido para ser exilé de manera que pueda ser utilizado por
organizaciones pequeñas, medianas o grandes que utilicen cualquier estilo de desarrollo.
Además, este modelo puede ser aplicado en toda la organización, en una sola l nea de negocio o
incluso en un proyecto en particular.

Principios bajo los cuales fue construido el Modelo SAMM:

• Cambios de comportamiento de una organización a través del tiempo

• No hay una sola receta que funcione para todas las organizaciones
• Los lineamientos relacionados a las actividades de seguridad deben ser específicos.
• El comportamiento de una organización cambia lentamente con el tiempo. Un software
de éxito desarrollado bajo un programa de seguridad debe ser especificado en iteraciones
pequeñas que ofrezcan material ganancias de la garantía, mientras que gradualmente se
esta trabajando hacia objetivos a largo plazo.
• Un software de seguridad es un marco que debe ser exilé y permitir a las organizaciones
adaptar sus decisiones a tolerancia a riesgos y a la forma en que ellos construyen el
software.

Figura 4: Descripción SAMM

El modelo SAMM Es un proyecto abierto, el contenido se puede mantener siempre

independiente de los vendedores y disponible libremente para que todo mundo lo use.
La metodologIa OpenSAMM establece:

Figura 5: Funciones de Negocio

Figura 6: Practicas de Seguridad

Tres objetivos secuenciales para cada Practica de seguridad de nen como ir mejorando a lo largo
del tiempo.
Esto establece el concepto de \Nivel" en el que una organización se encuentra al cumplir una
determinada ‘Practica’.

Los tres niveles, que son los Niveles de Madurez, para cada \Practica" co-rresponden
generalmente a
Figura 7: Niveles de Madurez

Figura 8: Acciones por Nivel

Acercamiento a la mejora iterativa

Dado que cada una de las 12 \Practicas" es un area de madurez, los objeti-vos sucesivos
representan los componentes basicos para cualquier programa de mejora de la seguridad en el
desarrollo.

En pocas palabras, la idea es de nir un plan de mejora de la seguridad en el desarrollo de la

siguiente forma:
 • Seleccionar Practicas de seguridad a potenciaren la siguiente fase del plan de mejora.

• Logar el siguiente Objetivo en cada practica mediante la realizacion de las Actividades

asociadas a los Umbrales de Satisfaccion.

SAMM visto desde el Ciclo de Desarrollo de software

Figura 9: SAMM en SDLC

SAMM incluye documentos de evaluación para cada \Practica" de seguridad, donde se permite
tanto evaluaciones super ciales como detalladas.

• Ligero - Las hojas de trabajo de cada practica son evaluadas y las ca-li caciones son
asignadas en base a las respuestas. Este tipo de revisión usualmente es su cliente para
una organización que intenta comparar su programa de aseguramiento actual contra el
SAMM y desea tener rapida-mente una idea de donde estan posicionados.

• Detallado - Después de completar la revisión de las hojas de trabajo, se realiza trabajo de

auditor a adicional para veri car que las actividades prescritas por cada practica existan y
funcionen. Adicionalmente, dado que cada practica también métricas de éxito, esta
información debe ser recolectada para asegurarse que la organización se esta
desempeñando como se espera.

Al medir una organización contra las practicas de seguridad de nidos, obtenemos un panorama
general de las actividades de seguridad existentes. Este tipo de revisiones es útil para entender
la amplitud de las actividades de seguridad que se han creado en la organización.
Es posible que las organizaciones se encuentren en niveles intermedios (+).

Figura 10: Flujo SAMM

Cali car una organización usando las hojas de trabajo para revisión es sen-cillo. Después de
responder las preguntas, evalue la columna de respuestas para determinar el nivel. El cual se
indicar a con respuestas a rmativas para todas las preguntas sobre los marcadores a la derecha
de la columna de respuestas.

Planes a futuro

• Relacionarlo a regulaciones y estándares existentes (muchos en proceso ac-tualmente)

• PCI, COBIT, ISO 17799/27002, ISM3, etc.
• Planes de actuacion adicionales donde se identi quen necesidades.
• Incorporacion de casos de estudio adicionales
• Feedback para re namiento del modelo
• Traducciones a otros lenguajes

Otros acercamientos modernos

• Microsoft SDL Optimization Model

• Fortify/Cigital Building Security InMaturity Model (BSIMM)
Resumen descriptivo de las Funciones de Negocio y las Practicas de seguridad
OPENSAMM

Figura 11: Descripción SAMM

Niveles de Madurez

Cada una de las practicas de seguridad tiene tres niveles de madurez bien de nidos y un nivel
inicial (cero) implícito.

Dado el diseño central del modelo en s , una organización puede usar SAMM como un marco de
referencia para medir su programa de aseguramiento de Software y crear una tarjeta de
calificaciones. Usando tarjetas de calificaciones, una organización puede demostrar mejoras a
través de las iteraciones de desarrollo en el programa de aseguramiento. Y lo mas importante, la
organización puede usar las plantillas de planes de implementación de SAMM como gu a para
construir o mejorar su iniciativa de aseguramiento de Software.
Al medir una organización contra las practicas de seguridad de nidas, obtenemos un panorama
general de las actividades de seguridad existentes. Este tipo de revisiones es útil para entender
la amplitud de las actividades de seguridad que se han creado en la organización. Mas aun,
permite que la organización utilice SAMM para crear un plan de implementación futuro para la
mejora continua.

Recomendaciones

SAMM, es uno de los modelos mas recomendables que se suele implantar, este modelo de
Madurez para el Aseguramiento de Software (SAMM { Softwa-re Assurance Maturity Model) que
es un marco de trabajo abierto y exilé desarrollado por OWASP. Este modelo sirve para ayudar a
las organizaciones a formular e implementar una Estrategia de Seguridad para el Desarrollo de
Software que sea adecuada a las necesidades especie cas de cada organización y tiene, entre
otras, las siguientes carácter sticas:

Donde encontrar la ultima version de SAMM?

Después de que OpenSAMM v1.0 fue donado a OWASP , evolución a OWASP SAMM, que es
desarrollado y mantenido por el equipo del proyecto OWASP SAMM. Puede encontrar las ultimas
descargas y lanzamientos en https://owaspsamm.org OWASP SAMM v1.5 lanzado OWASP
SAMMv1.1 disponible OpenSAMM Summit Dublin - Resultado

Como proyecto abierto, el contenido de SAMM siempre permanecer neutral para el vendedor y
estar disponible gratuitamente para que todos lo usen.
Ventajas y Desventajas del Modelo OPENSAMM

Figura 12: Ventajas y Desventajas SAMM

Conclusiones del Modelo OPENSAMM

Para la construccion de software seguro es necesario hacer una tarea ardua de concientizacion y
divulgacion de la información ya que los directivos de las empresas al momento de adoptar este
método deben de estar bien informados de las bondades de utilizar un método de desarrollo de
software seguro, para que al momento de implementarlo toda la empresa a través de los
directivos lo lleven a cabo con la mentalidad de que el adoptar este método es bene cioso.

Las empresas deben de estar conscientes de que implementar este método im-plica costo y
esfuerzo en un principio mientras la empresa aprende, pero cuando se llega a un nivel optimo
esto es automático. Además de los bene cios del re-torno de inversion es muy satisfactoria y
sobre todo la reputacion de la empresa.

Mejorar la seguridad del software implica un cambio cultural en la organiza -cion, debemos
cambiar la forma en la que se trabaja aplicando Metodología as que sirvan para evaluar las
practicas actuales de desarrollo seguro, SAMM pue-de ser utilizado para implementar un
programa de seguridad de aplicaciones en forma iterativa.

Este modelo demuestra mejoras concretas en un programa de aseguramiento de seguridad de

aplicaciones, de ne y mide actividades relacionadas a la segu-ridad en nuestra organización.
NIST 800-64 - SECURITY CONSIDERATIONS IN THE SYSTEM DEVELOPMENT LIFE
CYCLE

Objetivo

Brindar información de la siguiente investigación que utilizamos la gu a NIST SP 800-64 que

muestra un modelo de referencia (framework) para incorporar la seguridad en todas las fases del
proceso SDLC, desde el inicio hasta la disposición y explica como incluir requerimientos de
seguridad de a información en las fases apropiadas de SDLC.

Introducción

El método SDLC, es una gu a que se utiliza para implementar desde el prin-cipio del proyecto,
para evitar debilidades comunes, que conllevan a un código vulnerable y con de ciencias de
seguridad, ya que esto puede presentar con ictos de los objetivos de negocio estipulados en cada
fase de SDLC, en esta investi-gacion se utilizo la publicacion NIST SP 800-64, es una pauta que
asiste a las empresas a seleccionar y adquirir controles de seguridad rentables al explicar como
incluir los requerimientos de seguridad en el sistema de información apro-piadas del SDLC en las
que se encuentran las siguientes fases : inicializacion, adquisición/ desarrollo, implementación,
operaciones/ mantenimiento y dispo-sicion, cada una de las cinco fases incluye un grupo de pasos
de seguridad que son necesarios para la implementación de seguridad en el sistema durante su
desarrollo.

Ciclo de vida de desarrollo de Software (SDLC)

SDLC del NIST 800-64

Figura 14: SDLC

Fase Inicializacion

En esta primera fase del ciclo de vida del desarrollo, las atenciones de seguridad son clave para
una integración rapido y temprana, asegurando as que se consideren las amenazas, los requisitos
y las posibles limitaciones en la funcionalidad y la integración. En este punto, la seguridad se
considera mas en términos de riesgos comerciales con aportes de la o cina de seguridad de la
información. Las actividades de seguridad clave para esta fase incluyen:

Diseño inicial de los requisitos comerciales en términos de con genialidad, integridad y

disponibilidad.

Valor de la categorización de la información e identificación de los requisitos de manejo

especiales conocidos para transmitir, almacenar o crear información tal como información de
identificación personal y determina-cion de cualquier requisito de privacidad.

La planificación y el conocimiento tempranos resultaran en un ahorro de tiempo y costos a través

de una planificación adecuada de gestión de riesgos. Las discusiones de seguridad deben
realizarse como parte del proyecto de desarrollo (no por separado) para garantizar una
comprensión solida entre el personal del proyecto de las decisiones comerciales y sus
implicaciones de riesgo para el proyecto de desarrollo general.

Determinación de necesidades

Es una de nicion inicial de un problema que podr a resolverse mediante la automatización, Los
componentes tradicionales de la determinación de necesidades son el establecimiento de una
idea básica del sistema, la de nicion de requisitos preliminares, la evaluación de factibilidad, la
evaluación de tecnología a y alguna forma de aprobación para investigar mas el problema.

La fase de adquisición / desarrollo puede comenzar solo después de que una organización haya
determinado que existe una necesidad. Es posible que se ha-ya determinado una necesidad
durante la planificación estratégica o táctica. La fase de determinación de necesidades esta en
un nivel muy alto en términos de funcionalidad. Aquí no se de nen detalles especie cos de un
sistema. Se explora la idea de un sistema nuevo o sustancialmente mejorado y la viabilidad de la
idea. Durante esta fase temprana del desarrollo, la de nicion del requisito de seguridad debe
comenzar con la categorización de seguridad y la evaluación preliminar del riesgo.

La determinación de necesidades es una actividad anal tica que evalúa la capacidad de los activos
de una organización para satisfacer las demandas existentes y emergentes. La parte de seguridad
de la determinación de necesidades dar como resultado una descripción de alto nivel de los
controles de seguridad en el sistema propuesto y los requisitos de garantia. Este material se
utilizar para
respaldar la derivación de una estimación de costos que aborde todo el ciclo de vida. Se deben
estimar los costos totales del ciclo de vida, incluidos los costos de implementación y los costos
de gestión en servicio. Puede haber un equilibrio tal que el aumento de los gastos durante la
adquisición puede generar ahorros durante la operación del sistema. Deben considerarse las
implicaciones de seguridad de arquitecturas y tecnología as alternativas.

Determinación de necesidades

Categorización de seguridad

La empresa debe contar con una orientación estándar para establecer categorias de seguridad
los sistemas de información

Las categor as deben estar basados en el impacto potencial que ciertos eventos pueden causar
sobre los sistemas de información requeridos para cumplir la mision, proteger los activos, cumplir
las responsabilidades lega-les mantener la continuidad de las operaciones, y proteger a los
individuos.

Valoración preliminar del Riesgo

Describir las necesidades básicas de seguridad del sistema, en términos de integridad,

disponibilidad, con genialidad, responsabilidad, no repudiación.

Una evaluación de riesgo preliminar debe de nir el entorno de amena-za en el que operar el
producto o sistema. A esta evaluación le sigue una identificación inicial de los controles de
seguridad requeridos que de-ben cumplirse para proteger el producto / sistema en el entorno
operativo previsto.

Fase de Adquisición / Desarrollo

Esta sección aborda consideraciones de seguridad exclusivas de la segunda fase SDLC. Las
actividades de seguridad clave para esta fase incluyen:

• Realice la evaluación de riesgos y use los resultados para complementar los controles de
seguridad de l nea de base.
• Analizar los requisitos de seguridad.
• Realizar pruebas funcionales y de seguridad.
• Preparar documentos iniciales para la certificación y acreditación del sistema.
• Diseño de arquitectura de seguridad.
Aunque esta sección presenta los componentes de seguridad de la información de manera
secuencial de arriba hacia abajo, el orden de nalizacion no es ne-cesariamente jo. Sera necesario
repetir el análisis de seguridad de los sistemas complejos hasta que se logre la consistencia y la
integridad.

Para esta fase se deben incluir estas revisiones:

Una revisión de arquitectura / diseño que evalúa el diseño plani cado del sistema y la posible
integración con otros sistemas, as como la incorpo-racion de servicios compartidos y controles
de seguridad comunes, tales como autenticación, recuperacion ante desastres, deteccion de
intrusiones o informes de incidentes.

Una revisión del rendimiento del sistema que evalúa si el sistema esta entregando o es capaz de
cumplir con las expectativas documentadas del propietario y si el sistema se comporta de manera
predecible si esta sujeto a un uso inadecuado. (Por ejemplo, la capacidad del sistema para
mantener la disponibilidad y la integridad de los datos en las cargas extremas de recursos
esperadas).

Una revisión del rendimiento del sistema que evalúa si el sistema esta entregando o es capaz de
cumplir con las expectativas documentadas del propietario y si el sistema se comporta de manera
predecible si esta sujeto a un uso inadecuado. (Por ejemplo, la capacidad del sistema para
mantener la disponibilidad y la integridad de los datos en las cargas extremas de recursos
esperadas).

El estado intermedio del proyecto y la revisión nanciera son importan-tes para detectar cambios
importantes en el nivel de esfuerzo plani cado para garantizar que las relaciones costo-bene cio
sean monitoreadas y se continúen las decisiones efectivas.

Puede ser necesaria una revisión de seguimiento de las decisiones de gestión de riesgos si, debido
a las revisiones antes mencionadas, el sistema y / o sus controles de seguridad y / o sus requisitos
cambian.

Consideraciones de seguridad

Valoración formal y periodica del riesgo.

Facilita identificar los requerimientos de protección del sistema. Obser-vacion mas profunda y
detallada. Se debe realizar antes de la aprobación de las especi caciones del diseño. Puede
identificar de ciencias en el análisis de requerimientos de integridad, con genialidad y
disponibilidad o en el análisis de requerimientos de aseguramiento de seguridad.

Análisis de requerimientos funcionales de seguridad

Puede incluir las 2 fuentes de requerimientos de seguridad del sistema

Ambiente de seguridad del sistema (pol tica de seguridad de la información de la empresa y
arquitectura de seguridad de la empresa)

Requerimientos funcionales de seguridad

Debe incluir un análisis de leyes y regulaciones que de nan requerimientos de seguridad m nimos
(baseline)

Los requerimientos de seguridad legal, funcional y de TI deben establecer-se en términos especie

cos.

Para sistemas complejos, mas de una iteracion del análisis de requeri-mientos puede necesitarse.

Énfasis en integridad, disponibilidad y con genialidad

Consideraciones y Reporte de Costos

• Determinar cuanto costar el desarrollo, incluyendo Hardware, Software, perso-nal,

entrenamiento y seguridad.

• La identificación de costos asociados a la seguridad puede ser compleja. Po-sibles

entradas:

• Proceso de Administración de Riesgos, controles que mitigaran las vulnerabilidades identi

cadas

• Mitigación del riesgo, que incluye un análisis costo-bene cio de los con-troles
recomendados.

• Incluir la seguridad como un tem en los reportes presupuestales anuales o de

adquisiciones mayores.

• En términos de valor o porcentuales.

• El enfoque mas efectivo en costo es incluir la seguridad al inicio del SDLC, debido a que:

• Es mas dif cil adicionar funcionalidad en un sistema después de que ha sido construido.
 • Es menos costoso incluir medidas preventivas que tratar con el costo de un incidente de
seguridad.

Planeación de la Seguridad

• Asegurar que los controles de seguridad requeridos (planeados o existen-tes), para redes,
facilidades, sistemas de información, esten totalmente documentados.
• Provee una caracterizacion o descripción completa del sistema de información.
• Pueden incluirse referencias a documentos claves del programa de seguri-dad de la
información. Plan de administracion de la Con guracion Plan de contingencia Plan de
respuesta a incidentes. Plan de concientizacion y entrenamiento en seguridad.
• Reglas de comportamiento.
• Valoración del riesgo.
• Resultados de pruebas y evaluaciones de seguridad.
• Acuerdos de interconexion de sistemas
• Autorizaciones/acreditaciones de seguridad.
• Desarrollar controles de seguridad
• Dise~nar, desarrollar, modi car e implementar los controles, nuevos o adicio-nales,
referenciados en el Plan de Seguridad
• Prueba y Evaluación de la Seguridad Desarrollada
• Probar, si es posible, que los controles trabajan apropiadamente y son efec-tivos, antes
de colocarlos en produccion Las pruebas deben basarse en un plan de evaluación y
pruebas.
• Otros componentes de Planeación

Tipo de Contrato.

• Revisión de otros grupos funcionales.

• Revisión por Certi cador y Acreditador.
• Naturaleza c clica del proceso
• Evaluación y aceptación.

Fase de Implementación /Evaluación

En esta fase de Implementación / Evaluación es la tercera del SDLC. Du-rante esta etapa, el
sistema se instalar y evaluar en el entorno operativo de la organización.

Las actividades de seguridad clave para esta fase incluyen:

• Integrar el sistema de información en su entorno.

• Planificar y realizar actividades de certi cacion del sistema en sincroniza-cion con las
pruebas de los controles de seguridad.
• Actividades completas de acreditación del sistema.
• En esta fase se requiere hacer las siguientes revisiones:
• Revisión de preparación de prueba del sistema
• Revisión de C&A
• Estado nal del proyecto y revisión nanciera
• Revisión de preparación de implementación
• Decisión del Funcionario Autorizante (AO)
• Implementación de TI o aprobación de conexion.
• Consideraciones de seguridad
• Inspección y Aceptación
• Decisión de examinar y luego aceptar y pagar por un entregable, para establecer que el
sistema cumple los detalles.
• Pruebas por la organización.
• Validación y veri cacion por un contratista independiente.
• Las pruebas, validaciones veri caciones deben incluir la seguridad del sis-tema,
Acreditación del sistema: aceptación y aprobación para autorizar el procesamiento.
• Es una decisión separada basada en los riesgos y ventajas de instalar el sistema en el
ambiente operacional.
• No es correcto incluir la autorizacion para colocar en funcionamien-to el sistema como
uno de los criterios de aceptación debido a que muchos factores estan fuera del control
del vendedor.
• Inspección y Aceptación
• Ocurre en el sitio en donde el sistema sera colocado en produccion. Prue-bas de
integración y aceptación ocurren después de la entrega e instalacion del sistema. Los
controles de seguridad son establecidos e inicializados en concordancia con las
instrucciones del fabricante y con las gu as de imple-mentacion de seguridad disponibles.
 Certificacion de Seguridad

Antes de la puesta en funcionamiento del sistema, se debe asegurar que los controles de
seguridad establecidos en respuesta a los requerimientos de seguridad fueron incluidos durante
el proceso de desarrollo del sistema.

Pruebas y evaluaciones periodicas de los controles de seguridad deben rea-lizarse en un sistema

de información para asegurar que los controles estan implementados efectivamente.

Aplicación de metodolog as e instrucciones de veri cacion para lograr con-anza de que

salvaguardas y contramedidas adecuadas existen para res-guardar el sistema.

Fase Operaciones y mantenimiento

Operaciones y mantenimiento es la cuarta fase del SDLC. En esta fase, los sistemas estan en su
lugar y en funcionamiento, se desarrollan y prueban mejoras y / o modi caciones al sistema, y se
agrega o reemplaza hardware y / o soft-ware. El sistema se supervisa para un rendimiento
continuo de acuerdo con los requisitos de seguridad y se incorporan las modi caciones necesarias
del siste-ma. El sistema operativo se evalúa periodicamente para determinar como puede
hacerse mas efectivo, seguro y e cliente. Las operaciones continuan mientras el sistema se pueda
adaptar de manera efectiva para responder a las necesidades de una organización mientras se
mantiene un riesgo acordado nivel. Cuando se identi can las modi caciones o cambios necesarios,
el sistema puede volver a ingresar a una fase previa del SDLC.

Las actividades de seguridad clave para esta fase incluyen:

• Realizar una revisión de preparación operativa

• Gestionar la con guracion del sistema
• Instituir procesos y procedimientos para operaciones aseguradas y moni-toreo continuo
de los controles de seguridad del sistema de información.
• Realice la reautorizacion segun sea necesario.

Consideraciones de seguridad

• Administración y control de la con guracion Los sistemas de in-formacion estan en

constante estado de migracion con actualizaciones al Hardware, Software, o Firmware y
posibles modi caciones al ambiente que rodea al sistema.

• Cambios a un sistema pueden tener impacto signi cativo en la seguridad del sistema para
mantener la acreditación del sistema, es necesario:

• Documentar los cambios a los sistemas de información.

 • Valorar continuamente el impacto potencial de los cambios sobre la seguridad del
sistema.

• Monitoreo continuo

• Pruebas y evaluaciones periodicas y continuas de los controles de segu-ridad para

asegurar su efectividad

• Monitoreo de controles.

• Reportes del estado de la seguridad en el sistema a las instancias pertinentes

• Tecnicas de monitoreo

• Revisiones de Seguridad. Auto-evaluaciones.

• Pruebas y Evaluaciones. Auditor as

Fase Disposición

La eliminacion, la fase nal en el SDLC, predice la eliminacion de un siste-ma y el cierre de cualquier

contrato vigente. Las di cultades de seguridad de la información agrupada con la información y
la eliminacion del sistema deben afrontarse expl citamente. Cuando los sistemas de información
se trans eren, se vuelven obsoletos o ya no se pueden usar, es importante garantizar que los
recursos y activos esten protegidos.

Por lo habitual, no hay un nal de nitivo para un sistema. Los sistemas normalmente
evolucionan o pasan a la proxima generacion debido a los requisitos cambiantes o las mejoras en
la tecnología a. Los planes de seguridad del sistema deben evolucionar continuamente con el
sistema. Gran parte de la información ambiental, de gestión y operativa aun debe ser relevante
y útil para desarrollar el plan de seguridad para el sistema de seguimiento.

Las actividades de eliminacion aseguran la terminacion ordenada del sistema y preservan la

información vital sobre el sistema para que parte o toda la información pueda reactivarse en el
futuro, si es necesario. Se hace especial hincapie en la preservacion adecuada de los datos
procesados por el sistema para que los datos se migren efectivamente a otro sistema o se
archiven de acuerdo con las regulaciones y pol ticas de gestión de registros aplicables para un
posible acceso futuro.

Las actividades de seguridad clave para esta fase incluyen:

• Construir y ejecutar un plan de eliminacion / transicion.

 • Archivo de información cr tica.
• Desinfeccion de los medios de comunicación.
• Eliminación de hardware y software.
• Consideraciones de seguridad
• Consideraciones de seguridad
• Identificar los métodos requeridos para recuperar la información en el fu-turo y
considerar los requerimientos legales para la retencion de registros
• Saneamiento de medios
• Evitar que los datos (información sensitiva) sean reconstruidos y acce-didos por
individuos no autorizados.
• Eliminación, borrado, o sobre escritura de medios magneticos o electri-cos de
almacenamiento.
• Borrado de memorias no volátiles

Formas de saneamiento:

• Limpiar (no se puedan reconstruir datos haciendo un uso normal del sistema)
• Purga { depuracion (pueden reconstruirse datos a través de técnicas de laboratorio)
• Disposición del Hardware y Software
• Venta, dar de baja o descarte
• Software
• Se deben efectuar los acuerdos de licencias y las regulaciones
• Hardware

Para necesidad de destruirlo, excepto por algunos medios de alma-cenamiento que contienen
información sensitiva y que no pueden ser saneados sin destruccion Remocion o destruccion f
sica de los medios, de forma tal que el Hardware remanente pueda ser vendido o dado de baja
Algunos sistemas pueden contener información sensitiva des-pues de que el medio sea
removido. Si existe duda de que información sensitiva permanezca en el sistema, El O cial de
Seguridad debe ser consultado antes de disponer del sistema

Conclusiones del Modelo NIST 800-64

Este trabajo fue realizado con el n de veri car la inseguridad de las aplica-ciones de un inadecuado
proceso de desarrollo y poder implementar un modelo SDLC que va a brindar seguridad y bene
ciar los productos y aplicaciones de la organización , si se incluye desde el inicio de las fases de
SDLC, normalmen-te disminuye los costos y brindara una seguridad mas e cliente que adicionarla
cuando esta operativo, las compa~n as que no lo hacen desde un inicio pagan su
precio tanto en lo economico como en la interrupcion del negocio.
MICROSOFT SECURITY DEVELOPMENT LIFE CYCLE

La relevancia de incluir seguridad durante todo el ciclo de vida de desarrollo de software es

equivalente a la de garantizar la calidad, el mayor inconveniente detectado es que actualmente
las organizaciones se preocupan por las vulnera-bilidades hasta tanto el software esta
implementado y en produccion.

Figura 15: Ciclo de Desarrollo de Software

Debido a la constante explotacion de vulnerabilidades y ataques maliciosos a los sistemas

redundando en perdidas de información sensible o con dencial, da~no del buen nombre de las
compa~nias, indispoibilidad de los servicios entre otros, d a a d a las organizaciones le dan mas
importancia la seguridad desde el desarrollo del software garantizando sus funcionalidades
después de la puesta en marcha.

Los costos e impactos que tiene una vulnerabilidad entre mas tarde decteta dentro del SDLC son
mas altos, esto indica que es menos costoso para una or-ganizacion construir software seguro
que solucionar problemas en produccion.

En el articulo de la NASA Error Cost Escalation Through the Project Life Cycle indican que el costo
para corregir errores aumenta a medida que el pro-yecto madura, en el estudio realizado se
detecto que el costo de arreglar un error de requisitos descubierto durante la fase de requisitos
se de ne como 1 unidad, el costo de corregir ese error si se encuentra durante la fase de diseño
aumenta de 3 a 8 unidades; en la fase de fabricacion / construccion, el costo de arreglar el error
es de 7 a 16 unidades; en la fase de integración y prueba, el costo para corregir el error se
convierte en 21 -78 unidades; y en la fase de operaciones, el costo para corregir el error de
requisitos varia de 29 unidades a mas de 1500 unidades.
Figura 16: Costo Relativo de Arreglar un Error

La mejora de la seguridad en los procesos y practicas del ciclo de vida del desarrollo requiere un
cambio en el énfasis de las actividades para que as la seguridad tenga la misma importancia que
otras propiedades deseables como confiabilidad y rendimiento entre otras.

• Requisitos.
• Diseño e implementación.

• Revisión, evaluación y prueba. Se deben generar criterios de seguridad para cada

especificación, diseño y revisión de código, como parte de la evaluación de ingeniera de
software y la selección de componentes ad-quiridos y reutilizados y como parte de la
unidad de software y los planes de prueba de integración. Las revisiones y / o pruebas de
seguridad apro-piadas de la fase del ciclo de vida establecerán si todos los artefactos de
software han satisfecho sus criterios de salida de seguridad al nal de una fase del ciclo de
vida antes de que se permita que el desarrollo pase a la siguiente fase.

• Distribución, despliegue y soporte La distribución ira precedida de una limpieza cuidadosa

del código para eliminar cualquier problema de seguridad residual. La preparación para
la distribución también incluirá

• la documentación de los parámetros de configuración segura que deben establecerse

cuando se instala el software; Estos incluyen parámetros para el software en s y para
cualquier componente de su entorno de ejecución en el que se basar para protegerlo.
Se realizaran evaluaciones continuas, posteriores a la implementación, de vulnerabilidad y
amenaza, y análisis forenses de ataques exitosos para el software y su entorno. Los nuevos
requisitos que se cumplirán en futuras versiones se formularan en función de los resultados de
la evaluación y el análisis.

Seguridad en Análisis y Definición de Requerimientos

Si bien en esta fase se tiene como objetivo traducir las necesidades y expectativas de los
interesados en un conjunto viable de requisitos de software es de vital importancia de unir los
requerimientos de seguridad que cada funcionalidad del sistema vaya a tener.

Estas tareas deben aplicarse selectivamente para especificar los requisitos para cada elemento
de la arquitectura, este conjunto de tareas debe ser aplicado al producto en todas sus fases de
desarrollo.

El análisis de requisitos de software implica un conjunto de análisis y evaluaciones que deben

garantizar asi la con genialidad, integridad y disponibilidad ante ataques maliciosos, para
examinar las necesidades de las partes interesadas y los requisitos de software para comprender
las implicaciones de cada requisito en el alcance del esfuerzo de desarrollo.

Adicionalmente se debe realizar un detallado análisis de requerimientos de se-guridad en el cual

se debe tener en cuenta:

• Definición de la Arquitectura

• Plataforma

• Tipo de Datos que se manejan y niveles de sensibilidad de estos.

• Requerimientos ajustados a especi caciones legales y marco normativo.

• Log de registros del sistema.

• Per les y roles de usuarios.

• Tipos de Accesos incluyendo los tipos de funcionalidades que cada rol debe manejar.

• Métodos de Autenticación.

La revisión de los requisitos funcionales debe incluir una evaluación de vulnerabilidad y riesgo de
seguridad que debe formar la base para capturar el conjunto de requisitos generales de seguridad
no funcionales o disposiciones de seguridad mitigando as los riesgos identificados.
Seguridad en el Diseño

Las suposiciones y elecciones de diseño que determinan como funcionar el software y como
interactuaran los diferentes componentes deben analizarse y ajustarse para minimizar sus
vulnerabilidades y futuros posibles ataques, los errores en el código fuente deben marcarse no
solo cuando dan como resultado una funcionalidad incorrecta, sino también cuando la
funcionalidad correcta puede corromperse por entradas o parámetros de configuración no
deseados e inusuales.

Es importante tener en cuenta los siguientes principios de seguridad en esta fase:

• Reducción de Super cie de ataque.

• Criterio del menor privilegio.

• Criterio de defensa en profundidad.
• Diseño seguro de manejo de errores.

• Diseño seguro de autenticación.

• Separacion de privilegios.

• Interaccion \amigable" con Firewalls e IDS’s.

• Administración segura información Sensible.

• Diseño de Auditor a y Logging.

• Análisis de riesgo.

Dentro de la revisión de la literatura se describen alguna técnica a tener en cuenta en esta etapa
de desarrollo a n de garantizar la seguridad del software:

• Threat Modeling: A n de identificar y priorizar posibles amenazas y sus mitigaciones de

seguridad para proteger el software y sus funcionalidades, realizando un modelado
continuamente es posible ponderar los riesgos a los que esta expuesta la aplicación.
• Conformación de un grupo de seguridad que realice el análisis y plan de mitigación de los
riesgos.
• Descomposición de la aplicación y identificación de los componentes claves susceptibles
a ataques.
• Determinar amenazas de cada componente.
• Asignar ponderaciones que establezcan un valor a las amenazas
• Decidir como mitigar cada amenaza identicando las políticas, técnicas y tecnología as para
mitigar los riesgos.
Método STRIDE: En este modelo, las amenazas se clasi can segun los objetivos y propositos de
los ataques. Por usando estas categor as de ame-nazas, uno tiene la capacidad de crear una
estrategia de seguridad para un particular sistema para tener respuestas plani cadas y
mitigaciones a amenazas o ataques.

STRIDE se basa en la letra inicial de posibles amenazas:

• Spoo ng: Los atacantes ngen ser alguien o algo que no son.
• Tampering: Los atacantes cambian los datos en transito o en un almacen de datos.
• Repudiaton: Los atacantes realizan acciones que no se pueden ras-trear.
• Information disclosure: Los atacantes obtienen acceso a datos en
• transito o en datos tienda a la que no deber an tener acceso.
• Denial of service: Los atacantes interrumpen el funcionamiento nor-mal del sistema
• Elevation of privilege: Los atacantes realizan acciones para las que no estan autorizados
realizar.

Método DREAD: Este modelo actua como un esquema de clasi cacion para cuanti car comparando
y priorizando la cantidad de riesgos presen-tados por cada amenaza que ha sido evaluada. DREAD
es un acrónimo creado por la letra inicial de cada categor a de análisis de riesgos.
Damage potential: clasi ca la extension del da~no que ocurre si una vulnerabilidad es explotada.

Reproducibility : clasi ca con que frecuencia un intento de explotar una vulnerabilidad realmente
funciona.

Exploitability: Asigna un numero al esfuerzo requerido para explotar vulnerabilidad. Esto también
considera las condiciones previas tales como si el usuario debe ser autenticado.

A ected users: Un valor que caracteriza el numero de instancias ins-taladas de sistema que se ver
a afectado si un exploit estuviera am-pliamente disponible.

Discoverability: mide la probabilidad de que, si no se parchea, una vulnerabilidadseran

encontrados por investigadores de seguridad ex-ternos, hackers, etc.

Seguridad en la Codificación

Se deben generar criterios de seguridad para cada especificación, diseño y revisión de código,
como parte de la evaluación de ingeniería de software y la selección de componentes adquiridos
y reutilizados y como parte de la unidad de software y los planes de prueba de integración. Las
revisiones y / o pruebas de seguridad apropiadas de la fase del ciclo de vida establecerán si todos
los artefactos de software han satisfecho sus criterios de salida de seguridad al nal de una fase
del ciclo de vida antes de que se permita que el desarrollo pase a la siguiente fase.
 • Durante esta etapa se deben tener en cuenta los siguientes aspectos para la seguridad en
el software:

• Validar siempre los datos de entrada antes de procesarlos.

• Nunca con ar en que los datos recibidos sean correctos.

• Realizar validación de datos en todas las capas.

• Usar siempre criterio de \White List" en las validaciones.

• Controlar tama~no y tipo de datos.

• Eliminar o \escapear" caracteres especiales.

• Reemplazar sentencias SQL dinámicas por Stored Procedures.

• Evitar generar código con valores ingresados por el usuario.

• No mezclar datos con código.

• Capturar errores de capas inferiores y no mostrarlos al usuario

Pruebas de Seguridad

Esta actividad tiene como objetivo evaluar la calidad de un software a n de mejorarlo, identi cando
defectos y problemas.

Se deben seguir los principios establecidos. A pesar de tener limitaciones, las pruebas de software
siguen dominando otras técnicas de verificación como análisis estático, verificación de modelos,
por lo tanto, es indispensable comprender los objetivos, principios y limitaciones de las pruebas
de software para que la efectividad de estas pueda ser maximizada.
Las pruebas de software también se utilizan para probar software para asegurar factores de como
la confiabilidad, usabilidad, integridad, capacidad entre otras, Las pruebas de software deben
realizarse de manera e cliente y efectivamente, dentro de los l mites presupuestarios y de
programación.

Siguiendo los principios establecidos las pruebas sean mas fáciles y efectivas y asegurarse de que
los objetivos de prueba se alcancen al máximo a pesar de tener ciertas limitaciones.

Algunas pruebas de seguridad son:

1. Test de Seguridad Funcional

2. Test de Seguridad Basado en Riesgo

3. Test de Stress

4. Test de Mutacion de Datos

Seguridad en la Implementación

La distribución ira precedida de una limpieza cuidadosa del código para eliminar cualquier
problema de seguridad residual. La preparación para la dis-tribucion también incluirá la
documentación de los parámetros de con gura-cion segura que deben establecerse cuando se
instala el software; Estos incluyen parámetros para el software en s y para cualquier componente
de su entorno de ejecución en el que se basar para protegerlo en la implementación.

Se adoptaran con guraciones de distribución seguras y mecanismos de distri-bucion con ables.

Se realizaran evaluaciones continuas, posteriores a la imple-mentacion, de vulnerabilidad y
amenaza, y análisis forenses de ataques exitosos para el software y su entorno.

Los nuevos requisitos que se cumplirán en futuras versiones se formularan en función de los
resultados de la evaluación y el análisis.
Ventajas y Desventajas del Modelo SSDLC

Figura 17: Ventajas y Desventajas Modelo SSDLC

Conclusiones del Modelo SSDLC

Es importante destacar que la seguridad debe ser contemplada desde el inicio en todo proyecto
de desarrollo de software esto con el n de de nir los reque-rimientos de seguridad que mitigaran
los riesgos que se pueden presentar al ser implementado en ambientes productivos.

Deben de nirse y documentar en la organización todos los estándares, políticas y practicas a

seguir durante el SDLC, la relevancia que la seguridad de la información debe tener y participar
en todo el ciclo, as como la integración de todo el equipo de desarrollo de software deben ser
capacitados a tiempo sobre las buenas practicas que conlleven a la aplicación a altos estándares
de seguridad en la organización.

Desarrollar software con un nivel aceptable de seguridad implica reducción de esfuerzos técnicos
y monetarios que repercuten en el buen prestigio de la com-pa~n a, as como en la e ciencia
operacional de un proyecto traduciéndose en mayores ganancias futuras.
Recomendación el modelo a implementar al del Grupo Consultor a Z-Software

Teniendo en cuenta que la empresa Z-Software desarrolla e implementa pro-yectos de distintos

tipos entre los cuales destacan proyectos realizados para entidades del estado Colombiano,
consideramos que el modelo que deber a im-plementarse OpenSAMM.

Si bien la publicacion especial (SP) 800-64 del Instituto Nacional de Estandares y Tecnolog a (NIST)
tiene como objetivo ayudar a las agencias del gobierno a integrar las actividades esenciales de
seguridad en la metodolog a del SDLC que tienen establecida, consideramos que OPENSAMM
ayuda formular e implemen-tar una estrategia para la seguridad del software adaptables a cada
proyecto.
Lo anterior debido a que gracias a SAMM se puede:

• Evaluar las practicas de seguridad de software existentes.

• Construir un programa de garantiza de seguridad de software equilibrado en iteraciones

bien definidas

• Demostrar mejoras concretas a un programa de garant a de seguridad

• Definir y medir actividades relacionadas con la seguridad en una organi-zacion

Gracias a su estructura SAMM es exilé en su implementación y acople a distintos proyecto y

modelos de negocio sin importar su tama~no y utilizando cualquier estilo de desarrollo. Además,
este modelo se puede aplicar de forma holistica y transversal en todo el proyecto o bien sea
dentro de una organización, asi mismo no tiene restricciones en ser aplicado para una sola l nea
de negocio, o incluso para un proyecto individual.

Mas all de estos rasgosEsta describe las funciones y responsabilidades cla-ve de seguridad que
se necesitan en el desarrollo de la mayor a de los siste-mas de información identi cando
consideraciones de seguridad para cada fase (iniciacion/análisis, adquisición/diseño,
implementación/evaluación, operación/mantenimiento, disposición) del SDLC bajo los siguientes
parámetros:

La base del modelo se basa en las funciones centrales del desarrollo de software con practicas
de seguridad vinculadas a cada una donde los componentes basicos del modelo son los tres
niveles de madurez de nidos para cada una de las doce practicas de seguridad.

Esto permite de nir una amplia gama de actividades en que una organización podr a contratar
para reducir los riesgos de seguridad y aumentar la garant a del software.
Adicional se incluyen detalles para medir el desempe~no exitoso de la activi-dad, comprender la
garant a asociada bene cios, estimar personal y otros costos.

Por ultimo y no menos importante OpenSAMM es un proyecto abierto, el conte-nido de SAMM

siempre esta disponible gratuitamente para que todos lo utilicen.

Adicional a asegurar la seguridad encontramos en SAMM el modelo ideal de mejora continua ya

que su objetivo es evaluar el estado actual de la madurez de la organización al realizar actividades
de seguridad de software dentro del SDLC y derivar una hoja de ruta para que la organización
pueda seguir para mejorar sus capacidades en seguridad de software, as mismo estas actividades
pueden ser almacenadas y aplicadas a distintos proyectos heredando los aprendizajes, practicas
y experiencias.
REFERENCIAS

[1] Goertzel, K.M.,Security in the Software Life Cycle: Making Application Development
Processes { and Software Produced by Them { More Secure, [Online],
https://buildsecurityin.us-cert.gov

[2] Error Cost Escalation Through the Project Life Cycle, [Online], https://
ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20100036670.pdf

[3] National Institute of Standards and Technology. Guideline on Network Se-curity

Testing. Special Publication 800-42., [Online], http://csrc.nist.
gov/publications/nistpubs/800-42/NIST-SP800-42.pdf

[4] El ciclo SDLC en 7 fases, [Online], https://www.viewnext.com/ el-ciclo-sdlc-en-7-

fases/

[5] State-of-the-Art Report (SOAR) Software Security Assurance, [Online],

https://apps.dtic.mil/dtic/tr/fulltext/u2/a472363.pdf

[6] P. Milano.Seguridad en el ciclo de vida del desarrollo de softwa-re , [Online],

http://www.cybsec.com/upload/cybsec_Tendencias2007_ Seguridad_SDLC.pdf

[7] OWASP. (s.f.).OWASP Top 10, [Online], https://wiki.owasp.org/

images/5/5e/OWASP-Top-10-2017-es.pdf

[8] M arulanda Aguirre, M.FAplicaci+on de la Metodología a OWASP, [Online],

https://stadium.unad.edu.co/preview/UNAD.php?url=/bitstream/
10596/20479/3/1060648494.pdf

[9] S.P Kadhirvelan, A.Soderberg-RivkinThreat Modelling and Risk As-sessmentx,

[Online], http://publications.lib.chalmers.se/records/ fulltext/202917/202917.pdf

[10] E.J Robles Gomez,Ciclo de Vida de Desarrollo de Software Seguro en Me-

todolog as Agiles , [Online], https://cimat.repositorioinstitucional.

mx/jspui/bitstream/1008/411/1/ZACTE14.pdf

[11] Seguridad en SDLC, [Online], http://www.informatica-juridica.com/ wp-

content/uploads/2018/05/Ciber-Seguridad-en-SDLC_Medios.pdf

[12] C erullo.P, Modelo de Maduracion de Aseguramiento de Software, [On-line],

https://owasp.org/www-pdf-archive/05_OWASP_LatamTur2011_ OpenSAMM.pdf
[13] OWASP, The Open Web Application Security Project., [On-
line], https://docs.google.com/viewerng/viewer?url=http:

//www.opensamm.org/downloads/SAMM-1.0-es_MX.pdf

[14] Seguridad en el Desarrollo SW, [Online], http://acistente.acis.org.

co/typo43/fileadmin/Base_de_Conocimiento/VI_JornadaSeguridad/
FernandoFerrer_VIJNSI.pdf

[15] >Como utilizar la serie SP 800 de la norma ISO

27001?, [Online], https://www.pmg-ssi.com/2016/05/

como-utilizar-serie-sp-800-norma-iso-27001/

[16] Withdrawal of SP 800-64 Rev. 2, Security Considerations in the System Development

Life Cycle, [Online], https://csrc.nist.gov/News/2019/ Withdrawal-of-SP-800-64-Rev-2

[17
] Withdrawn NIST Technical Series Publication, [Onli-
ne], https://nvlpubs.nist.gov/nistpubs/Legacy/SP/
nistspecialpublication800-64r2.pdf
[18
] SDCL, [Online], https://brion25.blogspot.com/2013/05/
sdlc-software-development-life-cycle.html