plan y pruebas de seguridad de un sistema de gestión

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

[email protected]

Í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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


Figura 4.8: Diagrama de clases. El autor.

tación de medidas o controles que contribuyan a mejorar la seguridad. (Barba Olivares,

2017)

33


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


• 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


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


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


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


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


• 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


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


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


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


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


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


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


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


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

https://github.com/portswigger/json-web-token-attacker

https://github.com/portswigger/json-web-token-attacker

https://www.mozilla.org/en-US/firefox/

https://www.mozilla.org/en-US/firefox/

https://alfresco.com/

https://alligator.io/vuejs/raw-html-binding

https://alligator.io/vuejs/raw-html-binding



https://djangoproject.com/

https://djangoproject.com/

https://django-rest-framework.org/

https://django-rest-framework.org/


https://vuejs.org/


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

https://sphinx-doc.org/

https://orfeogpl.org/

https://orfeogpl.org/


https://git-scm.com/





https://portswigger.net/

https://portswigger.net/

https://openkm.com/


http://postgresql.org/

http://postgresql.org/

plan y pruebas de seguridad de un sistema de gestión

Documents