desarrollo de un sistema de informaciÓn web para la

1

DESARROLLO DE UN SISTEMA DE INFORMACIÓN WEB PARA LA GESTIÓN DE INCIDENTES DE TI EN CORRECOL S.A.

EFRAÍN DÍAZ MEJÍA GERMÁN BARRETO REYES

UNIVERSIDAD PILOTO DE COLOMBIA FACULTAD DE INGENIERÍA DE SISTEMAS

PROGRAMA DE ESPECIALIZACIÓN EN SEGURIDAD INFORMÁTICA BOGOTÁ

2018

DESARROLLO DE UN SISTEMA DE INFORMACIÓN WEB PARA LA GESTIÓN DE INCIDENTES DE TI EN CORRECOL S.A.

EFRAÍN DÍAZ MEJÍA GERMÁN BARRETO REYES

Proyecto de grado para optar por el título de

Especialista en seguridad informática

Asesor Ing. Álvaro Escobar Escobar

UNIVERSIDAD PILOTO DE COLOMBIA FACULTAD DE INGENIERÍA DE SISTEMAS

PROGRAMA DE ESPECIALIZACIÓN EN SEGURIDAD INFORMÁTICA BOGOTÁ

2018

3

Notas de aceptación: ______________________________ ______________________________ ______________________________ ______________________________

______________________________ Firma del presidente del jurado

______________________________ Firma primer jurado

______________________________ Firma segundo jurado

Bogotá D.C., Mayo 2019

4

AGRADECIMIENTOS

Agradezco primero a Dios por haberme dado la fortaleza para poder cumplir mis objetivos, ha sido mi guía en los momentos más difíciles de los cuales me he podido sobreponer con entereza y perseverancia, segundo agradezco también a mis padres por enseñarme primero que la familia es lo más importante y que es la base de una sociedad estable y duradera, que con el trabajo duro, con sacrificio y con transparencia me ayudará a ser cada día una mejor persona Por último agradezco a la Universidad Piloto de Colombia por habernos brindado las herramientas a través del gran grupo de docentes, herramientas y aulas que nos brindaron todos sus conocimientos y así poder elaborar este trabajo de grado el cual fue muy enriquecedor para nuestras carreras profesionales.

Efraín Díaz Mejía

Primero que todo agradezco a Dios por la vida, por tener la oportunidad de aprender cada día más a través de experiencias que enriquecen mi formación personal y profesional, como lo es la participación del Proyecto de Grado, segundo agradecerle a mi Esposa y a mis Padres por su paciencia y apoyo constante en todos los momentos de mi vida. Finalmente quiero dar agradecimiento a los profesionales de la universidad por habernos enseñado la importancia y aplicabilidad de la especialización a través de sus conocimientos y experiencias para nuestra proyección profesional.

Germán Barreto Reyes

5

CONTENIDO

Pág.

INTRODUCCIÓN 17

1. PLANTEAMIENTO DEL PROBLEMA 19

1.1 FORMULACIÓN DEL PROBLEMA 19 2. JUSTIFICACIÓN 20 3. OBJETIVOS 21 3.2 OBJETIVO GENERAL 21

3.3 OBJETIVOS ESPECÍFICOS 21 4. MARCO TEÓRICO 22 4.1 ISO 27001 22

4.2 ISO 27035 24 4.2.1 Objetivos 26

4.2.2 Fases 26 4.2.2.1 Planificar y preparar 26

4.2.2.2 Detección y presentación de informes 26 4.2.2.3 Evaluación y decisión 27

4.2.2.4 Respuestas 27 4.2.2.5 Lecciones aprendidas 27

4.3 ITIL V3 GESTIÓN DE INCIDENTES 27 4.3.1 Proceso de Gestión de Incidentes. 28

4.3.1.8 Relaciones del proceso de gestión de incidentes con otros procesos de ITIL. 31

4.4 SCRUM 32 4.4.1 Pilares de SCRUM 32

4.4.1 Ciclo de Vida de SCRUM 33 4.4.2 Roles 34

4.4.3 Artefactos 34 4.4.4 Ceremonias o reuniones 34

4.5 DEVOPS 35 4.5.1 Beneficios 36

5. MARCO LEGAL 38

5.1 LEY 1273 DE 2009 38 5.2 LEY ESTATUTARIA 1266 DE 2008 38

5.3 LEY ESTATUTARIA 1581 DE 2012 38

6

6. MARCO REFERENCIAL 39

6.1 GENERALIDADES DE LA EMPRESA CORRECOL S.A 39 6.1.1 Reseña Histórica 39

6.1.2 Misión 40 6.1.3 Visión 40

6.1.4 Estructura Organizacional 40 6.1.5 Actividad Económica 40

6.1.6 Procesos Que Maneja La Empresa 41 6.1.7 CORRECOL S.A. Diseño de programas de seguros 42

6.1.8 Inventario y Clasificación de Activos 42 6.1.8.1 Identificación de los activos 42

6.1.8.2 Propietario 43 6.2 SISTEMA DE GESTION DE LA INFORMACIÓN SGI EN LA EMPRESA CORRECOL SA 51 6.2.1 Objetivo y/o propósito del SGI en la empresa 51

6.2.2 Política del SGI de la empresa 51 6.2.2.1 Descripción 51

6.2.2.2 Cumplimiento 51 6.2.3 Diseño del proceso SGI basado en la normatividad y legislación 51

6.2.4 Descripción del proceso 52 6.2.5 Registros. 56

6.2.5 Roles. 56 6.2.6 Protocolos de actuación ante incidentes de seguridad 56

6.3 CARACTERIZACIÓN DE INCIDENTES DEL SGI 56 6.3.1 Incidentes con Activo afectado 58

6.3.2 Indicadores de gestión 62 6.4 2 Entrevista 63

7. METODOLOGÍA PARA EL DESARROLLO DEL SOFTWARE 65

7.1 GESTIÓN DE INCIDENTES 65 7.1.1 Roles 65

7.1.1.2 Funcionarios y contratistas 65 7.1.1.3 Mesa de servicio 65

7.1.2 Etapas 65 7.1.2.1 Reporte del incidente 66

7.1.2.2 Registrar incidente 67 7.1.2.3 Categorización 67

7.1.2.4 Priorización 68 7.1.2.5 Diagnóstico inicial 68

7.1.2.6 Investigación y Diagnostico 68 7.1.2.7 Seguimiento del incidente 70

7.1.2.8 Resolución del incidente 70 7.1.2.9 Cierre del incidente 71

7

7.2 CRONOGRAMA PARA EL DESARROLLO DEL APLICATIVO 71

7.3 DESARROLLO DEL SOFTWARE 76 7.3.1 Etapas de aplicación SCRUM 76

7.3.2 Roles 76 7.3.3 Artefactos 76

7.3.4 Ceremonias 77 8. CONSTRUCCIÓN DEL SITIO WEB Y MODELO RELACIONAL 78 8.1 MODELO RELACIONAL 78

8.1.1 Descripción artefactos Base de datos 80 8.2 CONSTRUCCIÓN APLICATIVO WEB 84

8.2.1 Requerimientos no funcionales. 84 8.2.2 Requerimientos funcionales 86

8.2.3 Requerimientos recomendados del servidor. 88 8.2.4 Configuración de puertos. 88

8.2.5 Software: Requerimientos de software mínimos para la aplicación Web 89 8.2.6 Menús identificados 89

8.2.7 Menú inicial. 90 8.2.8 Menú administrador 93

8.2.9 Menú incidentes 100 8.2.10 Plan de Trabajo 103

8.2.11 Menú Acciones 105 8.2.12 Menú Métricas 107

8.2.13 Base de conocimiento 108 8.2.14 Lecciones aprendidas 110

9. CONCLUSIONES 113

10. RECOMENDACIONES 116

BIBLIOGRAFÍA 117

ANEXOS 120

8

LISTA DE CUADROS

Pág.

Cuadro 1. Documentación obligatoria requerida ISO/IEC 27001 23

Cuadro 2. Registros obligatorios ISO/IEC 27001 24 Cuadro 3. Activos Primarios en CORRECOL S.A. 43

Cuadro 4. Activos Soporte en CORRECOL S.A. 47 Cuadro 5. Descripción del proceso y hallazgos encontrados 53

Cuadro 6. Incidentes registrados por año 57 Cuadro 7. Incidentes con Activo Afectado 59

Cuadro 8. Ejemplo de indicador de gestión de incidentes 62 Cuadro 9. Sistema de priorización 68

Cuadro 10. Valoración propuesta de los activos en CORRECOL S.A. 69 Cuadro 11. Niveles de valoración de activos en CORRECOL SA 69

Cuadro 12. Cronograma proyecto 72 Cuadro 13. Tabla TBL_SGI_PPARAMETRO 80

Cuadro 14. Tabla TBL_SIG_PACCIONES 80 Cuadro 15. Tabla TBL_SIG_PMENU 81

Cuadro 16. Tabla TBL_SIG_PMENU_ROL 81 Cuadro 17. Tabla TBL_SIG_PPARAMETROLISTA 81

Cuadro 18. Tabla TBL_SIG_PPLAN_ACCION 82 Cuadro 19. Tabla TBL_SIG_PROL 82

Cuadro 20. Tabla TBL_SIG_PSEGUIMIENTO_ACCIONES 82 Cuadro 21. Tabla TBL_SIG_PUSUARIO 83

Cuadro 22. Tabla TBL_SIG_TANALISIS_CAUSA 83 Cuadro 23. Tabla TBL_SIG_TINCIDENTE 83

Cuadro 24. Requerimientos no funcionales 84 Cuadro 25. Requerimientos funcionales 86

Cuadro 26. Requerimientos recomendados del servidor 88 Cuadro 28. Controles de tratamiento del riesgo. 182

Cuadro 29. Listado de riesgos. 183

9

LISTA DE GRAFICAS

Pág. Gráfica 1. Distribución por año de incidentes 57

Gráfica 2. Distribución Mensual de Incidentes 58

10

LISTA DE FIGURAS

Pág.

Figura 1. Diagrama de Relación de Objetos en una Cadena de Incidentes de Seguridad de la Información 25 Figura 2. Proceso de Gestión de incidentes en ITIL 28

Figura 3. Nivel de escalamiento ITIL 30 Figura 4. Pilares de SCRUM 32

Figura 5. Ciclo de vida de SCRUM 33 Figura 6. Modelo DevOps 37

Figura 7. Organigrama de la empresa CORRECOL S.A 40 Figura 8. Mapa de procesos empresa CORRECOL S.A. 41

Figura 9. Diagrama de flujo de gestión de incidentes en CORRECOL S.A. 52 Figura 10. Flujo de trabajo de la gestión de incidentes 66

Figura 11. Modelo relacional de la aplicación SGI para CORRECOL SA primera parte 78

Figura 12. DashBoard Aplicación SGI para CORRECOL SA 90 Figura 13. Grafica de los incidentes presentados en el mes en curso 91

Figura 14. Grafica del progreso de proyectos asociados a su área 91 Figura 15. Lista de últimos eventos realizados en la aplicación 92

Figura 16. Grafica del estado actual de los procesos 92 Figura 17. Lista de usuarios de la aplicación SGI 93

Figura 18. Formulario de creación de usuarios de la aplicación SGI 94 Figura 19. Verificación creación de usuario en la aplicación SGI 95

Figura 20. Formulario de actualización de usuario en la aplicación SGI 95 Figura 21. Mensaje de confirmación para inhabilitar usuario 96

Figura 22. Opciones para exportación de los datos 96 Figura 23. Archivo de exportación de datos formato CSV 97

Figura 24. Archivo de exportación de datos formato Excel 97 Figura 25. Archivo de exportación de datos formato Excel 98

Figura 26. Archivo de exportación de datos formato de impresión 98 Figura 27. Vista consulta lista de parámetros 99

Figura 28. Vista edición formulario parámetros 99 Figura 29. Lista de incidentes Aplicación SGI para CORRECOL SA 100

Figura 30. Nuevo incidente 101 Figura 31. Nuevo incidente (Continuación) 102

Figura 32. Descripción del incidente 102 Figura 33. Crear incidente Aplicación SGI para CORRECOL SA 103

Figura 34. Consulta de Incidentes 103 Figura 35. Planes de Trabajo 104

Figura 36. Confirmación Eliminación del plan 104 Figura 37. Acciones 105

11

Figura 38. Lista plan de acción 106

Figura 39. Historial de seguimiento - Acción 106 Figura 40. Cierre de Plan de Trabajo 107

Figura 41. Métricas de la aplicación: Visitas 107 Figura 42. Métricas de la aplicación: Uso 108

Figura 43. Página principal de base de conocimiento 109 Figura 44. Registro de base de conocimiento 110

Figura 45. Lista de lecciones aprendidas 111 Figura 46. Formulario de lecciones aprendidas 112

12

LISTA DE ANEXOS

pág.

Anexo A. Formato de reporte de incidentes 120

Anexo B. Valoración de los activos 123 Anexo C. Direccionamiento Estratégico 147

Anexo D. Sistemas de Gestión 149 Anexo E. Gestión de pólizas y documentos 151

Anexo F. Facturación y Cartera 153 Anexo G. Indemnizaciones 155

Anexo H. Recursos Humanos 157 Anexo I. Tecnología de la información 159

Anexo J. Administrativo y Financiero 161 Anexo K. Control interno 163

Anexo L. POLÍTICAS DE CORRECOL S.A. 165 Anexo M. MODELO DE RIESGOS ACTUAL EN EL SGSI 182

13

GLOSARIO

.NET C#: “es un lenguaje de programación orientado a objetos diseñado por

Microsoft para la infraestructura de lenguaje común, es uno de los lenguajes de programación más utilizados para desarrollar aplicaciones”.1 ASP.NET: “es un modelo de desarrollo Web que unifica los servicios necesarios

para desarrollar aplicaciones Web utilizando el mínimo de líneas de código posibles, es una amplia plataforma de desarrollo para crear aplicaciones Web”.2 CMDB: es la base de datos de gestión de la configuración es una herramienta

utilizada por una organización para almacenar información sobre los activos de hardware y software, comúnmente llamados elementos de configuración. CONFIDENCIALIDAD: es la propiedad que establece que un activo puede estar

disponible y no pueda ser divulgado a individuos, empresas o procesos no autorizados. DASHBOARD: “página en la aplicación Web que contiene la representación de los

principales indicadores que intervienen directamente en la consecución de los objetivos de la compañía”.3 DISPONIBILIDAD: Es la capacidad de que permanezca la información disponible

en el momento indicado en el que los usuarios la requieran. EVENTO DE SEGURIDAD DE LA INFORMACIÓN: es una ocurrencia que se ha identificado en el estado de un servicio, sistema o red, indicando una posible alteración o incumplimiento de la seguridad de la información, falla de los controles e incumplimiento de las políticas, puede ser también un evento desconocido que puede ser relevante para la seguridad pero que no es necesariamente una ocurrencia maliciosa o adversa. GRUPO ISIRT: el equipo de respuesta a incidentes de seguridad de la información

ISIRT o ERISI en Español es un grupo de personas debidamente capacitado y de confianza para la organización que cuenta con las habilidades para tratar los incidentes de seguridad de la información que se presenten durante su ciclo de vida.

1 MICROSOFT. C# guide provides many resources about the C# language [en línea]. Bogotá: La Empresa [citado 29 enero, 2018]. Disponible en Internet: <URL: https://docs.microsoft.com/en-us/dotnet/csharp/> 2 MICROSOFT. What is ASP.NET? [en línea]. Bogotá: La Empresa [citado 29 enero, 2019]. Disponible en Internet: <URL: https://dotnet.microsoft.com/apps/aspnet> 3 ELOSEGUI, Tristán. ¿Qué es un dashboard? [en línea]. Bogotá: Blogs [citado 29 enero, 2019]. Disponible en Internet: <URL: https://tristanelosegui.com/2014/10/27/que-es-y-para-que-sirve-un-dashboard/>

14

IIS: “Internet Information Services o IIS es un conjunto de servicios para servidores

Web y un conjunto de servicios para el sistema operativo Microsoft Windows”.4 INCIDENTE DE SEGURIDAD DE LA INFORMACIÓN: puede ser uno o una cadena de eventos de seguridad de la información que se presentan inesperados o no deseados que tienen una probabilidad significativa de amenazar las operaciones del negocio y comprometen la seguridad de la información. INTEGRIDAD: la información debe permanecer tal cual fue generada, de tal manera

que no puede ser alterada de manera no autorizada ISO: “son normas internacionales y documentos relacionados que cubren casi todas las industrias, desde la tecnología hasta la inocuidad de los alimentos, la agricultura y la sanidad. Las normas internacionales de ISO impactan a todos, en todas partes”.5 ITIL: la biblioteca de infraestructura de tecnologías de la información es un conjunto

de buenas prácticas diseñadas para estandarizar la selección, planeación, entrega y soporte de los servicios de TI dentro de una empresa. MICROSOFT AZURE DEVOPS: “anteriormente llamado Visual Studio Team

Services es un conjunto de herramientas de colaboración basado en la nube que sirve para planear, desarrollar y administrar proyectos de software de cualquier tamaño, en cualquier lenguaje de programación de software”.6 Usando las capacidades de Team Foundation Server, junto con servicios en la nube adicionales, Team Services le ayuda a administrar su código fuente, elementos de trabajo, compilaciones, pruebas y otros recursos. MICROSOFT VISUAL STUDIO: “es un entorno de desarrollo integrado elaborado

por Microsoft que permite realizar desarrollos de diversas aplicaciones en el que se puedan realizar aplicaciones de segundo plano, de escritorio, web, servicios Web y para dispositivos móviles”.7 PROTOCOLO HTTP: el protocolo de transferencia de hipertexto funciona en la capa de aplicación del modelo OSI, “además está basado en el modelo cliente/servidor permitiendo los intercambios de información entre los clientes Web y los servidores

4 MICROSOFT. Internet Information Services (IIS) for Windows [en línea]. Bogotá: La Empresa [citado 29 enero, 2018]. Disponible en Internet: <URL:https://www.iis.net/> 5 ISO. Standards What Is ISO? [en línea]. Bogotá: La Empresa [citado 29 enero, 2018]. Disponible en Internet: <URL:https://www.iso.org/standards.html> 6 MICROSOFT. Azure DevOps [en línea]. Bogotá: La Empresa [citado 29 enero, 2018]. Disponible en Internet: <URL:https://azure.microsoft.com/es-es/services/devops/> 7 MICROSOFT. Microsoft Visual Studio [en línea]. Bogotá: La Empresa [citado 29 enero, 2018]. Disponible en Internet: <URL: https://visualstudio.microsoft.com/es/>

15

HTTP por medio de la World Wide Web”8 PROTOCOLO SMTP: el protocolo SMTP (Simple Mail Transfer Protocol) es

utilizado para el envío de correos electrónicos a través de internet, suministrando la funcionalidad necesaria para conseguir una transferencia fiable y eficiente. SERVICE DESK: en ITIL representa un enfoque total de los servicios que se le

presentan al cliente y a sus usuarios, donde se centralizan todos los procesos de gestión de servicios. SGI: es un sistema que tiene como objetivo la resolución de los incidentes para

restaurar lo más rápidamente el servicio de la organización, debido a cualquier alteración de los servicios de TI. SGSI: el Sistema de Gestión de Seguridad de la Información (SGSI) se basa en la

norma ISO/IEC 27001 y tiene como propósito “asegurar que las empresas tengan implementados todos los controles que permitan la preservación de la confidencialidad, integridad y disponibilidad así como de los sistemas implicados en su tratamiento dentro de una organización”.9 SLA ACUERDOS DE NIVELES DE SERVICIO: es un contrato el cual describe el

nivel de servicio que un cliente espera recibir de su proveedor fundamentalmente por el servicio y los compromisos de calidad, establecen indicadores medibles para poder regular el servicio que se presta y así poder asegurar el cumplimiento del servicio prestado. SOFTWARE GESTOR DE INCIDENTES: un software gestor de incidentes es una

herramienta especializada que permite detectar, registrar, analizar y resolver un incidente durante todo su ciclo de vida, por medio de la priorización y clasificación de los incidentes, optimizando el tiempo de respuesta ante los incidentes por medio de una base de conocimientos que contiene respuestas pre configuradas y sugerencias a soluciones, con el propósito de mejorar la calidad del servicio reduciendo el tiempo para la solución a los problemas. SQL SERVER: es un sistema gestor de base de datos, que permite una fácil

organización y control de los datos por medio de tablas relacionadas. STAKEHOLDERS: involucrados, parte interesada o interesados hace referencia a una persona, organización o empresa que tiene interés en una empresa u

8 WIKIPEDIA. ¿Qué es el Protocolo de Transferencia de Hipertexto? [en línea]. Bogotá: Wikipedia [citado 29 enero, 2018]. Disponible en Internet: <URL: https://es.wikipedia.org/wiki/Protocolo_de_transferencia_ de_hipertexto> 9 INSTITUTO COLOMBIANO DE NORMAS TÉCNICAS Y CERTIFICACIÓN. Tecnología de la información. Técnicas de seguridad. Sistemas de gestión de la seguridad de la información (SGSI). Requisitos. NTC-ISO/IEC27001. Bogotá: ICONTEC, 2006

16

organización dada. TI: tecnologías de la información se refiere a todo lo relacionado con la tecnología

informática como Hardware, Software, Internet o el talento humano que trabajan con tales tecnologías.

17

RESUMEN

En el presente documento se muestra el diseño de la aplicación Web para la gestión de incidentes en la empresa CORRECOL S.A, que permite gestionar de manera oportuna los incidentes presentados en los servicios de TI, adaptando un marco de trabajo de buenas prácticas de desarrollo de software que busque garantizar la preservación de la confidencialidad, disponibilidad e integridad de los activos de la organización. Este desarrollo de software permitirá gestionar y visualizar todo el ciclo de vida de los incidentes presentados en TI, desde el reporte y registro, hasta el cierre del incidente, pasando por las etapas de categorización, priorización, investigación y diagnóstico, escalamiento, seguimiento y resolución. El software ayudará a la toma de decisiones frente al tratamiento de los incidentes de TI presentados que afecten directamente a los activos de la compañía, facilitando la comunicación entre todos los diferentes roles, a través del diseño e implementación de flujos asociados a normas, procedimientos y técnicas bajo un entorno confiable, eficiente y seguro.

18

INTRODUCCIÓN

En la actualidad los sistemas de información son de gran importancia en las compañías para garantizar sus objetivos organizacionales, es por esta razón que el acceso oportuno a la información aumenta la productividad y el esquema de comunicación se hace cada vez más eficaz entre las distintas áreas de la organización, mejorando el tiempo de atención de los clientes tanto internos como externos. La gestión de incidentes es un aspecto clave para el mejoramiento continuo de los procesos de la compañía, sin embargo, ante actividades de alta complejidad por sucesos no habituales que requieren de soluciones inmediatas, es necesario un manejo oportuno que evite inconvenientes de interrupción de los procesos para garantizar la confidencialidad, integridad y disponibilidad de la información. Es por ello que ante sucesos inesperados y al evitar comprometer las operaciones de negocio, es necesario contar con artefactos necesarios que busquen minimizar el impacto negativo en el negocio, garantizando el acceso a la información y que a su vez esté alineada con los objetivos y políticas organizacionales. Este proyecto se realiza con el fin de llevar a cabo el desarrollo de un sistema de información Web para el proceso de gestión de incidentes de TI en la empresa CORRECOL S.A., mediante un modelo metodológico enfocado a las buenas prácticas en el desarrollo de software con el fin de disponer de un mecanismo facilitador a través del cual la compañía logre alcanzar los niveles de eficiencia establecidos en sus procesos.

19

1. PLANTEAMIENTO DEL PROBLEMA

“CORRECOL S.A es una empresa ubicada en la ciudad de Bogotá que presta servicios de intermediación de seguros para personas naturales y jurídicas, teniendo como principal componente el aseguramiento de la satisfacción de sus clientes”10. Actualmente en el área de tecnología se proveen mecanismos para el control de gestión de incidentes que conllevan al mejoramiento continuo en el negocio; sin embargo, ante la vanguardia de cambios tecnológicos y crecimiento de la compañía, se han presentado inconvenientes en la prestación del servicio, dando como resultado la afectación en la disponibilidad, integridad y confidencialidad en los activos de la organización. Hoy en día las acciones preventivas, correctivas y de mejora que se han implementado para mejorar la gestión de incidentes, han ocasionado inconvenientes tales como gastos innecesarios en los procedimientos actuales de acuerdo a la afectación en los activos de la organización y múltiples quejas por parte del área usuaria al momento del diagnóstico y restablecimiento del servicio ante una eventualidad. Es por ello que surge la necesidad de desarrollar un sistema de información capaz de mejorar la gestión de incidentes de TI en CORRECOL S.A, buscando el mejoramiento en tiempos de respuesta y adaptando un modelo metodológico, capaz de aumentar la productividad, además de optimizar los recursos disponibles y mejorar el nivel de satisfacción de los clientes. 1.1 FORMULACIÓN DEL PROBLEMA ¿De qué forma se puede mejorar el proceso de gestión de incidentes de seguridad de la información en CORRECOL S.A?

10 CORRECOL S.A. Diseño de programas de seguros [en línea]. Bogotá: La Empresa [citado 10 octubre, 2018]. Disponible en Internet: <URL: http://www.correcol.com/programas-de-seguros.html>

http://www.correcol.com/programas-de-seguros.html

20

2. JUSTIFICACIÓN

Actualmente los sistemas de información son cada vez más complejos y las empresas dependen más de servicios de tecnologías de la información, por lo que la caída o la interrupción de la operación pueden llegar a tener importantes consecuencias tanto en la obtención de los objetivos como en problemas legales a la compañía, por lo tanto es crucial para las empresas que brindan estos servicios que sean capaces de identificar y resolver fallos que se presenten en los servicios , además que sean resueltos en el lapso más corto posible. Para ello deben tener identificados y controlados en todo momento cuáles son los problemas a los que se pueden enfrentar sus productos o servicios y qué grupo de personas se tienen dedicados a la solución de los mismos teniendo en cuenta los niveles de escalamiento. Un hecho determinante para lograr los objetivos misionales de la compañía es la calidad que se brinda a la hora de solucionar problemas, de ahí es importante saber la valoración del servicio prestado a la solución de los incidentes reportados. Por tal motivo hoy en día es fundamental que las aplicaciones para la gestión de incidentes puedan disponer de un modelo ágil ante los problemas reportados, además de identificar al personal que se encuentre capacitado y disponible en el momento para la solución del inconveniente, estableciendo la carga de trabajo de cada uno con el propósito de reducir el tiempo que se dedica para la planificación de incidentes. La calidad del servicio que brindan a la hora de solucionar incidentes puede ser un hecho determinante para captar o mantener a sus clientes. También es importante conocer la valoración de los clientes en cuanto a la eficacia en la solución de los problemas reportados. Teniendo en cuenta todo lo anterior, se pretende desarrollar una aplicación Web que se encargue de gestionar los incidentes de la compañía CORRECOL S.A para llevar el seguimiento de los incidentes de TI, con la capacidad de adaptación a los distintos flujos de trabajo de la compañía.

21

3. OBJETIVOS

3.2 OBJETIVO GENERAL

Desarrollar una aplicación Web para la gestión de incidentes en la empresa CORRECOL S.A capaz de gestionar de manera oportuna las posibles alteraciones en los servicios de TI, bajo un marco de buenas prácticas de desarrollo de software que busque garantizar la preservación de la confidencialidad, disponibilidad e integridad de los activos de la organización. 3.3 OBJETIVOS ESPECÍFICOS Caracterizar y analizar el sistema actual de información para la gestión de incidentes de TI en CORRECOL S.A. Identificar los requerimientos funcionales y no funcionales de acuerdo a las necesidades del negocio para la construcción del sistema de información Web, que permitan mejorar los procesos de gestión de incidentes de TI para la compañía CORRECOL S.A. Aplicar un modelo Ágil de desarrollo de software que permita realizar entregas de manera iterativa e incremental. Diseñar una arquitectura de software orientada a un modelo estructurado de capas, aplicando buenas prácticas para la construcción del software. Diseñar la interfaz gráfica y el modelo de base de datos, donde se permita la eficiente interacción entre el usuario y la aplicación Web Construir una aplicación que permita detectar, registrar, analizar y resolver incidentes con el fin de mejorar la calidad del servicio de TI.

22

4. MARCO TEÓRICO

La Internet y la Web han avanzado a pasos agigantados mejorando la forma de administrar los procesos en las compañías, también han ayudado a mejorar la manera de trabajar de sus empleados, de tal forma que las organizaciones exigen que estas aplicaciones sean cada vez más rápidas, ligeras y robustas, esto ayudando al desenvolvimiento y adaptación del medio al ser humano; como también ha generado cambios importantes en el manejo y procesamiento de información a través de la tecnología, generando grandes avances que van dejando gran conocimiento y descubrimientos que marcan la historia. Diversos procesos de negocio en las compañías se basan en tecnologías de la información ante los incidentes de TI como consecuencia de las interrupciones en el servicio, pérdida de clientes, pérdida de productividad y pérdidas financieras; por tal motivo las empresas ante la vanguardia de cambios tecnológicos buscan la implementación sistemas capaces de salvaguardar los activos de la organización por el impacto negativo ante un incidente. De acuerdo a la norma ISO 27035 que establece la gestión de incidentes de seguridad de la información, como estrategia global la organización debe poner los controles y procedimientos para permitir un enfoque estructurado y bien planificado de la gestión de incidentes, con el objetivo de evitar o contener los incidentes de seguridad de la información para minimizar los costos causados de manera directa o indirecta. 4.1 ISO 27001 Es una norma que ha sido construida brindando un marco de trabajo para el establecimiento, implementación, operación, seguimiento, revisión, mantenimiento y mejora de un sistema de gestión de la seguridad de la información SGSI, el núcleo central de la norma es velar y proteger los tres bastiones principales de la seguridad de la información, integridad, disponibilidad y confidencialidad, por medio de la investigación de cuáles son los potenciales problemas que podrían afectar la información, es decir la evaluación de los riesgos y luego definiendo lo necesario para que no se materialicen, es decir mitigación y evaluación. “La ISO 27001 se divide en 11 secciones más el anexo A, los títulos de las secciones de la norma son los mismos que se utilizan para la ISO22301 y la ISO9001:2015 y en otras normas de gestión, lo que lo hace más fácil de integrar con estas normas, las secciones de la 0 a la 3 son de carácter introductorio lo que significa que no son obligatorias para su implementación, mientras que las secciones de la 4 a la 10 son obligatorias, lo que implica que una organización tiene que implementar todos estos

23

Requerimientos para cumplir con la norma.”11. El contenido de la norma está dividida en las siguientes secciones: 0. Introducción 1. Alcance 2. Referencias normativas 3. Términos y definiciones 4. Contexto de la organización 5. Liderazgo 6. Planificación 7. Apoyo 8. Funcionamiento 9. Evaluación del desempeño 10. Mejora El Sistema de Gestión de Incidentes SGI se enfoca en la documentación requerida para verificar que se cumpla con la norma ISO/IEC 27001 de una forma correcta, (véase el Cuadro 1): Cuadro 1. Documentación obligatoria requerida ISO/IEC 27001

Documentos Capitulo

Alcance SGSI punto 4.3

Objetivos y política de seguridad de la información puntos 5.2 y 6.2

Metodología de evaluación y tratamiento de riesgos punto 6.1.2

Declaración de aplicabilidad punto 6.1.3 d

Plan de tratamiento de riesgo puntos 6.1.3 e y 6.2

Informe sobre evaluación de riesgos punto 8.2

Definición de roles y responsabilidades de seguridad puntos A.7.1.2 y A.13.2.4

Inventario de activos punto A.8.1.1

Uso aceptable de los activos punto A.8.1.3

Política de control de acceso punto A.9.1.1

Procedimientos operativos para gestión de T.I punto A.12.1.1

Principios de ingeniería para sistema seguro punto A.14.2.5

Política de seguridad para proveedores punto A.15.1.1

Procedimiento para gestión de incidentes punto A.16.1.5

Procedimientos para continuidad del negocio punto A.17.1.2

Requisitos legales, normativos y contractuales punto A.18.1.1

Fuente. INSTITUTO COLOMBIANO DE NORMAS TÉCNICAS Y CERTIFICACIÓN. Tecnología de la información. Técnicas de seguridad. Sistemas de gestión de la seguridad de la información (SGSI). Requisitos. NTC-ISO/IEC27001. Bogotá: ICONTEC, 2006

11 INSTITUTO COLOMBIANO DE NORMAS TÉCNICAS Y CERTIFICACIÓN. Tecnología de la información. Técnicas de seguridad. Sistemas de gestión de la seguridad de la información (SGSI). Requisitos. NTC-ISO/IEC27001. Bogotá: ICONTEC, 2006

24

Los registros obligatorios de la norma, cabe tener en cuenta que los documentos del Anexo A de la norma son obligatorios únicamente si existen riesgos en la implantación, (véase el Cuadro 2). Cuadro 2. Registros obligatorios ISO/IEC 27001

Registros Descripción

Registros de capacitación, habilidades, experiencia y calificaciones

Punto 7.2

Monitoreo y resultados de medición Punto 9.1

Programa de auditoría interna Punto 9.2

Resultados de auditorías internas Punto 9.2

Resultados de la revisión por parte de la dirección Punto 9.3

Resultados de medidas correctivas Punto 10.1

Registros sobre actividades de los usuarios, excepciones y eventos de seguridad

Puntos A.12.4.1 y A.12.4.3

Fuente. INSTITUTO COLOMBIANO DE NORMAS TÉCNICAS Y CERTIFICACIÓN. Tecnología de la información. Técnicas de seguridad. Sistemas de gestión de la seguridad de la información (SGSI). Requisitos. NTC-ISO/IEC27001. Bogotá: ICONTEC, 2006 4.2 ISO 27035

“Es una extensión de la norma ISO/IEC 27000 y se centra en la gestión de incidentes de seguridad de la información, el cual se identifica dentro de la norma como uno de los factores críticos de éxito para el sistema de gestión de seguridad de la información”12. En una organización las políticas y controles de seguridad de la información por si solos no garantizan la protección absoluta de la información, los sistemas de información, servicios o redes, una vez que se hayan implementado controles, cabe la posibilidad que subsistan vulnerabilidades residuales que puedan hacer que la seguridad de la información sea ineficaz, por lo tanto, esto puede tener impactos adversos tanto directos como indirectos en las operaciones comerciales de una organización. Adicionalmente es inevitable que ocurran nuevos casos de amenazas que previamente no hayan sido identificadas, la poca preparación de la organización para hacer frente a estos incidentes hará que cualquier tipo de respuesta será inefectiva y aumentará el grado de impacto adverso al negocio, por consiguiente, es necesario que cualquier organización que tome en serio el proceso de gestión de incidentes de la seguridad de la información tenga un enfoque estructurado y planificado para: Detectar, informar y evaluar los incidentes de seguridad de la información; Responder a incidentes de seguridad de la información, incluida la activación

12 INTERNATIONAL ORGANIZATION FOR STANDARDIZATION ISO. Information technology- information security incident management. DUS ISO/IEC 27035. Ginebra: ISO, 2016, p. 8

25

de controles apropiados para la prevención, reducción y recuperación de los impactos. Reportar vulnerabilidades de seguridad de la información que aún no han sido explotadas que causan eventos y posiblemente incidentes de seguridad de la información, posteriormente evaluarlos y tratarlos apropiadamente ”Aprender de los incidentes y vulnerabilidades de seguridad de la información, instituir controles preventivos y mejorar el enfoque general de la gestión de incidentes de seguridad de la información”13. “Esta Norma Internacional proporciona orientación sobre la gestión de incidentes de seguridad de la información en sus diferentes clausulas, estas cláusulas consisten en varias subcláusulas, que incluyen una descripción detallada de cada fase. El término "gestión de incidentes de seguridad de la información" se utiliza en esta Norma Internacional para la gestión de incidentes no sólo de seguridad de la información, sino también vulnerabilidades de seguridad de la información“14. Figura 1. Diagrama de Relación de Objetos en una Cadena de Incidentes de Seguridad de la Información

Fuente. Elaboración propia

13 Ibid., p. 9 14 Ibid, p. 14

26

Los objetos preexistentes se presentan sombreados, que son afectados por los objetos sombreados que terminan resultando un incidente de seguridad de la información, (véase la figura 1). 4.2.1 Objetivos. Como parte de la estrategia global de seguridad de la información

de una organización, se deben aplicar controles y procedimientos para permitir un enfoque estructurado y bien planificado de la gestión de la información de los incidentes de seguridad de la información desde un punto de vista empresarial, el principal objetivo es evitar o contener los incidentes de seguridad de la información para reducir costos directos e indirectos causados por los incidentes. Los pasos principales para minimizar el impacto negativo directo de los incidentes de seguridad de la información son los siguientes: Detener y contener. Erradicar. Analizar e informar. Seguimiento 4.2.2 Fases. Para cumplir con los pasos para minimizar el impacto se deben seguir las siguientes fases: 4.2.2.1 Planificar y preparar. La gestión eficaz de los incidentes de seguridad de

la información requiere una planificación adecuada, para que un esquema de gestión de incidentes y vulnerabilidades de seguridad de la información sea eficaz y eficiente. Por lo tanto, para que funcione, una organización debe garantizar que las actividades del plan y la fase de preparación incluyan lo siguiente: ”Política de gestión de incidentes de seguridad de la información y compromiso de la alta dirección. Políticas de seguridad de la información y de gestión de riesgos actualizadas tanto a nivel corporativo como de sistema, servicio y nivel de red. Esquema de gestión de incidentes de seguridad de información. Establecimiento del grupo ISIRT. Apoyo técnico y de otro tipo, apoyo del grupo de operaciones”15. 4.2.2.2 Detección y presentación de informes. Esta parte se encarga de realizar

15 Ibíd., p.9

27

la detección y notificación de eventos de seguridad de la información, además se encarga de: Detectar y reportar la ocurrencia de eventos de seguridad de la información (por medios humanos o automáticos).

Recopilación de información sobre eventos de seguridad de la información.

Detectar e informar sobre vulnerabilidades de seguridad de la información.

Registrar completamente toda la información recopilada en la base de datos de gestión de incidentes de seguridad de la información. 4.2.2.3 Evaluación y decisión. Evaluación del evento de seguridad de la información y decisión sobre si es incidente de seguridad de la información. “El ISIRT debe evaluar los eventos de seguridad de la información y confirmar si es o no es un incidente de seguridad de la información. Posteriormente hace una evaluación utilizando la escala de clasificación de incidentes, para confirmar los detalles del incidente potencial, tipo y recurso afectado. Esto debe ser seguido por las decisiones que se tomen sobre cómo debe tratarse el incidente de seguridad de la información, por quien y que prioridad debe tener, así como los niveles de escalamiento.”16 4.2.2.4 Respuestas. Los tipos de respuestas son:

Respuestas al incidente de seguridad de la información, incluido el análisis forense. Recuperación del incidente de seguridad de la información. 4.2.2.5 Lecciones aprendidas. Las lecciones aprendidas son: Análisis forense adicional, si es necesario. Identificación de las lecciones aprendidas. Identificación y mejora de la seguridad de la información. 4.3 ITIL V3 GESTIÓN DE INCIDENTES “La gestión de incidentes en ITIL tiene como objetivo principal manejar el ciclo de vida de todos los incidentes y restablecer el servicio de TI a los usuarios lo más pronto posible, de esta manera poder minimizar el impacto negativo en las operaciones de negocio. Para ello se debe detectar cualquier alteración en los servicios de TI. Una incidencia puede provenir de cualquiera de los siguientes

16 Ibíd., p.24

28

elementos”17. Errores de Software y Hardware. Errores en la operación del servicio. Peticiones de servicio (usuarios). Pedidos. Consultas. “La gestión de incidentes de hace comúnmente a través de un centro de servicio Service Desk, ya que a gran mayoría de estas incidencias provendrán de los usuarios utilizan el servicio, por lo tanto la gestión de incidentes es una labor reactiva.”18 Una correcta gestión de incidentes, al igual que la gestión de problemas, brinda grandes beneficios a la organización, como los siguientes: Las personas más organizadas y concienciadas hacia la consecución de los objetivos del proceso. Mayor satisfacción para los clientes. Generación de mayor conocimiento y mejora del rendimiento del servicio para la organización. 4.3.1 Proceso de Gestión de Incidentes. El ciclo de vida de la gestión de incidentes según el marco de buenas prácticas ITIL v3, (véase figura 2). Figura 2. Proceso de Gestión de incidentes en ITIL

Fuente. RÍOS HUÉRCANO, Sergio. ITIL v3 Manual integro. Sevilla: Biable

17 RÍOS HUÉRCANO, Sergio. ITIL v3 Manual integro. Sevilla: Biable Management, Excellence and Innovation, 2014. p. 79 18 Ibíd., p. 81

29

Management, Excellence and Innovation, 2014. p. 80 4.3.1.1 Recepción y registro. La recepción puede realizarse desde diferentes

orígenes: desde un administrador de eventos, una aplicación web de gestión de incidentes, una llamada telefónica o un correo electrónico, adicionalmente debe incluir por lo menos los siguientes apartados: Servicios afectados. Posibles causas. Nivel de prioridad. Impacto. Recursos asignados para su resolución. Estado de la incidencia. El registro debe hacerse siempre que ocurra una incidencia, para llevar a cabo el seguimiento y pueda ser derivado a la gestión de problemas con sus datos informativos anexados, esto evita que se presente perdida de información, por lo tanto, incrementa la eficiencia de las personas involucradas y del proceso. 4.3.1.2 Clasificación. El objetivo de la clasificación es estimar su impacto en la organización y su prioridad de resolución, dependiendo de su urgencia e impacto en la organización se asignarán los recursos necesarios y un tiempo estimado para su solución, el tiempo, impacto y urgencia pueden variar a lo largo del proceso de análisis de la incidencia, como también pueden ampliarse o recortarse el tiempo de la estimación, esto depende de que tan eficaz es el proceso de estimación o si se presentan soluciones temporales a las incidencias. Si la incidencia presentada tiene un impacto alto en el proceso de continuidad del servicio o bien no se encuentra solución definitiva, se deberá informa a la gestión de problemas, para que lleve a cabo el investigación y análisis más concretos, que permitan las causas que la provocan. A partir de los acuerdos de niveles de servicio se establecen los tiempos máximos en los que se deben responder y resolver los incidentes. “Se deben utilizar herramientas de gestión para el cálculo y la asignación de estas escalas de tiempo, así como para utilizar alertas y escalados para facilitar la respuesta/resolución de las incidencias dentro del tiempo máximo definido.”19 El proceso de investigación contiene de dos fases: 4.3.1.3 Comparación. La búsqueda en la base de datos de incidencias que puedan tener una raíz similar, por lo tanto, una solución rápida al problema, de lo contrario

19 Ibíd., p. 80

30

que no haya ninguna solución se pasará a la siguiente fase. 4.3.1.4 Investigación y diagnóstico. Se realiza el análisis del incidente y si el

primer nivel del centro de servicios tiene la capacidad para resolver la incidencia, de lo contrario se realiza el proceso de asignación o escalado. 4.3.1.5 Escalado. Es la asignación de la incidencia a un nivel superior del cetro de

servicios o a un nivel superior jerárquico para la toma de decisiones en el cambio en la forma de abordar la incidencia, la forma de escalamiento se define de la siguiente manera: Escalado funcional: se asigna a un especialista de mayor nivel técnico para su resolución. Escalado jerárquico: Se asigna a un superior jerárquico para que tome la

decisión de ampliar los recursos asignados o derivar la incidencia a otro tipo de resolución”20 El primer nivel de escalamiento del centro de servicios no suele tener mucha capacidad para resolver los incidentes, dependiendo de cómo se definan los niveles de servicio se desarrollará uno u otro proceso para la resolución de las incidencias, (véase la Figura 3): Figura 3. Nivel de escalamiento ITIL

Fuente. RÍOS HUÉRCANO, Sergio. ITIL v3 Manual integro. Sevilla: Biable

20 Ibíd., p. 82

31

Management, Excellence and Innovation, 2014. p. 82 4.3.1.6 Seguimiento. El seguimiento de los incidentes tienen una relación directa

con el nivel en el que se haya propuesto la solución, si ha sido el primer nivel el que ha propuesto la solución, “será la responsabilidad de la gestión de incidentes o del centro de servicios; sin embargo si la solución propuesta es derivada y solicita cambios, pasará a ser responsabilidad del proceso de gestión de cambios, este grupo debe actualiza la información en las correspondientes bases de datos de incidentes, para que los recursos implicados tengan siempre la información actualizada del estado de la incidencia”21 4.3.1.7 Cierre. Una vez resuelta la incidencia se debe realizar el siguiente proceso de cierre, está compuesto por las siguientes acciones: Comunicación al cliente y a los usuarios de la solución establecida. Actualización de la base de datos de incidentes. Actualización de la CMDB base de datos de gestión de la configuración sobre los elementos de configuración (CI), implicados en el incidente. 4.3.1.8 Relaciones del proceso de gestión de incidentes con otros procesos de ITIL. A continuación, se describen las relaciones del proceso de gestión de

incidentes Gestión de problemas: interaccionan a través de las BBDD de conocimiento y la CMDB, aportando información sobre problemas; errores conocidos; incidencias o problemas actuales; soluciones posibles. Gestión de la configuración: la CMDB aporta información de mucho valor sobre los CI, que pueden estar implicados en la incidencia. Gestión de cambios: existe una comunicación constante entre estos

procesos, de manera que toda incidencia debe ser comunicada a la gestión de cambios, cuando sea necesario establecer una RFC para su resolución. Gestión de la disponibilidad: la monitorización y el seguimiento que se

realiza en este proceso aporta información importante para la detección del posible inicio de la incidencia. Gestión de la capacidad: las incidencias pueden ocurrir por problemas en la

capacidad de la infraestructura TI. Gestión de los niveles de servicio: cuando se actualizan los SLA para

21 Ibíd., p. 83

32

comprobar su cumplimiento, se deben incorporar los informes de seguimiento de la resolución o del estado de las incidencias22. 4.4 SCRUM Como marco de trabajo para el desarrollo de software se encuentra SCRUM, el cual es utilizado para desarrollo y mantenimiento de productos complejos, en donde las empresas pueden abordar problemas complejos adaptativos, y a su vez entregar productos de alto valor productivo y creativo. “Es un marco de trabajo que permite la adaptación de manera iterativa e incremental, rápida, flexible y eficaz para ofrecer un valor significativo de forma rápida en todo el proyecto.” 23 SCRUM se basa en el control de proceso empírico o empirismo el cual asegura que el conocimiento procede de la experiencia y de tomar decisiones basándose en lo que se conoce. 4.4.1 Pilares de SCRUM. La metodología scrum está conformada por los siguientes pilares, (véase la Figura 4). Figura 4. Pilares de SCRUM

Fuente. Elaboración propia Transparencia: Los aspectos del proyecto que tienen relevancia deben de ser

visibles para los responsables de los resultados, por lo tanto requiere que dichos aspectos sean definidos en un estándar común, de tal forma que los observadores compartan un entendimiento común de lo que se está viendo. Algunas de las acciones e ponen de manifiesto la transparencia en el marco de trabajo son: Artefactos: Product Backlog, Sprint Backlog, Sprint e incremento. Radicadores de información: Tableros de información. Reuniones o ceremonias: Daily, Review y Retrospective. Inspección: “Se deben inspeccionar periódicamente los artefactos de SCRUM y el progreso hacia un objetivo, con el propósito de detectar las variaciones, esta inspección no debe ser tan frecuente como para que interfiera en el trabajo.” 24

22 Ibíd., p. 84 23 SCHWABER, Ken y SUTHERLAND, Jeff. La Guía de SCRUM. Bogotá: Scrum Guides, 2016. p. 5 24 Ibíd., p. 4

33

La inspección va a estar representada por las siguientes actividades: Scrum Board: Utilización de un tablero de SCRUM. Revisión del Sprint: Por medio de la ceremonia Sprint Review. Retroalimentación: Por medio del Sprint Retrospective. Adaptación: Cuando en el proyecto se determina que existen variaciones en uno o varios aspectos más allá de lo que se considera permitido, es necesario realizar ajustes que permitan mantener la meta alcanzable, a través de la transparencia y la inspección se pueden encontrar puntos de mejora mientras se implementa SCRUM, por lo tanto, la adaptación es el resultado y eso significa que todos los eventos definidos dentro de SCRUM hacen parte de la adaptación: Cambios en los requerimientos Identificación de los riesgos Reuniones de retrospectiva 4.4.1 Ciclo de Vida de SCRUM. El ciclo de vida que se utiliza en un marco de

trabajo ágil como SCRUM está dividido por varias partes, entre las más importante se encuentran: generación del caso de negocio del proyecto, declaración de la visión del proyecto, calendario y priorización del proyecto, calendario y priorización del producto, iteraciones y entregables por cada iteración y los criterios de aceptación, (véase la Figura 5). Figura 5. Ciclo de vida de SCRUM

Fuente. SCHWABER, Ken y SUTHERLAND, Jeff. La Guía de SCRUM. Bogotá: Scrum Guides, 2016. p. 9

34

4.4.2 Roles. Entender los roles y responsabilidades definidos en el proyecto es

importante para asegurar la exitosa implementación de SCRUM, son los papeles que obligatoriamente se requieren para producir el producto o servicios del proyecto. Product Owner: Representa la voz del cliente y es el encargado de maximizar el

valor del producto, siempre debe tener una visión dual del entorno, primero debe entender y apoyar las necesidades e intereses de todos los Stakeholders, y segundo debe de comprender las necesidades y el funcionamiento del Development Team. Scrum Master: “Es un líder enfocado al servicio, un facilitador, su responsabilidad es asegurar que SCRUM sea entendido y adoptado, está al servicio del Scrum Team para asegurar que se esté siguiendo a cabalidad con los procesos de SCRUM, propicia un ambiente para completar el proyecto con éxito, en donde incluye la labor de eliminar los impedimentos que encuentra el equipo.”25 Development Team: Es equipo de personas responsables de la comprensión de requerimientos, estimación y creación de los entregables, son los principales participantes de la creación del incremento. 4.4.3 Artefactos. A continuación, se explican los artefactos: Product Backlog: Es una lista ordenada de las ideas que se tienen del producto, todo el trabajo que realiza el Development Team debe provenir del Product Backlog. Sprint Backlog: Es la lista de tareas del Product Backlog refinados que han sido

elegidos para ser desarrollados en el sprint actual, empieza el sprint y el Development Team implementa el nuevo incremento del producto definido en el sprint Backlog. 4.4.4 Ceremonias o reuniones. “Para que el proyecto tenga éxito, los mecanismos de comunicación son fundamentales, los equipos de SCRUM emplean una serie de reuniones clave para estructurar el trabajo en equipo”26 Sprint: Es el corazón del marco de trabajo en el cual se crea el incremento del producto. Cada sprint puede considerarse un proyecto con un horizonte o un periodo de tiempo “Time Box” no mayor a un mes. Daily Meeting: Ceremonia que tiene como propósito evaluar y optimizar el progreso hacia el objetivo del Sprint y crear un plan para las siguientes 24 horas, para que esta reunión sea efectiva se debe formular las siguientes tres preguntas: ¿Qué terminé ayer?

25 Ibíd., p. 5 26 Ibíd., p. 7

35

¿Qué voy a terminar hoy? ¿Qué obstáculos o impedimentos si los hubo estoy enfrentando actualmente? Sprint Planning: El trabajo a realizar en el Sprint se planifica en esta ceremonia,

esta planificación se realiza con todo el Scrum Team, en esta ceremonia se define que puede ser terminado en el Sprint y como se completará el trabajo seleccionado, el resultado de esto debe ser plasmado en el Sprint Backlog, estableciendo cual es el Sprint Goal y el esfuerzo. Sprint Goal: Se plantea una Guía para que el equipo de desarrollo trabaje, este

objetivo se debe manejar en macro con respecto a toda la construcción del sprint. Proporciona una guía para el equipo de desarrollo. Sprint Review: Reunión donde se presenta el incremento del producto con el

objetivo de demostrar y validar el trabajo realizado en el Sprint, por lo tanto, se revisa tal incremento y se aprueba o se rechaza las historias de usuario concluidas. Sprint Retrospective: Reunión donde el SCRUM Team revisa y reflexiona sobre

el trabajo realizado en el sprint que acaba de terminar, el equipo discute los aspectos positivos y negativos que se presentaron en el Sprint con el objetivo de mejorar y aprender para los Sprints futuros. 4.5 DEVOPS “DevOps es un conjunto de prácticas que automatizan los procesos entre el desarrollo de software y los equipos de TI para que puedan hacer construcción, pruebas y lanzamientos de software de forma más rápida y confiable. El concepto de DevOps se basa en la construcción de una cultura donde los equipos se fusionan en uno solo, donde los ingenieros participan en todo el ciclo de vida de la aplicación, desde el desarrollo, las pruebas, la implementación y las operaciones, desarrollan una variedad de habilidades no limitadas a una única función”27. DevOps se describe como la forma más eficiente de crear un mecanismo de colaboración eficiente y productiva entre los equipos de desarrollo y operaciones, por lo tanto, al mejorar la colaboración y la eficiencia entre los equipos se reduce el riesgo de producción asociado con los controles de cambios o entregas frecuentes desde el grupo de desarrollo El concepto DevOps “Desarrollo y Operaciones” promueve que en el desarrollo de software empresarial se elimine la línea invisible que existía entre el desarrollo y las operaciones, adoptando nuevos marcos de trabajo de desarrollo, como el desarrollo ágil de aplicaciones, en una empresa tradicional de desarrollo tiene departamentos separados para el desarrollo, operaciones, control de calidad e implementación, ahora se requiere un nivel de colaboración de todas las áreas interesadas. El

27 WORDPRESS. ¿Qué es DevOps? [en línea]. Bogotá: La Empresa [citado 10 octubre, 2018]. Disponible en Internet: <URL: https://articulosit.files.wordpress.com/2012/09/devops.pdf>

36

concepto de DevOps se refiere no solo a la implementación del software, es un conjunto de procesos, métodos y herramientas para optimizar la comunicación entre los departamentos que están involucrados en el proceso de desarrollo de software (véase la figura 6). La adopción del maco de trabajo DevOps se ve impulsado por varios factores: Uso de marcos de trabajo para el desarrollo de aplicaciones agiles, (SCRUM, Kanban). Incremento de la tasa del número de versiones solicitadas por parte de las unidades de negocios. La amplia disponibilidad de virtualización e infraestructura alojada en la nube de proveedores internos y externos. Aumento del uso de procesos de automatización de procesos de regresión, del data center y de las herramientas de la gestión de la configuración. 4.5.1 Beneficios. A continuación, se describen los beneficios: Velocidad: Avance a gran velocidad e innovación que beneficia a los clientes, adaptación rápida a los cambios en los mercados y así adquirir mayor eficacia en la consecución de los resultados empresariales Entrega Rápida: Incrementa la frecuencia y ritmo de la entrega de las versiones de una aplicación, con el propósito de innovar y mejorar el producto entregado con mayor rapidez, entre más rápido se publiquen nuevas características y se arreglen errores, los clientes estarán más satisfechos. Fiabilidad: Garantizar la calidad de las aplicaciones desplegadas, por medio de

las actualizaciones, los cambios de la infraestructura con el propósito de ofrecer una experiencia positiva a los usuarios finales, utilizando prácticas como la integración continua para comprobar que cada cambio es funcional y seguro, adicionalmente tener a la mano herramientas de monitoreo y registro que ayudarán a estar informado del desempeño en tiempo real. El modelo DevOps es una intersección de desarrollo, operaciones de tecnología y calidad (QA), (véase la Figura 6).

37

Figura 6. Modelo DevOps

Fuente. WORDPRESS. ¿Qué es DevOps? [En línea]. Bogotá: La Empresa [citado 10 octubre, 2018]. Disponible en Internet: <URL: https://articulosit.files.wordpress. com/2012/09/devops.pdf>

38

5. MARCO LEGAL

Las empresas tienen la necesidad de establecer políticas y procedimientos adecuados que sean suficientes para garantizar el desarrollo de sus actividades y negocios conforme a las leyes que se encuentran en vigencia, por medio de mecanismos internos de gestión, prevención, control y reacción. De esta forma las compañías deben de integrar dentro de sus estructuras internas y su estrategia de negocio la forma de cómo dar cumplimiento a los preceptos legales o tener protección ante una situación de riesgo que pongan en peligro la estabilidad y continuidad de la actividad de la organización. Teniendo en cuenta lo anteriormente mencionado a continuación se tendrán algunos conceptos legales que son fundamentales para la ejecución de la propuesta: 5.1 LEY 1273 DE 2009 La ley de delitos informáticos por medio de la cual se modifica el Código Penal, se crea un nuevo bien jurídico tutelado denominado "de la protección de la información y de los datos"28 y se preservan integralmente los sistemas que utilicen las tecnologías de la información y las comunicaciones, entre otras disposiciones. La ley se centra en los atentados contra la confidencialidad, la integridad y disponibilidad de los datos y los sistemas informáticos. 5.2 LEY ESTATUTARIA 1266 DE 2008 “Por la cual se dictan las disposiciones generales del hábeas data y se regula el manejo de la información contenida en bases de datos personales, en especial la financiera, crediticia, comercial, de servicios y la proveniente de terceros países y se dictan otras disposiciones”29. 5.3 LEY ESTATUTARIA 1581 DE 2012 “Por la cual se dictan disposiciones generales para la protección de datos personales.”30

28 COLOMBIA. CONGRESO DE LA REPÚBLICA. Ley 1273 (5 enero, 2009). por medio de la cual se modifica el Código Penal, se crea un nuevo bien jurídico tutelado - denominado "de la protección de la información y de los atos" y se preservan integralmente los sistemas que utilicen las tecnologías de la información y las comunicaciones, entre otras disposiciones. Bogotá: El Congreso, 2009. p. 1 29COLOMBIA. CONGRESO DE LA REPÚBLICA. Ley 1266 (31diciembre, 2008). Por la cual se dictan las disposiciones generales del Hábeas Data y se regula el manejo de la información contenida en bases de datos personales, en especial la financiera, crediticia, comercial, de servicios y la proveniente de terceros países y se dictan otras disposiciones. . Bogotá: El Congreso, 2008. p. 1 30 COLOMBIA. CONGRESO DE LA REPÚBLICA. Ley 1581 (17 octubre, 2012). Por la cual se dictan disposiciones generales para la protección de datos personales. Bogotá: El Congreso, 2012. p. 1

39

6. MARCO REFERENCIAL

6.1 GENERALIDADES DE LA EMPRESA CORRECOL S.A

CORRECOL S.A es una empresa que presta servicios de intermediación de seguros que se encuentra ubicada en la Calle 93A No. 11-36 Pisos 4 y 5 Bogotá DC, Colombia. Su propuesta de valor busca ofrecer la mejor opción para cubrir las necesidades de sus clientes en seguros de forma fácil, integral y transparente con la más alta calidad brindando acompañamiento permanente. “CORRECOL adopta una política orientada a la calidad mediante la implementación de un sistema de gestión de calidad bajo la norma 9001 desde el año 2003”31. 6.1.1 Reseña Histórica. CORRECOL S.A. es un aliado líder en la administración de riesgos, gracias a más de 65 años generando confianza y seguridad con hechos. Aunque muchos ven en el riesgo un obstáculo, la empresa ve una oportunidad para que los clientes puedan ahorrar, gestionar e imaginar. “Garantizamos ofrecer la mejor opción para cubrir las necesidades de nuestros asegurados de forma fácil, integral y transparente, la de más alta calidad y acompañamiento permanente.”32 En CORRECOL S.A. se dedica a prestar servicios de intermediación de seguros para personas jurídicas y naturales, teniendo como primer componente de su filosofía empresarial el aseguramiento de la satisfacción de las necesidades de sus clientes. La organización cumple objetivos de mantenimiento y mejoramiento continuo del sistema de gestión, mediante los siguientes postulados. Se cerciora que por medio de: La promoción de la calidad de vida laboral. El aumento de la competencia de nuestro personal. El fomento de la responsabilidad social empresarial. El cumplimiento de los requisitos legales y de otras índoles que estén relacionados con la presentación del servicio, la seguridad, salud en el trabajo y ambiente. La prevención de las enfermedades laborales.

31 CORRECOL S.A. Diseño de programas de seguros [en línea]. Bogotá: La Empresa [citado 20 octubre, 2018]. Disponible en Internet: <URL: http://www.correcol.com/programas-de-seguros.html> 32 CORRECOL S.A. Diseño de programas de seguros [en línea]. Bogotá: La Empresa [citado 20 octubre, 2018]. Disponible en Internet: <URL: http://www.correcol.com/programas-de-seguros.html>

40

Accidentes. Daños a la propiedad. Impacto socio-ambiental. Riesgos prioritarios e impactos significativos de acuerdo a la identificación de peligros, evaluación y valoración de riesgos y establecimientos de controles. Esta política es aplicable a todos nuestros grupos de interés y actividades que estos desarrollen en todos los centros de trabajo. 6.1.2 Misión. “Trabajamos con dedicación para ofrecer un servicio de la más alta

calidad para nuestros clientes. Es por esto que trabajamos cada día por ser el corredor de seguros preferido en el mercado colombiano por nuestra confiabilidad, atención en el servicio y cumplimiento.”33 6.1.3 Visión. En CORRECOL S.A. “estamos de su lado, comprometidos con la protección de nuestros clientes mediante servicios de la más alta calidad en intermediación de seguros”34. 6.1.4 Estructura Organizacional. La compañía CORRECOL S.A Está organizada por las siguientes Gerencias y direcciones (véase la Figura 7). Figura 7. Organigrama de la empresa CORRECOL S.A

Fuente. CORRECOL S.A. Información corporativa. [CD-ROM]. [Bogotá]: La Empresa, 2018. Organigrama empresarial 6.1.5 Actividad Económica. CORRECOL S.A. está enfocada principalmente en

actividades que conciernen a empresas que prestan servicios de actividades de agentes y corredores de seguros, actividades inmobiliarias realizadas con bienes

33 CORRECOL S.A. Misión [en línea]. Bogotá: La Empresa [citado 20 octubre, 2018]. Disponible en Internet: <URL: http://www.correcol.com/programas-de-seguros.html> 34 CORRECOL S.A. Visión [en línea]. Bogotá: La Empresa [citado 20 octubre, 2018]. Disponible en Internet: <URL: http://www.correcol.com/programas-de-seguros.html>

41

propios o arrendados, evaluación de riesgos y daños, y otras actividades de servicios auxiliares, la actividad económica de CORRECOL SA está relacionada a los siguientes códigos: 6621 Actividades de agentes y corredores de seguros: Las actividades involucradas con el establecimiento, la gestión y la administración de planes de seguros o estrechamente relacionadas con ella, pero distintas de las de intermediación financiera. 6629 Evaluación de riesgos y daños, y otras actividades de servicios auxiliares: Las actividades involucradas o estrechamente relacionadas con el establecimiento, la gestión y la administración de planes de seguros o estrechamente relacionadas con ella, pero distintas de las de intermediación financiera. 6810 Actividades inmobiliarias realizadas con bienes propios o arrendados: Las actividades inmobiliarias que se realizan a cambio de una retribución o por contrata incluidos los servicios inmobiliarios. 6.1.6 Procesos Que Maneja La Empresa. CORRECOL S.A Se divide en 4

procesos principales: Procesos Gerenciales, Procesos Misionales, Procesos de Apoyo y procesos de Mejora y control (véase la Figura 8). Para más detalle de los procesos que maneja la empresa dirigirse a los Anexos C, D, E, F, G, H, I, J y K Figura 8. Mapa de procesos empresa CORRECOL S.A.

Fuente. CORRECOL S.A. Información corporativa. [CD-ROM]. [Bogotá]: La Empresa, 2018. Mapa de Procesos

42

6.1.7 CORRECOL S.A. Diseño de programas de seguros. "Posterior al análisis

de condiciones actuales del cliente y de acuerdo a un estudio según sus expectativas, se encuentra el proceso de evaluación de riesgos”35. Como objetivos del diseño del programa, se encuentran: Proteger el capital y los activos de la empresa asegurada. Asegurar la continuidad de sus operaciones. Minimizar los factores de riesgo. Proteger a empleados y terceros. Optimizar los costos de protección. Orientar el cumplimiento de la normatividad y reglamentación vigente. Adecuar el clausulado para que permitan a los asegurados obtener las más ágiles y efectivas indemnizaciones. 6.1.8 Inventario y Clasificación de Activos. Para la compañía es fundamental

brindar protección sobre sus activos, estableciendo normas y reglas para su correcta clasificación. De acuerdo a lo mencionando en la norma 27001:2013, todos los activos deben estar claramente identificados, clasificados y documentados, además de la importancia de implementación de reglas para el correcto uso de la información, garantizando la valoración correcta para la confidencialidad, disponibilidad e integridad de los activos. 6.1.8.1 Identificación de los activos. Para la identificación de activos, se tuvo en

cuenta la realización de comités operativos y directivos contando con la participación de roles claves para la identificación y definición de estrategias de control. Con base en la norma ISO 27005, la identificación de activos debe realizarse a un nivel de detalle apropiado teniendo en cuenta los dueños de los activos y los procesos de negocio a los que pertenecen. Activos primarios según la norma ISO27005: son los procesos y la información central de la actividad en el alcance. Activos de soporte: Elementos de procesamiento de información, los cuales, al ser vulnerados, pueden deteriorar los activos primarios del alcance. Los activos de soporte se pueden clasificar como: hardware, software, redes, personal, sitio, organización, entre otros. No: Consecutivo Categoría Activo: Tipo de Activo Clase Activo: Agrupación del Activo

35 CORRECOL S.A. Diseño de programas de seguros [en línea]. Bogotá: La Empresa [citado 20 octubre, 2018]. Disponible en Internet: <URL: http://www.correcol.com/programas-de-seguros.html>

43

Nombre Activo: Forma como se reconoce el activo 6.1.8.2 Propietario. Es la persona, proceso, grupo que tiene la responsabilidad de

definir quienes tienen acceso y que pueden hacer con la información y de determinar cuáles son los requisitos para que la misma se salvaguarde ante accesos no autorizados, modificación, pérdida de la confidencialidad o destrucción deliberada y al mismo tiempo de definir que se hace con la información una vez ya no sea requerida y los tiempos de retención asociados a la misma. Para este campo se incluye el cargo (rol) de la persona, la misma se salvaguarde ante accesos no autorizados, modificación, pérdida de la confidencialidad o destrucción deliberada y al mismo tiempo de definir que se hace con la información una vez ya no sea requerida y los tiempos de retención asociados a la misma. Para este campo se debe incluir el cargo (rol) de la persona. Los detalles de los activos primarios y de soporte principales de la empresa CORRECOL S.A. (véase los Cuadros 3 y 4). Cuadro 3. Activos Primarios en CORRECOL S.A.

No Clase de Activo

Categoría Activo

Nombre Activo Propietario

Activos Primarios

1 Información Dato Digital

Documentos para tramite de pago de siniestros

Avisos de Siniestro - cliente Fotos de siniestros FacturasConceptos técnicos Denuncias Informes de auditoría Manifiestos de carga Declaración de importación Conocimiento de embarque Guía aérea Actas de reunión Soportes contables Bonos de avería Cotizaciones - Certificaciones Actas de protesta capitán de motonav

Unidades Operativas Gerencia Operativa

Gerencia Legal y de riesgos

44

Cuadro 3. (Continuación)

No Clase de Activo

Categoría Activo


Activos Primarios

2

Dato Digital Cotizaciones de compañías de Seguros (SLIP)

Gerencia Operativa

Dirección de Cotizaciones Gerencia de

Ventas Unidades

Operativas

3 Dato Digital Informes de producción del cliente

Tecnología de la Información

4 Dato Digital Informe de Inspección de compañías de Seguros

Gerencia Operativa

Dirección de Cotizaciones

Unidades Operativas

5 Dato Digital Listas de Contactos de Outlook

Funcionarios

6

Dato Digital Relación de Activos Fijos

Contabilidad

7 Dato Digital Relación códigos fuentes de software


8 Dato

Documento Actas de reunión con clientes

Gerencia Operativa

Gerencia de Ventas

Cotizaciones Unidades

Operativas

9 Dato

Documento Aviso de vencimiento

Unidades Operativas

10 Dato

Documento Carta de nombramiento

Gerencia Operativa

Gerencia de Ventas


Unidades Operativas

45


No Clase de Activo

Categoría Activo


Activos Primarios

11

Dato Documento

Remisión de cobro Unidades

Operativas

12 Dato

Documento

Contratos (Pólizas de Cumplimiento y generales)

Unidades Operativas

13 Dato

Documento Resumen de seguros

Unidades Operativas

14 Dato

Documento

Documentos del cliente

Copia registro de matrimonio Declaraciones juramentadas Copia pasaporte Copia Tarjetas de propiedad vehículos Copia Documento de Identidad Copia Licencia de transito Copia Tarjeta profesional

Unidades Operativas

15 Dato

Documento

Formulario de Conocimiento del cliente – SARLAFT

Sistemas de Gestión y Riesgo


16 Dato

Documento

Formularios diligenciados de las compañías

Solicitudes de vida Solicitudes de Medicina Prepagada Solicitud Hogar Contrato Medicina Prepagada Relación de valores asegurados - vida Declaración de asegurabilidad

Unidades Operativas generales y beneficios

46


No Clase de Activo

Categoría Activo


Activos Primarios

17

Dato Documento

Información básica de póliza

Modificaciones a cotizaciones Solicitud de prórroga Solicitud de expedición Nota de cobertura Solicitud de Inclusiones y/o exclusiones

Cotizaciones Gerencia Operativa Unidades

Operativas

18 Dato

Documento

Información clasificada

Cifras (Valor de activos, inventarios de clientes) Esquema de seguridad (Seguridades Físicas) Operaciones de las empresas clientes Reporte de inspecciones Fotografías de inspecciones

Gerencia Legal y de riesgo


Gerencia Operativa Unidades

Operativas

19 Dato

Documento

Información complementaria de la póliza

Reporte mensual de huéspedes Reportes mensuales de transportes(Valor transportados, trayectos, destinos) Reporte de inventarios de mercancías Listados de bienes Reporte de personal asegurado Relación de parque automotriz

Gerencia Legal y de riesgo

Cotizaciones Gerencia Operativa Unidades

Operativas

20 Dato

Documento Papelería SOAT en blanco

Gerencia Operativa SOAT

Líneas personales

47


No Clase de Activo

Categoría Activo


Activos Primarios

21

Dato Documento

Póliza

Gerencia Legal y de

riesgo Cotizaciones

Gerencia Operativa Unidades

Operativas

22 Dato

Documento

Quejas (Independiente del canal de comunicación que ingrese)

Calidad y Riesgo

23 Dato

Documento Información caja fuerte Administrativo

24 Dato

Documento

Documentos pólizas de salud Historias Clínicas Ordenes Médicas Informes Médicos - Epicrisis Resultados de exámenes médicos Ultrasonidos -Incapacidades Autorización de servicios médicos Carnet EPS - ARL -MP, etc.

Unidad Beneficios

Fuente. CORRECOL S.A. Información corporativa. [CD-ROM]. [Bogotá]: La Empresa, 2018. Activos primarios Cuadro 4. Activos Soporte en CORRECOL S.A.

No Clase de Activo

Categoría Activo


Activos Soporte

25 Hardware Equipo de

procesamientos de datos

Servidores Físicos Host 1 de máquinas virtuales (HV05) Host 2 de máquinas virtuales (HV06) Host 3 de máquinas virtuales (HV10) Servidor Backups (BK02) Servidor (IBM)


48


No Clase de Activo

Categoría Activo


Activos Soporte

Servidor SharePoint (SH02) Servidor de dominio (DC01) Servidor Cámaras (HV11)

26

Dispositivos de almacenamiento SAM SAM HP SAM DELL


27

Servidores Virtuales

Servidor Scanner (DGS02, DGS01) Servidor Exchange (EX2013, EX02) Servidor SAP Servidor System Center Configuration (SCCM02) Servidor Base de datos (SQL01, SQL02) Servidor SharePoint (SH04, SH02) Servidor Aplicaciones (APP01) Servidor Dominio (DC01, DC03) Servidor CRM (CRM02) Servidor Impresión (PRT01)


28

Servidores Físico Centro Alterno (Triara) Host 1 de máquinas virtuales (HV07) Host 2 de máquinas virtuales (HV08)


29

Servidores Virtuales Centro Alterno Triara Servidor Exchange (DAGEX) Servidor Dominio (DC04)


30 Firewall Fortigate 300C (Red, VPN) Fortimail 200D (Correo)


49


No Clase de Activo

Categoría Activo


Activos Soporte

31

Firewall Centro Alterno (Triara)

Fortigate 60C


32 Firewall Femsa (Fontibón)

Fortigate 90D Tecnología de la Información

33 Equipo Transportable

Portátiles Funcionarios

34 Celular, Tablet corporativo Funcionarios 35 Equipo Fijo PC funcionarios Funcionarios

36

Periféricos para

procesamiento

Red LAN SWITCH 10 /100 /1000 Total Puntos Instalados 222 Categoría 6


37

Scaner e impresoras

3 Lexmark Multifuncionales 1 Lexmark Color xx Scaner HP


38 Medios para

Datos

Cintas de Backup

Serverdc01 - Serverex02 Contabilidad -Serversh02 BKusuarios


39

Software

Paquetes de Software o Software Estándar

Base de datos Correos Exchange


40 Base de datos Centro de documentación


41 Base de datos Share Point Tecnología de la Información

42 Aplicación

estándar del Negocio

Software CRM (Gestor) Gerencia General

43 SAP Business One Contabilidad

44

Aplicación específica del

Negocio

Base de datos Vdb Broker Tecnología de la Información

45

Aplicaciones de terceros

Desarrollos a la medida (IMG) Paginas de emisión de pólizas de las compañías de seguros


Unidades Operativas /

Gerencia Operativa

46 Red Medios y Soportes

Canal de Internet

Canal Principal TELMEX con ancho de Banda de 10000 K


50


No Clase de Activo

Categoría Activo


Activos Soporte

Canal de contingencia ETB con ancho de Banda de 10000 K (WIFI) Canal Dedicado TELMEX con ancho de Banda de 2.5 Megas

47

Canal de Internet Centro Alterno (Triara)

Canal MPLS 4 Megas Canal Dedicado TELMEX con ancho de Banda de 512K


48 Canal de internet de Coca-Cola

Canal Banda Ancha 8000K


49

Planta Telefónica

Alcatel oMNIPCX – 100 Planta teléfonos fijos Gateway XBELIUS X3 Planta Celulares 2N VoiceBlue Next Planta Celulares


50 Personal

Personal de Operación /

Mantenimiento

Directores de área Gerencia General

51 Personal Departamento T.I. Gerencia General

52

Sitio

Ubicación Zona

Centro de Computo Tecnología de la Información

53 Servicios Públicos

Protecciones eléctricas

3 Reguladores 15 KVA 2 UPS de 3 KVA protección de servidores Planta eléctrica con respuesta de 20 segundos (Suministrada por el Edificio) preguntar Tablero de control con amperímetros, voltímetro y bypass


Fuente. CORRECOL S.A. Información corporativa. [CD-ROM]. [Bogotá]: La Empresa, 2018. Activos primarios

51

6.2 SISTEMA DE GESTION DE LA INFORMACIÓN SGI EN LA EMPRESA CORRECOL SA 6.2.1 Objetivo y/o propósito del SGI en la empresa. Como parte de la estrategia del sistema de gestión de incidentes, CORRECOL debe poner los controles y procedimientos que permitan realizar un enfoque planificado y bien estructurado de la gestión de información con respecto a los incidentes de seguridad de la información de TI. El objetivo principal es contener o evitar los incidentes para reducir costos causados por los incidentes de manera directa o indirecta. 6.2.2 Política del SGI de la empresa. Ya que la empresa CORRECOL S.A. Cuenta

con un sistema de gestión de la seguridad de la información, es necesario el compromiso de todos los colaboradores de CORRECOL S.A. con el cumplimiento general de una política general de seguridad de la información. 6.2.2.1 Descripción. La alta dirección de la empresa CORRECOL S.A. se compromete con el mantenimiento del sistema de gestión de seguridad de la información, que es de obligatorio cumplimiento para todos los colaboradores de la organización con aras de proteger la Confidencialidad, integridad y disponibilidad de la información propia, de terceros y clientes que sean necesarios para la correcta operación del negocio. 6.2.2.2 Cumplimiento. Para el cumplimiento con el proceso de SGSI se han

establecido un grupo de políticas y procedimientos de apoyo, cuya responsabilidad de aprobación recae en la cabeza de la Gerencia general y su mantenimiento es responsabilidad del oficial de seguridad de la información o quien haga sus veces apoyado en el área de sistemas de gestión. Todos los colaboradores de la empresa CORRECOL S.A., deben velar por el cumplimiento de sus compromisos legales, regulatorios y contractuales, brindándoles seguridad y calidad en las operaciones que tienen a su cargo. Para ver el detalle de las demás políticas de la empresa CORRECOL S.A. dirigirse al Anexo L. 6.2.3 Diseño del proceso SGI basado en la normatividad y legislación. El

proceso de sistema de gestión de la seguridad de la información en la empresa CORRECOL S.A. debe de estar alineado con los cambios técnicos que se presentan en la norma ISO /IEC 27001 2013 que velan por la preservación de la Confidencialidad, integridad y disponibilidad de los activos de la compañía. De acuerdo a la legislación, la ley 1581 de 2012 de protección de datos personales, transparencia y acceso a la información pública con el propósito de conocer, actualizar y rectificar cualquier tipo de información sensible que se hayan recolectado en bases de datos o archivos de almacenamiento, las cuales se deben tener en cuenta para la gestión de la información.

52

Adicionalmente el marco legal colombiano para la protección de delitos informáticos que se encuentra en la ley 1273 de 2009, esta ley por medio de una reforma del código penal intenta protegernos de los delincuentes que quieran apoderarse, destruir o modificar la información relevante de la compañía. Con el objetivo de denunciar a los delincuentes y en el caso de demostrarse la culpabilidad por medio de una acción penal obtener una indemnización. 6.2.4 Descripción del proceso. Con el objetivo de realizar la gestión de los incidentes, CORRECOL S.A. plantea el flujo, (véase la Figura 9): Figura 9. Diagrama de flujo de gestión de incidentes en CORRECOL S.A.

Fuente. CORRECOL S.A. Información corporativa. [CD-ROM]. [Bogotá]: La Empresa, 2018. Gestión de incidentes

53

De acuerdo al proceso actual de la gestión de incidentes en la empresa CORRECOL S.A. describe los hallazgos encontrados, (véase el Cuadro 5). Cuadro 5. Descripción del proceso y hallazgos encontrados

Actividad Descripción Hallazgos Falencias

A. Inicio Inicio del Procedimiento

B. 1. Reportar Incidente de Seguridad

El usuario final reporta el incidente por medio de correo electrónico al oficial de seguridad de acuerdo al formato del anexo A,

No existe priorización del incidente de acuerdo al activo afectado, donde se pueda identificar la urgencia. Falta identificar el lugar del incidente. No existen niveles de escalamiento en la priorización ni SLA’s donde se refleje el tiempo de respuesta de acuerdo al tipo de incidente reportado No existen registros de lecciones aprendidas ni base de conocimiento. Documentación fundamental para la gestión. Si el incidente es mayor, no se tiene un flujo diferencial donde el tiempo de respuesta sea más corto ni está asociado a gestión de problemas. Existen usuarios que no han sido capacitados con conceptos de seguridad de la información, esto representa una dificultad a la hora de diferenciar la categoría afectada, tipo de eventos (Vulnerabilidad, Amenaza, Incidente); entre otros.

C. 2. Analizar Incidente

El oficial de Seguridad recibe el correo electrónico, realiza la descarga y versionamiento del archivo de registro del incidente y determina los pasos a seguir realizando un análisis inicial del incidente reportado, una vez se conozca la causa y realiza el escalamiento con el área afectada. El oficial de seguridad realiza la

No se tiene información histórica de fácil uso, con el fin de identificar si el incidente fue reportado anteriormente con su solución asociada. No existe un identificador de referencia único del incidente. No se tiene una técnica identificada de análisis de la causa raíz. Solo se maneja un nivel de categorías para el incidente, en este caso se recomiendan subcategorías de máximo 4 niveles con el fin de tener información más acertada con fines

54



Actualización del archivo con el plan de acción asociado.

Estadísticos. Ejemplo: Software, Aplicación, Modulo financiero, Sistema de orden de compra. No existe una forma de asociar la urgencia vs el activo afectado de forma paramétrica No existe un estado del incidente (Activo, En espera, Cerrado) ni fecha de cierre No existe un tiempo de resolución del incidente de acuerdo al impacto y prioridad. No se tiene un escalamiento para abordar la incidencia, esto ocasiona que el oficial de seguridad ante los posibles cambios, no pueda agilizar el incidente de la manera adecuada.

D. ¿Se Requiere

Contacto con Autoridades?

Flujos No: Continua con la Actividad # 5 (E) Si: Continua con la actividad # 3 (G)

E. 5. Ejecutar Investigación del Incidente

El Oficial de Seguridad indaga sobre las posibles causas y solución del incidente, además de las contramedidas para que en lo posible se pueda minimizar el impacto en la organización.

En algunas ocasiones no se reporta el responsable del incidente No se tiene la duración del incidente desde el momento de su ingreso hasta el cierre

F. 6. Gestionar Incidente con las Partes Interesadas

El oficial de seguridad vincula a las partes interesadas en el incidente a través de correo Electrónico y/o llamada telefónica de tal forma que se logren esclarecer las circunstancias del incidente y prevenir que su impacto sea mayor

No se tiene un esquema de escalamiento de acuerdo a la complejidad y/o criticidad del incidente

55



G. 3. Contactar a las Autoridades

Se contactan autoridades tales como Fiscalía, Policía, Cruz Roja, Investigadores Forenses, Defensa Civil, etc. Si es necesario, el oficial de seguridad contacta a las autoridades vía telefónica ante el tipo de incidente ocasionado, por ejemplo, cuando exista fuga de información, acceso malicioso a un sistema informático: entre otros

No existe información histórica sobre intervención de autoridades relacionados a incidentes en CORRECOL S.A.

H. 4. Realizar Acompañamiento a las Autoridades

El Oficial de Seguridad sirve de apoyo en la investigación y proceder de las autoridades contactadas, con el fin de brindar el correcto tratamiento al incidente.

I. 7. Documentar Informe del Incidente

Se documenta el informe de incidente donde se detallen las acciones tomadas y las actividades a ejecutar para minimizar la probabilidad de una nueva ocurrencia.

No hay información centralizada ni de fácil acceso para un histórico de incidentes No existen métricas donde se evalúen el total de incidentes en un intervalo de tiempo determinado teniendo en cuenta lo siguiente: Número de incidentes reabiertos, porcentaje de incidentes categorizados incorrectamente, entre otros.

J. Fin Finalización del procedimiento


56

6.2.5 Registros. A continuación, se explican los registros Informe del Incidente. El informe del incidente se consigna en el mismo formato

de reporte de incidentes, donde debe estar la evolución completa del incidente. Anexo A Formato de Reporte de Incidentes. Este formato contiene los datos relevantes

del incidente desde su materialización hasta el cierre. Relacionado en el anexo A. En el ciclo de vida del incidente se maneja el mismo formato relacionado en el Anexo A, esto dificulta en gran manera la generación de métricas, pues no se cuenta con una información centralizada. 6.2.5 Roles. A continuación, se describen los roles: Personal de CORRECOL o Terceros. Cualquier colaborador, contratista, cliente o proveedor que haya estado vinculado a un incidente de seguridad y deba reportarlo a CORRECOL. Oficial de Seguridad de la Información. Persona encargada de la gestión de la seguridad de la información, y en particular de la gestión de incidentes de seguridad de la información. 6.2.6 Protocolos de actuación ante incidentes de seguridad. CORRECOL S.A lleva a cabo acciones de concientización que consta de lo siguiente: Contexto de un incidente de Seguridad Metodología de la gestión de incidentes Medios de registro de un incidente Tipos de incidente Importancia de enfoques de prevención y monitorización 6.3 CARACTERIZACIÓN DE INCIDENTES DEL SGI

En la empresa CORRECOL S.A. se lleva a cabo un proceso de identificación, análisis, investigación y respuesta de los incidentes de TI, esta labor está a cargo del oficial de seguridad de la información el cual se encarga de llevar un registro de los incidentes que se presentan en la compañía por medio de un archivo plano, donde se especifica cual es el activo afectado, una breve descripción del incidente, se clasifica la criticidad del incidente, el diagnóstico realizado y la solución definitiva. Entre los incidentes reportados se evidencia que los más comunes son los relacionados a caídas del servicio de internet o interrupciones en los canales de comunicación por medio de conexiones por VPN y hurtos de equipos de cómputo de los funcionarios de la empresa. Actualmente en CORRECOL S.A. se maneja un plan de tratamiento de riesgos en

57

donde se especifican los controles de tratamiento, se evalúa la probabilidad y el impacto de los mismos, en el Anexo M se encuentra el detalle de los riesgos asociados a la seguridad de la información, entre la lista se identifican riesgos asociados a fuga de información, posible afectación a la integridad de la información, entre otros. Llevar un seguimiento continuo de los riesgos y tratamiento adecuado de los mismos, ayudará en gran manera a la prevención de incidentes. El análisis presentado corresponde a los incidentes generados desde el año 2014 hasta Julio de 2018, en donde se tuvo un total genera de 97, siendo el año 2014 en el que más incidentes se presentaron, (véase el cuadro 6) Cuadro 6. Incidentes registrados por año

Etiquetas de fila Incidentes

Registrados

2014 34

2015 26

2016 19

2017 14

2018 4

Total, General 97

Fuente. CORRECOL S.A. Información corporativa. [CD-ROM]. [Bogotá]: La Empresa, 2018. Incidentes Los incidentes presentados en la empresa CORRECOL S.A. agrupados por año, (véase la Gráfica 1). Gráfica 1. Distribución por año de incidentes

Fuente. CORRECOL S.A. Información corporativa. [CD-ROM]. [Bogotá]: La Empresa, 2018. Incidentes Como se refleja en la gráfica anterior el porcentaje con mayor incide de incidentes

35%

27%

20%

14%4%

Total

2014

2015

2016

2017

2018

58

corresponde al año 2014 de acuerdo a las siguientes acciones: Efectuar mecanismos preventivos, correctivos y concientización a los usuarios de CORRECOL S.A. Realizar monitoreo permanente desde TI con el fin de detectar inconvenientes con los sistemas actuales. Los incidentes presentados en la empresa CORRECOL S.A. de acuerdo a los meses del año, (véase la Gráfica 2).

Gráfica 2. Distribución Mensual de Incidentes

Fuente. CORRECOL S.A. Información corporativa. [CD-ROM]. [Bogotá]: La Empresa, 2018. Incidentes 6.3.1 Incidentes con Activo afectado. Los incidentes registrados y los activos que

fueron afectados en la empresa CORRECOL S.A. (véase el Cuadro 7).

12

10

15

4

23 3

23

7

12

5

1

4

21 1

54

1

4

21 1

2 21 1 1 1

2

0

2

4

6

8

10

12

14

16

feb

rero

sep

tiem

bre

no

viem

bre

ener

o

may

o

sep

tiem

bre

no

viem

bre

ener

o

abri

l

juni

o

sep

tiem

bre

feb

rero

abri

l

juni

o

sep

tiem

bre

may

o

julio

2014 2015 2016 2017 2018(en blanco)

Total

Total

59

Cuadro 7. Incidentes con Activo Afectado


Registrados

2014 34

febrero 1

Virus en pc 1

abril 2

CAIDA E1 MOVISTAR 1

septiembre 11

129A/WILLIAM CUBILLOS 1

287 A/ PEDRO ZAPATA 1

FIREWALL 5

SERVIDOR 192.168.10.207 2

Usuario 1

USUARIO/JOHANA ANGARITA 1

octubre 14

AIRE ACONDICIONADO 1

CLASIFICADOR/SERVIDOR 192.168.10.207 1

FIREWALL 1

FIREWALL/CAIDA DE RED 2

LUZ ELECTRICA 1

Portátil Katherine Saavedra 1

USUARIO /DANILO ROCHA 1

USUARIO/ALEXANDRA RIOS 1

USUARIO/CAROLINA HERNANDEZ 1

USUARIO/JAIRO LUGO 1

USUARIO/PAULA OSORIO 1

VDB 1

VDB Broker 1

noviembre 4

DIRECCION IP/BLOQUEO POR SPAM 2

FIREWALL/PERDIDA DE NAVEGACION 1

USUARIO/FALLA EQUIPO 1

diciembre 2

CORREO PERSONAL/SANDRA OLANO 1

PERSONAL/SANDRA OLANO 1

2015 26

enero 3

Backups en cinta 1

Base de datos del VDB Broker 1

Daño en los archivos de las carpetas compartidas de Automóviles 1

60



Registrados

Abril 3

CANAL DATOS FEMSA 1

MPLS TRIARA 1

Portátil Sandra Olano 1

mayo 2

Funcionaria beneficio 1

Información Sensible 1

junio 3

Incumplimiento Política de control de acceso 1

UPS 2

septiembre 7

equipo computo Mars Miller 1

Equipos desatendidos 1

Red CORRECOL 2

Red eléctrica CORRECOL 1

Servidor SH02 se bloqueó al reiniciarlo no arranca 1

VPN 1

Octubre 1

red CORRECOL 1

Noviembre 2

EQUIPO MIREYA RAMIREZ 1

SERVIDOR EXCHANGE 1

Diciembre 5

EQUIPO ANGELA ALVARADO 1

EQUIPO COMPUTO LILIANA GARCIA 1

Equipo Gabriel Sarmiento 1

SERVIDOR EXCHANGE 1

Vdbbroker 1

2016 19

Enero 2

EQUIPO YANETH OLAYA 1

Red CORRECOL 1

Marzo 3

EQUIPO KAREN BENAVIDEZ 1

FALLA RED CLARO 1

FALLAS BUZONES 1

Abril 2

EQUIPO EDWIN GOMEZ 1

EQUIPO MARS TRUJILLO 1

Mayo 1

61



Registrados

CANAL INTERNET CLARO VPN 1

Junio 1

CAIDA PBX 1

Julio 5

EQUIPO KAREN GONZALES 1

FALLA EQUIPO ENRIQUE ACEVEDO 1

FALLA PLANTA FONTIBON 1

PLANTA TELEFONICA CORRECOL 1

VIRUS EQUIPO DAVID MENJURA 1

Septiembre 4

CONTROLADOR DE DOMINIO 1

SERVIDOR EXCHANGE 1

SERVIDOR VDBBROKER 1

SERVIDORES VIRTUALES 1

Noviembre 1

CANAL DE INTERNET CLARO 1

2017 14

Febrero 4

ACCESS POINT 1

EQUPOS TECNOLOGICOS 1

Red CORRECOL 2

Marzo 2

MANTENIMIENTO SERVIDORES 1

SERVIDOR IMPRESORAS 1

Abril 1

BASES DE DATOS 1

Mayo 1

EQUIPO CARLOS GUTIERREZ 1

Junio 2

MANTENIMIENTO SERVIDORES FONTIBON 1

TABLERO ELECTRICO 1

Julio 2

SERVIDOR DE CORREO 1

SERVIDORES 1

Septiembre 1

CANAL INTERNET SECUNDARIO 1

Octubre 1

TELEVISOR SALA JUNTAS QUINTO PISO 1

62



Registrados

2018 4

Mayo 1

PBX CLARO 1

Junio 1

EQUIPO JENNY MONTAÑO 1

Julio 2

CANAL CLARO FONTIBON 1

EQUIPO OSCAR BERNAL 1

(en blanco)

(en blanco)

(en blanco) Total general 97

Fuente. CORRECOL S.A. Información corporativa. [CD-ROM]. [Bogotá]: La Empresa, 2018. Incidentes 6.3.2 Indicadores de gestión. De acuerdo con el resultado de las acciones

realizadas en la organización sobre los incidentes presentados, los indicadores de gestión permiten determinar si CORRECOL S.A. está cumpliendo con la gestión de los incidentes, cuantificando el comportamiento y desempeño de las acciones realizadas en el proceso. Esta magnitud debe ser comparada con algún nivel de referencia establecido por la organización, de esa manera se puede evidenciar si se presenta alguna desviación con la cual se toman acciones correctivas, preventivas o de mejora. Actualmente en la empresa CORRECOL S.A. se tienen varios indicadores en donde se monitorean las acciones realizadas en el proceso gestión de incidentes de TI, en el cual se identifican las desviaciones en el logro de las actividades. Para dar un ejemplo de un indicador actual de gestión de incidentes (véase el Cuadro 8), en donde se puede apreciar el modo en el cual se presentan los indicadores en la empresa CORRECOL S.A. no se realiza de la mejor manera, la compañía solo muestra indicadores de eficacia los cuales se enfocan en mostrar lo que se debe hacer en función de un objetivo específico, por lo tanto, solo se concentran en establecer el cumplimiento de las actividades de la compañía Cuadro 8. Ejemplo de indicador de gestión de incidentes

Fuente. CORRECOL S.A. Información corporativa. [CD-ROM]. [Bogotá]: La Empresa, 2018. Indicadores de gestión

INDICADOR META

3

3 90%

GESTION DE INCIDENTES RESULTADO

# Incidentes gestionados y

cerrados vs # Incidentes

reportados

Incidentes gestionados y cerrados

Incidentes reportados 100%

63

Por otra parte, es conveniente tener indicadores de eficiencia, en donde también se pueda mostrar la productividad del uso de los recursos disponibles con los que la empresa dispone para la consecución de los objetivos como por ejemplo: Esfuerzo de resolución de los incidentes. Satisfacción del usuario en la resolución. Incidentes, sin método de resolución. 6.4 2 Entrevista. Se realizaron una serie de preguntas a la directora de sistemas

de gestión para conocer cuál era el estado actual del proceso de gestión de incidentes de la empresa CORRECOL S.A: ¿Cuál fue el incidente de seguridad informática más relevante que se ha presentado en CORRECOL S.A. hasta la fecha? El incidente más relevante presentado hasta la fecha en CORRECOL S.A. fue en el año 2015 y afectó el servicio de internet de toda la empresa por la interrupción del servicio del proveedor de internet Claro en toda la calle 93. El incidente duró 2 días aproximadamente. ¿Cómo fue el proceso de la gestión de este incidente más relevante? El personal de TI identificó el incidente el cual lo informaron a la Gerencia de TI el cual citó a un comité de crisis. El comité de crisis estaba conformado por el siguiente grupo: Oficial de seguridad de la información Directora de sistemas de gestión Gerente de ventas Gerente general Gerente TI Gerente de Servicios generales Gerente administrativo y financiero En el comité se estableció un plan de acción con el propósito de reestablecer el servicio lo más pronto posible, asegurando el plan de continuidad del negocio de la compañía, posteriormente se llamó al proveedor de internet para que solucionaran el problema lo más pronto posible. ¿Qué tipo de plan de acción se realizó después del incidente para que no se volviera a presentar?

En el caso del incidente de la caída del servicio de internet se llevó a cabo la contratación de otro proveedor de servicios de internet para garantizar la continuidad del negocio si el proveedor principal vuelve a fallar.

64

¿En la empresa CORRECOL S.A. como es el proceso de priorización de los incidentes? En estos momentos no hay un mecanismo de priorización de los incidentes, todo se realiza por el juicio de experto que posee el oficial de seguridad de la información. ¿En la empresa CORRECOL S.A. se realiza el proceso de escalamiento de los incidentes y cuáles son sus niveles?

Si se realiza, El primer nivel de escalamiento es la mesa de servicios de TI, dependiendo del tipo de incidente, se escala al segundo nivel en conde está el oficial de seguridad de la información, en el tercer nivel se encuentra la directora de los sistemas de gestión la cual sería un escalamiento jerárquico. ¿Quién y cómo priorizan los incidentes?

El oficial de la seguridad de la información realiza la priorización y de acuerdo con el impacto y urgencia del incidente y dependiendo del activo afectado. ¿Dónde reportan los incidentes?

Existen dos maneras actualmente, la primera es enviando un correo electrónico a la mesa de servicios explicando el incidente de manera breve y la segunda es por medio de la plataforma de requerimientos de TI hay una opción para reportar los incidentes de seguridad de la información. ¿Cómo realizan el análisis del incidente?

El oficial de Seguridad recibe el correo electrónico, realiza la descarga del archivo de registro del incidente y determina los pasos a seguir realizando un análisis inicial del incidente reportado, una vez se conozca la causa y realiza el escalamiento con el área afectada. El oficial de seguridad realiza la actualización del archivo con el plan de acción asociado. ¿Cómo hacen seguimiento a las acciones del incidente? El oficial de seguridad de la información realiza el seguimiento. ¿Tienen métricas para la gestión de incidentes?

En estos momentos no se está haciendo ningún tipo de medición.

65

7. METODOLOGÍA PARA EL DESARROLLO DEL SOFTWARE

7.1 GESTIÓN DE INCIDENTES

Con el propósito de gestionar los eventos e incidentes de la manera más adecuada se plantea el desarrollo del sistema de gestión de incidentes según el marco de trabajo ITIL el cual está compuesto por las siguientes roles y etapas: 7.1.1 Roles 7.1.1.1 Oficial De Seguridad De La Información. Es la persona encargada de planificar, coordinar y administrar los procesos de seguridad informática de la organización, también es el responsable de las decisiones del cumplimiento regulatorio y la continuidad del negocio de la compañía. Debe realizar un seguimiento periódico de los incidentes presentados en la organización. 7.1.1.2 Funcionarios y contratistas. Todos los integrantes de la compañía tienen que tomar conciencia de su importancia dentro del proceso de gestión de incidentes, deben de reportar los eventos, posibles vulnerabilidades o cualquier comportamiento anormal que se presente en la compañía de manera oportuna a la mesa de servicios. 7.1.1.3 Mesa de servicio. Es el punto de referencia para los usuarios del servicio, ayudando a resolver las interrupciones de las operaciones del servicio lo más pronto posible, en el cual se centralizan todos los procesos de la gestión del servicio, canalización de las peticiones de servicios de los usuarios y el monitoreo de los SLA. 7.1.2 Etapas. El flujo de trabajo debe estar conformado por las siguientes etapas, (véase la Figura 10).

66

Figura 10. Flujo de trabajo de la gestión de incidentes

Fuente. Elaboración propia 7.1.2.1 Reporte del incidente. Responsables: Empleados, Contratistas y demás

personas que tengan interés en los activos de la empresa. Descripción: El individuo se percata de que están efectuando un ataque a los activos de la entidad, o es conocedor de que alguna persona de la compañía está violando las políticas de seguridad de la información de TI, está en la obligación de reportar la situación como un evento o incidente de seguridad de la información, debe comunicarse por cualquiera de los canales de comunicación: Correo, teléfono o informando directamente a la mesa de servicios.

67

7.1.2.2 Registrar incidente. Responsables: Mesa de servicios.

Descripción: La mesa de servicios toma los datos necesarios para realizar el registro, realiza la categorización inicial del incidente determinando si es un incidente o un evento, si se determina que no es un incidente es posible que sea una solicitud de servicio o un control de cambios, de lo contrario los datos del incidente los ingresa a la aplicación de gestión de incidentes ingresando la descripción de lo ocurrido con fecha y hora, si lo puede solucionar inmediatamente documenta la solución aplicada. Todos los incidentes deben estar completamente registrados con fecha y hora, independientemente si el incidente se soluciona a través de una llamada telefónica al centro de servicio, o si el incidente fue detectado a través de una alerta automática del sistema. Toda la información relevante relacionada con la naturaleza del incidente debe registrarse para mantener un registro histórico completo, ya que si el incidente es escalado a otro nivel del servicio tendrán toda la información a la mano para ayudarlos a la solución, para el registro de os incidentes se propone tener en cuenta los siguientes atributos: Fecha y hora registrada. Numero de referencia único. Categorización. Urgencia. Impacto. Priorización Nombre, id o grupo que registra el incidente. Método de notificación. Nombre, departamento, teléfono, ubicación del usuario. Método de devolución de la llamada. Descripción de los sistemas. Estado del incidente. Activo asociado. Grupo de apoyo al que se le asigna el incidente. Problema relacionado/Error conocido. Actividades emprendidas para resolver el incidente. Fecha y hora de resolución. Categorización de cierre. Fecha y hora de cierre36 7.1.2.3 Categorización. Responsables: Mesa de servicios. Descripción: La categorización permite asignar el tipo de incidente que está ocurriendo, por lo general las organizaciones utilizan un nivel de categorización de

36 STEINBERG, Randy. ITIL v3 Service operation. Norwich: TSO The Stationery Office. p. 91

68

nivel múltiple en el cual el primer nivel consta de pocas categorías que abarcan un nivel amplio de características de alto nivel, por ejemplo, categorías de primer nivel: Hardware, Software, Red. En otras palabras, realizar la categorización se trata de identificar un área en general a la que posiblemente corresponda el incidente. 7.1.2.4 Priorización. Responsables: Mesa de servicios. Descripción: Al realizar el registro de cada incidente se debe acordar y asignar un código de priorización que sea apropiado, ya que este código determinará como se le dará el manejo al incidente. La priorización la puede efectuar la aplicación web o el personal de la mesa de servicios con el propósito de clasificar la urgencia del incidente. (Véase el Cuadro 9). “Un modelo propuesto para realizar de una forma efectiva el cálculo de los elementos y asignar un nivel de prioridad a cada incidente se puede realizar de la siguiente manera”37. Cuadro 9. Sistema de priorización

Fuente. El Autor 7.1.2.5 Diagnóstico inicial. Responsables: Mesa de servicios.

Descripción: La mesa de servicio intenta comprender todos los síntomas del incidente para saber cuál es el inconveniente que se presenta y tratar de corregirlo, durante este proceso la mesa de servicio puede recurrir a la base de datos de errores comunes para acelerar la solución del incidente. 7.1.2.6 Investigación y Diagnostico. La investigación y diagnostico tiene las

siguientes etapas: Evaluar el impacto del incidente. De acuerdo a la norma ISO 27001, posterior

37 Ibíd., p. 95

ALTO MEDIO BAJO

ALTA 1 2 3

MEDIA 2 3 4

BAJA 3 4 5

DESCRIPCIÓN TIEMPO DE RESOLUCIÓN

CRITICO

ALTO

MEDIO

BAJO

PLANIFICACION

1 HORA

8 HORAS

24 HORAS

48 HORAS

PLANEADO

URGENCIA

IMPACTO

CÓDIGO DE PRIORIDAD

1

2

3

4

5

69

a la identificación de los activos, es importante tener en cuenta la identificación de amenazas, vulnerabilidades e impactos asociados que causen la perdida de confidencialidad, integridad y disponibilidad sobre los activos de la organización. De acuerdo a la escala se plantea el siguiente sistema de valoración de activos, (véase los cuadros 10 y 11): Cuadro 10. Valoración propuesta de los activos en CORRECOL S.A.

Fuente. Los Autores Cuadro 11. Niveles de valoración de activos en CORRECOL SA

Atributo Descripción

Critico >4

Alto >3 y <=4

Medio >2 y <=3

Bajo >1 y <=2

Muy bajo <=1

Fuente. Los Autores Responsable: Oficial de seguridad de la información.

Atributo Nivel Valor Descripción

>3 ConfidencialSi el activo es accedido por personas no autorizadas, el impacto

sería muy alto

1-3 Uso interno Afectación parcial al uso indebido sin autorización

<1 Publico No hay afectación, ya que es de uso público

>3 Alto Si la exactitud y el estado completo de la información y métodos

de procesamientos son alterados, el impacto sería muy alto

1-3 Medio

Si la exactitud y el estado completo de la información y métodos

de procesamiento, impacto seria medio y la afectación sería

parcial

<1 Bajo No se ve afectación importante

>3 Altamente Disponible Si no hay acceso a los activos en el momento que se requiere, se

tiene un impacto negativo afectando la imagen de la compañía

1-3 Disponible El activo puede estar disponible por lo menos el 50% del tiempo

<1 Disponibilidad básica El activo puede estar disponible por lo menos el 15% del tiempo

Confidencialidad

Integridad

Disponibilidad

70

Descripción: En el caso de que la mesa de servicios no pueda darle solución al incidente se escala al segundo nivel donde el oficial de seguridad de la información evaluará el tipo de incidente o evento que se está presentando, cuales activos está afectando, que alcance puede llegar a tener, así como un pronóstico con respecto a la expansión del incidente y daños potenciales a los activos de la compañía. Para la evaluación es importante tener la relevancia de los activos y el nivel del incidente. Identificar la relevancia del activo. Responsables: Oficial de seguridad de la información, Funcionarios, contratistas y demás partes interesadas. Descripción: Teniendo en cuenta la verificación de los riesgos que tienen relación con los activos, se establecerá el nivel de afectación incluyendo el valor económico y la cantidad de información relevante para la entidad contenida en el activo. Identificar el nivel del incidente Responsables: Oficial de seguridad de la información Descripción: El oficial de seguridad de la información tiene la responsabilidad de identificar el nivel de afectación del incidente de acuerdo a los niveles de criticidad establecidos para el incidente. Si el incidente no se encuentra en el nivel de clasificación establecido ya sea porque no tiene una solución propuesta o no corresponde a los niveles de servicio 0 y 1 debe ser derivado a gestión de cambios. Escalar el incidente

Responsables: Oficial de seguridad de la información Descripción: Para brindar una solución efectiva al incidente, el oficial debe de tener en cuenta los niveles de escalamiento, según su relevancia y complejidad puede realizar un escalamiento funcional o jerárquico. 7.1.2.7 Seguimiento del incidente. A continuación, se escribe el seguimiento del incidente: Responsables: Mesa de servicios, Oficial de seguridad de la información. Descripción: El seguimiento está relacionado directamente con el nivel de escalamiento que haya sido asignado para solucionar el incidente, su responsabilidad está en mantener actualizada las bases de datos del sistema de gestión de incidentes para mantener al tanto a los implicados. 7.1.2.8 Resolución del incidente. A continuación, se describe como se realiza la resolución del incidente:

71

Responsable: Mesa de servicios, Oficial de seguridad de la información. Cuando el nivel del servicio ha identificado una solución potencial del incidente, debe aplicarse la solución efectuando las acciones específicas a realizar y las personas que participarán en la solución, en la toma de acciones de recuperación varían según la naturaleza de la falla, esto podría implicar lo siguiente: Pedir al usuario que realice actividades dirigiéndolo desde un escritorio remoto. La mesa de servicios implementa una solución de forma centralizada como por ejemplo el reinicio de un servidor Se solicita a un grupo especializado que implementen una solución específica, como por ejemplo la configuración de un enrutador. Se solicita a un proveedor la resolución de la falla Se deben realizar pruebas suficientes para garantizar que el evento de recuperación se haya realizado de manera completa, y que el servicio haya sido restaurado completamente al usuario. 7.1.2.9 Cierre del incidente. A continuación, se describe como se hace el cierre

del incidente Responsable: Mesa de servicios, Oficial de seguridad de la información. El cierre está relacionado directamente con el nivel de escalamiento que haya resuelto el incidente, al cerrarse el incidente se enviará la respuesta al usuario que registró el mismo con la solución establecida, el usuario verifica que la solución del incidente haya sido efectiva, de lo contrario el incidente cambia su estado a reabierto y se repite el proceso nuevamente. Si el usuario no responde en el tiempo configurable en la aplicación de acuerdo a la prioridad establecida del incidente, el incidente se cerrará automáticamente. 7.2 CRONOGRAMA PARA EL DESARROLLO DEL APLICATIVO A continuación, se presenta el cronograma de actividades para el desarrollo del aplicativo (véase el Cuadro 12).

72

Cuadro 12. Cronograma proyecto

Nombre de tarea Duración Trabajo %

completado Comienzo Fin Predecesoras

Nombres de los recursos

Sistema de gestión de incidentes

101 días 912 horas

37% mar

05/06/18 mié

31/10/18

Sistema de información

16 días 264 horas

92% mar

05/06/18 mié

27/06/18

Fase arranque 16 días 264 horas

92% mar

05/06/18 mié

27/06/18

KickOff 1 día 16 horas

100% mié

06/06/18 mié

06/06/18

CORRECOL; Efrain Diaz

Reunión kickoff

1 día 0 horas 100% mié

06/06/18 mié

06/06/18

Pre-alistamiento general

14 días 240 horas

97% jue

07/06/18 mié

27/06/18 4

Incorporación Equipo Base

7 días 168 horas

100% jue

07/06/18 lun

18/06/18

CORRECOL; Efrain Diaz;

German Barreto Reyes

Solicitud requerimientos administrativos

1 día 32 horas

100% sáb

09/06/18 mar

12/06/18


Solicitud de requerimientos mínimos técnicos del producto (navegadores, base de datos, Framework)

1 día 8 horas 100% sáb

09/06/18 mar

12/06/18 Efrain Diaz

73





Solicitud de acceso a la red

1 día 8 horas 100% dom

10/06/18 mar

12/06/18 9 Efrain Diaz

Solicitud acceso a instancia de base de datos, carpetas y ambientes de versionamiento

1 día 8 horas 100% mar

12/06/18 mar

12/06/18 9


Hito: Solicitudes realizadas

0 días 0 horas 0% mar

12/06/18 mar

12/06/18 11

Definición de procedimientos de trabajo

10 días 40 horas

90% jue

14/06/18 mié

27/06/18

Modelo Organizativo

2 días 16 horas 100% jue

14/06/18 vie

15/06/18 CORRECOL

Gestión de la Demanda

1 día 8 horas 70% lun

18/06/18 lun

18/06/18 14 CORRECOL

Gestión de Herramientas TFS, MS VS


20/06/18 mié


Modelo de Gestión de Riesgos


27/06/18 mié


Hito: Término pre-alistamiento


05/06/18 mar

05/06/18

Alistamiento técnico


05/06/18 lun

25/06/18

74





Entrega y validación de accesos


05/06/18 mar

19/06/18

Hito: Término entregas accesos


19/06/18 mar


Validación de adherencia

6 días 0 horas 83% lun

18/06/18 lun

25/06/18

Hito: Término alistamiento técnico


05/06/18 mar

05/06/18

Alistamiento funcional

1,3 días 8 horas 70% lun

18/06/18 mar

19/06/18 7

Transferencia de conocimiento funcional


18/06/18 mar

19/06/18 CORRECOL

Definición de estrategia


25/06/18 mar

26/06/18 19

Hito: Término fase inicio fase de arranque


05/06/18 mar

05/06/18

Inicio SGI 42 días 648 horas

0% lun

03/09/18 mié

31/10/18 30

Modulo administración

15 días 120 horas

0% lun

03/09/18 vie

21/09/18 Efrain Diaz

Creación DashBoard

22 días 176 horas

0% lun

24/09/18 mié


75





Modulo creación de incidentes

30 días 240 horas

0% lun

03/09/18 vie

12/10/18


Modulo consulta de incidentes


16/10/18 lun

29/10/18 37


Creación plan de trabajo

2 días 16 horas 0% jue

25/10/18 vie


Consulta y modificación plan de trabajo

0 días 0 horas 0% vie

26/10/18 vie


Creación y edición de acciones y seguimiento


30/10/18 mié

31/10/18 38



76

7.3 DESARROLLO DEL SOFTWARE

En el proceso de desarrollo de software se define como la manea de dividir el trabajo en distintas actividades que tienen lugar durante el ciclo de vida, el objetivo básico de este proceso es tratar de hacer predecible el esfuerzo que se requiere, teniendo en cuenta el nivel de calidad, prediciendo el costo y el tiempo de desarrollo. Comúnmente, en la mayoría de proyectos de software que se desarrollan, no finalizan en el tiempo estimado y/o cuestan más de lo estimado. Esto sucede porque el desarrollo de software es de los artefactos más complejos que es capaz de desarrollar el ser humano, dado por su carácter inmaterial y por su dimensión en muchos casos ilimitada. Para esto se propone adaptar un marco de trabajo de acuerdo a las necesidades del software que se va a desarrollar. El desarrollo ágil es la metodología que más se adapta a los retos que se presentan en el desarrollo y mantenimiento de aplicaciones complejas. 7.3.1 Etapas de aplicación SCRUM. Ofrece un marco de trabajo iterativo e incremental en el cual se pueden realizar las actividades de desarrollo y pruebas alineados a las necesidades de la empresa CORRECOL S.A., para esto se estableció el SCRUM Team de la siguiente manera: 7.3.2 Roles. A continuación se describen los roles del software: Product Owner: (German Barreto) Es el encargado de ser la voz del cliente,

creación del Product Backlog, aprobación de los Sprint Scrum Master: (Efrain Diaz) Facilitador de la metodología, ayudar a solucionar los impedimentos que tenga el Development Team. Development Team: (Efrain Diaz, German Barreto) Grupo encargado de realizar

el desarrollo, pruebas y lanzamiento de versiones de la aplicación. 7.3.3 Artefactos. Las herramientas que vamos a utilizar para planear, desarrollar y administrar proyectos e desarrollo de Microsoft Azure DevOps en el cual tiene herramientas para el control del trabajo realizado. Product Backlog Y Sprint Backlog: Se utilizará Azure Boards para alimentar la lista de épicas, historias de usuario, planificar, realizar seguimientos a las actividades

77

7.3.4 Ceremonias. A continuación, se describen las ceremonias usadas: Sprint: Se llevarán a cabo Sprints de dos semanas de duración para entregar el

incremento del producto. Sprint Planing: Se realizarán reuniones de dos horas para la planificación, organización y distribución de las historias de usuario de cada sprint que se vaya a realizar en el proyecto. Daily Meeting: Se realizarán reuniones diarias de seguimiento para sincronizar las actividades del equipo de desarrollo cumpliendo con el Time Box de quince minutos. Sprint Review: Al final de cada sprint se llevará a cabo la reunión con una reunión de una hora para mostrar al Product Owner el incremento del producto. Sprint Retrospective: Posterior a la reunión Sprint Review se llevará a cabo la

reunión de retrospectiva de una hora con el propósito de reflexionar sobre lo realizado en el sprint anterior.

78

8. CONSTRUCCIÓN DEL SITIO WEB Y MODELO RELACIONAL

8.1 MODELO RELACIONAL

El modelo de base de datos relacional para el sistema de gestión de incidentes para la empresa CORRECOL SA, (véase la Figura 11). Figura 11. Modelo relacional de la aplicación SGI para CORRECOL SA primera parte


79

Figura 11. (Continuación)


80

8.1.1 Descripción artefactos Base de datos. A continuación, se escriben los

artefactos de bases de datos: TBL_SGI_PPARAMETRO: Tabla que almacena la configuración general de la aplicación, (véase el Cuadro 13) Cuadro 13. Tabla TBL_SGI_PPARAMETRO

Columna Tipo de

dato Restricció

n Descripción

PRM_SIG_NID int(4) null ID auto numérico

PRM_SIG_SNOMBRE varchar(150) null

Descripción del parámetro

PRM_SIG_SVALOR varchar(150) null Valor

PRM_SIG_DFECHA_REGISTRO datetime(8) null Fecha de registro

PRM_SIG_BESTADO bit(1) null true, false

PRM_SIG_SMODULO varchar(50) null Modulo origen del parámetro

Fuente. Elaboración propia TBL_SIG_PACCIONES: Tabla que representa las acciones realizadas en los incidentes, (véase el Cuadro 14) Cuadro 14. Tabla TBL_SIG_PACCIONES

Columna Tipo de dato Restricción Descripción

PLA_NID int(4) null Id plan de acción

PLT_NID int(4) null Id Acción

PLA_NRESPONSABLE int(4) null Responsable de la acción

PLA_DFECHA_CREACION datetime(8) null Fecha de creación

PLA_SCOMPROMISO varchar(500) null Descripción de compromiso

PLA_DFECHA_INICIO datetime(8) null Fecha inicio acción

PLA_DFECHA_FINAL datetime(8) null Fecha fin acción

PLA_NAVANCE int(4) null Porcentaje de avance acción

PLA_BEFICAZ bit(1) not null 1(Eficaz) 0 (no eficaz)

USR_NID int(4) null Usuario quien registra la acción

Fuente. Elaboración propia TBL_SIG_PMENU: Tabla que representa el menú de la aplicación, (véase el Cuadro 15)

81

Cuadro 15. Tabla TBL_SIG_PMENU


MNM_NIDMENU int(4) null Id menú

MNM_CDESCRIPCION varchar(200) null Descripción menú

MNM_NORIGEN int(4) not null Menú origen

MNM_NORDEN smallint(2) null Orden en que se va mostrar el menú

MNM_DFECHA_REGISTRO datetime(8) null Fecha de registro

MNM_BESTADO bit(1) not null 1 Activo, 0 inactivo

MNM_CRUTA varchar(300) not null Ruta del menú

MNM_SRUTANODOPR varchar(200) not null Ruta alterna

MNM_CICONCLA varchar(50) not null Ciclo

Fuente. Elaboración propia TBL_SIG_PMENU_ROL: Tabla que relaciona el menú con el Rol, (véase el Cuadro 16) Cuadro 16. Tabla TBL_SIG_PMENU_ROL


MNR_NIDMENUROL int(4) null Id menú rol

RLS_NIDROLE int(4) null id role

MNN_NIDMENU int(4) null id menú

RLS_DFECHA_REGISTRO datetime(8) null fecha de registro

Fuente. Elaboración propia TBL_SIG_PPARAMETROLISTA: Tabla que almacena la configuración de las listas (véase el Cuadro 17) Cuadro 17. Tabla TBL_SIG_PPARAMETROLISTA


PRL_NID int(4) null id parámetro

PRL_SNOMBRE varchar(150) null Descripción

PRL_SVALOR varchar(150) null Valor

PRL_DFECHA datetime(8) null Fecha registro

PRL_BESTADO bit(1) null 1 activo, 0 inactivo

PRL_CMODULO varchar(20) null Modulo origen del parámetro

PRL_CDESCRIPCION varchar(100) not null Descripción del módulo

Fuente. Elaboración propia TBL_SIG_PPLAN_ACCION: Tabla que almacena los planes de acción de la gestión de incidentes (véase el Cuadro 18)

82

Cuadro 18. Tabla TBL_SIG_PPLAN_ACCION


PLT_NID int(4) null id plan de acción

PLT_NRIESGO int(4) null Nivel riesgo

PRL_NID int(4) null Parámetro lista

PLT_DFECHA datetime(8) null Fecha de registro

PLT_SDESCRIPCION varchar(500) null Descripción

PLT_DFECHA_CIERRE datetime(8) null Fecha de cierre del plan

PLT_BCIERRE bit(1) null Estado cierre

PLT_BEFICAZ bit(1) not null 1 Eficaz 0 No eficaz

PLT_SOBSERVACIONES varchar(500) not null Observaciones

PLT_NUSUARIO int(4) null Usuario que registra el plan

Fuente. Los Autores TBL_SIG_PROL: Tabla que representa los tipos del Rol en la aplicación, (véase el Cuadro 19) Cuadro 19. Tabla TBL_SIG_PROL


RLS_NIDROLE int(4) null id Rol

RLS_SNOMBRE varchar(250) null Nombre Rol

RLS_BESTADO bit(1) null 1 Activo 0 inactivo

RLS_DFECHAR_REGISTRO datetime(8) null Fecha de registro

RLS_NNIVEL tinyint(1) not null Nivel de Rol

Fuente. Elaboración propia TBL_SIG_PSEGUIMIENTO_ACCIONES: Tabla que almacena los seguimientos realizados por cada acción, (véase el Cuadro 20) Cuadro 20. Tabla TBL_SIG_PSEGUIMIENTO_ACCIONES

Columna Tipo de dato Restricció

n Descripción

SGA_NID int(4) null id Seguimiento acción

PLA_NID int(4) null Id acción

SGA_SOBSERVACIONES varchar(500) null Observaciones

SGA_NSEGUIMIENTO int(4) null Porcentaje avance

SGA_DFECHA_REGISTRO datetime(8) null Fecha de registro

USR_NID int(4) null Usuario que registro el seguimiento


83

TBL_SIG_PUSUARIO: Tabla que almacena los usuarios de ingresarán a la aplicación, (véase el Cuadro 21) Cuadro 21. Tabla TBL_SIG_PUSUARIO


USR_NID int(4) null id auto numérico

USR_SNOMUSARIO varchar(20) null Nick usuario

USR_SCLAVE varchar(128) null Clave

USR_NOMBRE varchar(150) null Nombre de usuario

USR_APELLIDO varchar(150) null Apellidos

USR_STELEFONA varchar(100) null Teléfono

USR_BEXTERNO int(4) not null 1 Usuario interno , 2 usuario externo

USR_BESTADO bit(1) null 1 activo 0 inactivo

Fuente. Elaboración propia TBL_SIG_TANALISIS_CAUSA: Tabla que representa el análisis de causa de un incidente, (véase el Cuadro 22) Cuadro 22. Tabla TBL_SIG_TANALISIS_CAUSA


ANC_NID int(4) null id análisis de causa

ANC_SCAUSA varchar(700) null Descripción

PLT_NID int(4) null Acción

PRL_NID int(4) null Parámetro

Fuente. Elaboración propia TBL_SIG_TINCIDENTE: Tabla donde se almacena el incidente, (véase el Cuadro 23) Cuadro 23. Tabla TBL_SIG_TINCIDENTE


INC_NID int(4) null id incidente

INC_DFECHA_REPORTE datetime(8) not null Fecha en que se reportó

INC_SDESCRIPCION varchar(500) not null Descripción

INC_NORIGEN_ALERTA int(4) not null Origen del incidente

INC_DQUIEN varchar(150) not null Usuario origen

INC_NAREA int(4) not null Área del incidente

INC_DFECHA_EVENTO datetime(8) not null Fecha del el evento

INC_NTIPO_EVENTO int(4) not null Tipo de evento

INC_SCOTRA_CAT varchar(100) not null Categoría

ACT_NID int(4) not null


84

8.2 CONSTRUCCIÓN APLICATIVO WEB

8.2.1 Requerimientos no funcionales. A continuación, se describen los requisitos

no funcionales, (véase los Cuadros 24 y 25) Cuadro 24. Requerimientos no funcionales

No. Temática Requerimiento Requerido de

manera

1 General La aplicación deberá cumplir lo que establece la norma ISO/IEC27035 de la gestión de incidentes de la seguridad de la información de TI, como estrategia global la organización debe poner los controles y procedimientos para permitir un enfoque estructurado y bien planificado de la gestión de incidentes, con el objetivo de evitar o contener los incidentes de seguridad de la información

Obligatoria

2 La solución debe permitir la gestión de incidentes de TI de la empresa CORRECOL S.A.

Obligatoria

3 Plataforma y Arquitectura

Configurar la aplicación teniendo en cuenta los recursos de Hardware y Software que posee la Entidad

Obligatoria

4 La aplicación debe estar diseñada sobre una arquitectura de software orientada a un modelo estructurado de capas.

Obligatoria

5 La arquitectura de datos de datos deberá ser soportada en Microsoft SQL Server 2014 o superior.

6 La aplicación debe permitir ser operada desde diferentes sistemas operativos Windows (Desde Windows 7 o superior), Mac y Linux

Obligatoria

7 La aplicación debe permitir su navegar a través de los exploradores Firefox, Internet Explorer, Edge y Google Chrome. Por lo menos las últimas versiones desarrolladas por las casas matrices de dichos navegadores.

Obligatoria

8 Idioma Las ayudas, herramientas y documentación de la aplicación deben entregarse en idioma español.

Obligatoria

85



manera

9 Seguridad La aplicación debe permitir la administración de roles, perfiles, usuarios, permisos y niveles de acceso a las diferentes funcionalidades de sus componentes y datos

Obligatoria

10 La aplicación debe permitir parametrizar los derechos de accesos a usuarios.

Obligatoria

11 La aplicación debe proveer inicio de sesión integrándose con el Directorio Activo de Microsoft Windows Server especialmente para las funcionalidades que permiten autenticación y aprovisionamiento de información de los usuarios.

Obligatoria

12 Los usuarios y contraseñas deben ser los que se encuentran creados y válidos en el Directorio Activo.

Obligatoria

13 Debe permitir la administración de usuarios de la solución en el establecimiento de contraseñas, nivel organizacional al que pertenece el usuario, localización geográfica, cargo, jefe inmediato, extensión IP y permitir la activación o inactivación del usuario.

Obligatoria

14 La Solución debe poseer mecanismos para evitar la inyección de código malicioso en formularios, en información desde o hacia las interfaces que tengan los componentes de la solución, y en general en toda la solución donde pueda existir recepción de datos o aplicaciones externas

Obligatoria

15 La Solución debe establecer políticas y poseer mecanismos para evitar ataques de XSS (Cross Site Scripting), en todo elemento o componente de la Solución donde pueda existir recepción de datos o aplicaciones externas

Obligatoria

86



manera

16

La Solución debe generar logs de auditoría para hacer seguimiento a las operaciones y acciones realizadas por los usuarios, identificando tipo de transacción, tipo de operación realizada en los componentes de la solución, valores iniciales, valores actualizados; dejando así el rastro de las mismas.

Obligatoria

17 La Solución debe ofrecer un log detallado que permita establecer las acciones efectuadas por los usuarios sobre ésta a nivel de administración de seguridad.

Obligatoria

18 La Solución deberá evitar registrar información que tenga carácter de confidencial en los logs.

Obligatoria

19 Ayudas / documentación

La Solución debe contar con documentación técnica y de usuario en idioma español.

Obligatoria

Fuente. Los Autores 8.2.2 Requerimientos funcionales. A continuación, se describen los requerimientos funcionales (véase el Cuadro 25) Cuadro 25. Requerimientos funcionales

No. Modulo Requerimiento Requerido de

manera

1 Administración El sistema debe permitir que el rol administrador pueda configurar los usuarios, perfiles de usuarios tipos de acción

Obligatoria

2 El sistema debe permitir que el rol administrador pueda parametrizar el tipo de origen del incidente, categoría, tres niveles de subcategorías, tiempo de resolución que depende de la urgencia y el impacto asociado

Obligatoria

3 El usuario con el rol administrador podrá configurar los activos de CORRECOL S.A., tipos de causa y fuente asociado al incidente.

Obligatoria

87



manera

4

El rol administrador debe permitir asociar los usuarios creados a los niveles de escalamiento de un incidente

Obligatoria

5 DashBoard El sistema debe permitir un DashBoard donde se pueda consultar las últimas 5 alertas de incidentes presentados.

Obligatoria

6 El sistema debe permitir que el DashBoard contenga una gráfica de incidentes de su área.

Obligatoria

7 Creación de incidentes

El sistema debe permitir la creación y consulta de incidentes de acuerdo a la siguiente información: Categoría, Subcategoría, Origen, Estado del incidente, Descripción del incidente, Fecha y hora de resolución, Prioridad, Activo afectado, Urgencia, Impacto, Tiempo de resolución, Fecha de registro, Registrado Por Otro, ¿cuál?, Grupo de apoyo, Problema relacionado, Causa, Tipo de causa, Categoría de cierre, Fecha y hora de cierre, Fuente

Obligatoria

8 Al momento de crear el incidente debe llegar un correo electrónico a la mesa de ayuda

Obligatoria

9 El sistema debe permitir asignar una causa raíz sobre el incidente presentado, se debe capturar el usuario actual y la fecha de registro del incidente debe ser automática, día y hora actual.

Obligatoria

10 Consulta de incidentes

Deben existir las opciones de editar y eliminar el incidente y crear plan de trabajo.

Obligatoria

11 Al momento de la consulta del incidente debe aparecer categoría y subcategoría origen, estado, prioridad, descripción, fecha y hora de solución, activo afectado, usuario quien creó el incidente.

Obligatoria

12 Plan de trabajo

Para la creación del plan de trabajo debe permitir el ingreso de tipo de plan, descripción y fecha planeada de cierre.

Obligatoria

88



manera

13

El sistema no debe permitir editar el plan ni crear acciones si el plan o el estado del incidente se encuentra cerrado

Obligatoria

14 Debe permitir el cierre del plan teniendo en cuenta que todas las acciones del mismo se encuentren al 100%

Obligatoria

15 Debe permitir la eliminación del plan de trabajo, crear acciones y cierre del plan.

Obligatoria

16 Acciones Debe permitir la creación de la acción, teniendo en cuenta el nivel de escalamiento, responsable, fecha inicio y fecha fin.

Obligatoria

17 debe permitir realizar seguimiento de la acción teniendo en cuenta el porcentaje, descripción

Obligatoria

18 debe tener la posibilidad de eliminar, actualizar el seguimiento y ver el historial del seguimiento

Obligatoria

Fuente. Elaboración propia 8.2.3 Requerimientos recomendados del servidor. Todo sistema que se desee

implementar en una organización debe tener unos requerimientos mínimos de Hardware y Software para poder funcionar, (véase el Cuadro 26). Cuadro 26. Requerimientos recomendados del servidor

CPU 4 Núcleos de 64bits

RAM 8GB/16GB

Disco 1 (SO) 120 GB

Disco 2 (Data) 80 GB

Disco 3 (Paginación) 8 GB

Sistema Operativo Windows Server 2016 x64 Standard Edition, Ingles, ultimo Service Pack

IIS 8.0

Fuente. Los autores 8.2.4 Configuración de puertos.

Acceso por RDP Acceso por TCP 80 y 443 desde Visual Studio Team Services Acceso por TCP 80 y 443 desde Office365

89

Salida a login.microsoftonline.com y api.login.microsoftonline.com por puertos 80 y 443 https://login.microsoftonline.com/common/oauth2/authorize *sharepoint.com por puertos 80 y 443 *.powerbi.com 80 *.powerbi.com 443 *.analysis.windows.net 443 *.login.windows.net 443 *.servicebus.windows.net 5671-5672 *.servicebus.windows.net 443, 9350-9354 *.frontend.clouddatahub.net 443 *.core.windows.net 443 *.msftncsi.com 443 *.microsoftonline-p.com 443 8.2.5 Software: Requerimientos de software mínimos para la aplicación Web

IIS 7 o posterior Framework 4.6.1 o posterior SQL Server 2014 o posterior 8.2.6 Menús identificados. Para la gestión de incidentes, se tiene en cuenta el perfilamiento asociado bajo autenticación LDAP de acuerdo a lo siguientes menús: Dashboard: Contiene un listado de notificaciones, acciones y eventos asociados

a los incidentes presentados en el área correspondiente. (Véase la figura 12). Administrador: Configuración general de la aplicación bajo un rol con derechos administrativos, se podrán configurar los parámetros generales de la aplicación, configuración de usuarios, acciones; entre otros. Incidentes: Menú que contiene la gestión del incidente (lista, registro, clasificación, escalamiento, plan de acción, acciones, historial de seguimiento resolución y cierre. Métricas: Gráficos con las estadísticas que muestran comportamiento de la aplicación con respecto a las visitas y el uso de la aplicación. Base de conocimiento: Registro de solución de incidentes anteriores (CMDB)

con el fin de tener funciones de apoyo sobre la solución de los mismos. Lecciones aprendidas: Registro de recomendaciones y evidencias asociadas para la aplicación de nuevo conocimiento de manera preventiva para la gestión de los incidentes.

https://login.microsoftonline.com/common/oauth2/authorize

90

8.2.7 Menú inicial.

Figura 12. DashBoard Aplicación SGI para CORRECOL SA

Fuente. Los Autores

91

Una vez se realice el ingreso a la aplicación, aparece un DashBoard de acuerdo a los siguientes atributos, (véase la Figura 12): Gráfica de incidentes en el mes en curso (véase la Figura 13) Progreso de proyectos asociados a su área (véase la Figura 14) Incidentes asociados al área que pertenece (véase la Figura 15) Registro de los últimos eventos realizados en la aplicación (véase la Figura 16) Figura 13. Grafica de los incidentes presentados en el mes en curso

Fuente. Elaboración propia Figura 14. Grafica del progreso de proyectos asociados a su área


92

Figura 15. Lista de últimos eventos realizados en la aplicación

Fuente. Elaboración propia Figura 16. Grafica del estado actual de los procesos


93

8.2.8 Menú administrador. El usuario con rol Administrador podrá ingresar la

información de las listas desplegables requeridas para la gestión de los incidentes tales como Administración de activos, áreas, categorías, Tipos de Causa, Tipo de lección aprendida, fuente, Priorización; entre otros. Adicionalmente podrá crear usuarios e inhabilitar y activar nuevamente los registros asociados a la gestión de incidentes.

Al dar clic en menú aparecerá el siguiente listado: Nombres completos: Nombres y apellidos del colaborador. Email: Correo electrónico Usuario: Nombre de usuario con autenticación LDAP. Rol: Usuario, Líder o Administrador. Nivel: Hace referencia al nivel de escalamiento. Estado: Estado del registro (Activo o inactivo) (véase la Figura 17).

Figura 17. Lista de usuarios de la aplicación SGI

Fuente. Elaboración propia Una vez teniendo la vista de consulta de los usuarios, se procede a crear el usuario, (véase la figura 18).

94

Figura 18. Formulario de creación de usuarios de la aplicación SGI

Fuente. Elaboración propia El sistema valida que la información esté diligenciada en su totalidad y a continuación aceptar, esto lo llevará nuevamente a la vista de consulta, (véase la Figura 19).

95

Figura 19. Verificación creación de usuario en la aplicación SGI


La opción del botón verde realizará el direccionamiento al módulo de actualizar usuario, (véase la figura 20). Figura 20. Formulario de actualización de usuario en la aplicación SGI


96

El botón rojo permitirá activar o desactivar el registro, si el registro está inactivo no aparecerá en la creación ni en la consulta del incidente (véase la figura 21). Figura 21. Mensaje de confirmación para inhabilitar usuario

Fuente. Elaboración propia Las siguientes funcionalidades le permitirán realizar la exportación de los datos (véase la figura 22). Figura 22. Opciones para exportación de los datos

Fuente. Elaboración propia Copy: Realiza la copia de la información mostrada al portapapeles. CSV: Exporta archivo en formato CSV, (véase la figura 23)

97

Figura 23. Archivo de exportación de datos formato CSV

Fuente. Elaboración propia Excel: Exporta archivo en Microsoft Excel, (véase la figura 24)

Figura 24. Archivo de exportación de datos formato Excel

Fuente. Elaboración propia PDF: Exporta listado a tipo de archivo PDF, (véase la figura 25)

98

Figura 25. Archivo de exportación de datos formato Excel

Fuente. Elaboración propia Print: Asocia el listado a formato de impresión, (véase la figura 26)

Figura 26. Archivo de exportación de datos formato de impresión


En el menú el administrador podrá gestionar los activos, áreas de la compañía, Categorías de los incidentes, Estados incidente, Origen, Tipo de causa, Tipo de origen; entre otros, (véase la figura 27).

99

Figura 27. Vista consulta lista de parámetros

Fuente. Elaboración propia Lista de los parámetros utilizados en el sistema, (véase la figura 28) Figura 28. Vista edición formulario parámetros

100

Fuente. Elaboración propia 8.2.9 Menú incidentes. Si el usuario ingresa al menú incidentes aparecerá la

siguiente pantalla, (véase la Figura 29). Figura 29. Lista de incidentes Aplicación SGI para CORRECOL SA

Fuente. Elaboración propia Para el registro y consulta de incidentes, se tiene en cuenta los siguientes campos: Origen: Medio en que se identificó el incidente: Ej.: Llamada, Correo electrónico) Categoría: Clasificación que se usa para identificar la relevancia de un incidente para fácil uso. Subcategoría: Subnivel de agrupación basado en la categoría seleccionada. Urgencia: (Alta, media, baja). Medida de referencia para calcular la prioridad del

incidente Impacto: (Alto, medio, bajo). Medida del efecto de un incidente. Prioridad: Valor calculado de acuerdo al impacto y la urgencia. Fecha y hora de resolución: Fecha prevista de solución del incidente Registrado Por: Nombre del Usuario que registra el incidente Descripción del incidente: Detalle del incidente reportado

101

Estado del incidente: (En espera): Estado que hace referencia al incidente

creado, pero no Asignado, (En curso) Incidente creado y asignado, Cerrado (Incidente cerrado) Activo afectado: Lista desplegable de los activos TI de la organización. Otro ¿cuál?: Si el incidente afecta a más de un activo o el activo no aparece en

la lista previa se puede ingresar el activo afectado. Grupo de apoyo: Campo diligenciado por la mesa de servicio para su respectivo

escalamiento. Tiempo de resolución: Valor calculado de acuerdo a la prioridad. Fecha de registro: Fecha de registro del incidente. Otro, ¿cuál?: Si no aparece en la lista desplegable, se diligencia en este campo. Problema relacionado: Si existe un problema asociado en curso, se puede relacionar desde el aplicativo. Causa: Causa por la cual se generó el incidente. Tipo de causa: Parámetro configurable, ejemplo: Falta de entrenamiento,

planeación inadecuada, falta de medición y control. Categoría de cierre: Campo registrado por el responsable del incidente y

revisado por la mesa de ayuda donde hacen referencia a un nivel de agrupación del resultado, ejemplo: Completada satisfactoriamente, Completada con fallos, Fallo de software, Fallo de hardware, Usuario necesita entrenamiento. Fecha y hora de cierre: Fecha de cierre del incidente Fuente: Agrupación, (véase la figura 30, 31, 32 y 33) Figura 30. Nuevo incidente


102

Figura 31. Nuevo incidente (Continuación)

Fuente. Elaboración propia Figura 32. Descripción del incidente


103

Figura 33. Crear incidente Aplicación SGI para CORRECOL SA

Fuente. Elaboración propia Posterior a la creación de los incidentes, aparece la pantalla de consulta de incidentes, (véase la Figura 34). Figura 34. Consulta de Incidentes

Fuente. Elaboración propia En la columna Opciones se encuentran las siguientes funcionalidades:

Opción para editar el incidente (Esta funcionalidad la puede realizar la mesa de servicio, el usuario a quien se le asignó el incidente o quien ingresó el registro siempre y cuando esté en estado en progreso)

Opción para eliminar el incidente: Esta funcionalidad la puede realizar la mesa de servicio o el usuario a quien se le asignó el incidente 8.2.10 Plan de Trabajo. Posterior a la creación de incidentes, la mesa de servicio escala el incidente al nivel asociado de acuerdo al tipo de incidente y complejidad (véase la figura 35).

104

Figura 35. Planes de Trabajo

Fuente. Elaboración propia Para el registro y consulta del plan de trabajo, se tiene en cuenta los siguientes campos: Tipo: representa el tipo de plan de trabajo, si es preventivo, correctivo o de mejora. Descripción: Detalle del plan de trabajo a realizar. Fecha de cierre: Fecha planeada del cierre del plan de trabajo.

La eliminación del plan la lo realiza el mismo usuario que hizo la creación del mismo, (véase la Figura 36). Figura 36. Confirmación Eliminación del plan

105

Fuente. Elaboración propia Posterior a la asignación del plan de acción, se podrán asociar acciones definiendo nuevos responsables por nivel. Estas acciones se podrán actualizar de forma periódica siempre y cuando el plan no esté cerrado indicando el porcentaje real de la acción y descripción del seguimiento. 8.2.11 Menú Acciones. Para el registro y consulta de acciones, se tiene en cuenta

los siguientes campos: Compromiso: Compromiso establecido para el cumplimiento de la acción. Nivel de escalamiento: Niveles disponibles para realizar el escalamiento del plan

de acción. Responsable: De acuerdo al nivel de escalamiento aparecerá un especialista

responsable de ejecutar el plan de acción. Fecha inicio: fecha de inicio del plan de acción. Fecha fin: Fecha de cierre del plan de acción, (véase las Figuras 37 y 38). Figura 37. Acciones


106

Figura 38. Lista plan de acción

Fuente. Elaboración propia El usuario podrá actualizar y consultar el histórico de los seguimientos realizados (véase la Figura 39). Figura 39. Historial de seguimiento - Acción

Fuente. Elaboración propia Cuando el seguimiento de todas las acciones realizadas se encuentre al 100% , el responsable podrá cerrar el plan de trabajo seleccionando la eficacia del plan, si el plan es eficaz, se realiza el cierre del plan de acción y se realiza el cierre del incidente, de lo contrario se debe crear un nuevo plan de acción, (véase la figura 40).

107

Figura 40. Cierre de Plan de Trabajo

Fuente. Elaboración propia 8.2.12 Menú Métricas. Por medio de las métricas se pueden monitorizar las

transacciones de la página entre estas actividades se encuentra el número de consultas y el uso de la aplicación, (véase la figura 41). Figura 41. Métricas de la aplicación: Visitas


108

El usuario podrá ver el número de visitas a la aplicación en un intervalo de tiempo determinado (véase la figura 42). Figura 42. Métricas de la aplicación: Uso

Fuente. Elaboración propia. Adicionalmente el usuario podrá ver el número de visitas a la aplicación en el mes en curso y el promedio de tiempo de duración de la sesión dentro de la aplicación. 8.2.13 Base de conocimiento. Por medio del módulo de base del conocimiento se

podrá recolectar, organizar y recuperar información relevante para la solución de incidentes, con el propósito de mejorar la eficiencia al redescubrir el conocimiento (véase la figura 43).

109

Figura 43. Página principal de base de conocimiento

Fuente. Elaboración propia. En este módulo el usuario podrá generar una base de datos de conocimiento donde pueda ingresar y recuperar información relevante para el proceso de gestión de incidentes (véase la figura 44).

110

Figura 44. Registro de base de conocimiento

Fuente. Elaboración propia. Para el registro y consulta de la base de conocimiento, se tiene en cuenta los siguientes campos: Pregunta: Pregunta formulada de algún evento presentado el cual tenga solución. Respuesta Pregunta: procedimiento con detalles, paso a paso y evidencias que ayuden a responder la pregunta formulada. Activo afectado: Lista con los activos que se involucran directamente con el evento que involucra el procedimiento. Usuario: Usuario de registro. 8.2.14 Lecciones aprendidas. Las lecciones aprendidas permiten analizar los controles o procedimientos que tuvieron éxito y los que no, para así mitigar riesgos que se puedan presentar en el futuro, por medio de promover buenas prácticas que sean iterativas e incrementales (véase la figura 45).

111

Figura 45. Lista de lecciones aprendidas

Fuente. Elaboración propia. En la columna Opciones se encuentran las siguientes funcionalidades:

Opción para editar la lección aprendida (Esta funcionalidad la puede realizar la mesa de servicio, el usuario a quien se le asignó el incidente o quien ingresó el registro)

Opción para eliminar el incidente: Esta funcionalidad la puede realizar la mesa de servicio o el usuario que tenga permisos en la aplicación. En este módulo el usuario podrá crear un registro útil para la base de conocimiento de la aplicación, (véase la figura 46).

112

Figura 46. Formulario de lecciones aprendidas

Fuente. Elaboración propia. Para el registro y consulta de las lecciones aprendidas, se tiene en cuenta los siguientes campos: Área: Área donde se efectuó el evento que conllevó a retroalimentación. Lección: Categoría de la lección aprendida. Fecha: Fecha de registro. Tipo: Tipo de evento presentado. Descripción: Descripción del evento presentado. Situación: Descripción de la situación presentada. Causas: Descripción detallada de las causas del evento. Acciones: Descripción de las acciones tomadas. Recomendaciones: Detalle de las acciones realizadas para resolver el evento.

113

9. CONCLUSIONES

Ante la vanguardia de cambios tecnológicos y modelos de integración continua, los sistemas de información cumplen un papel fundamental en la toma decisiones, buscando facilitar la comunicación entre los diferentes roles de la compañía a través del diseño e implementación de flujos asociados a normas, procedimientos y técnicas bajo un entorno confiable, eficiente y seguro. Con base en lo anterior y el conocimiento adquirido en la especialización, se realizó el análisis y caracterización del sistema actual de la gestión de incidentes en CORRECOL S.A. Debido a que CORRECOL S.A. está invirtiendo más en tecnología y está comprometida con el mejoramiento del sistema de gestión de la seguridad de la información actual, buscando eliminar brechas asociadas a la ausencia de controles que representan gastos operativos y afectación en los activos de la compañía al no tener información en tiempo real, se identificaron los requerimientos funcionales y no funcionales para la construcción del sistema web bajo un modelo ágil teniendo en cuenta la proyección de la compañía a nivel de escalabilidad. Para el levantamiento de información se realizaron visitas a la sede de CORRECOL S.A, buscando acercamiento con el oficial de seguridad, el Gerente de TI y la Directora de sistemas de gestión mediante comités periódicos buscando la definición del contexto, oportunidades de mejora, próximos pasos orientados a un cambio cultural y maximización del uso de herramientas de sistemas de información para la gestión de incidentes; encontrándose que el sistema de gestión de incidentes de seguridad de la información de la empresa en la actualidad presenta falencias en todo el proceso, principalmente porque muchos de los procedimientos y actividades de registro se realizan de forma manual bien sea vía correo electrónico o en documento físico, no de manera sistematizada haciendo uso de las nuevas herramientas tecnológicas, que están diseñadas con el fin de agilizar y optimizar procesos, más aún cuando se trata de manejo de información en grandes volúmenes y con las cuales se puede reducir el tiempo de respuesta ante un incidente, que es otra de las falencias que se está presentando en la empresa. Sumado a lo anterior, se pudo establecer que los usuarios de los sistemas de tecnología de información de la empresa no tienen la capacitación requerida en lo que se relaciona al manejo de conceptos de seguridad de la información, en la gestión de los incidentes tanto en el reporte de los mismos como en proceso de solución, por lo tanto en el momento de presentarse un evento no saben cuál es el conducto regular a seguir, esperando hasta que el encargado verifique, lo que retara el proceso de reporte, gestión y solución del incidente. Al identificar las fallas y/o falencias que presenta el sistema de gestión de incidentes de información en la empresa, se pudo determinar la mejor opción para mejorar el

114

proceso, la cual se basa principalmente en el diseño de un aplicativo web que permita la automatización del mismo, además que brinde mecanismos para la verificación, seguimiento y control del estado de los incidentes presentados, esta estrategia de mejora permitirá y facilitará a los usuarios de la empresa el reporte de los incidentes desde su puesto de trabajo, generar de manera automática la alerta de los incidentes en el aplicativo para que el funcionario encargado de inicio de forma inmediata a la categorización, valoración y planeación de acciones de resolución, agilizado todo el proceso, clasificando los incidentes según nivel de incidencia e impacto y por tanto para brindar una solución más rápida y oportuna. Por otro lado, se pudieron identificar los requerimientos funcionales y no funcionales del aplicativo según las necesidades de la empresa, destacándose que la aplicación cumple con lo que establece la norma ISO/IEC 27035, al contar con una arquitectura tendrá un software orientado a un modelo estructurado de capas, con una arquitectura de datos soportada en Microsoft SQL Server 2014 o superior, compatible con sistemas operativos Windows (Desde Windows 7 o superior), Mac y Linux; además permitiendo el uso de navegadores Firefox, Internet Explorer, Edge y Google Chrome. Sumado a esto la aplicación diseñada contempla mecanismos para evitar la inyección de código malicioso en formularios, en información desde o hacia las interfaces que tengan los componentes de la solución, y en general en toda la solución donde pueda existir recepción de datos o aplicaciones externas, por lo que se establecieron políticas de seguridad de acuerdo a los protocolos de la empresa, adicionalmente, se generaran Logs de auditoría para hacer seguimiento a las operaciones y acciones realizadas por los usuarios, identificando tipo de transacción, tipo de operación realizada en los componentes de la solución, valores iniciales, valores actualizados; dejando así el rastro de las mismas. En cuanto a los requisitos funcionales el aplicativo diseñado, tiene un administrador principal mediante el cual se puede parametrizar el tipo de origen del incidente, categoría, tres niveles de subcategorías, tiempo de resolución que depende de la urgencia y el impacto asociado en tiempo real, al momento de presentarse la alerta de incidente, ubicando el origen, la causa y fuente asociada a éste, con lo que adicionalmente se podrá identificar el área o áreas en donde se presenta un mayor número de eventos, para de esta manera establecer estrategias de seguimiento y control específicas que contribuyan a la reducción de los mismos, o como mecanismo para identificar las circunstancias por las cuales se presenta un mayor número de incidentes en dichas áreas. Ahora bien, en cuanto al sistema de valoración de los incidentes, se estableció un mecanismo de priorización de incidentes según el nivel de impacto y por tanto su nivel de urgencia en resolución, discriminándolos de acuerdo a tres atributos principales que son confidencialidad del activo, integridad del activo y disponibilidad del activo lo que permitirá no sólo evaluar el nivel de impacto según el incidente que se presente, sino priorizar el evento y su tiempo de resolución, logrando solucionar los incidentes de manera más efectiva de acuerdo a las consecuencias que éstos

115

pueden tener en el manejo de operaciones para tener el menor traumatismo posible en el desarrollo normal de la empresa y brindando una mayor confiabilidad en la misma, permitiendo a su vez tener un mejor control de los incidentes para generar informes de gestión y toma de medidas de decisiones de mejora continua. Al implementar un sistema de información de gestión de incidentes permitirá que la organización tenga un amplio número de beneficios, dentro de las cuales se encuentran una mayor productividad y eficiencia en los procesos de la empresa, satisfacción de los usuarios, cumplimiento con los requerimientos de disponibilidad de los servicios de TI y oportunidad de mejora alineado a los objetivos misionales de la organización, razón por la cual se logró construir un sistema web capaz de llevar el ciclo de vida de los incidentes de TI. Resaltamos los conocimientos adquiridos durante la especialización de Seguridad Informática, ya que esto facilitó el análisis, entendimiento y aplicabilidad, buscando orientar a CORRECOL S.A. sobre la importancia de la seguridad de la información y como poder maximizar su beneficio a través de lineamentos de la norma 27001,27035, buenas prácticas en ITIL y apoyo de sistemas de información.

116

10. RECOMENDACIONES

La compañía actualmente cuenta con una infraestructura importante para la gestión de incidentes, sin embargo, se recomienda automatizar algunos procesos que busquen una estrategia de monitoreo constante, la cual permita identificar los incidentes de manera automatizada. Esta orientación ayudará a mejorar los tiempos de respuesta y disminución del impacto negativo que los incidentes puedan ocasionar. Se recomienda el ajuste de las políticas de la seguridad de la información, teniendo en cuenta el marco legal y normativo como también el plan de concientización y capacitación constante, el cual debe estar alineado con los objetivos de la organización. Debido al crecimiento constante que la empresa ha tenido en los últimos años, es importante crear una mesa de servicio bajo un equipo sólido, que busque mejorar la capacidad de respuesta ante un incidente dado, así como realizar actividades de documentación mediante lecciones aprendidas y base de conocimiento. Se recomienda realizar ajustes periódicos en la identificación de los activos teniendo en cuenta el esquema de valoración cuantitativo y cualitativo, así como establecer métricas asociadas a la eficiencia, donde se pueda identificar la productividad del uso de los recursos disponibles con los que la empresa cuenta, para la consecución de sus objetivos

117

BIBLIOGRAFÍA

COLOMBIA. CONGRESO DE LA REPÚBLICA. Ley 1266 (31 diciembre 2008). Por la cual se dictan las disposiciones generales del Hábeas Data y se regula el manejo de la información contenida en bases de datos personales, en especial la financiera, crediticia, comercial, de servicios y la proveniente de terceros países y se dictan otras disposiciones. . Bogotá: El Congreso, 2008. -------. Ley 1273 (5 enero 2009). por medio de la cual se modifica el Código Penal, se crea un nuevo bien jurídico tutelado - denominado "de la protección de la información y de los datos" y se preservan integralmente los sistemas que utilicen las tecnologías de la información y las comunicaciones, entre otras disposiciones. Bogotá: El Congreso, 2009. -------. Ley 1581 (17 octubre 2012). Por la cual se dictan disposiciones generales para la protección de datos personales. Bogotá: El Congreso, 2012. CORRECOL S.A. Diseño de programas de seguros [En línea]. Bogotá: La Empresa [citado 10 octubre, 2018]. Disponible en Internet: <URL: http://www.correcol.com/programas-de-seguros.html> -------. Información corporativa. [CD-ROM]. [Bogotá]: La Empresa, 2018. Organigrama empresarial -------. Información corporativa. [CD-ROM]. [Bogotá]: La Empresa, 2018. Mapa de Procesos ------. Información corporativa. [CD-ROM]. [Bogotá]: La Empresa, 2018. Activos primarios ------. Información corporativa. [CD-ROM]. [Bogotá]: La Empresa, 2018. -------. Información corporativa. [CD-ROM]. [Bogotá]: La Empresa, 2018. Incidentes -------. Información corporativa. [CD-ROM]. [Bogotá]: La Empresa, 2018. Indicadores de gestión -------. Misión [en línea]. Bogotá: La Empresa [citado 20 octubre, 2018]. Disponible en Internet: <URL: http://www.correcol.com/programas-de- Gestión de incidentes -------. Visión [en línea]. Bogotá: La Empresa [citado 20 octubre, 2018]. Disponible en Internet: <URL: http://www.correcol.com/programas-de-seguros.html>

http://www.correcol.com/programas-de-seguros.html

118

ELOSEGUI, Tristán. ¿Qué es un dashboard? [en línea]. Bogotá: Blogs [citado 29 enero, 2019]. Disponible en Internet: <URL: https://tristanelosegui.com/2014/10/27 /que-es-y-para-que-sirve-un-dashboard/> INSTITUTO COLOMBIANO DE NORMAS TÉCNICAS Y CERTIFICACIÓN. Tecnología de la información. Técnicas de seguridad. Sistemas de gestión de la seguridad de la información (SGSI). Requisitos. NTC-ISO/IEC27001. Bogotá: ICONTEC, 2006 -------. Tecnología de la información. Técnicas de seguridad. Sistemas de gestión de la seguridad de la información (SGSI). Requisitos. NTC-ISO/IEC27001. Bogotá: ICONTEC, 2006 INTERNATIONAL ORGANIZATION FOR STANDARDIZATION ISO. Information technology- information security incident management. DUS ISO/IEC 27035. Ginebra: ISO, 2016. -------. Standards What Is ISO? [en línea]. Bogotá: La Empresa [citado 29 enero, 2018]. Disponible en Internet: <URL:https://www.iso.org/standards.html> MICROSOFT. Azure DevOps [en línea]. Bogotá: La Empresa [citado 29 enero, 2018]. Disponible en Internet: <URL:https://azure.microsoft.com/es-es/services/devops/> -------. C# guide provides many resources about the C# language [en línea]. Bogotá: La Empresa [citado 29 enero, 2018]. Disponible en Internet: <URL: https://docs.microsoft.com/en-us/dotnet/csharp/> -------. Internet Information Services (IIS) for Windows [en línea]. Bogotá: La Empresa [citado 29 enero, 2018]. Disponible en Internet: <URL:https://www.iis.net/> -------. Microsoft Visual Studio [en línea]. Bogotá: La Empresa [citado 29 enero, 2018]. Disponible en Internet: <URL: https://visualstudio.microsoft.com/es/> -------. What is ASP.NET? [en línea]. Bogotá: La Empresa [citado 29 enero, 2019]. Disponible en Internet: <URL: https://dotnet.microsoft.com/apps/aspnet> RÍOS HUÉRCANO, Sergio. ITIL v3 Manual integro. Sevilla: Biable Management, Excellence and Innovation, 2014. SCHWABER, Ken y SUTHERLAND, Jeff. La Guía de SCRUM. Bogotá: Scrum Guides, 2016. seguros.html>

https://tristanelosegui.com/2014/10/27/que-es-y-para-que-sirve-un-dashboard/

https://tristanelosegui.com/2014/10/27/que-es-y-para-que-sirve-un-dashboard/

https://visualstudio.microsoft.com/es/

119

STEINBERG, Randy. ITIL v3 Service operation. Norwich: TSO the Stationery Office. WIKIPEDIA. ¿Qué es el Protocolo de Transferencia de Hipertexto? [en línea]. Bogotá: Wikipedia [citado 29 enero, 2018]. Disponible en Internet: <URL: https://es.wikipedia.org/wiki/Protocolo_de_transferencia_ de_hipertexto> WORDPRESS. ¿Qué es DevOps? [En línea]. Bogotá: La Empresa [citado 10 octubre, 2018]. Disponible en Internet: <URL: https://articulosit.files.wordpress .com/2012/09/devops.pdf>

120

ANEXOS

Anexo A. Formato de reporte de incidentes

Fecha y hora de diligenciamiento del reporte: , :

Datos personales (De quien está diligenciando el reporte)

Nombre: Área:

e-mail: Teléfono y extensión:

Información del evento

Quién alertó sobre el evento: Herramienta de

seguridad Usuario

Quién o cual: Área:

Cargo o herramienta:

Fecha y hora en que sucedió el evento: , :

Seleccione las opciones aplicables al evento

Defina el tipo de evento: Incidente Amenaza Vulnerabilidad

Defina la categoría aplicable:

Uso indebido de información Divulgación no autorizada de información personal

Interrupción en los servicios de red Pérdida o destrucción no autorizada de información

Uso inadecuado de recursos informáticos

Acceso o intento de acceso a un sistema informático

Cambio en la configuración en equipo Robo o pérdida de equipo

Uso indebido de correo electrónico institucional

Amenaza o acoso por medio electrónico

Fuga de información confidencial Divulgación no autorizada de información personal

Robo de contraseñas Borrado de información

Falla de una medida de seguridad Ataque de día cero

Delegación de servicios Ataque o infección de malware o código malicioso (virus, gusanos, troyanos, etc.)

Otro no contenido. ¿Cual?

121

Digite la siguiente información (De equipos, servidores, información u otro tipo de activo afectado)

Nombre del activo: Dirección IP (si aplica):

Descripción del activo: Sistema operativo (si aplica):

Lugar en donde se encuentra ubicado el activo (Casa, sede de CORRECOL, data center CORRECOL, data center externo, etc.):

Cantidad de horas en las que el sistema estuvo caído (si aplica):

Duración del evento (si aplica): ¿El evento aún está en progreso (si aplica)? Sí No

Describa y proporcione información acerca del evento

Plan de acción

1. 2. 3.

Indique las actividades de mitigación ejecutadas después del evento

1. 2. 3.

Conclusiones

1. 2. 3.

Digite la información de contacto (De quienes apoyaron la investigación y solución al evento)

Nombre: Nombre:

e-mail: e-mail:

122

Área: Área:

Cargo: Cargo:

Firma: Firma:

Nombre: Nombre:

e-mail: e-mail:

Área: Área:

Cargo: Cargo:

Firma: Firma:

Nombre: Nombre:

e-mail: e-mail:

Área: Área:

Cargo: Cargo:

Firma: Firma:

123

Anexo B. Valoración de los activos

Cuadro 4 Valoración de los activos de la empresa CORRECOL SA

Ítem No.

Nombre del Activo

PROPIEDADES DE SEGURIDAD DEL ACTIVO DE INFORMACIÓN VALOR DEL

ACTIVO CONFIDENCIALIDAD INTEGRIDAD DISPONIBILIDAD

Nivel Valor NIVEL Valor NIVEL Valor NIVEL Valor

1

Indemnizaciones seguros generales y vida

5 CONFIDENCIAL 5 ALTO 4 ALTAMENTE DISPONIBLE

4,7 CRÍTICO

2



5,0 CRÍTICO

3



5,0 CRÍTICO

4


4 CONFIDENCIAL 4 ALTO 2 DISPONIBLE 3,3 ALTO

5


2 USO INTERNO 2 MEDIO 3 DISPONIBLE 2,3 MEDIO

6


4 CONFIDENCIAL 2 MEDIO 3 DISPONIBLE 3,0 MEDIO

7 Gestión de pólizas y documentos

5 CONFIDENCIAL 3 MEDIO 3 DISPONIBLE 3,7 ALTO

124



4,3 CRÍTICO


3 USO INTERNO 5 ALTO 2 DISPONIBLE 3,3 ALTO

10 Sistemas de Gestión 5 CONFIDENCIAL 5 ALTO 5 ALTAMENTE DISPONIBLE

5,0 CRÍTICO


5 CONFIDENCIAL 5 ALTO 3 DISPONIBLE 4,3 CRÍTICO

12 TODOS 5 CONFIDENCIAL 5 ALTO 5 ALTAMENTE DISPONIBLE

5,0 CRÍTICO

13



4,7 CRÍTICO

14 Revisión y Facturación 3 USO INTERNO 5 ALTO 3 DISPONIBLE 3,7 ALTO

15 Operativo 4 CONFIDENCIAL 2 MEDIO 2 DISPONIBLE 2,7 MEDIO

16 Suscripción 4 CONFIDENCIAL 2 MEDIO 2 DISPONIBLE 2,7 MEDIO

17 Programa de Grandes Contratantes

3 USO INTERNO 5 ALTO 5 ALTAMENTE DISPONIBLE

4,3 CRÍTICO

18 Proceso Técnico 2 USO INTERNO 2 MEDIO 2 DISPONIBLE 2,0 BAJO


20 Proceso Técnico 2 USO INTERNO 3 MEDIO 2 DISPONIBLE 2,3 MEDIO

125




24 Proceso operativo 2 USO INTERNO 3 MEDIO 3 DISPONIBLE 2,7 MEDIO

25 Suscripción 5 CONFIDENCIAL 5 ALTO 4 ALTAMENTE DISPONIBLE

4,7 CRÍTICO

26 Programa de grandes contratantes


5,0 CRÍTICO

27 Gerencia Seguros Generales


5,0 CRÍTICO

28 Cotizaciones 2 USO INTERNO 2 MEDIO 2 DISPONIBLE 2,0 BAJO



31 Cotizaciones 5 CONFIDENCIAL 5 ALTO 5 ALTAMENTE DISPONIBLE

5,0 CRÍTICO

32 Cotizaciones 3 USO INTERNO 5 ALTO 4 ALTAMENTE DISPONIBLE

4,0 ALTO

33 Unidad de Riesgos Laborales

2 USO INTERNO 5 ALTO 2 DISPONIBLE 3,0 MEDIO



126


5 CONFIDENCIAL 5 ALTO 2 DISPONIBLE 4,0 ALTO




2 USO INTERNO 2 MEDIO 2 DISPONIBLE 2,0 BAJO




1 PÚBLICO 4 ALTO 1 DISPONIBILIDAD

BÁSICA 2,0 BAJO









44 Indemnizaciones 5 CONFIDENCIAL 2 MEDIO 2 DISPONIBLE 3,0 MEDIO

45 Indemnizaciones 2 USO INTERNO 2 MEDIO 2 DISPONIBLE 2,0 BAJO


127


48 Beneficios 5 CONFIDENCIAL 5 ALTO 5 ALTAMENTE DISPONIBLE

5,0 CRÍTICO

49 Beneficios 2 USO INTERNO 2 MEDIO 4 ALTAMENTE DISPONIBLE

2,7 MEDIO

50 Beneficios 5 CONFIDENCIAL 4 ALTO 4 ALTAMENTE DISPONIBLE

4,3 CRÍTICO


3,0 MEDIO


2,7 MEDIO


2,7 MEDIO


2,7 MEDIO


2,7 MEDIO

56 RRHH 5 CONFIDENCIAL 5 ALTO 5 ALTAMENTE DISPONIBLE

5,0 CRÍTICO

57 RRHH 5 CONFIDENCIAL 3 MEDIO 5 ALTAMENTE DISPONIBLE

4,3 CRÍTICO

58 RRHH 2 USO INTERNO 2 MEDIO 2 DISPONIBLE 2,0 BAJO

59 RRHH 5 CONFIDENCIAL 5 ALTO 2 DISPONIBLE 4,0 ALTO

60 RRHH 4 CONFIDENCIAL 2 MEDIO 2 DISPONIBLE 2,7 MEDIO

61 RRHH 2 USO INTERNO 1 BAJO 2 DISPONIBLE 1,7 BAJO

128

62 RRHH 2 USO INTERNO 2 MEDIO 2 DISPONIBLE 2,0 BAJO

63 RRHH 4 CONFIDENCIAL 3 MEDIO 2 DISPONIBLE 3,0 MEDIO




67 RRHH 2 USO INTERNO 2 MEDIO 4 ALTAMENTE DISPONIBLE

2,7 MEDIO

68 Revisión 5 CONFIDENCIAL 3 MEDIO 4 ALTAMENTE DISPONIBLE

4,0 ALTO

69 Revisión 2 USO INTERNO 5 ALTO 3 DISPONIBLE 3,3 ALTO

70 Revisión 5 CONFIDENCIAL 3 MEDIO 3 DISPONIBLE 3,7 ALTO

71 Revisión 2 USO INTERNO 3 MEDIO 4 ALTAMENTE DISPONIBLE

3,0 MEDIO

72 Revisión 2 USO INTERNO 3 MEDIO 4 ALTAMENTE DISPONIBLE

3,0 MEDIO

73 Cartera 5 CONFIDENCIAL 5 ALTO 4 ALTAMENTE DISPONIBLE

4,7 CRÍTICO


5,0 CRÍTICO


4,7 CRÍTICO

76 Cartera 3 USO INTERNO 5 ALTO 4 ALTAMENTE DISPONIBLE

4,0 ALTO

129


4,3 CRÍTICO

78 Cartera 2 USO INTERNO 3 MEDIO 2 DISPONIBLE 2,3 MEDIO

79 Cartera 2 USO INTERNO 3 MEDIO 3 DISPONIBLE 2,7 MEDIO

80 Contabilidad 4 CONFIDENCIAL 3 MEDIO 5 ALTAMENTE DISPONIBLE

4,0 ALTO


4,0 ALTO


4,0 ALTO

83 Contabilidad 5 CONFIDENCIAL 4 ALTO 5 ALTAMENTE DISPONIBLE

4,7 CRÍTICO

84 Contabilidad 2 USO INTERNO 5 ALTO 5 ALTAMENTE DISPONIBLE

4,0 ALTO

85 Contabilidad 4 CONFIDENCIAL 5 ALTO 5 ALTAMENTE DISPONIBLE

4,7 CRÍTICO

86 Contabilidad 1 PÚBLICO 2 MEDIO 5 ALTAMENTE DISPONIBLE

2,7 MEDIO

87 Contabilidad 1 PÚBLICO 2 MEDIO 5 ALTAMENTE DISPONIBLE

2,7 MEDIO

88 Sistemas de Gestión 3 USO INTERNO 4 ALTO 4 ALTAMENTE DISPONIBLE

3,7 ALTO

89 Sistemas de Gestión 2 USO INTERNO 4 ALTO 2 DISPONIBLE 2,7 MEDIO

90 Sistemas de Gestión 3 USO INTERNO 4 ALTO 3 DISPONIBLE 3,3 ALTO

130


5,0 CRÍTICO

92 Sistemas de Gestión 5 CONFIDENCIAL 5 ALTO 3 DISPONIBLE 4,3 CRÍTICO

93 Sistemas de Gestión 5 CONFIDENCIAL 5 ALTO 3 DISPONIBLE 4,3 CRÍTICO

94 Sistemas de Gestión 3 USO INTERNO 5 ALTO 4 ALTAMENTE DISPONIBLE

4,0 ALTO

95 Sistemas de Gestión 1 PÚBLICO 3 MEDIO 3 DISPONIBLE 2,3 MEDIO

96 Sistemas de Gestión 1 PÚBLICO 4 ALTO 2 DISPONIBLE 2,3 MEDIO


4,7 CRÍTICO

98

Tecnología de Información y Comunicaciones

1 PÚBLICO 1 BAJO 3 DISPONIBLE 1,7 BAJO

99



5,0 CRÍTICO

100



101



5,0 CRÍTICO

102 Tecnología de Información y


131

Comunicaciones

103



104



5,0 CRÍTICO

105



5,0 CRÍTICO

106



5,0 CRÍTICO

107



5,0 CRÍTICO

108



109



5,0 CRÍTICO

110



111



5,0 CRÍTICO

132

112



113



5,0 CRÍTICO

114



115



5,0 CRÍTICO

116



5,0 CRÍTICO

117



5,0 CRÍTICO

118



119



5,0 CRÍTICO

120





133

Comunicaciones

122



5,0 CRÍTICO

123



5,0 CRÍTICO

124



5,0 CRÍTICO

125



126



5,0 CRÍTICO

127



128



5,0 CRÍTICO

129



5,0 CRÍTICO

130



134

131



132



133



134



135



5,0 CRÍTICO

136



5,0 CRÍTICO

137



5,0 CRÍTICO

138



139



5,0 CRÍTICO



5,0 CRÍTICO

135

Comunicaciones

141



5,0 CRÍTICO

142



5,0 CRÍTICO

143



5,0 CRÍTICO

144



5,0 CRÍTICO

145


1 PÚBLICO 1 BAJO 1 DISPONIBILIDAD

BÁSICA 1,0

MUY BAJO

146



147



5,0 CRÍTICO

148



5,0 CRÍTICO

149



136

150



151



5,0 CRÍTICO

152



153



154



5,0 CRÍTICO

155



5,0 CRÍTICO

156



5,0 CRÍTICO

157



5,0 CRÍTICO

158



5,0 CRÍTICO



137

Comunicaciones

160



5,0 CRÍTICO

161



5,0 CRÍTICO

162



5,0 CRÍTICO

163



164



5,0 CRÍTICO

165



166



167



168



138

169



170



171



BÁSICA 1,0

MUY BAJO

172



BÁSICA 1,0

MUY BAJO

173



5,0 CRÍTICO

174



BÁSICA 1,0

MUY BAJO

175



5,0 CRÍTICO

176



5,0 CRÍTICO

139

177



BÁSICA 1,0

MUY BAJO

178



BÁSICA 1,0

MUY BAJO

179



180



181



182



183



140

184



185



BÁSICA 1,0

MUY BAJO

186



BÁSICA 1,0

MUY BAJO

187



BÁSICA 1,0

MUY BAJO

188



BÁSICA 1,0

MUY BAJO

189



BÁSICA 1,0

MUY BAJO

190



5,0 CRÍTICO

141

191



192



4,0 ALTO

193



194


2 USO INTERNO 2 MEDIO 4 ALTAMENTE DISPONIBLE

2,7 MEDIO

195



2,7 MEDIO

196



2,7 MEDIO

197



142

198



199



5,0 CRÍTICO

200



5,0 CRÍTICO

201



5,0 CRÍTICO

202



5,0 CRÍTICO

203



5,0 CRÍTICO

204



5,0 CRÍTICO

143

205



5,0 CRÍTICO

206



207



5,0 CRÍTICO

208



209



210



211



144

212



213



214



215



216



217



218



145

219



220



221



222



5,0 CRÍTICO

223



5,0 CRÍTICO

224



5,0 CRÍTICO

225



146

226



147

Anexo C. Direccionamiento Estratégico Cuadro 21 Proceso direccionamiento estratégico

OBJETIVO

Orientar la empresa en la gestión estratégica, identificación, diseño y optimización de los diferentes procesos de la organización, fortaleciéndola organizacionalmente, afianzando el trabajo de equipo, elevando la eficacia y eficiencia del funcionamiento operativo como elementos fundamentales en la productividad de los recursos técnicos, financieros, humanos, logísticos y competitivos. Evaluando periódicamente la conveniencia, adecuación y eficacia de los diferentes sistemas de gestión de CORRECOL S.A.

PROVEEDORES ENTRADAS

RESPONSABLE

Gerente General

SALIDAS CLIENTES

Cliente Externo

Todos los procesos del Sistema

Necesidades y expectativas de nuestros clientes

Análisis del entorno del negocio

Situación de la compañía / Resultados de la gestión de los periodos evaluados

Misión, Visión, Política de Calidad y Objetivos de Calidad

Plan Estratégico

Oportunidades de mejora

Acciones que permitan el mejoramiento continuo de los procesos de la compañía.

Todos los procesos del sistema

DOCUMENTOS ASOCIADOS

Manual de Calidad

Política de Calidad

Revisión por la Gerencia

Descripción de Procesos

Misión, Visión

Organigrama

148

Red de Procesos

RECURSOS

Infraestructura Talento Humano Ambiente de Trabajo

Infraestructura tecnológica, Internet

Equipo de comunicación

Software: Aplicaciones para control de actividades y Office

Gerente General

Director Sistemas de Gestión

Gerentes de Área

Subgerentes

Condiciones seguras de trabajo

Iluminación

Espacio adecuado para la concentración

149

Anexo D. Sistemas de Gestión Cuadro 22 Proceso de sistemas de gestión

OBJETIVO

Propender por el mantenimiento y mejoramiento del Sistema de Gestión de Calidad así como los Sistemas Administrativos de Riesgo (SARO, SARLAFT, SAC), coordinando actividades específicas con el Oficial de Seguridad de la Información para el mantenimiento del Sistema de Gestión de Seguridad de la Información mediante el establecimiento de mecanismos para que las herramientas de mejora sean usadas y gestionadas adecuadamente.


RESPONSABLE

Director Sistemas de Gestión

SALIDAS CLIENTES

Cliente Externo


Documentación de los diferentes sistemas de gestión

Resultados de la medición de la satisfacción del cliente

Quejas y reclamos de los clientes

Resultados de auditorías internas y externas

Resultados de las reuniones con la Gerencia (Comité – Revisión Gerencial)

Oportunidades de Mejora

Reportes SARO

Seguimiento a las acciones correctivas - preventivas

Control de la documentación

Análisis de la medición de la satisfacción del cliente

Atención a las quejas y reclamos de los clientes

Actas de reuniones con la Gerencia

Informe SARO a ente regulador

Informes SARLAFT a ente regulador

Coordinación de acciones o proyectos

Cliente Externo


150

Reportes SARLAFT especiales con las diferentes unidades de la organización


Elaboración y control de documentos

Control de Registros

Quejas

Auditorías Internas

Acciones Correctivas y Preventivas

Sugerencias

Evaluación del Servicio

Manual de Gestión de Riesgo

151

Anexo E. Gestión de pólizas y documentos Cuadro 23 Proceso de gestión de pólizas y documentos

OBJETIVO

Presentar al cliente en forma eficiente y confiable las mejores alternativas de mercadeo para suplir su necesidad especifica de aseguramiento general para sus bienes e intereses patrimoniales en forma oportuna. De igual forma, gestionar ante la compañía de seguros seleccionada la expedición, modificación o anulación de la póliza y documentos que se requieran para amparar dichos bienes.


RESPONSABLE

Gerentes Unidades Directores de

Unidad

SALIDAS CLIENTES

Cliente Externo

Mercadeo

Direccionamiento Estratégico

Compañías Aseguradoras

Requisitos de clientes externos

Información preliminar para cotización

Solicitud, modificación y anulación de pólizas

Listados de renovaciones

Condicionados de Compañías Aseguradoras

Guía de valores Fasecolda

Propuesta Comercial

Cotizaciones

Modificaciones

Anulaciones

Pólizas nuevas

Pólizas Renovadas

Planillas de facturación

Clientes Externos

Mercadeo

Revisión

Mensajería

Facturación

152


Matriz de Legislación aplicable

Seguro Obligatorio contra accidentes de tránsito y SOAT

Control de cúmulos

Gestión de pólizas

Cuentas Compartidas

Revisión de Garantías

Cuentas Referidas

Hoja de Ruta

Legislación aplicable

RECURSOS

Infraestructura Recurso Humano Ambiente de Trabajo

Equipo de cómputo, Internet


Software: Hoja de cálculo y procesador de texto

Programa de resumen de seguros

Sistema de Integración empresarial

Cotizadores de algunas compañías

Software base de Datos VDB Broker

Gerente Operativo

Subgerentes Operativo

Directores Técnicos

Directores de Unidad

Asistentes Técnicos

Ejecutivos de cuenta

Ventilación

Iluminación

Sitios de trabajo ergonómicos


153

Anexo F. Facturación y Cartera Cuadro 24 Proceso de facturación y cartera

OBJETIVO

Asegurar y garantizar que las condiciones pactadas con el cliente y la aseguradora se cumplan a cabalidad en la póliza o documento expedido, así como los requisitos legales aplicables, buscando el mejoramiento continuo en nuestro servicio. Además formalizar el cobro de la prima mediante la elaboración de la cuenta de cobro con destino a los clientes y de esta manera registrar de manera confiable y oportuna la producción de la compañía

PROVEEDORES

ENTRADAS

RESPONSABLE

Gerente Seguros

Generales Asistente Senior y

Junior de revisión y Facturación

SALIDAS CLIENTES

Gestión de Póliza y

Documentos

Pólizas y anexos

Carpeta del cliente con soportes

- Slip de cotización de la compañía seleccionada

- Póliza anterior en caso de renovación

- Solicitud de la póliza a la compañía

- Requisitos del cliente

Planilla de facturación

Solicitudes aprobadas de correcciones y modificaciones a cuentas de cobro

Póliza y anexos revisados

Pólizas no Conformes (PNC)

Solicitudes de trámite de PNC a las compañías

Recomendaciones producto de la revisión

Cuentas de Cobro conformes

Cuentas de cobro modificadas o anuladas

Compañías de Seguros

Gestión de Pólizas y Documentos

154


Revisión Seguros Generales y Vida

Revisión Seguros Judiciales y de Cumplimiento

Facturación


RECURSOS





Sistema de Integración empresarial


Gerente Seguros Generales

Asistentes de Revisión y Facturación


Ventilación

Iluminación

Sitios de trabajo ergonómicos


PARAMETROS DE CONTROL PROCESOS DE SOPORTE

Balance Scorecard

Productos no Conformes Gestión de Póliza y Documentos

155

Anexo G. Indemnizaciones Cuadro 25 Proceso de indemnizaciones

OBJETIVO

Garantizar permanentemente la atención y asesoría adecuada a nuestros clientes en caso de siniestros o reclamos hasta el cierre del mismo, salvaguardando los intereses del cliente e institucionales de orden legal

PROVEEDORES

ENTRADAS

RESPONSABLE

Director de Indemnizaciones

SALIDAS CLIENTES

Clientes Externos

Gestión de Pólizas y Documentos

Compañías Aseguradoras

Aviso de Siniestro

- Telefónico - E-mal - Páginas web

compañías - Carta - Reclamación

Carpeta del cliente

Siniestro cerrado

Expediente del siniestro

Cliente Externo


Indemnizaciones S. Generales

Indemnizaciones S. Automóviles


156

RECURSOS






Gerente Legal y de Riesgos


Directores de Indemnizaciones

Asistentes de Indemnizaciones

Ventilación

Iluminación



Balanced scorecard

Comités con Unidades Operativas

Satisfacción del cliente

Gestión de Póliza y Documentos

157

Anexo H. Recursos Humanos Cuadro 26 Proceso de recursos humanos

OBJETIVO

Seleccionar el personal competente con base en la educación, formación, habilidades y experiencia determinadas para cada cargo, así mismo proporcionar la formación o entrenamiento necesarios según las necesidades detectadas.


RESPONSABLE

Director Recursos Humanos

SALIDAS CLIENTES

Proveedores Formales:

Innocor S.A.S

SENA

Fasecolda

Entidades capacitadoras

Proveedores Informales:

Recomendaciones

Todos los procesos de la compañía

Solicitud de Personal

Reemplazos-ascensos

Perfiles de Cargo

Necesidades de formación

Evaluación de desempeño

Personal adecuado en cada uno de los cargos

Mayor efectividad en el desempeño

Mejoramiento continuo en el desempeño.


158


Gestión del Talento Humano

Manual de Inducción

Manual de perfiles y funciones

Selección y Contratación del personal

Evaluación del personal

Inducción y re inducción

Formación y desarrollo

Perfil de Puesto

Hojas de vida, Contratos

Legislación Aplicable

RECURSOS





Ayudas Audiovisuales

Subgerente Administrativo y Financiero

Director de Gestión del Talento Humano

Ventilación

Iluminación


Espacio para capacitaciones y entrevistas a personal


Balanced Scorecard

Evaluaciones de competencias


Gestión de Calidad y Riesgo

159

Anexo I. Tecnología de la información Cuadro 27 Proceso de Tecnología de la información

OBJETIVO

Estimar estrategias, políticas, planes y programas de los recursos informáticos y de comunicación que conlleven al buen funcionamiento y/o mejoramiento de las diferentes tecnologías de la información y Seguridad de la Información de la empresa con el fin de mantener la integridad permanente de la información y la continuidad del servicio.


RESPONSABLE

Gerente de TIC

SALIDAS CLIENTES


Empresa de telefonía

Proveedores Internet ISP

Proveedores de registro, hosting y DNS

Solicitudes de soporte

Programa de mantenimiento

Planeación estratégica

Equipos en buen funcionamiento

Disponibilidad e integridad permanente de los sistemas de Información y comunicación

Copias de seguridad



Política de Comunicación y Uso de Equipos de Computo

Sistemas Generales de Comunicación

Mantenimiento de equipos

Control de Acceso

Soporte en Sistemas

160

RECURSOS


Centro de computo

Líneas telefónicas primario y E1

Acceso internet banda Ancha

Cableado estructurado

Red eléctrica Regulada

Subgerente Administrativo y Financiero

Director de Tecnología de Información y Comunicaciones

Ing. de Soporte

Aire Acondicionado – Centro de Computo

Iluminación



Ejecución de proyectos

Balanced scorecard


Gestión de Calidad y Riesgo

161

Anexo J. Administrativo y Financiero Cuadro 28 Proceso administrativo y financiero

OBJETIVO

Planear, organizar, dirigir y controlar el área administrativa para prestar apoyo logístico a todos los demás procesos de la compañía. Recibir, analizar y presentar la información financiera de la compañía en forma oportuna a la Gerencia General, la Junta Directiva y a los diferentes entes de control.


RESPONSABLE

Gerente

Administrativo y Financiero

SALIDAS CLIENTES

Todos los procesos de la Compañía

Proveedores externos de la compañía

Facturas

Reembolsos de caja

Cuentas de Cobro

Nomina

Liquidación a funcionarios

Planilla Integrada de autoliquidación de aportes

Comprobantes de Egreso

Datos de producción y recaudo

Presupuestos

Requisición d-e bienes

Legalización de gastos

Legalización de gastos

Informes financieros

Liquidación de Impuestos

Estados financieros

Informes a entes de control


Junta Directiva

Entes de Control

162

Requisitos legales


Recepción y correspondencia

Compras

Archivo

Matriz de requisitos legales

RECURSOS


Equipo de Computo

Equipo de comunicación telefónica

Internet

Base de datos (VDB Broker)

Software contable (Alfasis)

SAP

Gerente Administrativo y Financiero

Asistente de gerencia Administrativa y Financiera

Contador

Asistente Contable

Iluminación



Balance Scorecard Direccionamiento Estratégico

163

Anexo K. Control interno Cuadro 29 Proceso de control interno

OBJETIVO

Propender por el mantenimiento y mejoramiento del Sistema de Control Interno (SCI) de acuerdo a lo exigido por la circular 014 de 2009 estableciendo los mecanismos para que las herramientas de control sean usadas y gestionadas adecuadamente.


RESPONSABLE

Control Interno

SALIDAS CLIENTES

Cliente Externo


Comité de auditoria

Junta Directiva

Documentación del SCI

Resultados de la medición control interno

Evaluaciones independientes

Valoración de riesgos

Circular 029 de 2014

Informe de control interno y su estado en la organización

Mapa de riesgos

Informes de Comité de Auditoria

Informes a ente regulador

Código de Conducta

Cliente Externo



Manual de Control Interno

Código de ética y conducta

Reglamento del Comité

Evaluaciones Independientes

Manual SARLAFT

Manual SARO

164

RECURSOS





Director de Sistema de Gestión

Oficial de Cumplimiento

Control interno

Ventilación

Iluminación



Planes y programas definidos por la organización para le mejora del control interno

Eficiencia en la aplicación de las metodologías y herramientas para la autoevaluación, autocontrol y autorregulación.

Todos los procesos de la Compañía

165

Anexo L. POLÍTICAS DE CORRECOL S.A.

POLITICA DE SEGURIDAD DE LA INFORMACIÓN

OBJETIVO Establecer el direccionamiento y permitir la promulgación de objetivos generales de seguridad de la información, así como fortalecer el compromiso de velar por la seguridad de la misma por parte de todos los colaboradores de CORRECOL S.A. ALCANCE Aplica para todos los funcionarios de CORRECOL S.A. DEFINICIONES

Confidencialidad: La propiedad de que la información sólo sea conocida por aquellas personas que tienen derecho legítimo a conocerla

Disponibilidad: La propiedad de que la información se encuentre disponible en los puntos de uso cuando ésta sea requerida por una persona autorizada

Integridad: La propiedad de que la información sea integra, confiable y no haya sido alterada bajo ninguna circunstancia

Sistema de Gestión: Conjunto de procesos y procedimientos encaminados a la planeación, construcción, monitorea y mejora continua de la seguridad de la información

ABREVIATURAS SGSI. Sistema de Gestión de Seguridad de la Información CONDICIONES GENERALES

Ya que se cuenta con un Sistema de Gestión de Seguridad de la Información,

es necesario el compromiso de TODOS los colaboradores de CORRECOL S.A. con el cumplimiento de una política general de seguridad de la información.

DESCRIPCIÓN DE LA POLÍTICA

166

La Alta Dirección de CORRECOL S.A. se compromete con el mantenimiento del Sistema de Gestión de Seguridad de la Información, que es de obligatorio cumplimiento para todos los colaboradores de la organización en aras de proteger la confidencialidad, integridad y disponibilidad de la información propia, de clientes y de terceros que sea requerida para la correcta operación del negocio.

CUMPLIMIENTO DE LA POLÍTICA Para cumplir con la política del Sistema de Gestión de Seguridad de la Información, se han establecido un compendio de políticas y procedimientos de apoyo, cuya responsabilidad de aprobación está en cabeza de la Gerencia General y su mantenimiento a cargo del Oficial de Seguridad de la Información o quien haga sus veces apoyado en el área de Sistemas de Gestión.

Todos los colaboradores de CORRECOL S.A., deben velar por el cumplimiento de sus compromisos legales, regulatorios y contractuales, brindándoles seguridad y calidad en las operaciones que tiene a su cargo.

POLITICA DE CONTINUIDAD DEL NEGOCIO

OBJETIVO Garantizar que se incluyan los aspectos de seguridad de la información en el plan de continuidad de negocios. ALCANCE Aplica a los Administradores de Sistemas, Gerencia de TI y al Oficial de Seguridad. DEFINICIONES

Confidencialidad: La propiedad de que la información sólo sea conocida por

aquellas personas que tienen derecho legítimo a conocerla.

Disponibilidad: La propiedad de que la información se encuentre disponible en

los puntos de uso cuando ésta sea requerida por una persona autorizada.

Integridad: La propiedad de que la información sea integra, confiable y no haya

sido alterada bajo ninguna circunstancia.

DESCRIPCIÓN DE LA POLÍTICA

167

Se deben establecer procedimientos de restablecimiento de las actividades críticas para garantizar la continuidad del negocio en CORRECOL S.A. en momentos de crisis y recuperación.

Se deben analizar riesgos de continuidad para el establecimiento del Plan de

Continuidad de Negocio.

Se deben realizar pruebas periódicas del plan de continuidad de negocio al

menos una vez al año, efectuando las actualizaciones y mejoras que resulten de dichas pruebas.

La participación del personal correspondiente de CORRECOL S.A. en las

pruebas de continuidad es de carácter obligatorio.

POLITICA DE CLASIFICACIÓN DE LA INFORMACIÓN

OBJETIVO Establecer los lineamientos para el manejo de la confidencialidad de la información de CORRECOL S.A. ALCANCE Aplica a toda la información que se maneja en CORRECOL S.A. DEFINICIONES Confidencialidad: Propiedad de que la información sólo sea conocida por

aquellas personas que tienen derecho legítimo a conocerla.

Disponibilidad: Propiedad de que la información se encuentre disponible en los

puntos de uso cuando ésta sea requerida por una persona autorizada.

Integridad: Propiedad de que la información sea integra, confiable y no haya

sido alterada bajo ninguna circunstancia.

CONDICIONES GENERALES

La Alta dirección de CORRECOL S.A. se compromete con el establecimiento de un Sistema de Gestión de Seguridad de la Información, que es de obligatorio cumplimiento para todos los funcionarios de la organización en aras de proteger la

168

confidencialidad, integridad y disponibilidad de la información propia, de clientes y de terceros que sea requerida para la correcta operación del negocio. DESCRIPCIÓN DE LA POLÍTICA La información de CORRECOL S.A es de uso interno por parte de su

responsable o de las áreas que legítimamente deben tener acceso a ella (a menos que sea clasificada de forma diferente de acuerdo al Procedimiento Clasificación de la Información).

Es obligación de cada responsable clasificar la información dentro de los criterios

que CORRECOL S.A ha establecido en el Procedimiento Clasificación de la Información.

Para la clasificación de la información se debe tener en cuenta el grado de

confidencialidad requerido en su manejo, entendiéndose por confidencial aquella información cuyo conocimiento por parte de usuarios no autorizado implique riesgos para la seguridad de la información de CORRECOL S.A.

El carácter de confidencialidad de la información, es una cualidad requerida para

que los procesos se den en un ambiente de control adecuado que garantice una correcta segregación funciones. En este sentido la confidencialidad no debe asimilarse a la no disponibilidad de la información. Dado el carácter de su información, CORRECOL S.A debe poner a disposición la información en el evento que sea requerida mediante mandato judicial o cuando lo considere pertinente.

La información confidencial es rotulada para que de una forma fácil y visible

pueda ser identificado su grado de clasificación, conforme con lo establecido en el Procedimiento Clasificación de la Información.

CORRECOL S.A lleva a cabo con la mayor diligencia todas las acciones que

sean necesarias para garantizar que la información clasificada se mantenga como tal de acuerdo con su nivel de clasificación y requerimientos de seguridad. Para garantizar la clasificación de la información se utiliza tecnologías, hardware, software o servicios que aseguren un adecuado control de acceso a la información.

Para los datos relacionados con el manejo de los datos personales de cada uno

de los clientes de CORRECOL S.A, administración, disposición y confidencialidad, se rigen bajo lo indicado en el Manual De Políticas y Procedimientos sobre Tratamiento de Datos Personales.

169

POLÍTICA DE SEGURIDAD EN LOS PROYECTOS OBJETIVO Incrementar la identificación de requisitos y gestión de riesgos de seguridad en los proyectos de CORRECOL S.A. ALCANCE Esta política se aplica para todos los proyectos que se generan en CORRECOL S.A. desde la planeación hasta su cierre. DEFINICIONES Proyecto: esfuerzo que se lleva a cabo para crear un producto o servicio, y que

tiene la característica de ser temporal, es decir, que tiene un inicio y un final establecido. El final de un proyecto es alcanzado cuando se logran sus objetivos o cuando se termina ya no existe la necesidad que lo originó.

Seguridad de la Información: se define como el conjunto de medidas

preventivas, correctivas y reactivas que permiten proteger la información de CORRECOL S.A, buscando mantener la confidencialidad, integridad y disponibilidad de la misma.

Plan de Tratamiento de Riesgos: Conjunto de contramedidas a implementar

para prevenir la materialización de un riesgo.

Riesgo Residual: Se define como el riesgo después de controles.

Activo Crítico: elemento cuya valoración media de integridad, confidencialidad

y disponibilidad, en la matriz de inventario de activos, dio como resultado una ponderación “Alta”.

DESCRIPCIÓN DE LA POLÍTICA Todos los proyectos que se gesten en CORRECOL S.A, deben realizar una identificación y valoración de riesgos que incluyan riesgos de Seguridad de la Información, esta identificación debe contener como mínimo lo siguiente: Descripción del riesgo Valoración de probabilidad

170

Valoración de impacto Calculo del riesgo residual Plan de tratamiento de riesgos

Se deben gestionar los riesgos para prevenir su materialización en el proyecto. En caso tal de que el proyecto involucre cualquier tipo de cambio en algún activo crítico (ver valoración de activos en el inventario de activos) deberá involucrarse en el proyecto al Oficial de Seguridad de la Información. Es necesario que para cada proyecto se identifiquen los requerimientos de seguridad que se deben tener en cuenta dura todo el ciclo de vida del proyecto. Para el envío de información, es preciso determinar si la información a comunicar es sensible o confidencial y si se necesita adoptar medidas adicionales de seguridad, para ello se debe cumplir lo estipulado en la POLÍTICA DE TRANSFERENCIA DE INFORMACIÓN. Si el proyecto involucra a proveedores, se debe heredar el cumplimiento de las políticas, controles y requerimiento de seguridad a estos, al igual que velar por el cumplimiento de la POLÍTICA PARA LA RELACIÓN CON PROVEEDORES En caso de requerir la implementación de controles criptográficos dentro del proyecto, estos deben evaluarse en conjunto con el Equipo de Seguridad de la Información y buscar su aprobación o rechazo en conjunto, para ello es necesario dar cumplimiento a la POLÍTICA DEL USO DE CONTROLES CRIPTOGRÁFICOS, y a la POLÍTICA DE GESTIÓN DE LLAVES CRIPTOGRÁFICAS. POLITICA DE TRANSFERENCIA DE INFORMACIÓN.

OBJETIVO Establecer los lineamientos que se tendrán en cuenta para el intercambio de información interna y con terceros. ALCANCE Aplica a todos los funcionarios de CORRECOL S.A. DEFINICIONES Compañía Externa, Tercero: Cualquier persona o empresa ajena a la

compañía (cliente, proveedor, usuario, contratista, etc.) que por razón de sus

171

actividades deba acceder a información contenida o bajo custodia de la compañía.

Riesgo Reputacional: El riesgo al que se encuentra expuesta la compañía por

el uso indebido de su nombre y que puede causar lesiones severas a la reputación.

Riesgo Operativo: Es la posibilidad de ocurrencia de pérdidas originadas por

fallas, deviaciones o insuficiencias en la ejecución de los procesos, conocimiento de las personas, manejo de sistemas internos, tecnología, y en la presencia de eventos externos imprevistos.

DESCRIPCIÓN DE LA POLÍTICA En caso de transferir información por cualquier medio de transmisión (electrónico,

físico, impreso, audiovisual) con terceros, sean estos clientes, proveedores, organismos de control o una compañía externa de cualquier otra índole, es necesario seguir el Procedimiento de intercambio con terceros.

Como base para establecer los controles se toma la clasificación de la información de

que trata la Política de Clasificación de la información, ya que bajo ninguna

circunstancia se puede pasar por alto dichos controles establecidos ni se puede poner en riesgo la información que haya sido clasificada como confidencial.

Se deben establecer mecanismos que incluyan la firma de acuerdos de intercambio

de información con los terceros (cuando sea viable y lo considere la compañía) estableciendo claramente las responsabilidades de CORRECOL S.A. y del receptor de la información.

Adicionalmente, cuando la información, sea cual sea el medio en que se encuentre,

deba ser transportada de un lugar a otro, se toman las medidas necesarias para garantizar que dicha información no es susceptible de acceso no autorizado.

Se debe realizar la revisión de los contratos estimados con sus partes interesadas para

corroborar los lineamientos específicos en relación al tratamiento de la información para la prestación del servicio, así como el control y acceso al mismo.

POLITICA DE CONTROL DE ACCESO OBJETIVO

172

Establecer los lineamientos correspondientes mediante los cuales CORRECOL S.A. controla el acceso lógico a sus activos de información. ALCANCE Aplica a todos los colaboradores y proveedores de CORRECOL S.A. DEFINICIONES Activos de Información: Cualquier pieza de información, sea esta en cualquier

medio magnético, impreso o que sea transmitida electrónica, visual u oralmente y que tenga importancia para el cumplimiento de las funciones.

Redes de datos: Cualquier mecanismo de interconexión por cable o inalámbrico

que permita la comunicación de dos o más sistemas de cómputo para compartir recursos entre sí.


Esta política aplica para el control de acceso físico y lógico en CORRECOL S.A.

CORRECOL S.A. controla el acceso a su información, en virtud de los

parámetros de clasificación de información de que trata la Política de Clasificación de Información, la Política de Intercambio de Información, la normatividad vigente y los requerimientos propios para resguardar y preservar la seguridad de sus activos de información.

DESCRIPCIÓN DE LA POLÍTICA Control de Acceso Lógico Todos los sistemas de información deben contar con un control de acceso que

solicite como mínimo usuario y contraseña.

Todos los sistemas de información deben permitir el cumplimiento de la Política de Contraseñas de CORRECOL S.A.

Se deben definir los privilegios que pueden tener los usuarios respecto a las aplicaciones, acorde a lo siguiente:

o Instalación o Desinstalación o Configuración

173

o Arranque o Detención o Funciones de auditoria

Para la implementación de esta definición se debe seguir el Procedimiento de

Gestión de Cuentas de Usuario.

Cuentas de Usuario Las cuentas de usuario definidas para CORRECOL deben cumplir estrictamente

y sin ninguna excepción con las siguientes condiciones:

o Cualquier cuenta de usuario a ser creada debe tener una justificación en

una o más actividades que se encuentren formalmente definidas en uno o más procesos de CORRECOL S.A.

o Las cuentas son de uso personal e intransferible, por lo tanto, no se permite el préstamo de usuarios o contraseñas bajo ninguna circunstancia.

o No puede haber una cuenta con acceso para más de una persona. o Se deben deshabilitar TODAS las cuentas genéricas de los sistemas de

información (Por ejemplo: Administrador, Auditor, Invitado, etc.). o En ningún caso se puede aceptar la suplantación o uso de una cuenta por

parte de una persona diferente a la que le fue asignada.

La gestión de cuentas de usuario en CORRECOL S.A. debe seguir los siguientes

lineamientos:

o La creación de cuentas de usuario debe seguir el Procedimiento de

Registro, Cancelación y Modificación de Cuentas de Usuario. o El reporte de eliminación de una cuenta debe hacerse en forma inmediata

a la Dirección de Recursos Humanos, siguiendo de igual manera el Procedimiento de Registro y Cancelación de Cuentas de Usuario.

o Se deben gestionar las cuentas de usuario mediante un listado de personal con sus respectivas cuentas y privilegios.

La asignación de accesos, periodos de cambios que ameriten modificación en el

acceso al sistema por parte de los colaboradores, la asignación de privilegios y la revisión periódica de dichos privilegios para garantizar que los mismos no exceden las funciones del usuario y los niveles de autorización necesarios para gestionar los usuarios en los sistemas, debe realizarse siguiendo el Procedimiento de Registro, Cancelación y Modificación de Cuentas de Usuario.

174

Se debe controlar mediante métodos tecnológicos o manuales, automatizados o

no, el cumplimiento del Procedimiento de Registro, Cancelación y Modificación de Cuentas de Usuario.

Control de Acceso a las redes Ninguna persona ajena a la organización puede hacer uso de la red de datos

bajo ninguna circunstancia.

Se debe realizar segmentación de redes acorde a la criticidad de la información almacenada por los equipos que se encuentran conectados en la red.

Se debe controlar el acceso e identificación de los equipos que se encuentran conectados a la red corporativa.

Control de Accesos Privilegiados Los colaboradores con accesos privilegiados a los sistemas de información son

los Gerentes, Directores y Administradores del sistema.

El abuso de permisos de administración por parte de los colaboradores con accesos privilegiados, será sancionado de acuerdo a lo descrito en el reglamento interno de trabajo y su tratamiento se realizará de acuerdo a la política disciplinaria interna.

POLITICA DE DESARROLLO SEGURO OBJETIVO Asegurar que la seguridad de la información este inmersa en el diseño e implementación del ciclo de vida del desarrollo de los sistemas de información. ALCANCE La política de desarrollo seguro debe aplicar para todas las aplicaciones utilizadas en CORRECOL S.A. DEFINICIONES Desarrollo seguro: prácticas de programación que se utilizan en el desarrollo

de software garantizando la integridad, confidencialidad y disponibilidad.


175

En esta sección se presentan las directrices que deben ser seguidas para el desarrollo de aplicaciones a ser usadas en CORRECOL S.A.

DESCRIPCIÓN DE LA POLÍTICA Confidencialidad

Considerando la clasificación para los activos de información, cada aplicación debe proveer los mecanismos para proteger la confidencialidad con base en el nivel al que pertenezca el activo que se va a proteger. Los mecanismos que las aplicaciones desarrolladas para CORRECOL S.A. deben proveer son:

Cifrado de datos sensibles: Opción de cifrar los datos en tránsito y

almacenamiento con un algoritmo criptográfico fuerte, como lo son a la fecha del desarrollo de este documento, se toma como referencia AES.

Control de acceso: Mecanismos de autenticación por usuario y contraseña siguiendo la Política de control de acceso a la información de CORRECOL S.A.

Registro: Permitir la parametrización para generar el registro en logs de eventos que permitan registrar los accesos a la información y así poder evidenciar potenciales violaciones a la confidencialidad de la información.

Integridad

Para proteger la integridad de la información las aplicaciones deben desarrollar las siguientes utilidades, que serán aplicadas con base en la clasificación del activo de información a proteger:

Control de acceso: Equivale a la funcionalidad descrita para la protección de la Confidencialidad

Verificación por Hashing: Opción que permita validar la integridad de los datos almacenados y/o transmitidos utilizando un campo de Hashing que se genere con el algoritmo SHA que será calculado en la capa de acceso a datos con el uso de una librería validada. Este valor será almacenado hasta el momento en que se requiera la validación de integridad, momento en que se volverá a calcular el Hashing y se realizará la comparación con el valor almacenado anteriormente.

Registro: Permitir la parametrización para generar el registro en logs de eventos que permitan registrar los accesos a la información y así poder evidenciar potenciales violaciones a la integridad de la información.

Disponibilidad

Para cumplir con los requerimientos de disponibilidad, las aplicaciones

176

desarrolladas para CORRECOL S.A deben mitigar el riesgo de interrupciones con la aplicación de mejores prácticas relacionadas con manejo de excepciones, validación de entradas, controles criptográficos y gestión de sesiones tal como se presenta en la siguiente sección.

Requerimientos Generales Eventos a ser registrados

Las aplicaciones para CORRECOL S.A. deben contar con la opción de registrar las siguientes acciones:

Creación, modificiación y/o eliminación de datos

Creación, modificación y/o eliminación de usuarios

Creación, modificación y/o eliminación de perfiles de usuario

Cambios en la configuración de la aplicación

Información general del sistema: configurar las opciones que serán registradas sobre desempeño de la aplicación, caídas, puesta en servicio, bloqueos, detención manual del servicio, problemas de hardware, entre otros.

Datos a registrar Se requiere que las aplicaciones cuenten con la opción de registrar los siguientes datos:

Fecha y hora: Señalando el año, mes, día, hora y segundos de la recepción del

requerimiento

Usuario: Identificación de la cuenta responsable de la acción

Tipo de requerimiento: Señalar cual fue la acción solicitada por el usuario

ID: Identificador de la transacción. Para dar un ejemplo en Java, se tomará del

campo Sesion-id que establece un número único por sesión y que se complementará con un contador que identificaría cada transacción en particular.

Tiempo de procesamiento: Intervalo de tiempo en el cual el usuario recibió la

respuesta. En el caso de Java, esto podrá ser manejado con una API que permitirá medir los tiempos de procesamiento para cada transacción entre las capas y frente al cliente.

Alerta: Registrar si durante la ejecución de la transacción se presentó alguna

situación Anormal. Es necesario implementar una función de manejo de excepción en las capas de presentación, lógica de negocio y acceso a datos para lograr capturar el código de error, en el caso de presentarse, se tomaría

177

del componente web y/o de los mensajes manejados que pueden ser http por ejemplo.

Exitosa técnicamente: Saber si la transacción cumplió con el proceso y se dio

una respuesta al usuario dentro del período de tiempo definido, esto se logra registrar, verificando si hay algún código de error de acuerdo a lo indicado en las alertas.

Problema identificado: Si la transacción no fue exitosa, especificar la causa

correspondiente como problemas en la conexión, no hay respuesta de la Base de Datos, problemas en el enlace; se utilizará el mismo mecanismo descrito en el campo de alerta.

Registro afectado: ID del registro objetivo de la acción del usuario

Base de datos: ID de la Base de Datos afectada por la acción del usuario

Tabla: ID de la tabla afectada por la acción del usuario

Dirección IP: Desde donde se realizó el requerimiento. Esto depende de las limitantes que se puedan tener Java con el manejo del protocolo http y lo que el browser envíe – las limitantes serían inherentes a la tecnología.

Tamaño de la trama: Registrar el tamaño del mensaje enviado para la solicitud

Tamaño de la trama de respuesta: Registrar el tamaño del mensaje que la aplicación respondió

Validación de Datos de Entrada

Si hay carencias en esta funcionalidad se presentarán vulnerabilidades de inyección o buffer overflow, que pueden causar ataques de negación de servicio que afecten la disponibilidad o acceso no autorizados que afectarían la integridad y/o confidencialidad. En el desarrollo de la aplicación se tendrán las siguientes consideraciones:

Protección contra Buffer Overflow: Aplicación de las mejores prácticas en el

desarrollo para tener un estricto control en la definición del tipo de variables para que se ajusten a los requerimientos. La validación se realiza analizando el código en cada una de las sentencias de definición de variables para que se limiten a un dominio o rango requerido por la función correspondiente. Un buffer Overflow se presenta cuando se acepta como entrada grandes cantidades de caracteres que logran desbordar el segmento de datos y que adicionalmente con una longitud específica pueden llegar a un segmento privilegiado de la memoria, donde se pueden ejecutar ciertos comandos; es decir que el atacante debe encontrar esta longitud y adicionalmente definir el comando que lograría ejecutar. Considerando lo anterior cada variable definida debe tener un tipo de datos limitado, preferiblemente definido por el programador y que los

178

mecanismos sean diseñados para que solo capturen lo estipulado por los formatos aceptados o lo estrictamente requerido, por ejemplo si se va a capturar un número celular, la variable definida debe ser un campo tipo texto de 10 caracteres y cuando se capture dicho campo se debe validar que solo se acepten valores entre 0 y 9 y que la entrada solo puede ser de 10 caracteres rechazando cadenas de texto de menor o mayor longitud; si dentro de la revisión de código se evidencia que no se implementan estas restricciones, a pesar de que funcionalmente sea aprobado se está generando una vulnerabilidad.

Restricción de las capturas: Los datos que se ingresen al sistema estarán

restringidos por la longitud y el tipo de datos para limitar a lo estrictamente necesarios. La validación se realiza analizando el código para cada una de las sentencias de captura de datos, verificando que se realice la “sanitización” o validación que restrinja los valores que puedan ser ingresados. Para cada uno de los campos capturados las entidades deben definir el tipo de datos que se va a capturar el cual puede seguir el estándar aceptado o entregar la especificación correspondiente; la validación debe proceder para constatar que las capturas de datos validen que no se ingresen caracteres que puedan ser usados para una intrusión y esto es cadenas de texto que correspondan a “Comandos o instrucciones en los lenguajes o sistemas operativos involucrados”, de esta forma en el Programador debe considerar los filtros más exigentes posibles de tal forma que sin limitar datos validos restrinja palabras o Wildcards que puedan ser usados en comandos o instrucciones. Se debe considerar que muchas veces los atacantes cambian las codificaciones (ASCII, EBCDIC, UNICODE) para saltarse los controles. Particularmente en el Aplicación para que la labor de Programación sea más efectiva en la implementación de estos filtros es requerido el mayor nivel de especificación para los datos recibidos de los usuarios y a intercambiar con las entidades. A simple vista podría exigirse que en ninguno de los campos tenga porque aceptarse caracteres diferentes a números y letras y que los signos de puntuación solo apliquen para campos tipo Memo, validando que estos no sean consecutivos, es decir nada justificaría que alguien ingrese algo como un punto y una coma consecutivos.

Librerías: Se tendrá una validación para evitar el uso de librerías con vulnerabilidades de cualquier tipo. La validación se realiza analizando el código y evaluando que cada una de las librerías utilizadas no tengan reporte de vulnerabilidades. Se tendrá una validación en el Framework de desarrollo el cual alertará sobre las librerías que se encuentren obsoletas y así evitar el uso de componentes vulnerables para la aplicación. Las vulnerabilidades son catalogadas por los boletines emitidos por los fabricantes correspondientes.

Parámetros pasados a través de la URL: Restringir el tamaño y el tipo de

caracteres que son pasados en los parámetros de la URL para evitar ataques de Cross Site Scripting y la exploración no autorizada de directorios del servidor donde resida la aplicación. La validación se realiza analizando el código para cada una de las sentencias de captura de datos, verificando que se realice la

179

validación que restrinja los valores que puedan ser ingresados; aplica el mismo concepto definido en la restricción de las capturas solo que en este caso aplicaría para los parámetros pasados de una URL, en el cual los filtros van a ser orientados hacia los datos que se puedan requerir en este entorno, es decir para este caso debe aceptarse el uso de la barra inclinada o Slash.

Es muy importante señalar que estos controles deben ser complementados por los mecanismos de seguridad perimetral tal como se especificó en la parte de Arquitectura.

Manejo de excepciones

En el desarrollo de la Aplicación, para cada una de las funciones implementadas seran contempladas las opciones resultantes de los casos de abuso, es decir evitar que la aplicación pierda el control en el flujo posible de acciones, evitando que una excepción permita violar las políticas de seguridad definidas. Todas las funciones tendrán un manejo específico para los casos que estén por fuera de los que señalan los requerimientos funcionales. Se hará uso de defunciones como en el caso de Java try-catch que permiten establecer el control para los casos de excepción en las diferentes capas.

CONTROL DE SESIÓN

Se debe contar con la opción de definir un tiempo máximo de sesión. Se debe hacer uso herramientas predefinidas en los diferentes entornos, en el caso de Java con el uso de la clase httpsession y el Java Web Framework se verificarán las opciones posibles para controlar los tiempos de sesión mínimo y máximo, como también un control de memoria aplicando un reinicio de sesión por cada nueva solicitud en el menú o interface de usuario. POLITICA DE DISPOSITIVOS DE ALMACENAMIENTO EXTRAIBLE

OBJETIVO Evitar la fuga de información que se pueda generar a través del uso de dispositivos de almacenamiento extraíble en CORRECOL S.A ALCANCE Esta política se aplica para todos colaboradores y externos que manejen información de CORRECOL S.A. DEFINICIONES

180

Dispositivos de almacenamiento extraíble: elementos de almacenamiento de

datos en formato digital, tales como: memorias USB, CDs, DVDs, Smartphones, memorias SD, entre otros. DESCRIPCIÓN DE LA POLÍTICA Todo el intercambio de información que se realice a nivel interno en CORRECOL S.A. deberá efectuarse mediante el servidor de archivos y las carpetas compartidas por red dispuestas para ello. Todas estaciones de trabajo y portátiles, deben tener restringido el uso de dispositivos de almacenamiento extraíble. En caso tal de que se requieran realizar excepciones para el uso de dispositivos de almacenamiento extraíble, se debe solicitar a través del FORMATO DE ACTIVACIÓN DE USO DE DISPOSITIVOS DE ALMACENAMIENTO EXTRAIBLE y siguiendo los lineamientos descritos en esta política y el PROCEDIMIENTO DE SOLICITUD DE USO DE MEDIOS REMOVIBLES. En los equipos de cómputo que se tenga habilitado el uso de dispositivos de almacenamiento extraíble, solo se podrán utilizar dispositivos que sean propiedad de CORRECOL S.A., en ningún caso se podrán utilizar dispositivos personales para almacenar información de CORRECOL S.A. Los dispositivos de almacenamiento extraíble autorizados para su uso en CORRECOL, deberán estar cifrados y configurados para que soliciten una clave para el acceso a estos. El único personal autorizado para ejecutar el formateo de los dispositivos de almacenamiento extraíble autorizados por CORRECOL S.A, son los colaboradores del área de TECNOLOGÍA DE LA INFORMACIÓN Y COMUNICACIONES. POLITICA DE RESPALDO DE INFORMACIÓN

OBJETIVO Establecer los lineamientos para el respaldo de la información de CORRECOL S.A. ALCANCE Aplica a toda la información que se maneja en CORRECOL S.A. DEFINICIONES

181

Disponibilidad: La propiedad de que la información se encuentre disponible en

los puntos de uso cuando ésta sea requerida por una persona autorizada.

DESCRIPCIÓN DE LA POLÍTICA Se deben generar copias de seguridad de la información crítica, con el ánimo de

mantener la disponibilidad de la información ante algún tipo de evento natural o humano que impacte de forma relevante la normal operación de CORRECOL S.A.

Las copias de respaldo deberán almacenarse en lugar externo a las instalaciones

principales de CORRECOL S.A, resguardarlos físicamente de una forma segura y efectuar las pruebas de recuperación que sean necesarias para asegurar que la información se encuentra disponible aun luego de un desastre natural o error humano.

Las copias de respaldo deben ejecutarse sobre configuración de servidores

virtuales, bases de datos, servidor de archivos y datos que se encuentren en los diferentes sistemas de información de CORRECOL S.A.

Todas las copias de seguridad deben estar identificadas y rotuladas claramente;

igualmente se debe mantener registro en una bitácora de respaldos.

182

Anexo M. MODELO DE RIESGOS ACTUAL EN EL SGSI Actualmente se han presentado riesgos asociados a la seguridad de la información, es importante realizar de una manera correcta el plan de tratamiento de los riesgos, ya que de no ser analizados y definidos cuidadosamente pueden transformarse en un incidente crítico. Para los controles se presentan las siguientes escalas: Cuadro 27. Controles de tratamiento del riesgo.

Efectividad Descripción

1 No efectivo

Los controles no mitigan los riesgos o son imposibles de implementar

2 Deficiente

Controles inadecuados y con frecuencia no pueden entregar los resultados esperados. Se requiere mejora

3

Adecuado Los controles funcionan, pero requieren de monitoreo y mantenimiento. Podrían ser omitidos por algunas personas

4 Muy Efectivo Los controles funcionan más allá de lo establecido

5 Control Completo

Los Controles establecidos siempre funcionan y no pueden ser omitidos ni manipulados

Procesos: Ejemplo Control Interno, Facturación y cartera, Recursos humanos

Evento o amenazada: Evento o Amenaza: Daño, destrucción o eliminación, Hurto de Portátiles, entre otros. Causa o vulnerabilidad: Se producen en su mayoría por ausencia de controles. Ejemplo Ausencia de copias de respaldo, Información sensible almacenada en impresoras, no se cuenta con el código fuente del software versionado. Valoración de impacto: Catastrófico, Mayor, Moderado, Menor, Insignificante Probabilidad del escenario: Altamente Probable, Muy Probable, Probable, Poco Probable, Remoto Controles actuales: Se establecen acciones sobre cada riesgo Efectividad de Control: De acuerdo al control dado se establecen revisiones

periódicas para validar la eficaz del control. De acuerdo al resultado del Riesgo residual, se establece el plan de tratamiento del riesgo, asignando responsable, fecha de inicio y terminación.

183

Cuadro 28. Listado de riesgos.

#

Nombre del

Proceso

Evento o Amenaza

Desc Causa Impacto Probabil

idad

Riesgo Inicial

Controles

Actuales

Efectividad

Riesgo

Residual

Tratamiento

17

Indemnizaciones

Error Humano

Error humano al ingres

ar datos

al Broker

en Indemnizaciones

El software no valida

la informaci

ón cuando

se ingresa.

Mayor Muy

Probable Inacept

able

No hay control

No hay Control

Inaceptable

1. Finalizar el desarrollo del nuevo ERP. 2. Ejecutar pruebas del ERP. 3. Planear paso a producción. 4. Capacitar a usuarios. 5. Generar paso a producción.

19

Gestión de

Pólizas y Document

os

Error Humano

Error humano al ingres

ar datos por

Excel

no hay sistema

de beneficio

s

Mayor Muy

Probable Inacept

able

No hay control

No hay Control

Inaceptable

1. Establecer reglas de validación de datos en el Excel de Beneficios, o desarrollar un sistema con validaciones para esta área

184

21

Gestión de

Pólizas y Document

os

Falla

El Broker gener

a errores en

temas de

facturación

de Beneficios

No se cuenta con el código fuente

del Software

Mayor Muy

Probable Inacept

able

Se está desarrollando un ERP para CORRECOL

Nula Grave

1. Finalizar el desarrollo del nuevo ERP. 2. Ejecutar pruebas del ERP. 3. Planear paso a producción. 4. Capacitar a usuarios. 5. Generar paso a producción. 6. Revisar propiedad intelectual de desarrollos.

185

22

TODOS Falla

El Broker gener

a errores en

descarga

No se cuenta con el código fuente

del Software

Mayor Muy

Probable Inacept

able


Nula Grave


186

23

TODOS Daño

Duplicidad de

información en el

Broker

no se realizan verificaciones de

interrelación de

información

Mayor Muy

Probable Inacept

able


Nula Grave


187

33

Gestión de

Pólizas y Document

os

Perdida o Hurto

perdida de

información

de Revisiones

Ausencia de

controles de

almacenamiento

y resguard

o

Mayor Muy

Probable Inacept

able

Se cuenta con respaldo de información de Revisiones, en caso de no tener respaldo este se puede recuperar fácilmente.

Total Tolera

ble

1. Realizar una campaña de sensibilización para solicitar y asegurar que se brinda respaldo de la información.

188

37

Administrativo

Fuga de Informació

n

fuga de

información

de Contabilidad

ausencia de

controles de

almacenamiento

físico

Mayor Altament

e Probable

Inaceptable

Se almacenan los documentos en una bodega en el sótano. Las llaves de la bodega solo las tienen los digitalizadores.

Ocasional

Tolerable

1. Generar una bitácora de acceso a la bodega

189

45

Sistemas de

Gestión

Indisponibilidad

Indisponibilidad del

personal de seguridad

No se cuenta

con personal

de respaldo

Moderado

Poco Probable

Tolerable

No se cuenta con un pool de hojas de vida de posibles candidatos de remplazo

No hay Control

Tolerable

1. Obtener un pull de Hojas de Vida de candidatos de remplazo

46

Tecnología de

Información y

Comunicaciones

Indisponibilidad

Indisponibilidad de la

información de los servidores

Ausencia de

documentación de

la operación de TI

Mayor Probable Grave

No se cuenta con documentación de la operación

No hay Control

Inaceptable

1. Generar documentación de los procesos de operación de TI, y estándares de configuración de los servidores

190

47

TODOS Modificaci

ón o Alteración

Modificación

o alteración del

Broker

Ausencia de

mecanismos de

auditoria


No se cuenta con mecanismos de auditoria

No hay Control

Inaceptable

1. Finalizar el desarrollo del nuevo ERP. 2. Ejecutar pruebas del ERP. 3. Planear paso a producción. 4. Capacitar a usuarios. 5. Generar paso a producción. 6. Revisar propiedad intelectual de desarrollos. 7. Contar con mecanismos tecnológicos de auditoria en el ERP

191

52

TODOS Fuga de

Información

Fuga de

información de los correo

s enviad

os

Ausencia de

controles de

cifrado


No hay control

No hay Control

Inaceptable

1. Realizar la migración de todas las cuentas de correo a Office 365. 2. Implementar licenciamiento de cifrado para la transferencia de información. 3. Capacitar a los usuarios.

desarrollo de un sistema de informaciÓn web para la

Documents