Modelo de Segurança em Desenvolvimento de Software

Vista previa del material en texto

UNIVERSIDAD MAYOR DE SAN ANDRÉS 
FACULTAD DE CIENCIAS PURAS Y NATURALES 
CARRERA DE INFORMÁTICA 
POSTGRADO EN INFORMÁTICA 
 
 
 
TESIS MAGISTER SCIENTIARUM 
 
PROGRAMA DE MAESTRÍA EN INFORMÁTICA FORENSE, 
SEGURIDAD DE LA INFORMACIÓN Y AUDITORÍA 
INFORMÁTICA (MAE-FORSAI) VERSIÓN 1 GESTIÓN 2017 – 2018 
 
 
MODELO DE SEGURIDAD PARA EL DESARROLLO DE 
SOFTWARE 
 
POR: Lic. Maribel Pachacuti Blanco 
TUTOR: M.Sc. Edson Vallejos Pacheco 
 
 
LA PAZ – BOLIVIA 
2020 
i 
 
 
 
 
 
 
 
 
 
 
 
 
DEDICATORIA 
 
 
 
 
 
 
 
A las personas que me apoyaron en todo momento 
y apoyaron incondicionalmente, en especial a mis 
padres que me dan fortaleza para seguir adelante. 
ii 
 
 
 
 
 
 
 
AGRADECIMIENTOS 
Deseo expresar mi más sincero agradecimiento a las personas que me apoyaron para poder 
cumplir este objetivo. 
A mi familia, quienes me apoyan con cariño, confianza y comprensión a lo largo de toda 
mi vida. 
Agradezco al Postgrado de Informática de la Universidad Mayor de San Andrés por 
acogerme en todo el tiempo que me tomo lograr esta meta. A los docentes de la maestría 
por haberme brindado sus conocimientos e impartido sus valiosas experiencias. 
Agradecer a mi tutor M.Sc. Edson Vallejos Pacheco por sus consejos, conocimientos, 
apoyo y asesoramiento en el desarrollo de este trabajo. 
A la Dirección General de Migración por darme la oportunidad de aplicar el presente 
modelo en sus proyectos de desarrollo, especialmente al ingeniero German Vidaurre Paz 
responsable de desarrollo y al ingeniero Roger Efraín Martínez Gonzales encargado de 
soporte, redes y telecomunicaciones por el apoyo y la confianza en mi persona. 
Agradecer a mi compañero de maestría Edson Machicado y al docente Diego Hinojosa 
por sus consejos, conocimiento y sugerencias. 
 
iii 
 
RESÚMEN 
El presente trabajo tuvo como objetivo general el diseño de un modelo de seguridad para 
el desarrollo de software con el propósito de reducir el riesgo en el software desarrollado 
en la institución pública dirección general de migración de la ciudad de La Paz. Este 
modelo está basado en normas, guías o estándares nacionales e internacionales. Se realizó 
un diseño experimental donde se seleccionó como muestra proyectos de desarrollo de 
software de la entidad pública Dirección General de Migración, donde se realizó una 
evaluación del proceso de desarrollo y prácticas de seguridad en el desarrollo de software. 
Para ello se realizó una entrevista con los encargados del área de desarrollo, 
posteriormente se seleccionó dos productos críticos de la institución para realizar una 
evaluación de vulnerabilidades. Los resultados evidencian que existe una reducción de 
riesgos en el software de acuerdo a los resultados obtenidos en primera instancia y 
posterior a la aplicación del presente modelo de desarrollo seguro. Por tanto, se puede 
concluir que la utilización de un modelo de seguridad para el desarrollo de software reduce 
el riesgo en el software. 
 
 
 
 
 
 
 
 
 
iv 
 
ÍNDICE 
INTRODUCCIÓN ............................................................................................................. 1 
CAPÍTULO I ..................................................................................................................... 3 
MARCO DEL PROBLEMA ............................................................................................. 3 
1.1 PLANTEAMIENTO DEL PROBLEMA DE INVESTIGACIÓN ..................... 3 
1.1.1 Antecedentes del Problema de Investigación .............................................. 3 
1.1.2 Identificación del Problema ......................................................................... 8 
1.2. FORMULACIÓN DEL PROBLEMA DE INVESTIGACIÓN ......................... 8 
1.3. PLANTEAMIENTO DE OBJETIVO................................................................. 9 
1.3.1 Objetivo General .......................................................................................... 9 
1.3.2 Objetivos Específicos .................................................................................. 9 
1.4 PLANTEAMIENTO DE HIPÓTESIS ................................................................ 9 
1.4.1 Variable Dependiente .................................................................................. 9 
1.4.2 Variable Independiente ................................................................................ 9 
1.4.3 Operacionalización de Variables ............................................................... 10 
CAPÍTULO II .................................................................................................................. 12 
MARCO TEÓRICO ........................................................................................................ 12 
2.1 ESTADO DEL ARTE ...................................................................................... 12 
2.2 REFERENCIA TEÓRICA O CONCEPTUAL ................................................ 14 
2.2.1 Desarrollo de software .................................................................................... 14 
2.2.2 Riesgo de seguridad ........................................................................................ 18 
2.2.3 Control de calidad de software ....................................................................... 21 
2.2.4 Seguridad de software ..................................................................................... 21 
2.2.5 Pruebas de seguridad ...................................................................................... 21 
v 
 
2.2.6 Security DevOps ............................................................................................. 22 
2.3 MARCO LEGAL E INSTITUCIONAL ........................................................... 26 
2.3.1 Lineamientos para la elaboración e implementación de los Planes 
Institucionales de Seguridad de la Información de las entidades del sector público26 
2.3.2 Decreto supremo Nº1793 ................................................................................ 26 
2.3.3 Ley Nº164, ley general de telecomunicaciones, tecnologías de información y 
comunicación ........................................................................................................... 27 
CAPÍTULO III ................................................................................................................. 29 
METODOLOGÍA DE LA INVESTIGACIÓN ............................................................... 29 
3.1 DISEÑO METODOLóGICO ................................................................................ 29 
3.1.1 Tipo de investigación ................................................................................. 29 
3.2 MÉTODO DE INVESTIGACIÓN ................................................................... 30 
3.2.1 Fases Metodológicos .................................................................................. 30 
3.2.2 Técnicas de investigación ............................................................................... 31 
3.3 UNIVERSO O POBLACIÓN DE REFERENCIA ........................................... 31 
3.3.1 Población ........................................................................................................ 31 
3.3.2 Muestra ...................................................................................................... 31 
3.4 DELIMITACIÓN .................................................................................................. 32 
3.4.1 Delimitación Geográfica ............................................................................ 32 
3.4.2 Delimitación Temporal .............................................................................. 32 
CAPITULO IV ................................................................................................................ 33 
MARCO PRÁCTICO ......................................................................................................33 
4.1 DESCRIPCIÓN Y PROCESAMIENTO DE DATOS RECOPILADOS. ............ 34 
4.2 ANÁLISIS Y DISEÑO DEL MODELO ............................................................... 35 
4.2.1 Análisis del contexto ....................................................................................... 35 
vi 
 
4.2.2 Cálculo del nivel de madurez .......................................................................... 39 
4.2.3 Personal ........................................................................................................... 41 
4.3 DESARROLLO DEL MODELO .......................................................................... 42 
4.4 ARQUITECTURA DEL MODELO ..................................................................... 44 
4.4.1 Fase 1: Planeación .......................................................................................... 44 
4.4.2 Fase 2: Diseño ................................................................................................. 46 
4.4.3 Fase 3: Desarrollo ........................................................................................... 53 
4.4.4 Fase 4: Pruebas ............................................................................................... 55 
4.4.5 Fase 5: Despliegue .......................................................................................... 56 
4.4.6 Fase 6: Mantenimiento .................................................................................... 58 
4.4.7 Desarrollo de software seguro según SAMM ................................................. 59 
4.4.8 Pruebas de seguridad según el ISTQB ............................................................ 60 
4.4.9 Análisis de Riesgo .......................................................................................... 67 
4.4.10 DevSecOps .................................................................................................... 69 
4.5 APLICACIÓN DEL MODELO ............................................................................ 74 
4.5.1 Fase 1: Planificación ....................................................................................... 75 
4.5.2 Fase 2: Diseño ................................................................................................. 77 
4.5.3 Fase 3: Desarrollo ........................................................................................... 84 
4.5.4 Fase 4: Pruebas ............................................................................................... 88 
4.5.5 Fase 5: Despliegue .......................................................................................... 92 
4.5.6 Fase 6: Mantenimiento .................................................................................... 94 
4.6 VALIDACIÓN DE RESULTADOS ..................................................................... 96 
4.6.1 Estado de objetivos ......................................................................................... 96 
4.6.2 Interpretación de resultados ............................................................................ 97 
vii 
 
4.6.3 Estado de Hipótesis ....................................................................................... 102 
CAPITULO V ................................................................................................................ 103 
CONCLUSIONES Y RECOMENDACIONES ............................................................ 103 
5.1. CONCLUSIONES .............................................................................................. 103 
5.2 RECOMENDACIONES ...................................................................................... 104 
GLOSARIO ................................................................................................................... 106 
BIBLIOGRAFIA ........................................................................................................... 109 
APÉNDICE A: EVALUACION DE PRACTICAS DE SEGURIDAD SEGÚN 
SAMM ........................................................................................................................... 112 
APÉNDICE B: EVALUACION DEL PISI ................................................................... 117 
APÉNDICE C: INVENTARIO DE ACTIVOS – DIGEMIG ....................................... 120 
APÉNDICE D: INFORME DE CONTROL DE CALIDAD DE SOFTWARE Y 
PRUEBAS DE SEGURIDAD ....................................................................................... 124 
APÉNDICE E: ESCENARIOS DE PRUEBAS – SICOF v2.2.1 .................................. 133 
APÉNDICE F: BUGS REPORTADOS - SICOF v2.2.1 ............................................... 138 
APÉNDICE G: ESCENARIOS DE PRUEBAS - SIOS v7.3.4 ..................................... 140 
APÉNDICE H: BUGS REPORTADOS – SIOS v7.3.4 ................................................ 149 
APÉNDICE I: BUGS FIXED – SIOS v7.3.5 ................................................................ 154 
APÉNDICE J: INFORME DE PRUEBAS DE SEGURIDAD DE SOFTWARE ....... 155 
APÉNDICE K: PROPUESTA DE POLITICAS PARA EL AREA DE 
DESARROLLO ............................................................................................................. 165 
APÉNDICE L: ESTRUCTURA DE TEST CASE ........................................................ 181 
APÉNDICE M: ESTRUCTURA DE BUG ................................................................... 182 
APÉNDICE N: ESTRUCTURA DE TEST PLAN ....................................................... 183 
viii 
 
APÉNDICE O: ENCUESTA ESTADO DE LA SEGURIDAD EN EL PROCESO DE 
DESARROLLO DE SOFTWARE EN BOLIVIA ........................................................ 184 
APÉNDICE P: ANÁLISIS EN EL CONTEXTO BOLIVIANO .................................. 204 
APÉNDICE Q: ANALISIS DEL LA ACEPTACION DEL MODELO ....................... 210 
APÉNDICE R: VALIDEZ DE CONTENIDO .............................................................. 214 
ANEXO A: PRACTICAS DE SEGURIDAD SEGUN SAMM ................................... 216 
ANEXO B: PROCESO DE PRUEBAS DE SEGURIDAD – ISTQB .......................... 220 
ANEXO C: CAPACITACIONES ................................................................................. 223 
ANEXO D: TABLERO SCRUM DEL SISTEMA DE CORRESPONDENCIA ......... 226 
ANEXO E: TABLERO DE BUGS Y VULNERABILIDADES DE SICOF V2.2.1 .... 227 
ANEXO F: TABLERO DE BUGS Y VULNERABIIDADES DE SIOS V7.3.4 ......... 228 
ANEXO G: AVAL DE CONFORMIDAD DE LA DIRECCION GENERAL DE 
MIGRACION ................................................................................................................ 229 
 
 
 
 
 
 
 
 
 
 
ix 
 
ÍNDICE DE TABLAS 
Tabla 1. Operacionalización de la variable dependiente ................................................. 10 
Tabla 2. Operacionalización de la variable independiente .............................................. 10 
Tabla 3. Fases Metodológicos ......................................................................................... 30 
Tabla 4. Tabla de fortaleza de modelos para el desarrollo de software ........................... 34 
Tabla 5. Niveles de madures según el SAMM ................................................................ 39 
Tabla 6. Evaluación del nivel de madurez a la Dirección General de Migración ........... 40 
Tabla 7. Propuesta de modelo de seguridad para el desarrollo de software .................... 42 
Tabla 8. Fase de planificación para la Dirección General de Migración ......................... 75 
Tabla 9. Proceso de planeación de software seguro ........................................................ 77 
Tabla 10. proceso de planeación de pruebas de seguridad .............................................. 77 
Tabla 11. Fase de Diseño para la Dirección General de Migración ................................ 78 
Tabla 12. Proceso de diseño de software seguro ............................................................. 79 
Tabla13. Proceso de diseño de pruebas de seguridad ..................................................... 80 
Tabla 14. Fase de desarrollo para la Dirección General de Migración ............................ 85 
Tabla 15. Proceso desarrollo seguro ................................................................................ 86 
Tabla 16. Fase de pruebas para la Dirección General de Migración ............................... 89 
Tabla 17. Proceso ejecución de pruebas de seguridad ..................................................... 90 
Tabla 18. Fase de despliegue para la Dirección General de Migración .......................... 93 
Tabla 19 Fase de mantenimiento para la Dirección General de Migración ..................... 95 
Tabla 20. Comparación del nivel de madurez de la dirección general de migración ...... 98 
Tabla 21. Días en la resolución de bugs y vulnerabilidades .......................................... 101 
 
 
 
 
 
x 
 
 
ÍNDICE DE FIGURAS 
Figura 1. OWASP top 10 2017 .......................................................................................... 5 
Figura 2. Defectos no cubiertos por el top 10 de OWASP ................................................ 6 
Figura 3. Modelo SDLC en cascada ................................................................................ 16 
Figura 4. Modelo SDLC iterativo .................................................................................... 16 
Figura 5. Modelo SDLC espiral ....................................................................................... 17 
Figura 6. Modelo en forma de V ...................................................................................... 18 
Figura 7. Modelo SDLC ágil ........................................................................................... 18 
Figura 8. Fases de DevOps .............................................................................................. 23 
Figura 9. Propuesta de modelo de seguridad para el desarrollo de software ................... 33 
Figura 10. Sistema de control de flujo migratorio SICOF v2.2.1 .................................... 36 
Figura 11. Sistema de inspectoría SIOS v.7.3.4 .............................................................. 37 
Figura 12. Modelo de seguridad para el desarrollo de software ...................................... 44 
Figura 13. Desarrollo de software según SAMM ............................................................ 59 
Figura 14. Proceso de pruebas de seguridad según el ISTQB ......................................... 62 
Figura 15. Análisis de riesgo en el ciclo de vida del desarrollo de software ................... 67 
Figura 16. Enfoque tradicional y enfoque DevOps ......................................................... 69 
Figura 17. Proceso DevOps ............................................................................................. 70 
Figura 18. Seguridad en DevOps ..................................................................................... 72 
Figura 19. Propuesta de ciclo de vida de desarrollo de software para DIGEMIG .......... 74 
Figura 20. Historia de usuario para el ingreso al sistema ................................................ 81 
Figura 21. Resultados iniciales del nivel de confianza para SICOF v2.2.1 ..................... 99 
Figura 22. Resultados del nivel de confianza para SICOF v2.2.5 ................................... 99 
Figura 23. Resultado inicial del nivel de confianza para SIOS v7.3.4 .......................... 100 
Figura 24. Resultado del nivel de confianza para SIOS v7.4.2 ..................................... 100 
 
 
1 
 
INTRODUCCIÓN 
En los últimos años se ha producido un gran crecimiento en la producción de software. 
Las empresas hoy en día, con el fin de automatizar sus procesos manuales, requieren el 
desarrollo de sistemas personalizados para la optimización de tiempo y recursos. Sin 
embargo, pese a la evolución y al crecimiento de la industria del software que permiten la 
transformación digital de muchas organizaciones, surgen nuevas necesidades como la 
seguridad del software. Por ello, tras el crecimiento de ataque cibernéticos a sistemas 
informáticos o software se ve la necesidad de adoptar estrategias de seguridad en las fases 
del ciclo de vida de desarrollo de software. 
Debido a los múltiples ataques cibernéticos en los últimos tiempos, las empresas dan 
mayor énfasis a la protección de sus activos de información. La información es un activo 
critico cuya exposición o alteración podría perjudicar a la organización. Por ese motivo 
las organizaciones requieren o solicitan servicios de pentesting para la evaluación de la 
capacidad del software en situaciones de ataque de vulnerabilidades. Dichos servicios en 
muchos de los casos son realizados cuando el software está en producción, en el peor de 
los casos después de un incidente de seguridad. Es allí, donde surge la importancia de 
adoptar estrategias de seguridad en el proceso de desarrollo de software para preservar la 
integridad, confiabilidad y disponibilidad de la información. 
La seguridad debe estar considerada en todas las etapas del ciclo de vida de desarrollo de 
software. Las etapas del ciclo de vida del desarrollo de software tienen distintas 
actividades que permiten la construcción de un software. Usualmente las etapas básicas 
de un ciclo de vida de desarrollo de software son: planeación, diseño, desarrollo, pruebas 
y mantenimiento, estas fases varían de acuerdo a la metodología de desarrollo, pero el 
objetivo de cada fase permanece. Por otro lado, las organizaciones en su mayoría, realiza 
una evaluación de la seguridad del software en la última fase del ciclo de desarrollo de 
software, siendo una mala práctica ya que si se identifica vulnerabilidades críticas y altas 
el equipo de desarrollo debe solucionar dichos problemas lo que demora tiempo y tiene 
un costo de desarrollo. Por esta razón, es importante que el software sea evaluado 
2 
 
constantemente y desde etapas tempranas en el ciclo de vida de desarrollo de software, así 
mismo, el personal encargado de las pruebas de seguridad debe contemplar nuevas 
técnicas de detección de vulnerabilidades continuamente. Estas técnicas de detección de 
vulnerabilidades no solo deben basarse en herramientas comerciales, o limitarse al top 10 
de OWASP web o los 25 errores más comunes que SANS presenta sino también deben 
ser manuales y nuevas, ya que existen vulnerabilidades que no están dentro de los riesgos 
más comunes. 
Las pruebas de seguridad también muestran que se ha realizado la diligencia debida en la 
protección de los activos digitales. Las pruebas de seguridad pueden ser una garantía para 
los clientes pues refleja que una organización toma las medidas adecuadas para proteger 
la información confidencial. 
Gran porcentaje de las amenazas de seguridad o vulnerabilidades de software derivan de 
malas prácticas de desarrollo o errores que se pudieron haber anticipado. Es necesario la 
detección temprana de posibles amenazas porque la explotación de las mismas podría 
perjudicar a la empresa y sus funciones. Por esta razón la seguridad debe ser un factor 
importante desde la primera fase del desarrollo de software. 
Por tanto, el presente trabajo presenta un modelo de desarrollo de software basado en 
normativas, estándares guías y buenas prácticas. Propone actividades para integrar 
prácticas de seguridad en cada una de las etapas del desarrollo de software con el objetivo 
de reducir el riesgo. 
 
 
 
 
 
3 
 
CAPÍTULO I 
MARCO DEL PROBLEMA 
1.1 PLANTEAMIENTO DEL PROBLEMA DE INVESTIGACIÓN 
1.1.1 Antecedentes del Problema de Investigación 
Las empresas en la actualidad están estrechamente vinculadas a la tecnología, sin 
embargo, el mismo hecho de incorporar soluciones informáticas conlleva riesgos en cada 
una de las aplicaciones tecnológicas comprometiendo de gran manera la integridad,confiabilidad y disponibilidad de la información, que es el activo más importante de toda 
empresa. Según un informe de la plataforma de seguridad de aplicaciones Veracode, en 
cuanto a la seguridad del software destaco que el 77% de las aplicaciones tiene al menos 
una vulnerabilidad, lo cual marca un dato alarmante e indica que el software no es testeado 
previo al pase a producción. Muchos de los defectos en el software pasan a ser 
vulnerabilidades que se suelen introducirse durante el proceso de desarrollo. (Micro 
Focus, 2018) 
Para lograr un software seguro es importante adoptar prácticas de seguridad en cada una 
de las etapas del ciclo de vida de desarrollo de software. Algunas empresas optan por 
probar la seguridad del software en la última fase previo a la entrega, sin embargo, se ha 
visto que existe buenos resultados cuando se integra seguridad en todo el ciclo de vida de 
desarrollo del software. Las pruebas de seguridad continuas y paralelas al control de 
calidad, desde etapas tempranas en las aplicaciones garantiza un producto más seguro y 
de calidad. 
El control de calidad implica pruebas específicas para la evaluación de calidad de un 
software. Las pruebas que realiza el personal de control de calidad son: pruebas 
funcionales, pruebas de integración, pruebas de regresión, pruebas smock, pruebas de 
rendimientos, estos a su vez pueden ser a nivel de caja blanca o caja negra. El personal de 
control de calidad tiene la tarea también de gestionar el plan de pruebas y errores 
4 
 
encontrados. La seguridad, por otro lado, se preocupa por hallar vulnerabilidades o 
debilidades en el software que podrían conducir a un uso incorrecto o una explotación. 
En Bolivia, muchas empresas públicas no cuentan con personal para el control de calidad. 
Las empresas públicas en su mayoría, no tienen el área de control de calidad, los 
desarrolladores son los que realizan pruebas al software. Dichas pruebas no son 
gestionadas ni documentadas, son pruebas internas que cada desarrollador hace antes del 
despliegue. En los últimos años, el control de calidad ha tomado mayor importancia. Las 
empresas de desarrollo, con el propósito de ofrecer un producto de calidad, están 
adoptaron métricas, estándares y protocolos para garantizar la calidad, sin embargo, hoy 
en día a la necesidad de calidad se suma la seguridad de software. 
Con los frecuentes ataques cibernéticos a sistemas informáticos, el trabajo del profesional 
de control de calidad de software se ha vuelto más difícil. El trabajo del personal de control 
de calidad, como su nombre lo dice, realiza y gestiona pruebas específicas para garantizar 
la calidad de un producto. No obstante, hoy en día se espera que el profesional de control 
de calidad de software también realice pruebas de seguridad en la aplicación. 
Si bien es cierto, que la calidad del software está fuertemente ligada a la seguridad de una 
aplicación, las pruebas con un enfoque específico en la detección de vulnerabilidades de 
seguridad requieren conocimientos, herramientas y procedimientos especiales. Incluso si 
una aplicación pasa las pruebas funcionales y cumple con ciertos estándares de software, 
el software aún puede ser vulnerable a los ataques cibernéticos a nivel operacional. Por 
esta razón, se recomienda que exista un encargado de las pruebas de seguridad que 
gestione su propio plan de pruebas y vulnerabilidades, ya que el personal de control de 
calidad tiene otros objetivos. 
Por otro lado, la organización Open Web Application Security Project (OWASP), realiza 
la evaluación y publicación de los 10 riesgos más comunes en aplicaciones web, API y 
aplicativos móviles. En la Figura 1, se observa los 10 riesgos de seguridad en aplicaciones 
web más críticos entre el año 2013 al año 2017. Se puede observar que pese al tiempo 
algunos riesgos permanecen dentro del top 10, es decir siguen ocurriendo, esto se debe a 
5 
 
que los desarrolladores desconocen estos riesgos, no reciben la capacitación en 
ciberseguridad y desarrollo seguro. Es necesario realizar mínimamente una evaluación a 
estos 10 riesgos comunes antes del pase a producción. OWASP facilita una 
documentación completa acerca estos riesgos, también propone formas de evaluar y de 
solucionar dichas vulnerabilidades. 
Figura 1. OWASP top 10 2017 
Fuente: https://www.owasp.org/ 
 
 
El equipo de Software Security Research en Micro Focus Fortify ha publicado su informe 
anual sobre el estado de la seguridad de la aplicación. Se dice que 1 de cada 2 aplicaciones 
tiene vulnerabilidades críticas o altas que no están cubiertas por el OWASP top 10 2017. 
Muchos profesionales en seguridad realizan sus pruebas de seguridad basado en un 
software para la detección de vulnerabilidades. Existe muchas herramientas para la 
detección de vulnerabilidades, incluso algunas realizan el escaneo de los diez riesgos 
frecuentes que presenta OWASP como OWASP ZAP. Sin embargo, es necesario realizar 
pruebas manuales para mayor cobertura de pruebas, ya que existen muchas 
vulnerabilidades fuera de los diez que presenta OWASP. Al igual de OWASP existen 
otras organizaciones que también ayudan con la exposición de riesgos comunes como 
SANS pero no debe ser un factor limitante, sino una base de las pruebas que se tiene que 
hacer al software y siempre estar al pendiente de las nuevas vulnerabilidades que 
constantemente van apareciendo. 
6 
 
En la figura 2 se observa que un 90% de las aplicaciones tienen al menos un problema 
fuera de los 10 principales de OWASP, también se ve que el 49% de las aplicaciones 
probadas contenían una vulnerabilidad crítica o de alta severidad que no está cubierta por 
OWASP. Aunque cabe mencionar que OWASP se actualiza constantemente, existe 
vulnerabilidades fuera de su top 10 de riesgos de seguridad más críticos. 
Figura 2. Defectos no cubiertos por el top 10 de OWASP 
Fuente: Micro Focus Fortify Software Security Research Team 
 
Existen modelos de desarrollo de software seguro como por ejemplo modelo de madurez 
para el aseguramiento del software (SAMM) creado por OWASP y el ciclo de vida del 
desarrollo de la seguridad (SDL) creado por Microsoft, que son una buena guía para 
integrar aspectos de seguridad en el ciclo de vida de desarrollo de software. Sin embargo, 
pocas empresas toman en cuenta estas guías en el proceso de desarrollo. 
De acuerdo con la International Software Testing Qualifications Board (ISTQB), las 
pruebas de rendimiento, usabilidad y seguridad son las tres principales actividades de 
prueba no funcionales con prioridades altas. Las pruebas de seguridad se realizan en un 
38% por las empresas. También menciona que solo el 11% de los profesionales en control 
de calidad tienen trayectoria en pruebas de seguridad. En los próximos 5 años, según la 
ISTQB, en los temas de mayor importancia en la industria en control de calidad de 
software está la seguridad con un porcentaje de importancia de 52%. 
A nivel nacional, no se cuenta con una guía para el desarrollo de software seguro. Sin 
embargo, la agencia de gobierno electrónico y tecnologías de información y comunicación 
(AGETIC) desde su sitio web provee al público estándares y lineamientos para la 
7 
 
publicación de sitios web donde se habla de la seguridad que los servicios web deben tener 
de manera general, también menciona las vulnerabilidades comunes que mínimamente se 
debe considerar. 
El consejo para las tecnologías de información y comunicación del estado plurinacional 
de Bolivia (CTIC) conformo un grupo de desarrollo de software, el cual trabaja en la 
adopción y desarrollo de estándares oficiales, integración de buenas prácticas y proponen 
ciertos lineamientos vinculadas al desarrollo de software en las entidades públicas. Dentro 
de la documentación que CTIC proporciona podemos encontrar el “Plan de 
implementación de software libre y estándares abiertos 2017 - 2025”. En dichoplan, se 
puede observar algunas referencias al desarrollo de software, ciclo de vida del software y 
seguridad informática de manera general sin especificar los requisitos en cada etapa del 
ciclo de vida del desarrollo del software. Este plan establece condiciones para el desarrollo 
de software libre y estándares abiertos en las entidades públicas, como también 
promocionar su desarrollo en la sociedad civil. 
Así mismo, dentro los lineamientos para la elaboración e implementación de los planes 
institucionales de seguridad de la información de las entidades del sector público, 
desarrollado por el CTIC, en los controles de seguridad de la información se exige 
establecer requisitos de seguridad para el proceso de desarrollo, mantenimiento y 
adquisición de sistemas que contemplen pruebas de seguridad, pruebas de calidad y 
pruebas de aceptación para desarrollo de software interno y externo. En el desarrollo de 
este control de seguridad, se menciona diferentes directrices, objetivos donde se refleja la 
necesidad de establecer seguridad desde el diseño, desarrollo, pruebas y mantenimiento 
del software. La creación de un modelo de desarrollo de software seguro en base a estos 
requerimientos es de gran necesidad para muchas instituciones públicas. 
Cuando el software está en producción, es decir, cuando ha sido desplegado a los usuarios 
finales es donde se halla más vulnerabilidades al ser expuesto a amenazas externas. La 
vulnerabilidad del software pone en riesgo la información del cliente. Las empresas de 
desarrollo que no realizan pruebas de seguridad, son sometidas a auditorias por lado del 
8 
 
cliente para detectar las vulnerabilidades y encontrar las fallas del software comprometido, 
cabe mencionar que mientras no se detecta la falla de seguridad los costos de migración y 
daños potenciales se incrementa. 
1.1.2 Identificación del Problema 
Debido a la demanda del desarrollo de software, en los últimos años, se ha visto necesario 
integrar seguridad en el ciclo de vida del software. El proceso de desarrollo de muchas 
empresas no contempla la seguridad de la información en sus distintas etapas. El control 
de calidad de software en su mayoría, solo incluye pruebas funcionales y de rendimiento 
dejando de lado la seguridad del software. Dicho proceso de control de calidad solo 
garantiza la funcionalidad, usabilidad, portabilidad, eficiencia, mantenibilidad y 
confiabilidad, sin tomar en cuenta las pruebas de seguridad. 
La explotación de vulnerabilidades de software en producción cada vez es más frecuente. 
En los últimos años, muchos sistemas informáticos han sido vulnerados comprometiendo 
la integridad, confidencialidad y disponibilidad de la información de dichos sistemas, 
provocando pérdidas considerables a las empresas, fuga de información y por último el 
costo de desarrollo para mejorar la seguridad del sistema. 
La necesidad de un producto o software seguro cada vez toma más importancia. De hecho, 
los lineamientos para la elaboración e implementación de los planes institucionales de 
seguridad de la información de las entidades del sector público hacen referencia, en varias 
de sus directrices, a la necesidad de incorporar la seguridad en el desarrollo de software. 
1.2. FORMULACIÓN DEL PROBLEMA DE INVESTIGACIÓN 
No considerar prácticas de seguridad en las distintas etapas en el desarrollo de software y 
los crecientes ataques cibernéticos a los diferentes sistemas informáticos lleva a la 
siguiente pregunta: 
¿Cómo reducir los riesgos en el software desarrollado en la institución pública 
dirección general de migración de la ciudad de La Paz? 
9 
 
1.3. PLANTEAMIENTO DE OBJETIVO 
1.3.1 Objetivo General 
Diseñar un modelo de seguridad para el desarrollo de software con el propósito de 
reducir los riesgos en el software desarrollado en la institución pública dirección general 
de migración de la ciudad de La Paz. 
1.3.2 Objetivos Específicos 
• Realizar un análisis de vulnerabilidades a sistemas en producción previo a la 
implementación del modelo de desarrollo de software seguro. 
• Evaluar las prácticas de seguridad en el proceso de desarrollo de software de 
acuerdo al cumplimiento de normativas nacionales. 
• Definir actividades relacionadas con la seguridad en cada etapa del ciclo de 
vida de desarrollo de software. 
• Validar la contribución de un modelo de desarrollo de software 
implementando estrategias de seguridad en la detección temprana de 
vulnerabilidades. 
1.4 PLANTEAMIENTO DE HIPÓTESIS 
El diseño de un modelo de seguridad en el desarrollo de software permite reducir los 
riesgos en el software desarrollado en la institución pública dirección general de migración 
de la ciudad de La Paz. 
1.4.1 Variable Dependiente 
Reducción de los riesgos en el software 
1.4.2 Variable Independiente 
Modelo de seguridad para el desarrollo de software 
10 
 
1.4.3 Operacionalización de Variables 
Tabla 1. Operacionalización de la variable dependiente 
(Fuente Propia) 
 
Variable Componente Dimensiones Indicadores 
Reducción de los 
riesgos en el 
software. 
Disminución de la 
probabilidad de 
ocurrencia de un 
evento potencial 
que afecte al 
software. 
Análisis de 
vulnerabilidades 
Pruebas de 
penetración. 
Pruebas de seguridad 
basado en OWASP 
TOP 10. 
Número de 
vulnerabilidades 
encontradas. 
Costo de 
desarrollo. 
 Análisis de 
impacto de 
riesgo 
Cálculo de riesgo 
Evaluación de 
impacto. 
Niveles de aceptación 
de riesgo. 
 
 
Tabla 2. Operacionalización de la variable independiente 
(Fuente Propia) 
 
Variable Componente Dimensiones Indicadores 
Modelo de 
seguridad 
para el 
desarrollo 
de software. 
Modelo de 
desarrollo 
con la 
integración 
seguridad en 
cada etapa 
del 
desarrollo de 
software. 
Planeación Planeación de estrategias 
de seguridad. 
Construcción de procesos 
de seguridad. 
Concientización sobre 
vulnerabilidades de 
seguridad en el producto, 
diseño y código. 
Nivel de cumplimiento 
de estándares y 
políticas. 
Porcentaje de personal 
capacitado en temas de 
seguridad de software. 
Diseño Análisis de requerimientos 
con un enfoque en 
seguridad 
Nivel de cumplimiento 
de las políticas para el 
análisis de 
requerimientos de 
seguridad. 
Desarrollo 
 
Elaboración de modelos de 
amenazas. 
Alineación de la seguridad 
respecto a los 
requerimientos de software. 
Nivel de cumplimiento 
con los requisitos de 
seguridad. 
 
 
11 
 
Incorporar lineamientos de 
seguridad en el proceso de 
diseño de software. 
Desarrollo de software 
Pruebas Revisión del diseño del 
software de acuerdo a las 
buenas prácticas de 
seguridad. 
Revisión de errores de 
codificación. 
Verificación de pruebas de 
Seguridad basados en la 
implementación y 
requisitos de software. 
Pruebas de funcionalidad. 
Nivel de cumplimiento 
de diseño conforme a 
las prácticas de 
seguridad. 
Cobertura de testeo. 
Número de casos de 
prueba de seguridad o 
escenarios de prueba. 
Criticidad de los 
hallazgos de las 
pruebas de seguridad. 
Número de 
vulnerabilidades de 
software. 
Nivel de confianza del 
software. 
Despliegue Revisión del proceso de 
despliegue. 
Revisión de controles para 
la modificación de 
software. 
Revisión de reglamentos 
para la gestión de versiones 
de software. 
Nivel de cumplimiento 
con las políticas o 
procesos de 
despliegue. 
Mantenimiento Aprobación de software. 
Establecer un proceso de 
respuesta a incidentes. 
Identificación de 
actualizaciones y parches 
críticos de seguridad. 
Aprobación del nivel de 
riesgo de software. 
Porcentaje de 
incidentes 
documentados con sus 
recomendaciones. 
 
 
12 
 
CAPÍTULO II 
MARCO TEÓRICO 
2.1 ESTADO DEL ARTE 
En diversas investigaciones se destaca la importancia de incluir las pruebas de seguridad 
en el proceso de desarrollo. Entre algunasde esas investigaciones, podemos destacar: 
• “Software Assurance Maturity Model” proyecto de OWASP (Owasp, 2009). 
OWASP apoyo al desarrollo del modelo de madurez para el aseguramiento del 
software (SAMM por sus siglas en inglés) desarrollado inicialmente por Pravir 
Chandra. Actualmente este documento es mantenido y actualizado por el proyecto 
OpenSAMM que es liderado por el mismo autor, Pravir Chandra. El Modelo de 
madurez para el aseguramiento del software (SAMM) es un marco abierto para 
ayudar a las organizaciones a formular e implementar una estrategia para la 
seguridad del software que se adapte a los riesgos específicos que enfrenta la 
organización. SAMM cuenta con una flexibilidad para ser utilizado por 
organizaciones pequeñas, medianas y grandes que utilizan cualquier tipo de 
desarrollo. 
SAMM proporciona una guía para integrar seguridad en el desarrollo de software, 
ayuda a la evaluación de las prácticas de seguridad de software existentes en una 
organización. También ayuda a la construcción de un programa de seguridad de 
software equilibrado en iteraciones bien definidas para finalmente demostrar 
mejoras concretas a un programa de garantía de seguridad. 
• “Ciclo de vida de desarrollo de la seguridad” por Microsoft (Microsoft, 2018). 
Integra seguridad en el flujo del ciclo de vida del desarrollo del software. Esta 
propuesta trata de un proceso de desarrollo de software que ayuda a los 
desarrolladores a crear un software más seguro y cumplir con los requisitos de 
cumplimiento de seguridad al tiempo que reduce los costos de desarrollo. La 
metodología que presenta Microsoft se basa en tres conceptos principales, los 
13 
 
cuales son: Formación al personal en temas de seguridad, mejora continua del 
software y la responsabilidad de tener un plan de detección y respuesta ante 
incidentes de seguridad. 
El SDL de Microsoft posee 7 fases, los cuales son: entrenamiento, requisitos, 
diseño, implementación, verificación, liberación y respuesta, los cuales son poseen 
requisitos de seguridad y recursos específicos para cada practica de seguridad. 
• “Software Security Design and Testing” por Sami Masalin, (Masalin, 2000). Esta 
tesis de maestría describe el proceso de pruebas y diseño de seguridad del sistema 
para el desarrollo seguro. También proporciona una base teórica de seguridad del 
software y del proceso de desarrollo, da énfasis en estándares de seguridad y 
análisis de riesgo. 
• “Certified Tester Advanced Level Syllabus Security Tester” por la International 
Software Testing Qualifications Board (ISTQB, 2016). Este plan de estudios 
provee conceptos básicos de seguridad, plantea la alineación de las actividades de 
prueba de seguridad con las actividades del ciclo de vida del software. El objetivo 
de esta guía es capacitar al profesional de control de calidad en temas de seguridad 
para que este pueda planificar, realizar y evaluar las pruebas de seguridad desde 
diversas perspectivas. 
El profesional experto en seguridad debe tener en cuenta que los ataques siempre están 
evolucionando. Surgen nuevos ataques y, al igual que en cualquier aplicación de software, 
los nuevos defectos pueden hacerse evidentes, es una razón para realizar pruebas de 
seguridad desde la mentalidad del atacante constantemente. 
Al igual que las pruebas de software en general, las pruebas de seguridad no pueden 
garantizar que un software u organización no esté expuesto a ataques cibernéticos. Los 
ataques cibernéticos son cada vez más sofisticados y continuamente se van descubriendo 
nuevas formas de atacar o encontrar vulnerabilidades. Sin embargo, las pruebas de 
seguridad pueden ayudar a identificar riesgos y evaluar la efectividad de las defensas de 
14 
 
seguridad existente en el software. Existen otras actividades para complementar las 
pruebas de seguridad, como auditorías y revisiones de prácticas de seguridad. 
2.2 REFERENCIA TEÓRICA O CONCEPTUAL 
2.2.1 Desarrollo de software 
Según IBM Research: "El desarrollo de software se refiere a un conjunto de actividades 
informáticas dedicadas al proceso de creación, diseño, despliegue y soporte de software". 
(IBM, 2019) . Por tanto el desarrollo de software es un proceso logico iterative cuyo 
objetivo es la creacion de software. El desarrollo de software incluye subprocesos como 
recoleccion de informacion, diseño de flujos, documentacion, pruebas, depuracion entre 
otros, a esto se le denomina ciclo de vida de software o software development life cycle 
(SDLC). 
2.2.1.1 Software Development Life Cycle (SDLC) 
Software development life cicle (SDLC) o el ciclo de vida del desarrollo de software es un 
proceso que define una serie de etapas o fases involucradas en el desarrollo de software 
para la entrega de un producto de calidad y de menor costo en el menor tiempo posible, 
cumpliendo los requisitos del cliente. El SDLC garantiza que el proceso de desarrollo de 
software funcione de manera fluida, eficiente y productiva. 
a) Fases del ciclo de vida de desarrollo de software 
Existen varios modelos de SDLC, cada uno con sus características y debilidades, sin 
embargo, cada uno de ellos tiene las siguientes etapas básicas: 
1) Planificación y análisis de requisitos: En esta etapa las partes interesadas 
discuten los requisitos para el producto final. Es necesario asegurarse que todos 
los participantes del proceso hayan entendido claramente las tareas y como se 
implementaran todos los requisitos. También detalla los riesgos involucrados y 
proporciona sub-planes para suavizar esos riesgos. 
15 
 
2) Diseño: Esta fase de SDLC comienza al convertir las especificaciones de software 
en un plan de diseño, donde los desarrolladores van diseñando la arquitectura del 
proyecto. Las partes interesadas revisan este plan, ofrecen comentarios, 
sugerencias y se resuelven dudas que pueden aparecer. En esta etapa se definen las 
tecnologías utilizadas en el proyecto, la carga del tiempo, limitaciones entre otros. 
3) Implementación: También llamado desarrollo real, en esta etapa los 
desarrolladores comienzan con la escritura de código fuente teniendo en cuenta los 
requisitos previamente definidos. Dependiendo la especialidad del programador se 
van trabajando en tareas de front-end y back-end. Esta fase a su vez tiene las 
siguientes etapas: Desarrollo de algoritmos y diseño de interfaces, escritura de 
código fuente, compilación, pruebas y depuración. 
4) Prueba: En esta etapa, se analiza y detecta defectos y deficiencias del software. 
Dichos defectos o fallos son documentados y reportados a los desarrolladores 
involucrados, quienes solucionan o resuelven problemas o defectos hasta que el 
producto cumpla con las especificaciones definidas. Este proceso se repite hasta 
eliminar problemas críticos y el software sea estable. 
5) Despliegue: Cuando se obtiene un software candidato a reléase, pasa a los 
usuarios finales. En esta fase interviene el equipo de soporte técnico para realizar 
el lanzamiento de la nueva versión del software. Este equipo proporciona soporte 
a los usuarios durante el tiempo de explotación. También, en esa fase se realiza la 
actualización de los componentes involucrados para asegurarse que la 
actualización de software sea exitosa. 
b) Modelos SDLC 
Existe gran variedad de modelos SDLC, que están predeterminados por la cantidad de 
tipos de productos, desde un sistema simple a un sistema complejo. 
1) Modelo en cascada: Posee un proceso de desarrollo tipo flujo, pasando paso a 
paso a través de las fases de análisis, proyección, realización, prueba, 
implementación y soporte. Este modelo SDLC incluye la ejecución gradual de 
16 
 
cada etapa por completo. Este proceso está estrictamente documentado y 
predefinido con características que se esperan para cada fase de este modelo de 
ciclo de vida de desarrollo de software.Figura 3. Modelo SDLC en cascada 
Fuente: Empresa de desarrollo Existek 
 
2) Modelo iterativo: El modelo SDLC iterativo no necesita la lista completa de 
requisitos antes de que comience el proyecto. El proceso de desarrollo puede 
comenzar con los requisitos de la parte funcional, que se puede ampliar más 
adelante. El proceso es repetitivo, lo que permite hacer nuevas versiones del 
producto para cada ciclo. Cada iteración (que dura de dos a seis semanas) incluye 
el desarrollo de un componente separado del sistema, y después de eso, este 
componente se agrega al funcional desarrollado anteriormente. Hablando con 
terminología matemática, el modelo iterativo es una realización del método de 
aproximación secuencial; eso significa una cercanía gradual a la forma planificada 
del producto final. 
Figura 4. Modelo SDLC iterativo 
Fuente: Empresa de desarrollo Existek 
 
17 
 
3) Modelo en espiral: Es el modelo SDLC, que combina arquitectura y creación de 
prototipos por etapas. Es una combinación de los modelos SDLC iterativos y en 
cascada con el acento significativo en el análisis de riesgos. El tema principal del 
modelo en espiral es definir el momento adecuado para dar un paso hacia la 
siguiente etapa. Se recomiendan los marcos temporales preliminares como la 
solución a este problema. El cambio a la siguiente etapa se realiza de acuerdo con 
el plan, incluso si el trabajo en la etapa anterior aún no se ha realizado. El plan se 
presenta basándose en los datos estadísticos, recibidos durante los proyectos 
anteriores, incluso de la experiencia del desarrollador personal. 
Figura 5. Modelo SDLC espiral 
Fuente: Empresa de desarrollo Existek 
 
4) Modelo en forma de V: El modelo SDLC en forma de V es una expansión del 
modelo clásico en cascada y se basa en la etapa de prueba asociada para cada etapa 
de desarrollo. Este es un modelo muy estricto y la siguiente etapa se inicia solo 
después de la fase anterior. Esto también se llama modelo de "Validación y 
verificación". Cada etapa tiene el control de proceso actual, para asegurarse de que 
la conversión a la siguiente etapa sea posible. 
18 
 
Figura 6. Modelo en forma de V 
Fuente: Empresa de desarrollo Existek 
 
5) Modelo ágil: En la metodología ágil después de cada iteración de desarrollo, el 
cliente puede ver el resultado y comprender si está satisfecho con él o no. Esta es 
una de las ventajas del modelo de ciclo de vida ágil de desarrollo de software. Una 
de sus desventajas es que, a falta de requisitos definidos, es difícil estimar los 
recursos y el costo de desarrollo. La programación extrema es uno de los usos 
prácticos del modelo ágil. La base de dicho modelo consiste en reuniones 
semanales cortas: Sprints, que son parte del enfoque Scrum. 
Figura 7. Modelo SDLC ágil 
Fuente: Empresa de desarrollo Existek 
 
2.2.2 Riesgo de seguridad 
Los riesgos de seguridad de la información son aquellos que surgen de la pérdida de 
confidencialidad, integridad o disponibilidad de información o sistemas de información y 
reflejan los posibles efectos adversos para las operaciones de la organización (es decir, 
19 
 
misión, funciones, imagen o reputación), activos de la organización, individuos, otras 
organizaciones y un país. (NIST 80-30, 2012) 
La función de una evaluación de riesgos de seguridad es permitir que una organización 
comprenda qué áreas y activos pueden estar en riesgo y determinar la magnitud de cada 
riesgo. Para los evaluadores de seguridad, una evaluación de riesgos de seguridad puede 
ser una fuente rica de información a partir de la cual se pueden planificar y diseñar pruebas 
de seguridad. Se puede utilizar una evaluación de riesgos de seguridad para priorizar las 
pruebas de seguridad, de modo que el mayor nivel de rigor y cobertura de las pruebas se 
pueda centrar en las áreas con mayor exposición al riesgo. 
Cuando se da prioridad a las pruebas de seguridad basadas en una evaluación de riesgos 
de seguridad, las pruebas se alinean con los objetivos de seguridad del negocio. Sin 
embargo, para que se produzca esta alineación, la evaluación de riesgos de seguridad debe 
reflejar con precisión las amenazas de seguridad de la organización, las partes interesadas 
afectadas y los activos a proteger. 
Es importante comprender que cualquier evaluación de riesgos es solo una instantánea en 
un momento dado y se basa en información limitada que puede llevar a suposiciones y 
conclusiones no válidas. Los riesgos de seguridad cambian continuamente dentro de una 
organización y proyectos, ya que surgen nuevas amenazas diariamente. Por lo tanto, las 
evaluaciones de riesgos de seguridad deben realizarse a intervalos regulares. El intervalo 
de tiempo exacto para realizar evaluaciones de riesgos de seguridad varía según la 
organización y el grado de cambio que experimenta. (International Software Testing 
Qualifications Board, 2016) 
Otro problema con las evaluaciones de riesgo es el nivel de conocimiento de los 
participantes. Los riesgos pueden perderse debido a la falta de información detallada. Los 
riesgos pueden pasarse por alto si las personas no comprenden las amenazas y los riesgos 
de seguridad. El proceso de evaluación de riesgos de seguridad es muy similar a una 
evaluación de riesgos estándar, siendo la principal diferencia el enfoque en áreas 
relacionadas con la seguridad. 
20 
 
La preparación para una evaluación de riesgos incluye las siguientes tareas (NIST 80-30, 
2012): 
• Identificar el propósito de la evaluación. 
• Identificar el alcance de la evaluación. 
• Identificar los supuestos y limitaciones asociados con la evaluación. 
• Identificar las fuentes de información que se utilizarán como insumos para la 
evaluación. 
• Identificar el modelo de riesgo y los enfoques analíticos (es decir, enfoques de 
evaluación y análisis) que se emplearán durante la evaluación. 
 La realización de evaluaciones de riesgos incluye las siguientes tareas específicas (NIST 
80-30, 2012): 
• Identificar las fuentes de amenazas que son relevantes para la organización. 
• Identificar eventos de amenazas que podrían ser producidos por esas fuentes. 
• Identificar vulnerabilidades dentro de la organización que podrían ser explotadas 
por fuentes de amenazas a través de eventos de amenazas específicos y las 
condiciones predisponentes que podrían afectar la explotación exitosa 
• Determinar la probabilidad de que las fuentes de amenaza identificadas inicien 
eventos de amenaza específicos y la probabilidad de que los eventos de amenaza 
sean exitosos. amenaza 
 La comunicación y el intercambio de información consta de las siguientes tareas 
específicas (NIST 80-30, 2012): 
• Comunicar los resultados de la evaluación de riesgos. 
• Compartir información desarrollada en la ejecución de la evaluación de riesgos 
para apoyar otras actividades de gestión de riesgos. 
21 
 
2.2.3 Control de calidad de software 
Es la evaluación del software basada en ciertos atributos. La calidad del software se define 
según el estudio de las características externas e internas del software. La calidad externa 
se determina según el rendimiento del software en el escenario en tiempo real en el modo 
operativo y su utilidad para los usuarios. La calidad interna, por otro lado, se centra en los 
aspectos intrínsecos que dependen de la calidad del código escrito. El usuario se centra 
más en cómo funciona el software en el nivel externo, pero la calidad en el nivel externo 
se puede mantener solo si el desarrollador ha escrito un código de buena calidad 
significativa. 
2.2.4 Seguridad de software 
Es la capacidad del software para mantener la integridad, confiabilidad y disponibilidad 
de la información. El software siempre tendrá problemas de seguridad. Casi todo software 
puede ser vulnerado fácilmente. Pero con la seguridad del software y las técnicas 
relacionadas, es posible que pueda hacer una diferencia en cuantoa la cantidad de errores 
de seguridad que eventualmente permanecerán en el software. 
2.2.5 Pruebas de seguridad 
Las pruebas de seguridad evalúan la vulnerabilidad de un sistema a las amenazas al 
intentar comprometer la política de seguridad del sistema. Dentro de las pruebas de 
seguridad a un determinado software se debe contemplar los riesgos más comunes de 
dichas aplicaciones, tomando en cuenta el tipo de aplicación, tecnología empleada, diseño 
y arquitectura. OWASP ofrece un top 10 de riesgos más comunes en aplicaciones web, 
móviles e interfaces de programación de aplicaciones, se podría considerar estos riesgos 
como una base de las pruebas de seguridad, pero no como una limitante ni la totalidad, ya 
que constantemente van apareciendo nuevos riesgos y vulnerabilidades. A continuación, 
se lista algunos ejemplos de riesgos potenciales, que deben considerarse durante las 
pruebas de seguridad. 
22 
 
• Para aplicaciones web: Inyecciones SQL, pérdida de autenticación, mala 
configuración de seguridad, entradas XML, control de acceso, secuencia de 
comandos en sitios cruzados (XSS), deserialización insegura, uso de componentes 
con vulnerabilidades conocidas, exposición de datos sensibles, insuficiente 
registro y monitoreo. 
• Para aplicaciones móviles: Controles débiles en el lado del servidor, 
almacenamiento inseguro de datos, insuficiente protección en el transporte de 
datos, fuga de información no intencionada, pobre autorización y autenticación, 
métodos obsoletos de criptografía, inyección de código en el lado cliente, 
decisiones de comunicación entre aplicaciones no confiables, indebida 
manipulación de sesión y la falta de protección a nivel binario. 
• Para la interfaz de programación de aplicaciones (API): Problemas en la 
autorización de nivel de objeto, problemas en la autenticación, exposición excesiva 
de datos, escasez de recursos y limitación de velocidad, problemas de autorización 
de nivel de función, asignación masiva, configuración incorrecta de seguridad, 
inyección, gestión de activos inadecuada, registro y monitoreo insuficientes. 
Las pruebas de seguridad deben integrarse con todas las demás actividades de desarrollo 
y pruebas. Esto requiere considerar las necesidades únicas de la organización, las políticas 
de seguridad existentes, los conjuntos de habilidades de prueba de seguridad actuales y 
las estrategias de prueba existentes. 
2.2.6 Security DevOps 
El movimiento de la cultura DevOps ha impulsado y logrado romper barreras dentro de 
las organizaciones que dividen los equipos en funciones especializadas de desarrollo y 
operaciones. DevOps permite que las organizaciones que adoptan el movimiento y la 
cultura sean más competitivas al permitir lanzamientos de software más rápidos y 
confiables al aprovechar la automatización para reemplazar los procesos manuales 
involucrados en el envío de software. 
23 
 
Un efecto secundario de esta velocidad es que las herramientas y procesos de seguridad 
deben moverse al mismo ritmo para mantenerse al día. La idea que impulsa DevSecOps, 
DevOpsSec o Security DevOps es realizar las pruebas de seguridad de la aplicación en 
desarrollo en el proceso utilizado para enviarla. 
2.2.6.1 DevOps 
Es una metodología de trabajo basada en el desarrollo de código que usa nuevas 
herramientas y prácticas para reducir la tradicional distancia entre desarrollo y 
operaciones. Este nuevo enfoque de colaboración que es DevOps permite a los equipos 
trabajar de forma más cercana, aportando mayor agilidad al negocio y notables 
incrementos de productividad. Adoptando el cambio cultural que es DevOps, las empresas 
pueden acelerar el ciclo de vida de sus aplicaciones. (Bird, 2016) 
2.2.6.2 DevSecOps 
DevSecOps, es una extensión de la mentalidad de DevOps a seguridad, es decir, incorporar 
seguridad en todo el proceso de DevOps. No existe un consenso en el campo sobre el 
orden de las palabras, por lo que los términos de búsqueda deben abarcar posibles 
permutaciones, por ejemplo: devsecops, secdevops, devopsec entre otros. (Vehent, 
Securing DevOps, 2018) 
Figura 8. Fases de DevOps 
Fuente: Securing DevOps 
 
 
24 
 
a) Principios 
Los principios que caracterizan a DevSecOps se basan en DevOp y los principios CAMS, 
cultura, automatización, medición y compartir, pero con la adición de agregar seguridad 
desde el principio: 
1) Cultura: Una cultura DevOps promueve la colaboración entre los equipos de 
desarrollo y los equipos de operación, donde todos aceptan que son responsables 
de entregar el software a un usuario final. DevSecOps significa incluir la 
colaboración con el equipo de seguridad, así como promover una cultura donde 
las operaciones y el desarrollo también trabajen para integrar la seguridad en su 
trabajo. Eso significa involucrar al equipo de seguridad desde las etapas de 
planificación, y hacer que todos se pongan de acuerdo en que la seguridad es 
responsabilidad de todos. (Vehent, Securing DevOps, 2018) 
2) Automatización: En DevOps, la automatización de la compilación, la 
implementación y las pruebas es importante para lograr un rápido desarrollo e 
implementación. DevSecOps también promueve un enfoque en la automatización 
de la seguridad, para poder mantenerse al día con la velocidad y la escala logradas 
por DevOps. El objetivo debe ser la automatización al 100% de los controles de 
seguridad, donde los controles se pueden implementar y administrar sin 
interferencia manual (Hewlett Packard Enterprise, 2016). 
3) Medición: Las mediciones incluyen el monitoreo de métricas comerciales, como 
los ingresos y los indicadores clave de rendimiento, como el efecto que las nuevas 
versiones tienen sobre la estabilidad de un sistema, para conocer el estado actual 
y encontrar la forma de mejorarlo. DevSecOps promueve el uso y el desarrollo de 
métricas que rastrean amenazas y vulnerabilidades en todo el proceso de desarrollo 
de software (Hewlett Packard Enterprise, 2016). Los controles de seguridad 
automáticos en todo el proceso de desarrollo de software significan que las 
métricas están disponibles para rastrear amenazas y vulnerabilidades en tiempo 
real y eso permite a la organización verificar qué tan buena es una aplicación bajo 
demanda (Vehent, Securing DevOps, 2018). 
25 
 
4) Compartir: Los desarrolladores y operadores comparten conocimientos, 
herramientas de desarrollo y técnicas para gestionar el proceso. DevSecOps 
promueve la inclusión del equipo de seguridad en el intercambio promovido en un 
entorno DevOps. Al informar a los equipos de seguridad sobre los desafíos que 
enfrentan los operadores y desarrolladores, y viceversa, se mejorarán los procesos 
de seguridad que desarrollan (Vehent, Securing DevOps, 2018). 
5) Desplace la seguridad hacia la izquierda: En el proceso tradicional de desarrollo 
de software, la seguridad es un paso cercano al final del proceso. DevSecOps 
promueve un cambio hacia la izquierda por seguridad, donde debe incluirse en 
cada parte del proceso de desarrollo de software. Esto significa que los equipos de 
seguridad están involucrados desde el primer paso de planificación y es parte de 
la planificación de cada iteración del ciclo de desarrollo. 
b) Practicas 
 Las prácticas de DevOps seguros significan que las organizaciones deben desarrollar 
experiencia y procesos para descubrir, proteger y encontrar mejores soluciones a las 
amenazas y los riesgos, preferiblemente con anticipación (Bird, 2016). Realizar 
evaluaciones de riesgos desde la primera etapa de planificación y continuamente antes de 
cada iteración es importante como una forma de priorizar los riesgos, examinar los 
controles ya establecidos y decidir cuáles son necesarios en el futuro. 
1) Pruebas continuas: Los controles de seguridad automáticos en cada parte del 
proceso de desarrollo del software son importantes para garantizar la seguridad y 
permiten que las pruebas escaneencontinuamente el código en busca de cambios, 
detecten continuamente anomalías y reviertan el código automáticamente cuando 
sea necesario. 
2) Monitoreo y registro: Al automatizar los controles de seguridad a lo largo del 
proceso de desarrollo de software, es importante que los involucrados puedan 
generar evidencia a demanda de que los controles están funcionando y que son 
efectivos. 
26 
 
3) Seguridad como código: Esto significa definir políticas de seguridad, por 
ejemplo, pruebas de integración y configuración y acceso a la red, y escribir 
plantillas con guiones o archivos de configuración que se puedan implementar en 
el proceso de desarrollo desde el inicio del proyecto. 
4) Equipo rojo y simulacros de seguridad: Para adelantarse a los posibles 
atacantes, los practicantes de DevSecOps crean un equipo rojo que ejecuta 
simulacros de seguridad en el software implementado. Tienen la tarea de encontrar 
y explotar vulnerabilidades en el sistema. Esto no solo ayuda a encontrar fallas de 
seguridad, sino que mejora las mediciones y ayuda a la organización a encontrar 
soluciones. El objetivo del equipo rojo es tener personas que nunca afirman que 
algo no puede suceder. (Vehent, Securing DevOps, 2018) 
2.3 MARCO LEGAL E INSTITUCIONAL 
2.3.1 Lineamientos para la elaboración e implementación de los Planes 
Institucionales de Seguridad de la Información de las entidades del sector público 
 Establece los lineamientos para que las entidades del sector público del Estado 
Plurinacional de Bolivia puedan elaborar e implementar sus Planes Institucionales de 
Seguridad de la Información (PISI) de acuerdo a la normativa vigente. El decreto supremo 
N°2514 de septiembre del 2016. En su parágrafo III del Artículo 17, que establece que 
“Las entidades del sector público deberán desarrollar el Plan Institucional de Seguridad 
de la Información acorde a los lineamientos establecidos por el CGII”. 
Este plan institucional de seguridad de la información en su anexo A presenta una sección 
donde establece directrices para el desarrollo, mantenimiento y adquisición de sistemas. 
En las diferentes directrices de esta sección se hace referencia a la adopción de un ciclo 
de vida de desarrollo seguro y prácticas de seguridad. 
2.3.2 Decreto supremo Nº1793 
En el decreto supremo Nº1793 de 13 de noviembre de 2013, hay artículos que conciernen 
al desarrollo de aplicaciones digitales como también a la seguridad informática: 
27 
 
En el párrafo IV del artículo 4, principios, señala que el software a ser utilizado por las 
entidades públicas debe regirse por la seguridad informática del código fuente que es uno 
de los principios establecidos el cual menciona lo siguiente: “Debe permitir al Estado 
Plurinacional de Bolivia la posibilidad de auditar, conocer y modificar el código fuente 
del mismo sin requerir ningún tipo de autorización, para obtener el comportamiento 
deseado de parte de ellas y ningún otro no consentido o requerido, precautelando la 
seguridad, independencia y soberanía tecnológica de Bolivia” 
El artículo 5, desarrollo de contenidos y aplicaciones TIC, menciona que el estado 
promoverá de manera prioritaria el desarrollo de contenidos, aplicaciones y servicios de 
las TIC en software libre, utilizando estándares abiertos y velando por la seguridad de la 
información en las áreas de: educación, salud, gestión gubernamental, productivo, 
comunicación e información. 
El artículo 6, objetivos de desarrollo de contenidos digitales, señala que fortalecer la 
seguridad informática del Estado Plurinacional de Bolivia deberá ser un objetivo mínimo 
para el desarrollo, diseño e innovación de contenidos digitales. 
El artículo 7, desarrollo de aplicaciones digitales, establece que: “El desarrollo de 
aplicaciones digitales por parte de las entidades públicas priorizará el uso de herramientas 
y plataformas de software libre, las cuales deben permitir a los usuarios y las usuarias: 
comunicarse entre sí, realizar trámites, entretenerse, orientarse, aprender, trabajar, 
informarse, activar servicios en las redes públicas de comunicaciones y realizar una serie 
de tareas de manera práctica y desde uno o más tipos de equipos terminales, proceso para 
el cual se enmarcarán en el uso de Estándares Abiertos, de modo que los contenidos sean 
democratizados y accesibles para los usuarios.” 
2.3.3 Ley Nº164, ley general de telecomunicaciones, tecnologías de información y 
comunicación 
En artículo 72, párrafo I de la ley Nº 164 de 8 de agosto de 2011, se establece que: “El 
Estado en todos sus niveles, fomentará el acceso, uso y apropiación social de las 
tecnologías de información y comunicación, el despliegue y uso de infraestructura, el 
28 
 
desarrollo de contenidos y aplicaciones, la protección de las usuarias y usuarios, la 
seguridad informática y de redes, como mecanismos de democratización de oportunidades 
para todos los sectores de la sociedad y especialmente para aquellos con menores ingresos 
y con necesidades especiales.” 
 
 
 
 
 
 
 
 
 
 
 
 
 
29 
 
CAPÍTULO III 
METODOLOGÍA DE LA INVESTIGACIÓN 
3.1 DISEÑO METODOLÓGICO 
El diseño de la presente investigación es de tipo experimental. Este diseño permite la 
manipulación de dos variables: la variable dependiente, la causa; y la variable 
independiente, el efecto. La investigación con diseño experimental ayuda a determinar el 
efecto de la variable independiente sobre la variable dependiente en una situación 
particular es este caso el efecto de implementar un modelo de seguridad para el desarrollo 
de software en la reducción de los riesgos en el software, de esta manera controlar el 
aumento o disminución de la variable dependiente. 
3.1.1 Tipo de investigación 
El tipo de investigación del presente trabajo es correlacional. De acuerdo a la clasificación 
que propone Dankhe (1986), existen tipos básicos de investigación, en función al estado 
del conocimiento de la ciencia que se trata, y del enfoque particular adoptado por el 
investigador en el tratamiento del problema y el objetivo. La presente investigación pasa 
de ser una investigación de tipo exploratoria a correlacional, donde en la: 
Investigación exploratoria, se inició el proceso investigativo, identificando posibles 
relaciones entre factores y estableciendo posibilidades de investigaciones posteriores. 
Para establecer el objeto de investigación en este caso modelo de seguridad para el 
desarrollo de software es necesario revisar la literatura correspondiente. 
Investigación descriptiva, se especificó el objeto de investigación, describió el problema 
y finalmente se describió la solución. Se buscó determinar las propiedades del proceso de 
desarrollo de software para la integración de conceptos y pruebas de seguridad. 
Investigación correlacional, se buscó establecer relaciones entre las variables 
identificadas, es decir, se determinó las posibles relaciones que existen entre esas 
variables, y luego se midió el grado de correlación o el cómo se comporta una variable en 
30 
 
función de la otra variable. También se procuró obtener un indicador cuantitativo que mida 
el grado de relación entre las variables. 
3.2 MÉTODO DE INVESTIGACIÓN 
La presente investigación se realizó con el método hipotético deductivo. El método 
hipotético deductivo consiste en hacer observaciones manipulativas y análisis, a partir de 
las cuales se formula una hipótesis que será comprobada mediante experimentos 
controlados. Esta investigación al poseer una hipótesis es necesario refutar las 
aseveraciones de la hipótesis para llegar a conclusiones que debe confrontarse con hechos, 
es por esa razón que la investigación se hizo con el método hipotético deductivo. 
3.2.1 Fases Metodológicos 
Tabla 3. Fases Metodológicos 
Fuente: Propia 
 
Objetivo Especifico Fases Metodológicas 
Realizar un análisis de 
vulnerabilidades a sistemas en 
producción previoa la 
implementación del modelo de 
desarrollo de software seguro. 
Análisis de vulnerabilidades. 
Ejecución de pruebas de intrusión. 
Ejecución de pruebas OWASP top ten. 
Elaboración de reporte de la evaluación de 
vulnerabilidades técnicas. 
Evaluar las prácticas de seguridad en 
el proceso de desarrollo de software 
de acuerdo al cumplimiento de 
normativas nacionales. 
Revisión de normativas nacionales. 
Evaluación del cumplimiento a las normativas 
y políticas de la institución. 
Evaluación de riesgo de software. 
Definir actividades relacionadas con 
seguridad en cada etapa del ciclo de 
vida de desarrollo de software. 
Elaboración de controles de seguridad para 
cada fase del ciclo de vida de desarrollo de 
software. 
Establecer una guía de buenas prácticas de 
seguridad dentro el proceso de desarrollo de 
software. 
31 
 
Validar la contribución de un modelo 
de desarrollo de software 
implementando estrategias de 
seguridad en la detección temprana de 
vulnerabilidades. 
Aplicación de un modelo de desarrollo de 
software. 
Análisis de datos obtenidos. 
 
3.2.2 Técnicas de investigación 
En la presente investigación, se utilizó las siguientes técnicas: 
i) Técnicas de recolección de datos: Con el propósito de verificar la 
importancia de la seguridad en el proceso de desarrollo de software se realizó 
encuestas a profesionales en el área de desarrollo y al responsable de desarrollo 
de la entidad pública Dirección General de Migración. 
ii) Técnicas de observación: Para la evaluación de modelo propuesto se ejecutó 
los siguientes pasos. 
a. Establecer los objetivos a ser medidos 
b. Seleccionar para que servirán en la investigación 
c. Establecer el modelo que mejor se ajuste a los casos de estudio reales. 
d. Recopilar y analizar datos. 
e. Efectuar una evaluación en función a los datos obtenidos 
f. Informar y documentar los resultados. 
3.3 UNIVERSO O POBLACIÓN DE REFERENCIA 
3.3.1 Población 
La población está delimitada al área de desarrollo de software de la institución pública 
Dirección General de Migración de la ciudad de La Paz. 
3.3.2 Muestra 
La presente investigación se desarrolló en la entidad pública dirección general de 
migración y con el fin de viabilizar la presente investigación se tomó como muestra el 
proceso de desarrollo de la institución, eligiendo dos aplicaciones de la misma para el 
32 
 
respectivo análisis de ciclo de vida de desarrollo de software y evaluación de seguridad, 
por tanto, la muestra es de tipo determinístico sesgado. 
3.4 DELIMITACIÓN 
3.4.1 Delimitación Geográfica 
La investigación se desarrolló en la ciudad de La Paz, Bolivia. 
3.4.2 Delimitación Temporal 
Se ha considerado la evaluación de los datos obtenidos en el último año y software en 
producción de la dirección general de migración para ser comparados con los resultados 
obtenidos después de la implementación del presente modelo. Es decir, se delimito a las 
vulnerabilidades de software encontradas en el software en producción durante la gestión 
2019, posteriormente se identificó y evaluó las vulnerabilidades en los productos lanzados 
a producción en los próximos 2 meses una vez aplicado el modelo de seguridad para el 
desarrollo de software. Esta evaluación al proceso de desarrollo y a las aplicaciones de la 
dirección general de migración se realizó en el mes de junio hasta octubre de la gestión 
2019. 
 
 
 
 
 
 
 
 
33 
 
CAPITULO IV 
MARCO PRÁCTICO 
La presente propuesta considera las seis fases más comunes de un ciclo de vida de 
desarrollo de software, también incluye cinco etapas para la gestión de pruebas de 
seguridad que señala la ISTQB, considerando las practicas importantes del modelo de 
desarrollo seguro de SAMM, análisis de riesgo, buenas prácticas de DevSecOps y de 
acuerdo a los requerimientos de desarrollo de sistemas de los lineamientos del plan 
institucional de seguridad de la información. La siguiente propuesta esta detallada en el 
punto 4.4. arquitectura del modelo. 
Figura 9. Propuesta de modelo de seguridad para el desarrollo de software 
Fuente: Propia 
SDLC 
 Análisis de riesgo Análisis de riesgo 
 
 DevSecOps 
 
 
Gestión de Pruebas – ISTQB 
 
Software Assurance Maturity Model 
PLAN INSTITUCIONAL DE SEGURIDAD DE LA INFORMACION 
 
Para establecer la presente propuesta se realizó un procesamiento de datos recompilados 
donde se evaluó modelos de desarrollo seguros para ver sus fortalezas y debilidades, 
también se realizó un análisis y diseño del modelo de acuerdo al contexto, mismos que 
serán descritos a continuación. 
PLANEACION DISEÑO DESARROLLO PRUEBAS DESPLIEGUE MANTENIMIENTO
Planificación de 
pruebas de 
seguridad
Diseño de 
pruebas 
seguridad
Ejecución de 
pruebas de 
seguridad
Evaluación 
de pruebas 
de seguridad
Mantenimiento 
de pruebas de 
seguridad 
34 
 
4.1 DESCRIPCIÓN Y PROCESAMIENTO DE DATOS RECOPILADOS. 
El presente trabajo propone un modelo de desarrollo de software adoptando prácticas de 
seguridad en cada actividad del ciclo de vida de desarrollo de software. El modelo consta 
de las siguientes actividades: planeación, diseño, desarrollo, pruebas, despliegue y 
mantenimiento de acuerdo a los lineamientos para la elaboración e implementación de los 
planes institucionales de seguridad de la información de las entidades del sector público 
y buenas prácticas de desarrollo de software. En ese sentido, se inició con el análisis donde 
se recopilo antecedentes de trabajos similares, normativas nacionales, estándares 
nacionales e internacionales. 
Tras el estudio de guías, modelos, estándares y normativas nacionales e internacionales, 
como base teórica para el presente modelo, se ha rescatado las mejores prácticas para el 
desarrollo seguro analizando la fortaleza de cada una. Como podemos observar en la tabla 
4 de fortalezas de modelos para el desarrollo de software, se ha considerado las debilidades 
y fortalezas de los modelos de SDLC y estándares que ayudan a mejorar el desarrollo de 
software integrando seguridad en las distintas actividades del SDLC. 
Tabla 4. Tabla de fortaleza de modelos para el desarrollo de software 
Fuente: Propia 
 
MODELOS Y ESTANDARES PARA EL DESARROLLO SEGURO 
Modelos y 
estándares 
Diseño y 
planificación 
Desarrollo Pruebas Despliegue Mantenimiento 
SAMM Fortaleza Fortaleza Medio Básico Medio 
SDLC 
Microsoft 
Medio Medio Medio Medio Medio 
Security 
Tester 
ISTQB 
Básico Básico Fortaleza Debilidad Debilidad 
DevSecOps Básico Básico Básico Fortaleza Fortaleza 
35 
 
De acuerdo a las fortalezas de cada estándar, modelo o guía se hizo una evaluación de 
actividades de seguridad descartando algunas prácticas repetitivas o básicas. Tras el 
estudio de cada modelo o estándar se descartó el modelo SDLC de Microsoft ya que si 
bien presenta aspectos importantes para el desarrollo seguro se enfoca en tecnologías de 
Microsoft y muchas de las actividades están cubiertas por los otros modelos y guías 
consideradas en la construcción del presente modelo. 
Para el procesamiento de datos se realizó una evaluación del modelo de madures de 
prácticas de seguridad de acuerdo al SAMM con el propósito de evaluar la madurez de 
seguridad en un punto inicial y finalmente comparar con el nivel de madurez después de 
aplicar el presente modelo, de esta manera demostrar la contribución del modelo. También 
se hizo una recolección de información de la institución pública dirección general de 
migración de acuerdo a los requerimientos del PISI, para ello se hizo una encuesta al 
responsable de sistema y al encargado de desarrollo de sistemas. (Ver Apéndice B) 
4.2 ANÁLISIS Y DISEÑO DEL MODELO 
Después del estudio del estado de arte, donde se conoció trabajos similares, se dio inicio 
con el análisis para el desarrollo del modelo de seguridad para el desarrollo de software 
basado