Universidad Distrital Francisco José de Caldas
Facultad de Ingeniería
Ingeniería de Sistemas
Plan y pruebas de seguridad de un Sistema de
Gestión Documental tomando como referencia la
Guía de Pruebas de OWASP.
9 de julio de 2020
Diego Andrés Osorio Gutiérrez
Índice general
1. Objeto de la investigación 5
1.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Palabras Clave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Problema de investigación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Justificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5.1. Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5.2. Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.6. Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.6.1. Sistemas de Gestión Documental . . . . . . . . . . . . . . . . . . . . . . . 7
1.6.2. Guía de pruebas de OWASP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.7. Limitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2. Marco referencial 12
2.1. Marco teórico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2. Marco Legal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3. Etapa inicial 16
3.1. Ciclo de vida del desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2. Políticas y estándares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3. Criterios de mediciones, métricas y trazabilidad . . . . . . . . . . . . . . . . . . . 20
4. Etapa de definición y diseño 23
4.1. Requerimientos del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1.1. Requerimientos de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1.2. Requerimientos funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1.3. Requerimientos no funcionales . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2. Descripción general del Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1
Capítulo 0 Universidad Distrital Francisco José de Caldas
4.3. Creación y revisión modelos UML . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3.1. Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3.2. Diagrama de clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.4. Modelo de amenazas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.4.1. Dependencias externas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.4.1.1. Niveles de confianza . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.4.1.2. Puntos de entrada . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.4.1.3. Activos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.4.1.4. Diagrama de flujo de datos . . . . . . . . . . . . . . . . . . . . . . 36
4.4.1.5. Determinar y jerarquizar amenazas . . . . . . . . . . . . . . . . . 36
5. Etapa de desarrollo 42
5.1. Primer ciclo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.1.1. Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.1.2. Modelado de amenazas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.1.3. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.1.3.1. Caminatas a través del código . . . . . . . . . . . . . . . . . . . . 45
5.1.3.2. Comprobación del Json Web Token . . . . . . . . . . . . . . . . . 45
5.1.4. Análisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.2. Segundo ciclo: Modulo de administración . . . . . . . . . . . . . . . . . . . . . . 49
5.2.1. Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.2.2. Modelo de amenazas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.2.3. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.2.3.1. Caminata a través del código . . . . . . . . . . . . . . . . . . . . . 51
5.2.3.2. Acceso no autorizado . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.2.3.3. Inyección SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.2.4. Análisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.3. Tercer ciclo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.3.1. Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.3.2. Modelo de amenazas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.3.3. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.3.3.1. Caminata a través del código . . . . . . . . . . . . . . . . . . . . . 57
5.3.3.2. Cross Site Scripting (XSS) . . . . . . . . . . . . . . . . . . . . . . . 58
5.3.4. Análisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
2
Capítulo 0 Universidad Distrital Francisco José de Caldas
6. Etapa final 61
6.1. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.2. Impacto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.3. Recomendaciones para el proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.4. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.5. Anexo: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Referencias 66
3
Resumen
En la construcción de un Sistema de Gestión Documental libre y de código abierto en
un ambiente web, el presente trabajo tiene como objeto elaborar un plan de seguridad
para la parte inicial de este proyecto de desarrollo del sistema de información usando como
metodología la referencia de la Guía de Pruebas de OWASP (Matte Meuccí, 2015) en su versión
número 4 en busca de satisfacer las necesidades de seguridad que se presentan.
En la etapa inicial, se define un contexto general donde dicho sistema entra en producción,
basado en esto y las tecnologías escogidas se analizan las necesidades del Sistema de Gestión
Documental, se realiza un diseño, planteamiento e implementación de las medidas a tomar
para satisfacer las necesidades principales. Durante el desarrollo se hacen revisiones y se
aplican pruebas para comprobar la seguridad y las funcionalidades principales que se van a
elaborar durante los primeros 4 meses del proyecto de la construcción del sistema.
4
Capítulo 1
Objeto de la investigación
1.1. Introducción
En un mundo donde la información digital gana valor cada día, esta se vuelve blanco de
amenazas. Las entidades requieren de instrumentos para el manejo y organización de esta
información que sean seguras y fáciles de usar.
1.2. Palabras Clave
Plan de seguridad; Pruebas; Guía de Pruebas de OWASP; Sistema de gestión Documental.
1.3. Problema de investigación
En la construcción de un Sistema de Gestión Documental SGD libre, no se había tenido
en cuenta para el proyecto la perspectiva de seguridad de dicho software lo cual puede
ocasionar que el proyecto falle al no cumplir con las características requeridas para llegar a
ser implementado.
El grupo de trabajo del proyecto consta de 5 personas, todos estudiantes y con poca
experiencia en proyectos grandes y trabajo en grupo, lo cual aumenta la probabilidad de uso
de malas practicas que afecten la integridad del software.
¿Cómo se debe abordar la seguridad durante el desarrollo de un Sistema de Gestión Docu-
mental Web para garantizar la integridad, disponibilidad, confidencialidad de la información
y del mismo sistema?
5
Capítulo 1 Universidad Distrital Francisco José de Caldas
1.4. Justificación
Existe la necesidad en entidades Colombianas, en su mayoría de un carácter público, de
una herramienta para la gestión documental que se acojan a sus necesidades y a las políticas
por las cuales estas entidades son acogidas. Además existen muy pocas alternativas libres,
siendo estas alternativas un poco antiguas y con problemáticas de seguridad y diseño de
software. Este proyecto busca contribuir a la elaboración de un SGD moderno, libre y seguro
que pueda ayudar a estas entidades.
Es bastante común que los servidores de las entidades sean víctimas de ataques en
búsqueda de robos de información, hacer uso de su procesamiento y memoria o simplemente
afectar la integridad del sistema. En caso de que el SGD se vea afectado puede tener grandes
consecuencias ya que interrumpe gran parte de los procesos organizacionales al perder
el flujo de documentos cotidiano negando a los empleados la posibilidad de consulta o
modificación de dichos documentos, puede incluso generar repercusiones legales si por
ejemplo no se contesta a tiempo una tutela, o repercusiones monetarias. El proyecto se usa
como herramienta para hacer el nuevo SGD competitivo y adaptado a un entorno actual
dónde la interoperabilidad y la conexión a internet son obligatorios para una herramienta de
este tipo.
Se hace necesario abordar la seguridad como un aspecto de gran importancia durante
el proceso de desarrollo y se propone una metodología de análisis, desarrollo y pruebas
en busca de corregir vulnerabilidades a tiempo durante todo el desarrollo del software
haciendo referencia a la Guía de Pruebas de OWASP(Matte Meuccí, 2015) en su versión
número 4, ya que esta guía se ha construido con el consenso y la colaboración de gran
cantidad de expertos alrededor del mundo, es de código abierto e intenta reunir la mayor
cantidad de problemáticas de los aplicativos web y ofrecer la correspondiente explicación,
recomendaciones, métodos para probar y mejorar dichas problemáticas.
La comunidad Open Web Application Security Project OWASP es sin ánimo de lucro,
está conformada por diferentes personas, organizaciones, empresas, etcétera; alrededor del
mundo y buscan un conocimiento abierto y colaborativo, dedicado a definir y ayudar a
combatir las problemáticas que hacen que el software sea inseguro en un ambiente web.
6
Capítulo 1 Universidad Distrital Francisco José de Caldas
1.5. Objetivos
1.5.1. Objetivo General
Realizar el análisis e implementación del plan de seguridad, el cual esta compuesto por
procesos como la elaboración de criterios, políticas, métricas y pruebas, durante el desarrollo
de un Sistema de Gestión Documental para alcanzar un nivel de seguridad confiable en la
nueva plataforma usando la Guía de Pruebas de OWASP como referencia.
1.5.2. Objetivos Específicos
Determinar las necesidades de seguridad que afronta un sistema de gestión documental
y cómo deben ser tratadas.
Implementar métodos para satisfacer dichas necesidades durante una primera fase del
desarrollo.
Realizar las pruebas necesarias para verificar el estado de seguridad del software.
Dejar la madurez requerida para que en el proyecto se implementen prácticas y medi-
das de seguridad.
Evaluar la forma correcta de como un sistema de gestión documental debe mantener
control de acceso a documentos.
1.6. Antecedentes
Para el sistema aplican dos y tipos principales de antecedentes, los primeros son sistemas
ya existentes relacionados con la gestión documental utilizados en el contexto colombiano.
El otro antecedente trata de la guía de pruebas y seguridad que tiene como referencia para la
elaboración de presente proyecto
1.6.1. Sistemas de Gestión Documental
Actualmente son pocos los diferentes Sistema de Gestión Documental usados en las
entidades públicas, algunas de ellas toman alternativas como software’s a la medida de su
entidad que incluye módulos para su gestión documental, pero esto implica un gran costo
en el desarrollo de estos módulos por lo que la mayoría de entidades prefieren usar algún
7
Capítulo 1 Universidad Distrital Francisco José de Caldas
software de propósito especifico. A continuación se listan las alternativas mas usadas para
este propósito.
OrfeoGPL (Jairo Losada, 2002) es un software para gestión documental de código abier-
to colombiano, que nació en la Superintendencia de Servicios Públicos Domiciliarios
(SSPD) en Colombia, conceptualizado en el año 2002 y desde unos pocos años después
mantenido por la fundación Correlibre, aunque existen mas de un repositorio que lo
contiene. Se estima que se encuentra en producción en mas de 100 entidades tanto
publicas como privadas en todo Colombia e incluso el gobierno ecuatoriano adopto
una versión que modifico y utiliza a nivel nacional. Esta registrado y es distribuido bajo
la licencia GNU GPL.
OrfeoGPL ha evolucionado adoptando múltiples funcionalidades nacidas de las nece-
sidades de las diferentes entidades como módulos de préstamo, envío, digitalización,
radicación, notificación y respuesta por correo electrónico, entre otros. Esta escrito en
Php. Tiene soporte para bases de datos PostgreSql, MySql, Oracle DB y Microsoft SQL
Server.
Debido a la forma en que se ha construido OrfeoGPL, desde un principio no se diseño
una arquitectura definida, si no a través del tiempo se han desarrollado y modificado
componentes de forma desorganizada, cuando en alguna entidad tienen una nece-
sidad los desarrolladores suelen solucionarla de la forma mas rápida posible ya que
en el contexto empresarial es común tener que hacerlo con muy pocos recursos de
tiempo, pero esto tiene consecuencias, como muchos archivos de código que quedan
sin usar, pocas buenas practicas de desarrollo y una estructura del software muy grande
y compleja. Lo anterior conlleva a problemáticas de seguridad y gran dificultad para
aprender y entender el funcionamiento del software lo cual afecta el crecimiento de la
comunidad que hace parte y aporta de manera significativa a la construcción de soft-
ware. Para el caso de la comunidad de OrfeoGPL, el grupo está compuesto por varios
analistas y programadores de cada una de las entidades que han optado participar en el
proyecto, quienes interactúan dentro del proceso de desarrollo, recibiendo además los
reportes de errores y las correcciones de los mismos, así como mejoras para optimizar
el desempeño de la aplicación.
La acogida y el crecimiento que ha tenido OrfeoGPL sumado sus problemáticas de
diseño y seguridad han inspirado este proyecto en la búsqueda de una alternativa que
pueda ser usada como OrfeoGPL pero diseñada desde un principio teniendo en cuenta
sus debilidades.
8
Capítulo 1 Universidad Distrital Francisco José de Caldas
Openkm (S.L., 2006) es un software nacido en el 2004 en España, ellos se definen como
un Sistema de gestión electrónica de documentos y registros, tienen varias versiones
de su producto, entre ellas versión para la comunidad con licencia GPLv2 y una versión
profesional que usa un acuerdo de licencia de usuario final que involucra código y
estándares abiertos mas la posibilidad de soporte comercial. Entre las características
que ofrecen resaltan la gestión de registros, flujos de trabajo, tareas automáticas, dife-
rentes módulos, integración con otras herramientas, OCR en documentos, entre otros.
Esta escrito en Java y utiliza el servidor HTTP Apache. No cumple con algunas de las
normativas del Archivo General De la Nación al ser de otro país como por ejemplo el
permitir clasificar los documentos según el Cuadro de Clasificación Documental, este
también esta reglamentado por esta institución por lo que no es una buena opción ene
l contexto colombiano.
Plataforma Alfresco (Alfresco Software, s.f.). Es una plataforma empresarial digital que
integra diferentes software que ofrece soluciones para potenciar los negocios y manejo
de empresas, entre sus herramientas se encuentra la de gestión documental, la cual fue
el producto inicial de la organización. Se encuentra desarrollada en Java.
Manejan tres tipos diferentes de distribuir su software, su lanzamiento fue en Noviem-
bre de 2005 por Alfresco Software Inc.
• Alfresco Community Edition: La versión liberada bajo licencia LGPL de código
abierto.
• Alfresco Enterprise Edition: Distribuida también como código abierto pero con
vinculación de excepción, permite soporte comercial y propietario en modo
empresarial.
• Alfresco Cloud Edition: Es un versión de la plataforma Orientada a servicios
Entre las características que ofrece se destacan la búsqueda y localización de docu-
mentos, integración con flujos de trabajo y procesos empresariales; y mecanismos de
seguridad que protegen la integridad de los documentos. Se definen como una platafor-
ma modular y escalable. Al igual que Openkm no cumple con toda la reglamentación
dada por el Archivo General De la Nación pero actualmente es ampliamente usado a
nivel nacional.
9
Capítulo 1 Universidad Distrital Francisco José de Caldas
1.6.2. Guía de pruebas de OWASP
La guía de pruebas de OWASP actualmente se ha consolidado como herramienta en el
ciclo de vida de desarrollo de software, esta orienta al equipo de desarrollo a usar practicas y
recomendaciones de seguridad que se deben implementar a nivel de diseño, codificación o
implementación y así reducir el riesgo de amenaza permanente y directa para aplicaciones o
servicios.
Un ejemplo de esto (D. Guamán, 2017) donde toman como referencia las recomenda-
ciones de OWASP para la construcción de un software prototipo escrito en JAVA, con un
estilo arquitectónico orientado a servicios Web, permitiendo validar que con su aplicación se
puede minimizar en una gran proporción las vulnerabilidades y asegurar las aplicaciones
web. En la pruebas que se aplicaron en este ejemplo se usaron las validaciones necesarias
desde el punto de vista de la arquitectura del software, el código fuente y seguridad. Para la
prueba de arquitectura se utiliza una herramienta que a través de un análisis que extrae las
características del diseño del prototipo codificado, en este caso como resultado del análisis
se obtuvo que el prototipo cuenta con un alto porcentaje de estabilidad; aplicando los están-
dares y técnicas recomendadas por OWASP a nivel de código y realizando revisiones para
validar el código a través del uso de herramientas y métricas, se puede incrementar la calidad
y seguridad del prototipo; en la última etapa se evalúa la seguridad del prototipo, Para la
validación desde el punto de seguridad del prototipo se utilizan diferentes herramientas de
pruebas, las cuales pueden variar dependiendo el contexto en que se apliquen, se observo
que las mayores problemáticas de seguridad se encuentra relacionadas con la inyección de
código XSS y SQL, además se encontraron graves errores que se desencadenan de errores de
configuración de Autenticación y Autorización.
Como conclusión del trabajo se tienen las recomendación hechas a partir de los resultados
de las pruebas y la recomendación del el uso de normativas OWASP como referencia para el
aseguramiento de aplicaciones web.
1.7. Limitaciones
Este proyecto esta limitado al alcance y tamaño del Sistema de Gestión Documental
durante sus primeros 5 meses de desarrollo que es la duración de el presente proyecto y
aborda los primeros tres ciclos de desarrollo, solo se cubrirán las funcionalidades principales,
no es posible abarcar todo el contexto y funcionalidades del software debido a su alcance
amplio donde se requeriría mayor recursos de personal y un tiempo de desarrollo demasiado
10
Capítulo 1 Universidad Distrital Francisco José de Caldas
largo hasta llegar a una versión madura que cumpla con las condiciones para ser aplicable
en alguna entidad.
Las pruebas se realizaran en un ambiente controlado con datos ficticios simulando lo mejor
posible una aplicación en producción, pero sin llegar realizarlas en una entidad real.
11
Capítulo 2
Marco referencial
2.1. Marco teórico
Una prueba en el desarrollo de software, como una herramienta útil que involucra una
combinación de personas, procesos y tecnologías para la verificación de un correcto funcio-
namiento (Matte Meuccí, 2015). En este caso se utilizan con un enfoque en la seguridad de
la aplicación utilizados durante su desarrollo para garantizar que el sistema de gestión de
documentos desde el inicio de su construcción contemple y aplique medidas de seguridad.
Los sistemas de gestión de documentos generalmente son archivadores digitales que
proporcionan arquitectura para organizar todos los documentos digitales (M. K. Ugale y
Musande, 2017). Permiten controlar el manejo y flujo de documentos dentro de una organi-
zación, convirtiéndolo en una herramienta fundamental en las operaciones diarias de una
organización, que debe contar con garantías de seguridad.
Un sistema de gestión documental esta compuesto por cinco componentes: entrada de
documentos al sistema, almacenamiento, indexación de estos para facilitar identificación,
recuperación de documentos facilitado por búsquedas y retención de los documentos que
permite mantenerlos durante tiempos definidos en caso de ser requeridos. Para el ultimo
caso los tiempos suelen definirse de acuerdo a las leyes y normativas que tienen impacto en
la entidad tanto internas como externas. Además de estos, hay otros componentes que ofre-
cen un rendimiento suplementario y características como clasificación de los documentos,
gestión y actualización de expedientes, radicados, anexos, uso de estadísticas, manejo de
flujos de trabajo, control de acceso a documentos, seguridad, entre otros.(C. Savulescu, 2016)
La seguridad contempla un alto grado de criticidad, pues, desde el punto de vista de software,
los datos son un bien clave a nivel organizacional que deben ser asegurados desde todos
los aspectos (McGraw, 2004). Es necesario aplicar un conjunto de practicas y estándares
12
Capítulo 2 Universidad Distrital Francisco José de Caldas
en la búsqueda del aseguramiento de la información que se compone por tres aspectos
principales:
Confidencialidad: En este aspecto se asegura que la información solo sea accedida por
las personas autorizadas y que para los terceros no sea accesible ni sea descubierta.
Integridad: Se asegura de que la información no pueda ser alterada por terceros no
autorizados y conserve de manera confiable.
Disponibilidad: Garantiza que la información pueda ser accedida cuando se requiera.
Los buenos resultados en el uso de normativas OWASP como referencia para el asegura-
miento de aplicaciones web (D. Guamán, 2017), ofrece ayuda en gran medida a la ausencia
de estándares de seguridad que se deben aplicar en un SGD. Implementar procedimien-
tos almacenados como recomienda OWASP, garantiza el aseguramiento de información y
principalmente previene ataques.
El estándar de internet Json Web Token JWT (J. B. N. S. M. Jones Microsoft, 2015) y
actualizado por JSON Web Signature JWS (M. M. Jones, 2016), para la comunicación entre las
aplicaciones del lado del servidor y del lado del cliente, a sido ampliamente acogido en los
últimos años y es simple, lo cual nos ayuda a cumplir con el objetivo de que el software pueda
ser utilizado, entendido y modificado de forma fácil y con estándares abiertos. También
permite que a futuro el sistema sea inter-operable con otras plataformas, por ejemplo para
aplicaciones móviles. Al ser un estándar común existen gran cantidad de librerías para los
diferentes frameworks y tecnologías que nos permiten la fácil utilización y configuraciones
predefinidas para su uso correcto y seguro. JWT utiliza un token de acceso en cada petición
que identifica al usuario y contiene información, el token se devuelve al usuario después su
autenticación. El servidor es quien decide a quien dar acceso, una de las ventajas de usar el
token es que este es autónomo y puede contener la información necesaria para el correcto
funcionamiento de la aplicación. El tamaño del Json completo suele ser pequeño, esto nos
da facilidad en el transporte de la información, el token es firmado y después verificado por
el servidor.
Dentro del gran número de herramientas usadas en la seguridad, se encuentra a las listas
de control de acceso. Una lista de control de acceso ACL permite gestionar el acceso de
usuarios a diferentes privilegios en un sistema, suele ser usado en sistemas de archivos o en
este caso el acceso a documentos. El ACL utiliza una lista de criterios, pueden tener jerarquía
entre ellos, que se validan al momento en que el usuario solicita acceso, esto lo hace dinámico
y parametrizable dependiendo las necesidades.
13
Capítulo 2 Universidad Distrital Francisco José de Caldas
2.2. Marco Legal
Existe un amplio marco legal y jurídico sobre el que se desarrollan la gestión documental
y el archivo, de todas estas normas es fundamental destacar: la Ley 80 de 1989, por la cual se
crea el Archivo General de la Nación y se dictan otras disposiciones, del congreso de Colombia
que contempla la organización y dirección del Sistema Nacional de Archivos, con el fin de
planear y coordinar la función archivística en toda la Nación, salvaguardando el patrimonio
documental del País para ponerlo al servicio de la comunidad.
La ley 594 de 2000, por medio de la cual se dicta la Ley General de Archivos y se dictan
otras disposiciones, de el Congreso de Colombia que estableció las reglas y principios ge-
nerales que regulan la función archivística del Estado, y determinó como obligación para
las Entidades Públicas, el elaborar programas de gestión documental, en cuya aplicación
deberán observarse los principios y procesos Archivísticos. Adicional mente, es importante
destacar el alcance del Decreto 2609 del 14de diciembre de 2012, por el cual se reglamenta
el título V de la Ley 594 de 2000, de la Presidencia de la Colombia, dispone en su artículo
3º que “la gestión de documentos está asociada a la actividad administrativa del Estado, al
cumplimiento de las funciones y al desarrollo de los procesos de todas las entidades del
Estado; por lo tanto, es responsabilidad de los servidores y empleados, aplicar las normas
que en esta materia establezca el Archivo General de la Nación.”
El Archivo General de la nación es la entidad de orden nacional adscrita al Ministerio de
Cultura, que se encarga de regir y custodiar la normatividad y política archivista. Además
de coordinar el Sistema Nacional de Archivos y la Red Nacional de Archivos, y garantizar la
conservación del patrimonio documental. El decreto 1080 de 2015 del Ministerio de Cultura
“Por medio del cual se expide el Decreto Único Reglamentario del Sector Cultura”, contiene
entre otras cosas la reglamentación archivista que rige al país, en el capitulo 2 , requisitos rara
la gestión de documentos electrónicos define, los lineamientos para programas de gestión
documental. A este decreto lo anteceden los decretos 2609 y 2578 de 2012, para después de
esto citar un solo decreto.
El Archivo General de la Nación obliga a las entidades públicas y aquellas que participen
en licitaciones públicas a manejar los siguientes instrumentos archivísticos, entre otros:
Cuadro de Clasificación Documental(CCD): Instrumento archivístico que se expresa
en el listado de todas las series y susbseries documentales con su correspondiente
codificación.
Tablas de retención documental: Instrumento archivístico que permite la clasificación
14
Capítulo 2 Universidad Distrital Francisco José de Caldas
documental en una entidad, de acuerdo con su estructura orgánico-funcional e indica
los criterios de retención documental en tiempos y disposición final resultante de la
valoración documental por cada una de las agrupaciones documentales dadas en series
y subseries.
Programa de Gestión Documental (PGD): Plan elaborado para facilitar la identificación,
gestión, clasificación, organización, conservación y disposición de la información públi-
ca, desde su creación hasta su disposición final, con fines de conservación permanente
o eliminación.
Este último instrumento es de gran importancia y amplio, para su definición la Ley
General de Archivos 594 de 2000. Ley General de Archivos. Título V: Gestión de Documentos.
Artículo 21, Programas de gestión documental: Las entidades públicas deberán elaborar
programas de gestión de documentos, pudiendo contemplar el uso de nuevas tecnologías
y soportes, en cuya aplicación deberán observarse los principios y procesos archivísticos.
Además de otros decretos que la reglamentan. Entre los cuales se destaca el Decreto 2609
de 2012. Reglamenta el título V de la Ley 594 de 2000, parcialmente los artículos 58 y 589 de
la Ley 1437 de 2011 y se dictan otras disposiciones en materia de gestión documental para
todas las entidades del Estado.
Dentro del uso de tecnologías contempladas en el programa de gestión de documentos cabe
recalcar como herramienta que ayuda a satisfacer gran parte de los requerimientos legales
un Sistema de Gestión Documental.
Para las entidades publicas aplica la ley 1712 de 2014, "Por medio de la cual se crea la
Ley de Transparencia y del Derecho de Acceso a la Información Pública Nacional y se dictan
otras disposiciones". Cuyo objetivo es regular el derecho que cualquier ciudadano tiene de
acceso a la información pública y determina que tipo de información debe tener el acceso
garantizado y sus excepciones. Busca el principio de máxima publicidad de la información
en busca de la transparencia en la ejecución de procesos organizacionales de las entidades
publicas como herramienta para facilitar la veeduria y control por parte de los ciudadanos y
evitar la corrupción.
Para que una entidad publica pueda cumplir con las normas que dicta la ley de trans-
parencia y derecho al acceso a la información, debe tener un buen control y manejo de su
archivistica y gestión documental, siendo un Sistema de Gestión Documental el protago-
nista para que la información documental este organizada y disponible de forma practica y
eficiente.
15
Capítulo 3
Etapa inicial
La etapa inicial es muy importante ya que se toman decisiones que afectan para bien o
para mal a lo largo del proyecto, en ocasiones esta etapa es pasada de forma rápida y simple o
no se tiene en cuenta, lo que ocasiona que el equipo tenga que tomar muchas decisiones en
el camino, por lo general con un enfoque poco general. Desde una perspectiva de seguridad
es importante definir la forma de trabajo del equipo de desarrollo que incluyen políticas y
formas de medir para las retroalimentaciones correctas.
3.1. Ciclo de vida del desarrollo
Las técnicas de ingeniería de la seguridad no suelen estar integradas dentro del proceso
de ingeniería del software, sino que se añaden una vez que el software se ha terminado de
desarrollar(Maña, 2019). Es común que los equipos de desarrollo sólo se preocupen por
las pruebas al final de la construcción del software, incluso ya estando en producción, esta
mala práctica es ineficaz para garantizar la seguridad del software, puede ser que decisiones
mal tomadas durante el desarrollo implique grandes cambios o no se puedan implementar
requerimientos de seguridad, y suele incurrir en gastos y tiempos adicionales, en muchos
casos, no se realizan de forma adecuada las pruebas por cumplir los tiempos de entrega
establecidos y se deja a un lado la perspectiva de la seguridad.
Es fundamental definir un ciclo de vida de desarrollo de software apropiado, en donde se
contemple la seguridad del mismo mediante la definición de normas, políticas y directrices
que encajan y funcionan dentro de la metodología de desarrollo, incluyendo buenas prácticas
y pruebas.
El ciclo de vida del desarrollo de software que se define para este proyecto esta basado
en el modelo en espiral, ya que este tiene en cuenta el análisis de riesgos dentro de cada
16
Capítulo 3 Universidad Distrital Francisco José de Caldas
iteración y permite el inicio del desarrollo de un componente sin necesariamente haber
terminado la anterior, adaptándolo para cumplir las necesidades de seguridad, en la figura
3.1 se muestra una representación general del modelo.
Figura 3.1: Ciclo de vida del desarrollo de software en espiral. El autor.
A continuación se describen las etapas del ciclo de vida del desarrollo del software:
Definición de funcionalidades y requerimientos: Esta etapa se diferencia de la que
normalmente se encuentra en este modelo de desarrollo ya que no hay un cliente,
las necesidades y requerimientos de esta fase están basadas en las funcionalidades
de OrfeoGPL (Jairo Losada, 2002) y los requerimientos extraídos del marco legal que
rige la gestión documental en Colombia. Para completar esta etapa se deben crear las
historias de usuario, casos de uso y diagramas de secuencia.
Planificación: En esta etapa se deben definir los objetivos, recursos a utilizar, tiempos y
los requerimientos para la iteración bien definidos.
Análisis de riesgos: Analizar, estudiar y evaluar los riesgos potenciales, técnicos y de
seguridad a los que se enfrenta la iteración, así como la toma de medidas y decisiones
en la búsqueda de reducir o eliminar los riesgos. Deben quedar documentados los
17
Capítulo 3 Universidad Distrital Francisco José de Caldas
riesgos encontrados y las medidas y decisiones tomadas para implementar en las
etapas siguientes. Se debe realizar el modelo de amenazas y revisión de diagramas en
busca de problemas de seguridad.
Ingeniería y diseño: Se modela y diseña la estructura del nuevo componente de la
aplicación. Al finalizar debe quedar la documentación con los diagramas de clases, de
objetos, de estados y de componentes.
Construcción y adaptación: Fase de desarrollo donde se construye, se prueba y se
integra el componente al software. Debe quedar documentación técnica acerca del
desarrollo así como commit’s y merge necesarios en el repositorio de trabajo.
Evaluación y pruebas: Una vez la construcción del componente esté completa, se
realizarán las correspondientes pruebas de validación, verificación y seguridad. Se eva-
luará si el componente cumple con los requisitos funciones y de seguridad o requiere
mejoras.
3.2. Políticas y estándares
La políticas y estándares son necesarios para la unificación y estandarización de prácticas
que se van a adoptar para el desarrollo del software y así evitar problemáticas de seguridad y
falta de unificación en el código. se describen a continuación:
1. Los framework utilizados son Django (Django Software Foundation, 2018) en su 2
versión y Django REST (Encode OSS Ltd, 2018) para la aplicación de la parte del servidor.
Vue.js (Evan You, 2014) para la aplicación del lado del cliente, y el motor de base de datos
es PostgreSQL (The PostgreSQL Global Development Group, 1996) para la persistencia
de los datos.
2. Se define usar los estándares de internet Json Web Token JWT (J. B. N. S. M. Jones
Microsoft, 2015) y JSON Web Signature JWS (M. M. Jones, 2016) para la comunicación
entre las aplicaciones del lado del servidor y del lado del cliente, adicional la aplicación
del lado del cliente deberá refrescar el token en cada petición que realice.
3. El repositorio de trabajo está alojado en un servidor Git (Linus Torvalds, Junio Hamano
y otros, 2005), esta herramienta también se utiliza como sistema de control de cambios
y versiones durante el desarrollo .
18
Capítulo 3 Universidad Distrital Francisco José de Caldas
4. En un principio se realizan reuniones presenciales semanalmente, para la explicación
de modelos, asignación de tareas y socialización de las mismas, se define la posibilidad
de realizar reuniones virtuales más adelante y aumentar el tiempo entre reuniones
presenciales, dependiendo del ritmo de trabajo que coja el equipo de desarrollo.
5. No se permite el manejo de la base de datos directamente desde el código realizando
consultas SQL, se debe utilizar la capa que ofrece Django a través de sus modelos para
la modificación de la persistencia en la base de datos.
6. Al momento de detectar una vulnerabilidad el equipo de trabajo debe clasificar en tres
categorías dependiendo de su gravedad y del impacto que esta genera, Pueden ser de
impacto bajo, medio o alto y dependiendo de esto se dará la prioridad correspondiente
para solucionar dicha vulnerabilidad. Las vulnerabilidades de alto impacto se deben
mitigar en un tiempo no mayor a dos semanas, las de impacto medio en un tiempo no
mayor a 5 semanas y las de bajo impacto queda a consideración del equipo, pero se
deben mitigar antes de acabar la iteración del ciclo de vida del desarrollo.
Las políticas especiales para la documentación debido a su importancia en un softwa-
re de licencia abierta y para facilitar a los desarrolladores general la documentación y la
intervención del código existente, esas políticas son:
Para la documentación se va a utilizar Sphinx (Georg Brandl, 2008), es una herramienta
hecha en Python, generadora de documentación, que de una forma fácil nos ayuda a
obtener una documentación bonita y ordenada. Esta utiliza reStructuredText el siste-
ma de sintaxis analizador de marcado en texto que se encuentra dentro del proyecto.
Además con la extensión autodoc, la cual nos permite importar módulos que incluyen
grandes cantidades de código y a partir de este obtener la documentación de forma se-
mi automática. La combinación de estas dos herramientas nos permiten de una forma
fácil generar la documentación basada en el código y en los comentarios incluidos en
este.
Para lograr que la documentación quede con lo que deseamos, dentro del código,
dentro de comentarios limitados por 3 comillas dobles (“”” ..... “””) se usa una sintaxis
definida dentro de las directivas de las extensiones.
El desarrollador está en la obligación de generar la documentación dentro del código
durante la fase del ciclo de desarrollo de construcción y adaptación, mientras se escribe
el código.
19
Capítulo 3 Universidad Distrital Francisco José de Caldas
3.3. Criterios de mediciones, métricas y trazabilidad
Es importante tener un plan de mediciones, que defina los criterios a evaluar durante el
ciclo de vida de desarrollo del software. Imprescindible para conocer el estado de seguridad
del proyecto en cualquier momento y para la toma de decisiones.
1. Metas y objetivos del programa de métricas: Proporcionar indicadores que comuniquen
de manera clara y simple qué tan eficiente y efectiva es la manera como se gestiona
la seguridad durante la creación del software de gestión documental para equilibrar
los riesgos de seguridad y las medidas preventivas de modo que se obtenga un sistema
fiable y seguro de acuerdo a las necesidades que este presenta.
Proporcionar herramientas frente a la toma de decisiones durante el proceso de
desarrollo respecto a la seguridad del software.
Poder comparar la evolución del aspecto de seguridad del software a través del
tiempo.
2. Métricas de riesgo de seguridad de la aplicación: El objetivo es identificar, medir y
gestionar el riesgo general del software, para disminuirlo, dependiendo de las vulnera-
bilidades encontradas y su impacto.
Métrica: Proporción actual de vulnerabilidades abiertas. Medición: Número de
vulnerabilidades diferentes descubiertas que se encuentran abiertas.
Métrica: Proporción actual de vulnerabilidades mitigadas. Medición: Número de
vulnerabilidades diferentes descubiertas que se han mitigado.
Métrica: Nivel de riesgo por vulnerabilidad abierta y clasificación Medición: Por-
centaje de riesgo por vulnerabilidad abierta dependiendo del impacto de la misa,
se clasificaron en impacto bajo, medio o alto.
Métrica: Nivel de riesgo general. Medición: Porcentaje de riesgo general, basado
en la cantidad de riesgos de alto y medio impacto; en relación al tiempo.
3. Métricas de seguridad en CVDS para decisiones de mitigación de riesgos. El objetivo es
determinar y medir el rendimiento del equipo al mitigar vulnerabilidades.
Métrica: En cuanto tiempo el equipo logra mitigar vulnerabilidades dependien-
do de su nivel de riesgo . Medición: Tiempo medio en mitigar vulnerabilidades
categorizadas por nivel de riesgo.
20
Capítulo 3 Universidad Distrital Francisco José de Caldas
Métrica: Efectividad del equipo al mitigar vulnerabilidades. Medición: Porcentaje
de cumplimiento en mitigación de vulnerabilidades por tiempo.
Métrica: Efectividad del equipo en la utilización de prácticas de seguridad Medi-
ción: Porcentaje de utilización de prácticas de seguridad por persona del equipo
Objetivo: Identificar y mejorar el manejo de riesgos y prácticas de seguridad en
relación a el ciclo de vida del desarrollo.
Métrica: Medir y mirar la evolución de problemas de seguridad encontrados por
fase del ciclo de vida del desarrollo del software. Medición: Cantidad de problemas
de seguridad encontrados por fase del ciclo de vida del desarrollo del software.
Métrica: Nivel de riesgo de seguridad por fase y seguimiento del mismo. Medi-
ción: Porcentaje de riesgo desarrollo por fase del ciclo de vida del del software
dependiendo de la cantidad de problemas encontrados y el nivel de riesgo de
estos.
Métrica: Nivel de madurez de las prácticas de seguridad por fase. Medición: Cla-
sificación del nivel de madurez en tres categorías, bajo, medio o alto según las
prácticas de seguridad correspondientes utilizadas en cada fase del ciclo de vida
del desarrollo del software.
4. Métricas para la identificación de causas de raíz de vulnerabilidad. El objetivo es medir
y gestionar los orígenes de las vulnerabilidades descubiertas y cómo se distribuyen en
el software aprovechando su distribución modular.
Métrica: Proporción de vulnerabilidad por módulo. Medición: Número de vulne-
rabilidades encontradas por módulo de la aplicación.
Métrica: Proporción de vulnerabilidad por origen de la causa. Medición: Núme-
ro de vulnerabilidades por por origen de la causa(autenticación, autorización,
configuración, validación de datos, entre otros.)
5. Estrategias para generar las métricas
En cada fase del ciclo de vida se realizan las correspondientes revisiones y pruebas
según aplique con el fin de identificar vulnerabilidades y problemas de diseño
respecto a la seguridad.
Se hará un análisis de las causas que generaron las vulnerabilidades y se llevará
registro de estas.
21
Capítulo 3 Universidad Distrital Francisco José de Caldas
Con ayuda de la herramienta Kanboard se hará el seguimiento de los tiempos
transcurridos entre el descubrimiento de la vulnerabilidad y clasificación, el inicio
de las acciones correctivas, la finalización de estas, pruebas y la confirmación de
que se ha solucionado.
6. Puntos referencia. Debido a que el desarrollo empieza de cero, el equipo de trabajo
no ha realizado más proyectos en conjunto que sirvan de guía, no se tendrá un punto
de referencia inicial. El punto de referencia durante el ciclo de vida del desarrollo del
software va a ser la iteración anterior al que se encuentra en desarrollo para hacer
una comparativa a través del tiempo, también se va a hacer referencia a las etapas
anteriores de la misma iteración, con el fin de darle un contexto apropiado a los
criterios y mediciones. Para el caso de la primera iteración se tiene como referencia la
fase de definición y diseño en especial el modelo de amenazas.
7. ¿Cómo se informan las métricas?. Para mostrar los resultados de las métricas se utilizará
en los informes herramientas gráficas para permitir la fácil visualización, análisis y
toma de decisiones. Se usarán tablas, gráficos de barras, tortas, planos cartesianos y
otros.
22
Capítulo 4
Etapa de definición y diseño
A partir de esta fase se repiten en cada iteración del ciclo de de vida del desarrollo. Para la
simplificar los pasos del ciclo de vida en cada iteración, en una primera instancia se realiza la
fase de definición y diseño de una manera general que incluye definición de funcionalidades
y requerimientos, planificación, análisis de riesgos e ingeniería y diseño ya recolectados
durante los primeros tres ciclos de vida, donde se intenta abarcar la mayor cantidad de
aspectos para estas primeras iteraciones, aunque los aspectos que se escapan, algunos muy
específicos que se tienen en cuenta dentro las iteraciones y que dependen del propósito
específico de estas. Cuando se tienen en cuenta las problemáticas de seguridad en esta fase,
es la forma más barata y segura de de solucionarlos, evitando gastos futuros en arreglo de
errores.
Como se describe en la figura 4.1, donde se muestran los pasos en cada iteración del ciclo
de vida del software, lo relacionado al plan de seguridad aparecen en verde, en un principio
se hace la revisión de políticas de desarrollo, manuales, el marco legal, entre otros, con el fin
de determinar los requisitos de seguridad a tener en cuenta. Sigue el diseño, el modelo de
amenazas previos al desarrollo. Después de la construcción se realizan pruebas funcionales
y por último las pruebas de seguridad. Después de realizadas las pruebas se evalúan las
métricas para ese ciclo.
4.1. Requerimientos del sistema
4.1.1. Requerimientos de seguridad
Para el tratamiento de datos personales:
Asegurar el control de acceso solo de personas autorizadas a la información personal
23
Capítulo 4 Universidad Distrital Francisco José de Caldas
Figura 4.1: Ciclo de vida del desarrollo de software en espiral. El autor.
almacenada en la base de datos.
Garantizar la seguridad de información personal, la confidencialidad, integridad y
disponibilidad de consulta.
Anunciar la captura de datos personales y hacer aviso de privacidad de la información.
Mecanismo para la autorización de tratamiento de la información personal por el
titular de la misma.
Para gestión documental y manejo de archivos:
Toda acción hecha sobre un radicado o un expediente debe quedar registrada y poder
ser consultada, este registro debe incluir el usuario o usuarios involucrados, fechas,
hora y descripción de la acción.
Se debe contar con un mecanismo único para eliminar documentos oficiales, restringi-
do sólo a personas autorizadas y este debe garantizar la trazabilidad del documento y
el registro de su eliminación.
Garantizar la autenticidad de documentos de archivo, su integridad, acceso, conserva-
ción e inalterabilidad.
Se debe contar con procedimientos de protección para evitar pérdida o corrupción de
la información.
24
Capítulo 4 Universidad Distrital Francisco José de Caldas
Los documentos no deben ser almacenados cifrados.
Autenticación segura.
• Bloquear después de varios intentos fallidos de autenticación
• Enmascarar cualquier dato confidencial en pantalla (por ejemplo, contraseñas,
cuentas).
• No mostrar errores de validación específicos para el usuario como
• consecuencia de un error de inicio de sesión.
Cifrar las contraseñas usando cifrado no reversible.
Todas las acciones de guardar y actualizar la base de datos deben quedar registradas
para su posible auditoría.
No se debe permitir eliminar usuarios ya que puede haber pérdida de la información
que está asociada a dicho usuario, inhabilitar en el caso de que no se le permita acceso
al sistema.
La visualización y acceso a funcionalidades debe ser controlada mediante el uso de
roles, perfiles por usuario o grupos de usuarios, estas relaciones definen los permisos
que se tienen en la sesión.
En el transporte de la información esta de estar cifrada.
Los usuarios deben estar registrados antes de que puedan acceder a cualquier funcio-
nalidad del sistema
4.1.2. Requerimientos funcionales
Según el decreto 1080 del 2015 en su quinto capítulo, se debe permitir la clasificación
de documentos radicados en la organización de acuerdo a lo dispuesto en la tabla de
retención documental oficial de dicha organización. La tabla de retención documental
debe permitir la relación entre la clasificación documental dada en serie, subserie y
tipo documental, con cada dependencia.
Incluir radicados en expedientes digitales y administrar dichos expedientes, cerrar o
abrirlos,modificar datos, consultar y desvinculación de radicados.
Cada expediente y radicado debe tener un número único consecutivo.
25
Capítulo 4 Universidad Distrital Francisco José de Caldas
Gestionar posibles vínculos archivísticos entre documentos archivístico.
Manejar un archivo digital donde se administrarán los documentos que ya no se
encuentran en gestión, pero se deben mantener para consulta según el tiempo que
especifique su clasificación.
Administrar la tabla de retención documental permitiendo ingresar, editar o borrar sus
relaciones.
Administración del cuadro de clasificación documental, relación de pertenencia de
subseries a series, creación y edición de estas.
Radicación de documentos, asociación de datos y archivos digitales, tanto para imagen
principal como anexos del mismo.
Permitir visualizar y gestionar radicados asignados al usuario, dentro las acciones
de la gestión se encuentra: editar datos, modificar archivos, reasignar a otro usuario,
informar a usuarios.
Búsqueda y consulta de radicados.
Trazabilidad en las acciones hechas sobre radicados y expedientes.
4.1.3. Requerimientos no funcionales
Los requerimientos no funcionales se describen en la tabla 4.1:
Atributo RequerimientoManejo de recursos Se debe poder desplegar el sistema en entornos de bajos
recursos, con por lo menos 2GB de memoria RAM disponi-ble, esto para facilitar los entornos de desarrollo y pruebas.
Usabilidad Los radicados asociados a un usuario debe ser accedidos yorganizados por un sistema de bandejas.
Usabilidad La interfaz de usuario debe correr en los navegadores Mo-zilla Firefox y Google Chrome
Rendimiento La aplicación debe dar respuesta en menos de 5 segundospara el 90% de las solicitudes
Disponibilidad El sistema debe tener la capacidad de estar corriendo24x7x365 con una disponibilidad del 99%
Escalabilidad El sistema debe poder soportar una carga de 300 usuariosconcurrentes.
Cuadro 4.1: Requerimientos no funcionales. El autor.
26
Capítulo 4 Universidad Distrital Francisco José de Caldas
4.2. Descripción general del Software
Se trata de un software de gestión documental pensado para ser de código abierto, ex-
tensible y fácil de comprender. Su implementación va dirigida principalmente a entidades
públicas ya que estas son obligadas a implementar un sistema de gestión documental según
el Archivo General de la Nación, aunque cualquier entidad pública o privada al alcanzar
un tamaño considerable empiezan a tener la necesidad de una administración documental
eficiente. Las tecnologías utilizadas para el proyecto son: el framework Django REST (Django
Software Foundation, 2018) en su versión 2, PostgreSQL (The PostgreSQL Global Develop-
ment Group, 1996) para el almacenamiento de datos, y en la parte del front se va a utilizar
JavaScipt con el framework Vue.js(Evan You, 2014), de las librerías de este framework que se
utilizan se destacan dos, una es Vuetify el cual es un componente utilizado para la parte visual
y de interaccion con el usuario, y Axios, un cliente HTTP diseñado para navegadores que
facilita la interacción son el servicio REST. En la figura 4.2 se observa el diagrama de capas del
flujo de datos en la aplicación. Django al igual que Vue.js nos da la facilidad de trabajar con
Figura 4.2: Diagrama de capas. El autor.
una arquitectura modular basada en componentes que en Django llaman App’s, dentro de
cada una maneja sigue une diseño basado en modelos, y controladores, aunque en este caso
27
Capítulo 4 Universidad Distrital Francisco José de Caldas
lo nombra ‘Models and Views’. En la figura 4.3 se observa el diagrama de componentes del
software. Se especifican componentes individuales que hacen parte del sistema, mostrando
Figura 4.3: Diagrama de componentes. El autor.
como ellos se ajustan al framework y cuáles son responsabilidades. Componentes:
Users: Administrador de la gestión de usuarios, personas, roles, permisos y sesiones.
Utiliza el módulo de Django.auth. Sensible a ataques de suplantación de identidad,
secuestro de sesión
Dependences: Componente encargado de la distribución de usuarios y personas tanto
de manera organizacional como territorial.
Records: Administrador de archivos.
Classifications: Gestiona y administra la clasificación documental según la disposición
del Archivo General de la Nación.
Files: Radicación, visualización y consulta de radicados, transacciones. Encargada del
control de acceso a la información
28
Capítulo 4 Universidad Distrital Francisco José de Caldas
Expedients: Organización y gestión de los radicados agrupándolos en expedientes
digitales, también encargada de la gestión de estos
4.3. Creación y revisión modelos UML
4.3.1. Casos de uso
Los casos de uso nos ayudan a definir los requerimientos funcionales del aplicativo,
se elaboran los casos de uso que se involucran el los primeros ciclos de vida del proyecto,
además estos nos dan el soporte para poder construir los requerimientos futuros.
Figura 4.4: Caso de uso: autenticación. El autor.
Los casos de uso relacionados con la autenticación son de los mas frecuentes, se tiene en
cuenta en todo proyecto donde se hace uso de usuarios para el acceso, como se muestra en
la figura 4.4 el actor es un usuario normal, el cual requiere realizar tres acciones principales:
Iniciar sesión: Debe iniciar sesión con su nombre de usuario único y su contraseña, al-
haceresto el sistema debe cargar la información relacionada con este usuario y permitir
el acceso según sus permisos.
Cerrar sesión: Se usa para que el usuario finalice la sesión de manera segura, evitando
que la sesión permanezca abierta cuando el usuario lo desee.
29
Capítulo 4 Universidad Distrital Francisco José de Caldas
Refrescar el token: Este requerimiento es transparente a el usuario, aún así el lo desen-
cadena cuando realiza diferentes operaciones, la parte de la aplicación en el navegador.
Figura 4.5: Caso de uso: gestión de radicados. El autor.
Para la gestión de radicados que se muestra en la figura 4.5, que es una de las partes
principales de un SGD y son de los primeros requerimientos a cubrir, debe permitir:
Creación de radicados: Para esto debe existir un servicio y un formulario que permitan
introducir los datos principales del radicado, se genera un registro con un número
único de radicado y se le asigna a un usuario para su gestión, en su primera versión
este radicado se debe asociar al usuario que lo genera.
Consulta: Para este caso de uso en una primera instancia se debe permitir la consulta
organizada por parte del usuario de los radicados a cargo, para esto se usará un sistema
de bandejas, además de acceder a una vista dónde se encuentre la información del
radicado. La consulta de radicados general y reportes será un requerimiento general
mas amplio que se deberá realizar en futuras iteraciones.
Modificar atributos: Esta modificación se puede dar desde el mismo formulario de
radicación o desde la vista de información del radicado.
Organizar y clasificar: Del marco legal se desprende el requerimiento de poder clasificar
el radicado según el Cuadro de Clasificación de Documentos CCD de la entidad.
30
Capítulo 4 Universidad Distrital Francisco José de Caldas
Asociar archivos: Se debe poder asociar un archivo como imagen principal del radicado
y si es necesario subir y asociar documentos anexos a este.
Figura 4.6: Caso de uso: administración del sistema. El autor.
La administración del sistema es uno de los módulos base de la aplicación.como se
muestra en la figura 4.6, cuyo actor es el administrador, desprende los siguientes casos de
uso:
Administración de usuarios: Permite la creación y modificación de usuarios.
Administrador de dependencias: Permite la creación y modificación de dependencias,
así como la inclusión de usuarios a dichas dependencias.
Administración del cuadro de clasificación documental: Debe permitir la creación y
modificación de series y sub series documentales, tipos de radicados y las relaciones
entre serie, sub serie, tipo documental y dependencias.
Parametrización general: Debe permitir administrar las variables generales de la apli-
cación, como el nombre y datos de la entidad, colores por defecto, información de
contacto, entre otros.
Otro aspecto importante en la gestión documental es el uso de expedientes para la
organización de radicados, como se muestra en la figura 4.7, cualquier usuario común debe
poder:
31
Capítulo 4 Universidad Distrital Francisco José de Caldas
Figura 4.7: Caso de uso: gestión de expedientes. El autor.
Creación de expedientes: Debe ser a través de un formulario simple donde se capturen
los datos princiapels del expediente
Consulta: se debe poder buscar y consultar la información principal de los expedientes
a los cuales el usuario tiene acceso.
Incluir radicados: se debe poder asociar radicados a los expedientes, un radicado puede
estar en mas de un expediente.
Cerrar expediente: Estado del expediente en el cual no se puede incluir mas radicados
4.3.2. Diagrama de clases
Se realiza un diagrama de clases general que se observa en la figura 4.8 que es usado en
las iteraciones del ciclo de vida, puede tener modificaciones en la iteraciones por aspectos
que no se alcanzan a contemplar en esta etapa.
4.4. Modelo de amenazas
El modelado de amenazas es una técnica de comprobación cuyo objetivo es ayudar a
identificar y planificar de forma correcta, la mejor manera de mitigar las amenazas de una
aplicación mediante un enfoque moderno de análisis de gestión de riesgos, y la implemen-
32
Capítulo 4 Universidad Distrital Francisco José de Caldas
Figura 4.8: Diagrama de clases. El autor.
tación de medidas o controles que contribuyan a mejorar la seguridad. (Barba Olivares,
2017)
33
Capítulo 4 Universidad Distrital Francisco José de Caldas
4.4.1. Dependencias externas
Fortificación del servidor (Hardening): En entornos de producción se recomienda
realizar configuraciones en el servidor como limitar el peso y tipos de archivos a cargar,
dominios de confianza, uso de memoria por sesión, entre otros, dependiendo de la
necesidad y capacidad de cada entidad en la búsqueda de mejorar la seguridad y
rendimiento del software
Firewall: Se recomienda que la aplicación se coloque detrás de un firewall lógico o físico
que ayude a eliminar tráfico indeseado que ponga en riesgo el servidor o directamente
al aplicativo.
Base de datos: La integridad y el correcto acceso de la información depende de una
buena configuración de usuarios, esquemas y privilegios en el motor de base de datos.
4.4.1.1. Niveles de confianza
Alto: Otorgado a una ó un grupo muy pequeño de personas, con los conocimientos y
confianza para acceder con los mayores privilegios a todos los módulos del sistema.
Medio: Se asocia herramientas de actividades de unos cargos muy específicos, para un
grupo pequeño de personas.
Bajo: Asociado al usuario común, suele ser una cantidad grande de personal.
Muy bajo: Todo tipo de petición que realice sin que se haya autenticado e iniciado
sesión.
4.4.1.2. Puntos de entrada
Para la primera fase del proyecto solo se contemplan entradas a través de la interfaz web
por HTTP/S utilizando servicios REST.
Nombre: Módulo de administración.
Descripción: El punto de entrada se refiere a aquellos componentes que están de desig-
nados solo para el administrador, contempla actividades como administración de la
tipología documental, administración de usuarios, permisos, roles, perfiles, dependen-
cias y administración de radicados
Nivel de confianza: Alto
34
Capítulo 4 Universidad Distrital Francisco José de Caldas
Nombre: Correspondencia y Radicación
Descripción: Punto de entrada que se encuentra generalmente en las recepciones y
correspondencia de entidades, allí se realizan actividades como radicar documentos,
digitalizar, distribuir y enviar con empresas de envíos consulta y gestión de radicados y
expedientes. Los usuarios que lo usan suelen ser de una sola dependencia y ser pocos.
Nivel de confianza: Medio
Nombre: Consulta y gestión de radicados y expedientes
Descripción: Módulos de consulta, control de acceso a archivos, visualización, edición
y acciones tomadas sobre radicados. Proviene del usuario común del aplicativo, pueden
llegar ser muchos y tienen permisos limitados, dependiendo sus roles.
Nivel de confianza: Bajo
4.4.1.3. Activos
Nombre: Archivos alojados en el repositorio documental.
Descripción: Archivos digitales alojados de forma organizada en un repositorio docu-
mental, son los todos los documentos oficiales que tramitan en la entidad, contienen
información importante y en algunos casos clasificada.
Nivel de confianza: Cualquier usuario puede acceder a documentos, pero de forma
restrictiva, los criterios se deben manejar en una lista de control de acceso para que
sea parametrizable dependiendo de las necesidades de la entidad.
Nombre: Base de datos.
Descripción: Información general que usa el aplicativo, contiene datos de usuarios,
dependencias, gestión documental, transacciones y trazabilidad de la gestión de radi-
cados. Su información y alteración puede ser de valor para un posible atacante.
Nivel de confianza: Cualquier usuario puede acceder a consultar, modificar o insertar
información alojada en la base de datos, no directamente pero sí a través del aplicativo,
los diferentes niveles de acceso a la información depende de los permisos asignados
con los que cuente un usuario. La información relacionada con trazabilidad no puede
ser modificada o eliminada por ningún usuario ningún punto de entrada con ningún
nivel de confianza.
35
Capítulo 4 Universidad Distrital Francisco José de Caldas
Figura 4.9: Diagrama de flujo de datos. El autor.
Nombre: Archivos alojados en el repositorio documental.
4.4.1.4. Diagrama de flujo de datos
4.4.1.5. Determinar y jerarquizar amenazas
Inicialmente, basado en los diagramas de flujo se hará un análisis en búsqueda de vulne-
rabilidades y amenazas a las que puede estar expuesto cada componente. Para determinar
las amenazas se utiliza el método de clasificación STRIDE, donde cada letra representa una
categoría de amenazas a tener en cuenta en el análisis.
Spoofing - Falsificación.
Tampering - Manipulación.
Repudiation - Repudio.
36
Capítulo 4 Universidad Distrital Francisco José de Caldas
Information disclosure - Revelación de información.
Denial of services - Denegación del servicio.
Elevations of privilege - Elevación de privilegios.
Una forma de lograr determinar las amenazas es descomponer el diagrama de flujo en sus
diferentes componentes y flujos de datos, esto logra un análisis mas exhaustivo para así
determinar sus amenazas.
Para la valoración de las amenazas se usa como referencia el método DREAD por su
simplicidad, donde cada letra representa un criterio que es valorado de 1 a 3 y al final la suma
de todos estos por amenaza da una valoración cuantitativa del riesgo para determinar a que
amenazas enfocarse mas o si es aceptable el riesgo, se clasifican en tres niveles de riesgo
alto para 12 o 13 puntos, medio para 10 u 11 y bajo para 8 o 9, a continuación se listan los
criterios:
Daño potencial, responde a la pregunta ¿Cuánto daño puede generar la explotación de
esta vulnerabilidad?
Reproducibilidad, ¿Qué tan fácil es reproducir las condiciones propicias para el ataque?
Explotabilidad, ¿Qué tan sencillo es hacer el ataque?
Affected users, usuarios afectados, ¿Qué proporcion de usuarios se ven afectados por el
ataque?
Descubrimiento ¿Qué tan fácil es descubrir la vulnerabilidad?
En la cuadro 4.2 se listan las amenazas y su valoración.
A continuación se muestran las amenazas que resultaron del análisis, en esta fase inicial.
37
Capítulo 4 Universidad Distrital Francisco José de Caldas
Amenaza D R E A D Total PuntuaciónEnvenenamiento ARP 2 2 1 2 2 9 Bajo
Robo de sesión 3 2 1 2 1 9 BajoSpoofing IP 2 2 1 2 2 9 Bajo
Spoofing DNS 2 2 1 2 2 9 BajoRepudio 2 2 3 2 2 10 Medio
Inyección de código SQL 3 2 1 2 2 11 MedioAtaque de DOS a la base de datos 2 1 1 3 1 8 Bajo
Ataque de DOS por carga de archivos 2 1 1 3 1 8 BajoCarga de archivos infectados 2 2 2 1 2 9 Bajo
Modificación del repositorio documental 2 1 1 3 2 9 BajoModificación de código 3 1 2 3 2 11 Medio
Revelación de información en red 3 2 2 3 3 13 AltoAtaque DOS en inicio de sesión 2 1 1 3 2 9 Bajo
Modificación de información 3 1 1 2 1 8 Bajo
Cuadro 4.2: Valoración de amenazas por el método DREAD. El autor.
Categoría SpoofingDescripción Envenenamiento ARP, Spoofing IP, DNS spoofing,son riesgos de una
dependencia externa ya que su mitigación depende en parte de prác-ticas a nivel de red.
Objetivo Suplantación de IP para el desvío de trafico.Nivel de riesgo Bajo
Contra medidas Control en el tráfico en la red, medidas de autenticación y sesiónseguros. Con el uso del token de JWT combinado con una correctaconfiguración de los certificados usados en HTTPS se vuelve muycomplicado lograr suplantar un usuario de la aplicación por mas quese haya suplantado la IP a nivel de red.
Cuadro 4.3: Amenaza: Spoofing de red. El autor.
38
Capítulo 4 Universidad Distrital Francisco José de Caldas
Categoría SpoofingDescripción Suplantación de identidad por robo de sesión.
Objetivo Suplantación de identidad por robo de sesión. Ataque que consisteen la explotación del mecanismo de control de la autenticación enbúsqueda de obtener información sensible y manipulación de estacon ataques de hombre en el medio.
Nivel de riesgo BajoContra medidas Mantener las librerías de autenticación actualizadas para evitar vulne-
rabilidades nuevas. Control en el tráfico de red, medidas de autentica-ción y sesionamiento seguros. usar un método de cifrado seguro parael token. Implementación del protocolo HTTPS para que la comunica-ción sea cifrada.
Cuadro 4.4: Amenaza: Spoofing por robo de sesión. El autor.
Categoría RepudiationDescripción El usuario puede negar haber hecho acciones que en realidad sí hizo,
culpando al sistema de un error; o pueden quedar acciones sin registrode quien las hizo.
Objetivo Repudio de acciones por parte de un usuario.Nivel de riesgo Medio
Contra medidas Sistema de registro de acciones realizadas por usuario, incluyendohistóricos por radicado y expedientes.
Cuadro 4.5: Amenaza: Repudio de acciones por parte del usuario. El autor.
Categoría TamperingDescripción Inyección SQL.
Objetivo Acceso y manipulación de la base de datos.Nivel de riesgo Medio
Contra medidas Sanitización de información de fuentes externas, políticas de uso demodelos (Capítulo 3.2.5).
Cuadro 4.6: Amenaza: Inyección de código SQL. El autor.
39
Capítulo 4 Universidad Distrital Francisco José de Caldas
Categoría Denial of servicesDescripción La base de datos es un objetivo común para ataques de denegación de
servicio, buscando, en ocasiones con consultas complejas y en masa omuchas solicitudes de conexión llegar a los límites del procesamientoy uso de memoria del servidor.
Objetivo Poner fuera de servicio la base de datos.Nivel de riesgo Bajo
Contra medidas Tratar de no hacer operaciones que resulten en consulta muy comple-jas. Restringir el acceso a la base de datos a unos pocos host o a undominio, si es posible aislar en una red privada.
Cuadro 4.7: Amenaza: Ataque de negación de servicio a la base de datos. El autor.
Categoría Denial of servicesDescripción En los servicios POST donde se reciben archivos, es vulnerable a ata-
ques en los cuales se intenta subir gran cantidad de archivos y degran tamaño buscando ocupar el procesamiento, memoria y anchode banda del servidor.
Objetivo Poner fuera disponibilidad el servidor del servicio RESTNivel de riesgo Bajo
Contra medidas Una correcta configuración del tamaño máximo permitido para ar-chivos, restringir uso de memoria por sesión y control de tráfico dered.
Cuadro 4.8: Amenaza: Ataque de negación de servicio por envío de archivos. El autor.
Categoría TamperingDescripción En los servicios POST donde se reciben archivos, es vulnerable a ata-
ques en los cuales se intente subir infectados que queden alojados enel servidor o repositorio documental.
Objetivo Infectar con archivos infectadosNivel de riesgo Bajo
Contra medidas Limitar el tipo de archivos a subir y controlar la forma en como seutilizan, también se pueden usar un analizador de archivos.
Cuadro 4.9: Amenaza: Infectar con archivos infectados. El autor.
Categoría TamperingDescripción Modificación de archivos alojados en el repositorio documental.
Objetivo Modificar información sensible alojada en el sistemaNivel de riesgo Medio
Contra medidas Copias de seguridad, uso de hash para comprobación de archivos.
Cuadro 4.10: Amenaza: Modificación de archivos en el repositorio documental. El autor.
40
Capítulo 4 Universidad Distrital Francisco José de Caldas
Categoría TamperingDescripción Modificación o inserción de archivos del código de la aplicación.
Objetivo Alterar el comportamiento de la aplicación, inyección de código, queconsume los recursos de procesamiento y almacenamiento del servi-dor.
Nivel de riesgo MedioContra medidas Copias de seguridad, uso de alguna herramienta de control de ver-
siones como git que ayude a encontrar modificaciones hechas en losarchivos; revisiones frecuentes del esta de los archivos.
Cuadro 4.11: Amenaza: Modificación de archivos del código de la aplicación. El autor.
Categoría Information disclosureDescripción Susceptible a captura y revelación información durante la comunica-
ción y análisis de tráfico.Objetivo Acceso no autorizado a la información que transita por la red.
Nivel de riesgo AltoContra medidas Implementación del protocolo TLS(E. Rescorla, 2018) ó SSL para que
la comunicación sea cifrada.
Cuadro 4.12: Amenaza: Acceso no autorizado a la información que transita por la red. El autor.
Categoría Denial of servicesDescripción En la autenticación, al ser el proceso de cara al usuario puede ser
víctima a un envío en masa de solicitudes de inicio de sesión.Objetivo Poner fuera disponibilidad el servidor del servicio REST en especial el
inicio de sesiónNivel de riesgo Bajo
Contra medidas Implementación del protocolo TLS(E. Rescorla, 2018) ó SSL para quela comunicación sea cifrada.
Cuadro 4.13: Amenaza: Ataque DOS en la autenticación. El autor.
41
Capítulo 5
Etapa de desarrollo
5.1. Primer ciclo
5.1.1. Diseño
Definición de funcionalidades y requerimientos: Esta iteración al ser la primera juega
un papel importante ya que se inicializan los proyectos base y repositorio, se definen y
parametrizan variables generales. Se realiza configuración de usuarios y autenticación
para así conectar las aplicaciones del lado del servidor con la del lado del cliente, esta
parte de la autenticación es de gran importancia ya que se encarga de garantizar que se
cumplan varios de los requisitos de seguridad definidos en el capitulo 4, como lo son el
control de acceso autorizado a la información y la seguridad de la información personal.
Se realiza la importación de librerías y configuración inicial para la documentación
semi automática y se hará la documentación de la parte de la autenticación. Basado en
los casos de uso de autenticación 4.4 se definen los siguientes requerimientos:
• Iniciar sesión: Debe existir un pequeño formulario de autenticación para el usua-
rio donde pueda colocar su nombre y contraseña. La aplicación del lado del cliente
se encarga de enviar los datos del usuario al servidor, este realiza la validación,
si la autenticación es correcta se devuelve a la aplicación del lado del cliente la
respuesta con el token, en el caso contrario se da respuesta de error. Al usuario se
muestra al usuario el mensaje de confirmación o error de inicio de sesión.
• Cerrar sesión: En la interfaz gráfica de usuario a través de un icono o un botón se
debe permitir al usuario la terminación segura de su sesión. Esto desencadena en
el envío de la petición al servidor, este realiza el cierre dela sesión, inhabilita el
42
Capítulo 5 Universidad Distrital Francisco José de Caldas
token y de vuelve la confirmación, al final al usuario se notifica que su sesión se
cerro satisfactoriamente.
• Refrescar el token: La aplicación del lado del servidor debe permitir refrescar el
token, según el estándar JWT, la aplicación del lado del cliente debe solicitar esto
cada cierto tiempo.
Planificación
• Recursos: Se hace uso de las librerías que nos ofrece Django REST Framewrok,
entre las cuales se destacan rest_framework_authentication, rest_framewor_jwt
(Django Software Foundation, 2018), django.contrib.auth, django.contrib.sessions,
estas incluyen las funcionalidades para el manejo de sesiones, autenticación y la
aplicación del estándar JWT. Además la aplicación de la parte de la vista utiliza
librerías incluidas en el framework Vue.js (Evan You, 2014) y otras hechas en
JavaScript. Para el manejo de las peticiones al servidor se utiliza Axios, el token
y el usuario se guardaran en forma de estado en la aplicación, para esto se usa
Vuex.store, el cual es un administrador de estados a los cuales se puede tener
acceso desde cualquier componente de la aplicación.
• Objetivos:
◦ Tener una interfaz de usuario de login, y el cierre de sesión.
◦ Conectar la aplicación de parte del servidor con la aplicación de la vista,
autenticación y manejo de sesión básico.
◦ Repositorios inicializados con las primeras versiones de los proyectos.
5.1.2. Modelado de amenazas
Punto de entrada: Formulario sencillo usando el método POST para el envío de los
parámetros.
Análisis de riesgos:
• Algoritmo para firmar: Una de las decisiones mas importantes en este punto es
definir que algoritmo se va a usar para firmar los tokens, nos encontramos entre
dos posibilidades principales, RSA (K. Moriarty, 2016) algoritmo de criptografía
asimétrica, este proporciona mas fiabilidad al usar un par de llaves y sólo distribuir
la púbica, entonces se puede firmar con la clave privada y verificar con la pública.
43
Capítulo 5 Universidad Distrital Francisco José de Caldas
Por otra parte nos encontramos con el algoritmo HMAC (S. Turner, 2011) mas
sencillo, que solo implementa una llave para firmar y verificar. En este caso se
determina que usar el algoritmo HMAC ya que es mas simple y sencillo de utilizar
para las primeras versiones del aplicativo donde nos interesa tener una base para
el desarrollo de las otras funcionalidades, además la aplicación de la parte de
la vista también está dentro del dominio de los desarrolladores por lo cual se
considera segura. De ser necesario después puede adaptarse al uso de criptografía
asimétrica, se recomienda el uso del estándar OAuth 2 (D. Hardt, 2012) para
versiones próximas a salir a producción si va a tener acceso desde internet.
• Vulnerabilidades del día cero: Al utilizar librerías que son muy usadas actualmen-
te, en muchos proyectos, hay que estar pendientes de las vulnerabilidades que se
descubren, con revisiones frecuentes de las posibles vulnerabilidades y actualiza-
ciones de las librerías. El hecho que sean ampliamente usadas es una ventaja a
hacerse validaciones de seguridad frecuentemente y constantes actualizaciones,
pero al descuidarlas y tener por ejemplo una librearía de una versión muy antigua
podría significar tener alguna vulnerabilidad que todo el mundo puede conocer.
• Relacionado a JWT se conocen dos vulnerabilidades genéricas, aunque ya se
encuentra corregidas en la mayoría de librerías, una de ellas aplica cuando se
intenta cambiar el algoritmo para generar la firma, enviado en el parámetro
correspondiente al algoritmo ’alg’, en la búsqueda de que en algún algoritmo el
mecanismo falle y se pueda hacer pasar información falsa como si fuese real, esta
amenaza es llamada key confusion. Otra amenaza, también tienen que ver con
este parámetro modificado, pero en este caso pasando ’none’ tratando de que se
acepte el no uso de algoritmo y no se verifiquen firmas, perdiendo la garantía de
autenticidad.
Determinar y jerarquizar amenazas:
En el cuadro 5.1 es un listado de las amenazas que se tuvieron en cuenta para este primer
ciclo
5.1.3. Pruebas
Se realizan las pruebas correspondientes para asegurar que las amenazas principales
estén mitigadas y haya un correcto funcionamiento de la autenticación de usuario.
44
Capítulo 5 Universidad Distrital Francisco José de Caldas
Amenaza Abierta PuntuaciónModificación de la información No BajoAtaque DOS en inicio de sesión Si BajoRevelación de información en red No AltoInyección SQL No BajoRepudio No MedioRobo de sesión No BajoSpoofing No BajoFallas JWT No MedioAtaque fuerza bruta de contraseña Si BajoTotal 9 2
Cuadro 5.1: Amenazas de la primera iteración. El autor.
5.1.3.1. Caminatas a través del código
Durante las caminatas a través del código se evidencio una lógica sencilla y correcta
basada en las librerías de los frameworks para la autenticación, aunque se evidencia que
mecanismos de algunas políticas de seguridad no se han cumplido, el uso captcha que deja
abierta una vulnerabilidad a un ataque de negación de servicio en la autenticación y el no
bloqueo al usuario tras varios intentos de inicio de sesión fallidos, lo que deja abierto un
ataque de fuerza bruta con diccionario de contraseñas.
5.1.3.2. Comprobación del Json Web Token
Con el fin de evaluar el comportamiento de los mecanismos de autenticación y garantizar
que las amenazas relacionadas con el JWT se encuentran mitigadas se usa la herramienta
JavaScript Object Signing and Encryption Pentesting Helper JOSEPH ( Dennis Detering, Ruhr-
University Bochum, Spike Reply, 2016) que es una extensión de la plataforma Burp Suite
Community Edition (PortSwigger, s.f.), esta actúa como proxy al interceptar la comunicación
entre la aplicación en el navegador y el servidor, para observarla y alterarla como lo haría un
atacante, además JOSEPH cuentan con herramientas que automatizan y facilitan las pruebas.
Se analiza la estructura del JWT como se observa en la figura 5.1, que esta compuesta por tres
partes el encabezado o header que a la vez esta compuestode dos partes: el algoritmo que
se usa, en enste caso HS256 y el tipo de token, en este caso JWT, la carga útil o payload, que
lleva información adicional y la firma o signature, que es la union del header y el payload,
cada uno codificado en base64, todo esto como entrada del algoritmos SHA265, junto con
una clave secreta, esta firma se usa para la comprobación de la autenticicdad del header y el
payload, en la imagen se observa que este es un Json Web Token normal que se obtiene como
45
Capítulo 5 Universidad Distrital Francisco José de Caldas
respuesta de una correcta autenticación, donde en el payload se entrega la información del
usuario básica que utiliza el cliente.
Figura 5.1: Estructura del Json Web Token.
JOSEPH permite modificar los los datos del Json, como se observa en la figura 5.2 en
este caso basados en una posible vulnerabilidad, se cambia el parámetro del algoritmo ’alg’
del header por ’none’ intentando forzar al servidor a no verificar la autenticidad de los Json
permitiendo la manipulación de la información.
Figura 5.2: Modificación del Json Web Token. El autor.
La respuesta del servidor, como se observa en la figura 5.3 va con el código de estado 401,
no autorizado y como respuesta un Json que muestra el detalle del error ’Credenciales de
autenticación incorrectas’ confirmado el correcto funcionamiento del mecanismo de autenti-
46
Capítulo 5 Universidad Distrital Francisco José de Caldas
cación con esta amenaza. También se comprueba el correcto funcionamiento con la amenaza
Figura 5.3: Respuesta del Json Web Token modificado. El autor.
Key confusion, la herramienta automatiza este proceso, donde envía diferentes paquetes, con
diferentes tipos de algoritmos en el encabezado y verifica las respuesta respuesta, se observa
e en la figura 5.4, el aplicativo de nuevo responde como se esperaba, negando el acceso con
el código de estado 401 para todos los algoritmos.
5.1.4. Análisis
Una amenaza que cabe resaltar, es que por defecto la información del Json va sin cifrar,
se puede observar la información solo con interceptarla e incluso modificarla, viaja a travez
de la red así. Esta amenaza se observa como una vulnerabilidad grave en el caso de que no
se use el protocolo TLS(E. Rescorla, 2018), este provee privacidad y con fiabilidad sobre la
comunicación, impide ataques que están relacionados con la manipulación de la información
cuando viaja por la red.
Según la prueba 5.1.3.2, las librerías que nos Django proporciona están actualizadas y
responden bien ante los posibles errores conocidos, por lo general son aplicaciones mas
antiguas y un poco descuidadas las que suelen ser vulnerables a este tipo de problemas.
A partir de las anotaciones de la prueba de caminata a través del código 5.1.3.1 se tiene
en cuenta la amenaza en la cual el formulario de inicio de sesión se puede utilizar para
ataques DOS, enviando solicitudes de autenticación en masa esto se puede evitar con la
47
Capítulo 5 Universidad Distrital Francisco José de Caldas
Figura 5.4: Ataque Key confusion. El autor.
implementación de un mecanismo como el CAPTCHA que nos permite diferenciar entre
una petición de una persona a peticiones automatizadas, tiempo de espera entre posibles
peticiones del mismo origen o control del tráfico de la red. Debido al la baja puntación que
se le otorgo en la valoración de riesgo, los resultados en el cuadro 4.2, principalmente por
lo poco ocurrente que se de las condiciones ideales en los contextos que se esperan para
plataformas de gestión de este tipo y la complejidad que tiene para realizarse el ataque,
se determina que en en este ciclo no tomarán acciones y se dejará con una autenticación
simple y esta vulnerabilidad abierta, se aconseja en iteraciones futuras volver a evaluar si es
necesario o no implementar alguna medida de mitigación a esta amenaza.
En el cuadro 5.2 se listan las métricas recopiladas durante el primer ciclo.
48
Capítulo 5 Universidad Distrital Francisco José de Caldas
Métrica Valor# de vulnerabilidades abiertas conocidas 2% de vulnerabilidades abiertas conocidas 11.11
Nivel de madurez en aplicación de medidas de seguridad BajoNivel de riesgo general Bajo
Cuadro 5.2: Métricas de la primera iteración. El autor.
5.2. Segundo ciclo: Modulo de administración
En este ciclo se crea un modulo de administración básico, que permita el control de los
modelos principales y se usarán para la gestión de estos, servirá de ayuda en el desarrollo en
ciclos futuros. Además la elaboración de plantilla básica de la página también para usar de
base.
5.2.1. Diseño
Definición de funcionalidades y requerimientos: Basados en en los casos de uso de
la figura 4.6 se definen los siguientes requerimientos.
• Parte visual base de la aplicación, cuenta principalmente con un panel superior
donde se incluyen el menú de manejo de sesión de usuario, además de un panel
izquierdo que se utiliza para el menú de administración y la gestión de radicados.
• Administración de los grupos de clasificación de documentos, CRUD’s de series,
subseries y tipos documentales.
• Administración de dependencias, CRUD básico.
• Administración básica de usuarios, este panel se piensa reemplazar mas adelante
por el modulo de usuarios, roles y permisos, se realiza para facilitar las labores de
desarrollo cuando requiera de manipulación de los usuarios.
Planificación y objetivos: Los requerimientos se pueden dividir en dos grupos de
acuerdo a sus características, la parte visual base y la parte de administración, esta
última es de baja complejidad, que consta de listas y formularios normales, además al
realizar una se puede reutilizar código para las demás.
Para la parte visual se utilizan los módulos de Vue.js, diferentes herramientas que
facilitan la elaboración, añaden dinamismo y aspectos visuales atractivos al usuario.
Para la administración de los modelos en la parte del servidor se utilizan los Serializa-
dores de Django que permiten la personalizar la forma en que se reciben los datos y se
49
Capítulo 5 Universidad Distrital Francisco José de Caldas
modifican los elementos en la base de datos; se utiliza la clase base APIView de Django-
rest-framework que cuentan con los diferentes métodos usados en una arquitectura
REST y sus servicios.
Objetivos:
• Hacer un panel de administración de usuarios básico que permita listar, la crea-
ción y modificación.
• Realizar un módulo de administración de dependencias que permita listarlas,
crearlas, editarlas y eliminarlas.
• Realizar un módulo de administración de clasificaciones para las series, subseries
y tipos documentales que permita listarlos, crearlos, editarlos y eliminarlos.
• Hacer un panel que contenga un menú de navegación, este menú debe indexar
los diferentes componentes de administración.
• Hacer un panel superior donde se localice el titulo de la aplicación, la entidad e
iconos que servirán para las acciones de sesión, otros iconos se reservan para uso
posterior.
5.2.2. Modelo de amenazas
Puntos de entrada: Los puntos de entrada en este caso de parte del usuario son formu-
larios normales para crear o editar elementos enviando peticiones POST al servidor, el
usuario previamente inicio sesión.
Análisis de riesgos: Los riesgos mas frecuentes, para este tipo de módulos, están rela-
cionados con la manipulación de la información que se envía tanto al servidor como la
aplicación de interfaz de usuario, buscando errores que permitan manipular o extraer
información sensible. Otra parte a tener en cuenta es la correcta notificación de errores,
cuando un usuario llena de forma incorrecta un formulario.
Al ser las primeras funcionalidades después de la autenticación, son muy susceptibles a
cometer errores simples, pero que pueden poner en riesgo la seguridad de la aplicación,
para esto es muy importante las revisiones y caminatas a través del código.
Determinar y jerarquizar amenazas
• Repudio: Un usuario puede negar acciones que hizo.
50
Capítulo 5 Universidad Distrital Francisco José de Caldas
• Inyección SQL: Se puede aprovechar los formularios para manipular información
en búsqueda de lograr manipular la base de datos con código SQL.
• Autorización: Un externo o un usuario que no tenga privilegios puede acceder a
módulos que debería estar restringidos, por ejemplo al intentar acceder directa-
mente por la URL.
• Revelación de información.
• Control de errores.
En el cuadro 5.3 es un listado de las amenazas que se tuvieron en cuenta para este segundo
ciclo.
Amenaza Abierta PuntuaciónModificación de la información en red No BajoAutorización Si BajoRevelación de información en red No AltoInyección SQL No BajoRepudio Si MedioManejo de errores Si BajoSpoofing No BajoRevelación de información en la aplicación Si BajoTotal 8 3
Cuadro 5.3: Amenazas de la segunda iteración. El autor.
5.2.3. Pruebas
5.2.3.1. Caminata a través del código
En esta prueba, cuando se realiza a la aplicación de la parte visual, se observa que no
se verifican y ni limpia las entradas del formulario y envía así la solicitud al servidor, la
aplicación del lado del servidor si verifica y devuelve el error, pero al usuario solo se muestra
un error general y no se informa en que parte cometió el error.
La lógica muestra que aún no hay registro histórico de las acciones hechas en este módulo
de administración
5.2.3.2. Acceso no autorizado
Esta es una prueba sencilla donde se busca comprobar que alguien que no ha iniciado
sesión o un usuario no autorizado no pueda acceder y hacer acciones a sitios no autorizados
51
Capítulo 5 Universidad Distrital Francisco José de Caldas
como los de administración. En este caso se intentará ingresar directamente a un modulo de
administración de clasificaciones por medio de la URL por mas que al usuario no le sale en
su menú.
Se entra a la URL /classifications directamente y como se observa en la figura 5.5, se
muestra el el sitio, pero sin datos, al analizar las peticiones hechas por el navegador se pudo
observar que la aplicación de la vista permite el acceso e intenta cargar los datos, pero la
aplicación del lado del servidor devuelve una respuesta con el código 401 de no autorizado,
por lo tanto no hay fuga de información ni se pueden crear elementos, pero se considera
como error y una vulnerabilidad el hecho de que alguien externo pueda ver esas vistas, puede
servir a un atacante para extraer información.
Figura 5.5: Prueba de acceso no autorizado. El autor.
De esta prueba, sumado a la lógica expuesta por el desarrollador, se concluye que la
aplicación de la parte de la vista, maneja bien la parte de sesión y autenticación, pero no
maneja los permisos internos de la aplicación aún en sus diferentes componentes.
5.2.3.3. Inyección SQL
La inyección SQL es una de las vulnerabilidades más comunes y por esta razón se decide
hacer esta prueba, aprovechando la comunicación y los datos que se envían al servidor,
generalmente a través de URL’s y formularios, se trata de buscar algún error en donde el
servidor ejecute sin validar alguna entrada directamente en una consulta SQL en la base de
datos.
Para esta prueba también se usa el módulo de clasificaciones, se modifican los parámetros
enviados del formulario que se muestra en la figura 5.6, usando el inspector de red que trae
Mozilla Firefox ( Mozilla Corporation, Mozilla Foundation, 2002) que trae en sus herramientas
de desarrollo para editar y enviar las peticiones como se muestra en la figura 5.7 usando
como base peticiones reales aprovechando del token y la sesión ya iniciada en el navegador.
52
Capítulo 5 Universidad Distrital Francisco José de Caldas
Figura 5.6: Formulario de creación de una serie. El autor.
Figura 5.7: Edición de las peticiones. El autor.
Para verificar si nuestra aplicación es vulnerable, modificamos los parámetros de diferen-
tes formas, agregando caracteres como ’;’ o partes de consultas SQL como se observa en la
figura 5.7, en la búsqueda de generar un error que de pista acerca de la base de datos, por
lo generar a partir de este error se puede deducir que motor base de datos usa la aplicación
para elaborar un ataque mas sofisticado, se intenta con gran cantidad de cadenas diferentes,
pero la respuesta tiene código 400 de petición errónea y un json que contiene la descripción
del error, siempre devuelve error de sintaxis en el json, en algunas oportunidades devolvió
una respuesta correcta con el código 200 pero lo que hizo fue insertar un registro en donde
algún atributo, por ejemplo el nombre o su descripción quedo como la cadena completa
incluyendo los caracteres que se usaron para buscar error.
No se logró obtener ningún tipo de información de la base de datos, la aplicación del lado
del servidor maneja bien la respuesta, las librerías del Django dan tranquilidad de su buen
funcionamiento.
53
Capítulo 5 Universidad Distrital Francisco José de Caldas
Figura 5.8: Envío de las peticiones. El autor.
5.2.4. Análisis
En base a las revisiones y caminatas sobre el código se determina como vulnerabilidad
abierta, de nivel de riesgo bajo, el manejo de errores en los formularios de administración,
pues el usuario administrador puede ingresar mal algún parámetro y el sistema no le dice en
cual esta el error, en estos formularios no es difícil encontrar el error, no es de tanta gravedad
ya que hay pocas entradas, pero es importante adoptar esas prácticas ya que en formularios
futuros, un poco más grandes puede ser difícil encontrar el error que se comete.
También al no quedar registros de las acciones de administración, queda abierta la
vulnerabilidad de repudio pues no se puede saber que usuario ni cuando a editado, creado o
modificado algo, esta vulnerabilidad se considera grave y tiene que solucionarse antes de
salir a producción.
De la prueba de autorización se mostró que aunque alguien no autorizado no puede
modificar o ver información de la base de datos, hay una vulnerabilidad de revelación de
información, por que así las listas se ven vacías un atacante obtiene información sobre sus
parámetros y relaciones, la revelación de esta información no es tan grave, pero se deben
cerrar todas las fugas de información innecesarias.
Por el contrario la prueba de inyección de SQL nos muestra un correcto funcionamiento
del manejo de los parámetros de las peticiones y las consultas a la base de datos por parte
del Django, dejando esta vulnerabilidad cerrada, aunque se recomienda estar pendientes de
actualizaciones y las vulnerabilidades de día cero que posiblemente afecten estas librerías en
un futuro.
Métrica Valor# de vulnerabilidades abiertas conocidas 3% de vulnerabilidades abiertas conocidas 37.5
Nivel de madurez en aplicación de medidas de seguridad BajoNivel de riesgo general Medio
Diferencia de vulnerabilidades con el ciclo anterior +2
Cuadro 5.4: Métricas de la segunda iteración. El autor.
54
Capítulo 5 Universidad Distrital Francisco José de Caldas
A partir de las métricas mostradas en la tabla 5.4 se puede deducir que bajo el nivel de
seguridad y aumentaron las vulnerabilidades abiertas por ciclo, esto se esperaba, ya que
son las primeras funcionalidades, en general se espera que al principio del desarrollo las
vulnerabilidades aumenten los primero ciclos, hasta que llegue el punto en que se estabilicen
y empiecen a bajar, mientras aumenta el nivel de madures en la aplicación de medidas de
seguridad mientras avanzan las iteraciones. Ya hay dos módulos iniciales, en la figura 5.9 se
muestra la proporción de vulnerabilidades abiertas por módulos.
Figura 5.9: Diagrama de torta: Porcentaje de número de vulnerabilidades por módulo. El autor.
5.3. Tercer ciclo
5.3.1. Diseño
Definición de funcionalidades y requerimientos: Para la getión de radicados, que es
la primera parte para el modulo de correspondencia, basados en en los casos de uso de
la figura 4.5 se definen los siguientes requerimientos.
• Creación y modificación de radicados: Formulario que permite la captura de los
datos principales del radicado, permita asociarlo a un destinatario y asigna un
número único de radicado. Estas acciones deben registradas en el histórico del
radicado.
• Lista y consulta de radicados: Permite a un usuario listar y consultar los radicados
que tiene asignados. Para la visualización de los radicados que cada usuario tiene
a cargo en un momento determinado se crea un sistema de bandejas, una por
tipo de radicado y el modelo debe permitir la creación de bandejas personales
por usuario para añadir este tipo de funcionalidades mas en un futuro.
55
Capítulo 5 Universidad Distrital Francisco José de Caldas
• Visualización de la información del radicado: Vista donde se encuentra toda la
información del radicado, para este primer ciclo incluye también la información
del destinatario e histórico del mismo.
La administración de radicados puede abarcar bastantes temas y estos componentes
van a ser los que mas van a evolucionar a través del tiempo, para el diseño de las vistas,
por ejemplo se tendrán que tener en cuenta en la visualización de la información
espacios para los iconos de acciones, pestañas, entre otros.
Planificación y objetivos
Como primera parte, del lado del servidor se crean los modelos y los servicios relacio-
nados a la radicación, teniendo en cuenta sus posibles tipos y , los consecutivo, según
los requerimientos se definen por defecto los radicados de entrada, salida e internos,
con respecto a la entidad donde se use. A diferencia de los modelos del modulo de
administración los radicados tienen separados los servicios, uno para la creación y otro
para la consulta de la información con URL’s diferentes.
Objetivos:
• Formulario de radicación.
• Bandejas para listar los radicados en gestión.
• Visualización de información básica del radicado.
5.3.2. Modelo de amenazas
Puntos de entrada: Provienen del usuario, hay información que viene por el método
GET, POST y algunas cosas por la URL, que el sistema de direccionamiento de la
aplicación utiliza.
Análisis de riesgos: Para el formulario de radicación es importarte el manejo de errores
para evitar registros con información incompleta o errada. También es importante en
caso de algún error en el formulario notificar al usuario de su error de forma correcta
para que pueda corregirlo.
En la visualización de la información del radicado se presta para que algún usuario con
malas intenciones intente modificar la información que se muestra a su conveniencia,
como por ejemplo una fecha.
56
Capítulo 5 Universidad Distrital Francisco José de Caldas
En la búsqueda de información se encuentran 2 amenazas existentes para las herra-
mientas usadas, en este caso Vue.js. La primera se trata de la vulnerabilidad a un ataque
XSS basado en el DOM del framework, esto cuando trabaja en modo compatibilidad
para un navegador muy viejo o des actualizado (Bemenderfer, 2017). Otra amenaza
relacionada con Vue.js y XSS es una vulnerabilidad relacionada con el componente
v-html[https://blog.sqreen.com/xss-in-vue-js/]. Se recomienda no usarlo para mostrar
información ingresada por el usuario. La publicación es algo antigua pero no se en-
cuentra evidencia de que el problema este solucionado, tambien se recomienda estar
pendientes de las actualizaciones.
Determinar y jerarquizar amenazas
• Cross site scripting (XSS) : Es un problema de seguridad e el que un atacante
logra ejecutar código malicioso en la aplicación del lado del cliente, generalmente
en el navegador. Esto le permite obtener información de la sesión, el token, evadir
controles de acceso y seguridad, modificar información que se visualiza, entre
otros.
Amenaza Abierta PuntuaciónAtaque XSS No MedioAtaque XSS en navegadores viejos Si BajaModificación de la información en red No BajoAutorización Si BajoRevelación de información en red No AltoInyección SQL No BajoRepudio No MedioManejo de errores Si BajoSpoofing No BajoRevelación de información en la aplicación No BajoTotal 10 3
Cuadro 5.5: Amenazas de la tercera iteración. El autor.
5.3.3. Pruebas
5.3.3.1. Caminata a través del código
Para esta iteración se observa que en el modelo ya se empieza a tener en cuenta los regis-
tros históricos de acciones y modificaciones, en este caso sobre los radicados, la radicación y
57
Capítulo 5 Universidad Distrital Francisco José de Caldas
modificación queda registrada con usuario, acción fecha y hora, esto evita la problemática
de repudio de las acciones hechas por un usuario.
También se observa que la aplicación del lado del servidor sólo devuelve la información
específica del error en algunos casos, pero hace falta mejorar esta parte.
Durante la revisión del código se hace una búsqueda recursiva de la etiqueta v-html en
búsqueda de vulnerabilidades, se encuentra en el formulario de radicación, en dos entradas
de información y se corrige para evitar la vulnerabilidad asociada a esta etiqueta.
5.3.3.2. Cross Site Scripting (XSS)
Este ataque se ha vuelto bastante popular en los últimos años y es una de las primeras
amenazas que verifica un atacante cuando se refiere a una aplicación web. Para este caso
vamos a usar de nuevo la herramienta a Burp Suite Community Edition(PortSwigger, s.f.),
usare su proxy para interceptar y modificar el contenido de las peticiones hechas.
Se intentan modificar los parámetros enviados por el método POST y los que van en
la URL, insertando partes de contenido JavaScript buscando que la aplicación lo ejecute
en algún momento, como se observa en la figura 5.10, principalmente en el formulario de
radicación que es donde se ingresa información y se hace uso del componente v-html se
intenta en diferentes URL’s cambiando diferentes parámetros e introducciones diferentes
posibles cadenas que permitan encontrar un error y una vulnerabilidad de inyección de
código. Para analizar si la aplicación es vulnerable se observa el comportamiento de la pagina,
Figura 5.10: Ataque XSS. El autor.
esperando alguna afectación provocada y la consola JavaScript del navegador en búsqueda
de algún error generado o alguna pista. Todas las respuestas son normales, en algunos casos
muestra error en los datos ingresados y en otras simplemente guarda cadenas con caracteres
como nombre o descripción de elementos, pero al visualizar la información así mismo se ven
como cadenas de texto sin ejecutarse en el navegador.
58
Capítulo 5 Universidad Distrital Francisco José de Caldas
5.3.4. Análisis
De las revisiones del código se observa una mejora en la aplicación de medidas como
registro y manejo de errores lo que evidencia una mejora en la madures de aplicación de las
políticas de seguridad.
Con respecto a la vulnerabilidad abierta de ataques XSS en navegadores antiguos se
considera que por ser tan baja la probabilidad de se se den las condiciones ideales para el
ataque no se tomarán medidas al respecto y se aconseja que en las entidades donde pueda
entrar en producción tengan políticas de seguridad respecto a los navegadores que se usan.
De la prueba de XSS se tiene una buena respuesta por parte de la aplicación, no se
observan fugas de información ni vulnerabilidad a este ataque. Respecto a las etiquetas
v-html aunque la información de esta entrada no se usa para mostrar nada después y no
se evidencio ser vulnerable, igual no se recomienda su uso. Como se observa en la tabla de
Métrica Valor# de vulnerabilidades abiertas conocidas 3% de vulnerabilidades abiertas conocidas 30
Nivel de madurez en aplicación de medidas de seguridad MedioNivel de riesgo general Bajo
Diferencia de vulnerabilidades con el ciclo anterior 0
Cuadro 5.6: Métricas de la tercera iteración. El autor.
métricas 5.6 en este ciclo se encontraron la misma cantidad de vulnerabilidades abiertas que
el ciclo anterior, pero el porcentaje bajo, ya que se encontraron mayor número de amenazas.
Un aspecto positivo para el proyecto es la madurez en la aplicación de medidas de seguridad,
esta madures se va ganando y se espera siga mejorando, en este caso se manejan de mejor
forma los registros de lasacciones realizas y el manejo de errores. De la figura 5.11 se observa
que la proporción de vulnerabilidades abiertas por módulo es pareja. Se busca que para
futuras iteraciones las vulnerabilidades de estos primeros módulos baje
59
Capítulo 5 Universidad Distrital Francisco José de Caldas
Figura 5.11: Diagrama de torta: Porcentaje de número de vulnerabilidades por módulo, tercer ciclo.El autor.
60
Capítulo 6
Etapa final
6.1. Resultados
Figura 6.1: Vulnerabilidades por iteración. El autor.
Como se observa en la figura 6.1 en la primera iteración solo se encontró dos vulne-
rabilidades abiertas, en la segunda y tercera se encontraron de a tres, pero el porcentaje
de la tercera fase disminuyo, esto quiere decir que para la tercera fase se tienen en cuenta
mas vulnerabilidades, esto se debe a que a medida que la aplicación va creciendo aumenta
61
Capítulo 6 Universidad Distrital Francisco José de Caldas
funcionalidades, formas de interacción, recursos utilizados, entre otros, a su vez esto hace
que se aumenten la posibles vulnerabilidades a tener en cuenta.
Figura 6.2: Vulnerabilidades y su nivel de riesgo. El autor.
Tanto en la primera como en la tercera iteración tenemos unas pocas vulnerabilidades
abiertas con bajo de riesgo, pero en la segunda iteración si tenemos una vulnerabilidad
abierta de riesgo medio como se ve en la figura 6.2. Por lo anterior se considera la segunda
iteración con nivel de riesgo medio y las otras dos con nivel bajo representado den la figura
6.3. Esto es positivo, por que cuando el equipo fue capaz de mitigar la vulnerabilidad de
riesgo medio cuando se presento y a medida que avanza no aumenta demasiado el numero
de vulnerabilidades de bajo riesgo.
Gracias a las revisiones de código también se evidencio un gran progreso al utilizar buenas
practicas de seguridad, generando una buena documentación y mejorando el manejo de
errores. Como se ve en la figura 6.4 para la tercera iteración se estima un 40% de aplicación
de prácticas de seguridad, y se espera que continúe subiendo para los próximos ciclos.
62
Capítulo 6 Universidad Distrital Francisco José de Caldas
Figura 6.3: Nivel de riesgo general por iteración. El autor.
Figura 6.4: Porcentaje de aplicación de buenas prácticas de seguridad. El autor.
6.2. Impacto
El hecho de lograr que durante el proyecto, desde sus inicios se tenga en cuenta la
perspectiva de seguridad con un marco de trabajo establecido, definición de políticas a seguir
y que en cada iteración de ciclo de vida de desarrollo se tenga un espacio para el análisis y
pruebas de seguridad, dan garantía y soporte de que el proyecto inicia de forma correcta para
63
Capítulo 6 Universidad Distrital Francisco José de Caldas
llegar a ser competitivo y estable desde la perspectiva de seguridad.
Se evidencia el progreso en las pruebas de revisión del código a medida que se avanza
de iteración como el equipo de desarrollo tiene en cuenta y aplica buenas practicas de
desarrollo en general, lo que contribuye a tener un mejor código, mas organizado y legible, lo
que también ayuda en la parte de seguridad a hacer revisiones y seguimiento de forma mas
fácil y evitar errores dados por malas practicas.
Parte importante a la hora de evaluar la perspectiva de seguridad en un proyecto de
software es poder realizar comparaciones respecto a iteraciones pasadas para así observar
comportamientos del equipo de trabajo en cuando al numero de problemáticas que se
encuentran en cada iteración y como es la respuesta ante estas, por ejemplo el tiempo que
se utiliza en solucionar vulnerabilidades y el nivel de esfuerzo requerido, para el análisis de
estos comportamientos y llegar a una correcta toma de decisiones al respecto. Este trabajo
deja un marco de referencia respecto a las tres primeras iteraciones para que en las próximas
se facilite este trabajo de comparación y evaluación de la evolución del proyecto.
En la tabla 5.6 que presenta las métricas registradas al final de la tercera iteración se
muestra que el equipo logra un nivel medio de madurez en la aplicación de medidas de
seguridad, esto es muy importante ya que demuestra el progreso del equipo de desarrollo
lo que contribuye al proyecto en general, se espera mejorar este indicador a medida que se
avanza en el proyecto.
Se espera con los resultados del proyecto contribuir en el aspecto de la seguridad infor-
mática en un Sistema de Gestión Documental libre y de código abierto que puede llegar a
ser implementado en diferentes tipos de entidades a nivel nacional, con lo se aporta a la
protección de la información donde sea implementado.
Además una vez se encuentre al código liberado estará disponible para ser utilizado por
cualquier persona e incluso aportar de manera indirecta en otros proyectos de desarrollo.
6.3. Recomendaciones para el proyecto
Para la parte de la autenticación, si el aplicativo se poner en internet en producción
se recomienda la implementación de criptografía asimétrica y el uso del estándar
OAuth2(D. Hardt, 2012).
En los requisitos de seguridad definidos en el capitulo 4, hay 4 acerca del uso de
tratamiento de datos personales de los cuales hay dos que no se han tenido en cuenta
cuando se realizo la autenticación y manejo de sesión básico del primer ciclo y es
64
Capítulo 6 Universidad Distrital Francisco José de Caldas
notificar el uso y un mecanismo de autorización para el uso de datos personales, estos
deben colocarse en el registro o primer uso del aplicativo.
Para ambientes de producción es importante la correcta configuración y uso de proto-
colo TLS(E. Rescorla, 2018) para una comunicación cifrada.
Realizar periódicamente revisiones de las vulnerabilidades conocidas de las herramien-
tas utilizadas y en dado hacer las actualizaciones de seguridad correspondientes.
Realizar comparaciones en las métricas a con el avance del proyecto para la toma de
decisiones.
6.4. Conclusiones
Las necesidades de seguridad del sistema de gestión documental nacen de distintos
aspectos, durante trabajo se analizó el marco legal, amenazas,vulnerabilidades, activos,
participantes, entre otros para así definir los requerimientos de de seguridad que
satisfacen dichas necesidades.
Se logro de forma satisfactoria la implementación del plan de seguridad dentro del
proyecto.
El equipo de trabajo entendió la importancia y los beneficios del plan. Se genero un
impacto positivo en donde se aprendió y se aplican mejores prácticas de desarrollo.
Uno de los objetivos de el proyecto es determinar la manera correcta en que se debe
otorgar acceso a los documentos, se implementará una lista de control de acceso
ACL que permite el dinamismo y flexibilidad a la hora de definir las reglas de acceso,
aprovechando el uso de roles para distinguir entre diferentes tipos de usuario.
6.5. Anexo:
Como trabajo anexo se entrega una versión resumida del plan de pruebas y seguridad que
se dará al equipo de desarrollo para que lo usen como guía y referencia durante los próximos
ciclos de vida del proyecto.
65
Referencias
Dennis Detering, Ruhr-University Bochum, Spike Reply. (2016). Javascript object sig-
ning and encryption pentesting helper joseph. Descargado de https://github.com/
portswigger/json-web-token-attacker
Mozilla Corporation, Mozilla Foundation. (2002). Mozilla firefox. Descargado de https://
www.mozilla.org/en-US/firefox/
Alfresco Software, I. (s.f.). Alfresco. Descargado de https://alfresco.com/
Barba Olivares, G. E. (2017). Modelado de amenazas, una técnica de análisis y gestión de
riesgo asociado a software y aplicaciones. Universidad Piloto de Colombia.
Bemenderfer, J. (2017, Junio). Render raw html in your vue apps. Descargado de https://
alligator.io/vuejs/raw-html-binding
C. Savulescu, N. D., Z. Polkowski. (2016). Collaborative data management for business:
A review of collaborative techniques. 8th International Conference on Electronics,
Computers and Artificial Intelligence (ECAI), Ploiest, 1–4.
D. Guamán, D. J. M. S., F. Guamán. (2017). Implementation of techniques and owasp security
recommendations to avoid sql and xss attacks using j2ee and ws-security. 12th Iberian
Conference on Information Systems and Technologies (CISTI), Lisbon, 1–7.
D. Hardt, E. (2012, 10). The oauth 2.0 authorization framework (RFC n.o 6749). Internet
Engineering Task Force (IETF). Standards Track. Descargado de https://tools.ietf
.org/html/rfc6749
Django Software Foundation. (2018). Django. Descargado de https://djangoproject
.com/
Encode OSS Ltd. (2018). Django rest. Descargado de https://django-rest-framework
.org/
E. Rescorla, M. (2018, 08). The transport layer security (tls) protocol version 1.3 (RFC n.o
6151). Internet Engineering Task Force (IETF). Standards Track. Descargado de
https://tools.ietf.org/html/rfc6151
Evan You. (2014). Vue.js. Descargado de https://vuejs.org/
66
Capítulo 6 Universidad Distrital Francisco José de Caldas
Georg Brandl. (2008). Sphinx. Descargado de https://sphinx-doc.org/
Jairo Losada, J. R. J. R. F. L. R. O., Denis López. (2002). Orfeogpl. Descargado de https://
orfeogpl.org/
K. Moriarty, B. K. V. J. J., EMC Corporation. (2016, 11). Pkcs 1: Rsa cryptography specifications
version 2.2 (RFC n.o 8017). Internet Engineering Task Force (IETF). Standards Track.
Descargado de https://tools.ietf.org/html/rfc8017
Linus Torvalds, Junio Hamano y otros. (2005). Git. Descargado de https://git-scm.com/
Matte Meuccí, A. M. (2015). OWASP testing guide v4. Open Web Application Security Project
(OWASP).
Maña, D. y. S. C. F. y. V. M., Antonio y Ray. (2019, 12). Integrando la ingeniería de seguridad
en un proceso de ingeniería software. Departamento de Lenguajes y Ciencias de la
Computación de la Universidad de Málaga.
McGraw, G. (2004). Software security. IEEE Security & Privacy, vol. 2, no. 2, 80–83.
M. Jones, J. B. N. S., Microsoft. (2015, 3). Json web token (jwt) (RFC n.o 7519). Internet
Engineering Task Force (IETF). Standards Track. Descargado de https://tools.ietf
.org/html/rfc7519
M. Jones, M. (2016, 2). Json web signature (jws) unencoded payload option (RFC n.o 7797).
Internet Engineering Task Force (IETF). Standards Track. Descargado de https://
tools.ietf.org/html/rfc7797
M. K. Ugale, S. J. P., y Musande, V. B. (2017). Document management system: A notion
towards paperless office recommendations to avoid sql and xss attacks using j2ee
and ws-security. 1st International Conference on Intelligent Systems and Information
Management (ICISIM), Aurangabad, 217–224.
PortSwigger. (s.f.). Burp suite community edition. Descargado de https://portswigger
.net/
S.L., O. D. M. S. (2006). Openkm. Descargado de https://openkm.com/
S. Turner, L. C. N., IECA. (2011, 03). Updated security considerations for the md5 message-
digest and the hmac-md5 algorithms (RFC n.o 6151). Internet Engineering Task Force
(IETF). Standards Track. Descargado de https://tools.ietf.org/html/rfc6151
The PostgreSQL Global Development Group. (1996). Postgresql. Descargado de http://
postgresql.org/
67