manual de reglas de negocio asociadas al proceso diseño ... · pdf fileestructura...

ESTRUCTURA NORMATIVA DE EMPRESAS PÚBLICAS DE MEDELLÍN E.S.P.

REGLAS DE NEGOCIO ASOCIADAS AL PROCESO DISEÑO DEL SERVICIO DE TI

Página 1 de 51

Manual de reglas de negocio asociadas al proceso diseño del servicio de TI pertenecientes al macro proceso gestión de

tecnología de información Versión Junio 2012

Página 1

MANUAL DE REGLAS DE NEGOCIO ASOCIADAS AL PROCESO DISEÑO DEL SERVICIO DE TI PERTENECIENTES AL MACRO

PROCESO GESTIÓN DE TECNOLOGÍA DE INFORMACIÓN

VERSIÓN 001

Junio 2012



Página 2 de 51



Página 2

Tabla de contenido

INTRODUCCIÓN

OBJETIVO

GLOSARIO DE TÉRMINOS

1 REGLAS DE NEGOCIO PARA EL PROCESO DISEÑO DEL SERVICIO DE TI. ............... 9

1.1 Reglas relacionadas con ingeniería requisitos del servicio de TI ....................................... 9

1.2 Reglas relacionadas con el diseño de la arquitectura del servicio de TI. ......................... 11

1.3 Reglas relacionadas con gestión de la disponibilidad del servicio de TI .......................... 12

1.4 Reglas relacionadas con gestión de la capacidad del servicio de TI ............................... 13

1.5 Reglas relacionadas con gestión de la continuidad del servicio de TI. ............................ 14

1.6 Reglas relacionadas con gestión de la seguridad del servicio de TI. ............................... 23

1.7 Reglas relacionadas con gestión de catálogo y niveles de servicios de TI ...................... 47



Página 3 de 51



Página 3

INTRODUCCIÓN

Acorde con el Modelo Normativo Interno propuesto para las Empresas, mediante el cual se

busca optimizar el manejo de la información, la efectividad en la toma de decisiones y facilitar la

operación, corresponde al Subdirector de Tecnología de Información (STI-EPM) dictar las

reglas de negocio para la “Gestión de Tecnología de Información” contando con una normativa

interna que indique como se deben operar, sin desconocer las normas externas que impactan

los mismos, es decir, tomando como referente las disposiciones legales y estatutarias de los

sistemas y modelos de gestión.

El Modelo Normativo Interno para su aplicación tiene en cuenta dos manuales, el primero

contiene la política aprobada por la Junta Directiva de EPM y los lineamientos dictados por el

Gerente General; el segundo manual relaciona las reglas de negocio definidas por el

responsable del proceso que detallan o establecen la operación del proceso.

Como parte del primer manual, la Junta Directiva en su sesión de febrero 01 de 2011, según

Acta 1528 definió la política para la “Gestión de Tecnología de Información” en los siguientes

términos: “En EPM, la Gestión de Tecnología de Información habilita a la empresa para que

disponga de la información requerida por los grupos de interés y se adapte oportunamente a

los cambios generados por el entorno, sus procesos y la visión de negocio, usando como

referencia la arquitectura empresarial y operando bajo un modelo de prestación de servicios

con las mejores prácticas de mercado como una forma de apalancar la sostenibilidad y el

crecimiento del negocio”.

Paso siguiente, el Gerente General el 31 de enero de 2012, según Decreto 1866 definió el

“Manual de lineamientos asociados al macroproceso gestión de tecnología de información”, y

como objetivo fundamental “Establecer los Lineamientos Asociados al Macro proceso Gestión

de Tecnología de Información, con el propósito de guiar la toma de decisiones en el marco de

tecnología de información (TI en este documento) y la optimización y aprovechamiento de sus

recursos.”

Y como parte del segundo manual, “Bajo el entendido de que los lineamientos están en

continua evolución, la Subdirección Tecnología de Información (STI-EPM) tiene, de acuerdo



Página 4 de 51



Página 4

con el marco de gobierno definido para el Grupo Empresarial EPM (GE-EPM), la

responsabilidad de crear los mecanismos de actualización y divulgación apropiados que

permitan publicar y desarrollar estos lineamientos a través de reglas de negocio,

procedimientos e instructivos.”, así como se contempló en el decreto 1866 de enero 31 de

2012.

Este documento contiene el Manual de Reglas de Negocio asociadas a los lineamientos del

proceso “Diseño del servicio de TI” y brinda elementos de referencia que facilitan la orientación

y actuación de todos los servidores de EPM.

OBJETIVO

Establecer las Reglas de Negocio asociadas a los lineamientos del proceso “Diseño del

servicio de TI”, con el propósito de establecer parámetros que califican y cuantifican criterios

específicos para la actuación del personal en la operación de dichos procesos.

GLOSARIO DE TÉRMINOS

A continuación, se presenta la definición de los términos de TI que facilitan la comprensión del

presente documento.

CICLO DE VIDA DE SOFTWARE: Es un período de tiempo que se inicia cuando se concibe el

producto software y finaliza cuando el producto software se retira de uso. Típicamente incluye:

fase de requisitos, fase de diseño, fase de implementación, fase de pruebas, fase de

instalación y liberación, fase de operación y mantención, y algunas veces, fase de retiro. Estas

fases se pueden superponer o se puede ejecutar iterativamente.

ARQUITECTURA DE UN SISTEMA SOFTWARE: La arquitectura de un sistema es el conjunto

de decisiones significativas sobre la organización del sistema software; la selección de

elementos estructurales y sus interfaces a través de los cuales se constituye el sistema; el

comportamiento del sistema, como se especifica en las colaboraciones de esos elementos; la

composición de esos elementos estructurales y de comportamiento en subsistemas

progresivamente más grandes; el estilo arquitectónico que guía esta organización: los

elementos estáticos y dinámicos y sus interfaces, su colaboración y su composición.



Página 5 de 51



Página 5

SISTEMA SOFTWARE: Un sistema software es una colección de subsistemas organizados

para lograr un propósito descrito por un conjunto de modelos que representan diferentes

puntos de vista del sistema. Desde un enfoque de ciclo de vida, un sistema representa el

elemento que se está desarrollando, visto desde diferentes dimensiones mediante diferentes

modelos presentados en forma de diagramas.

SUBSISTEMA: Un subsistema es un grupo de elementos, algunos de los cuales constituyen

una especificación del comportamiento ofrecido por los otros subsistemas.

MODELO: Un modelo es una abstracción semánticamente cerrada de un sistema, es decir,

representa una simplificación completa y autoconsciente de la realidad, creado para

comprender mejor el sistema, es decir, representa una simplificación completa y

autoconsciente de la realidad, creado para comprender el sistema.

VISTA: Una vista es una proyección de la organización y estructura de un modelo de un

sistema en el contexto de su arquitectura.

DIAGRAMA: Es la representación gráfica de un conjunto de elementos, el cual normalmente se

muestra como un grafo de nodos (elementos) y arcos (relaciones).

DIAGRAMAS ESTRUCTURALES DE UN SISTEMA SOFTWARE: Existen para especificar,

construir y documentar los aspectos estáticos de un sistema software. Los aspectos estáticos

de un sistema representan su esqueleto y su andamiaje, es decir, incluyen la existencia y

ubicación de clases, interfaces, colaboraciones, componentes y nodos. Los aspectos estáticos

de un sistema se representan mediante los diagramas siguientes: diagrama de clases,

diagrama de objetos, diagrama de componentes, diagramas de despliegue.

DIAGRAMA DE CLASES: Un diagrama de de clases presenta un conjunto de clases,

interfaces y colaboraciones, y las relaciones entre ellas. Se utilizan para describir la vista de

diseño estática o la vista de procesos estática de un sistema. Los diagramas de clase que

incluyen clases activas se utilizan para cubrir la vista de procesos estática de un sistema. Los

diagramas de clases son los diagramas más comunes en el modelado de sistemas orientados



Página 6 de 51



Página 6

por objetos. Por último, un sistema se puede estructurar como un conjunto de subsistemas,

donde un diagrama de subsistemas como un conjunto de clases del sistema.

DIAGRAMAS DE OBJETOS: Un diagrama de objetos representa un conjunto de objetos y sus

relaciones. Se utiliza para describir estructuras de datos, instantáneas de las instancias de los

elementos que se encuentran en los diagramas de clases. Los diagramas de objetos cubren la

vista de diseño estática o la vista de procesos estática de un sistema al igual que los diagramas

de clase, pero desde la perspectiva de casos reales o prototípicos.

DIAGRAMAS DE COMPONENTES: Un diagrama de componentes muestra un conjunto de

componentes y sus relaciones. Los diagramas de componentes se utilizan para describir la

vista de implementación estática de un sistema. Los diagramas de componentes se relacionan

con los diagramas de clases en que un componente normalmente se corresponde con una o

más clases, interfaces o colaboraciones.

DIAGRAMAS DE DESPLIEGUE: Un diagrama de despliegue muestra un conjunto de nodos y

sus relaciones. Los diagramas de despliegue se utilizan para describir la vista de despliegue

estática de una arquitectura. Los diagramas de despliegue se relacionan con los diagramas de

componentes en que un nodo normalmente incluye uno o más componentes.

DIAGRAMAS DE COMPORTAMIENTO DE UN SISTEMA SOFTWARE: Se emplean para

visualizar, especificar, construir y documentar los aspectos dinámicos de un sistema software.

Los aspectos dinámicos de un sistema software se pueden ver como aquellos que representan

sus partes mutables. Los aspectos dinámicos de un sistema software involucran cosas tales

como el flujo de mensajes entre los componentes del sistema a lo largo del tiempo y el

movimiento físico de los componentes en una red de telecomunicaciones. Los componentes

dinámicos de un sistema software se representan mediante los diagramas siguientes:

diagramas de casos de uso, diagramas de secuencia, diagramas de colaboración, diagramas

de estados, diagramas de actividades.

DIAGRAMAS DE CASOS DE USO: Un diagrama de casos de uso representa un conjunto de

casos de uso y actores (un tipo especial de clase) y sus relaciones. Los diagramas de casos

de uso se utilizan para describir la vista de casos de uso estática de un sistema. Los



Página 7 de 51



Página 7

diagramas de casos de uso son especialmente importantes para organizar y modelar los

comportamientos de un sistema.

DIAGRAMAS DE INTERACCIÓN: Es el nombre que recibe el conjunto conformado por los

diagramas de secuencia y diagramas de colaboración.

DIAGRAMAS DE SECUENCIA: Un diagrama de secuencia es un diagrama de interacción que

resalta la ordenación temporal de los mensajes. El diagrama de secuencia presenta el

conjunto de objetos y los mensajes enviados y recibidos por ellos. Los objetos suelen ser

instancias con nombre o anónimas de clases, pero también pueden representar instancias de

otros elementos, tales como colaboraciones, componentes y nodos. Los diagramas de

secuencia se utilizan para describir la vista dinámica de un sistema. Los diagramas de

secuencia y colaboración son isomorfos, es decir, se puede convertir el uno en el otro sin

pérdida de información.

DIAGRAMAS DE COLABORACIÓN: Un diagrama de colaboración es un diagrama de

interacción que resalta la organización estructural de los objetos que envían y reciben

mensajes. Un diagrama de colaboración muestra un conjunto de objetos, enlaces entre esos

objetos y mensajes enviados y recibidos por esos objetos. Los objetos normalmente son

instancias con nombre o anónimas de clase, pero también pueden representar instancias de

otros elementos, como colaboraciones, componentes y nodos. Los diagramas de colaboración

se utilizan para describir la vista dinámica de un sistema. Los diagramas de secuencia se

utilizan para describir la vista dinámica de un sistema. Los diagramas de secuencia y

colaboración son isomorfos, es decir, se puede convertir el uno en el otro sin pérdida de

información.

DIAGRAMAS DE ESTADOS: Un diagrama de estados representa una máquina de estados,

constituida por estados, transiciones, eventos, actividades. Los diagramas de estados se

utilizan para describir la vista dinámica del un sistema. Son especialmente importantes para

modelar el comportamiento de una interfaz, una clase o una colaboración. Los diagramas de

estado resaltan el comportamiento dirigido por eventos de un objeto, lo que es especialmente

útil al modelar sistemas reactivos. Los diagramas de secuencia se utilizan para describir la vista



Página 8 de 51



Página 8

dinámica de un sistema. Los diagramas de estado y actividades son isomorfos, es decir, se

puede convertir el uno en el otro sin pérdida de información.

DIAGRAMA DE ACTIVIDADES: Un diagrama de actividades muestra el flujo de actividades en

un sistema. Una actividad muestra un conjunto de actividades, el flujo secuencial o ramificado

de actividades y los objetos que actúan y sobre los que se actúa. Los diagramas de

actividades se utilizan para ilustrar la vista dinámica de un sistema. Además, estos diagramas

son especialmente importantes para modelar la función de un sistema, así como para resaltar

el flujo de control entre objetos. Los diagramas de estado y actividades son isomorfos, es decir,

se puede convertir el uno en el otro sin pérdida de información.



Página 9 de 51



Página 9

1 REGLAS DE NEGOCIO PARA EL PROCESO DISEÑO DEL SERVICIO DE TI.

1.1 Reglas relacionadas con ingeniería requisitos del servicio de TI

Alcance de del proceso de ingeniería de requisitos: El proceso de ingeniería de

requisitos se utilizará para definir el alcance de los servicios y soluciones que

tecnología de información que deben implementar o modificarse a partir de las

iniciativas, requerimientos de servicio y planes de versiones que se prioricen y

aprueben en el portafolio de servicios. Este proceso se usará igualmente para

establecer el alcance detallado de un cambio menor sobre una solución de software

existente, con el fin de atender una orden de cambio originada en una actividad de

mantenimiento correctivo o adaptativo. Estas especificaciones de alcance se

materializarán a través requisitos funcionales y no funcionales.

Requisitos funcionales y no funcionales: Los requisitos funcionales se usan para

establecer el comportamiento (flujos y transacciones) y las capacidades (funciones

de negocio o de acceso a datos) que proveerá un sistema de información o solución

de tecnología. Los requisitos no funcionales se utilizan para establecer cualidades o

criterios de operación que debe cumplir dicho sistema o solución en términos de

facilidades para su uso (usabilidad), estabilidad (confiabilidad, disponibilidad,

continuidad), habilidades de protección de la información (seguridad), facilidades de

soporte y mantenimiento (mantenibilidad), tiempos de respuesta (desempeño),

capacidades de crecer a adaptarse a nuevas versiones o plataformas (portabilidad) y

de sus características o restricciones particulares de arquitectura (ejemplo

obligatoriedad de utilizar cierta lenguaje de codificación).

Completitud de los requisitos: Los requisitos funcionales y no funcionales deben

ser completos de forma que permitan obtener de ellos la suficiente información para

plantear una solución técnica, teniendo en cuenta las necesidades de integración con

otros procesos o sistemas detectados, las restricciones de negocio y sus respectivos

criterios de aceptación (Estos criterios deberán servir para definir los casos de



Página 10 de 51



Página 10

prueba). Para las funcionalidades que tengan interacción con usuario, se recomienda

especificar requisitos en casos de uso.

Calidad de los requisitos: Los requisitos funcionales y no funcionales con los que

se especifiquen las soluciones deberán cumplir los criterios calidad definidos en las

guías de ejecución del proceso que establece que los requisitos deben ser

completos, consistentes, verificables y comprensibles. Para asegurar que se cumplan

estos criterios, cada analista de requisitos deberá ejecutar una verificación de calidad

a sus especificaciones, aplicando las listas de chequeo que mantendrán disponibles

para este fin y aleatoriamente se ejecutarán validaciones por parte de revisores par,

lo cual se reflejará en un indicador de calidad que se publicará periódicamente.

Administración de requisitos no funcionales: Teniendo en cuenta que los

requisitos no funcionales describen criterios, cualidades de operación o restricciones

tecnológicas o de operación que son aplicables a la mayoría de los servicios o

soluciones de tecnología, los arquitectos de dominio y de servicio elaborarán y

mantendrán actualizado un repositorio de requisitos no funcionales clasificado por

dominio de arquitectura acompañado de una guía de aplicación de los mismos con el

fin de acortar los tiempos de especificación. Este repositorio y su respectiva guía se

actualizará periódicamente para reflejar cambios de arquitectura y estándares.

Herramientas de apoyo: Con el fin de facilitar el proceso de especificación de

requisitos de software, propiciar la reutilización de especificaciones y mantener la

trazabilidad de componentes, se implementará una herramienta de modelamiento, la

cual será de uso obligatorio, para todos los funcionarios que actúan en el proceso de

ingeniería de requisitos.

Gestión de cambios a los requisitos: Todo requerimiento que contenga una

especificación de necesidades que haya pasado por el proceso de ingeniería de

requisitos del servicio y diseño de arquitectura del servicio de TI hasta su aprobación

por el cliente, se considera como la línea base convenida para el desarrollo y dichos

requisitos solo puede cambiarse mediante el procedimiento formal de gestión de

cambios.



Página 11 de 51



Página 11

1.2 Reglas relacionadas con el diseño de la arquitectura del servicio de TI.

Adherencia del Diseño a la arquitectura: El diseño de las aplicaciones debe

cumplir la arquitectura de la solución definida, si un Requerimiento de Cambio la

modifica deberá ser cancelado y atenderse de nuevo como una Iniciativa o

Requerimiento de servicio según sea su impacto.

Diseño Preliminar y detallado: El diseño preliminar debe realizarse completamente

para que sea insumo para la estimación definitiva del desarrollo de la solución. El

diseño detallado, solo debe iniciarse una vez se aprobó el diseño preliminar. Para

requerimientos de servicio y de cambio, la documentación de diseño ya debe existir,

y deberá ser actualizada.

Elaboración de la arquitectura: Durante las fases de análisis y diseño se deberán

completar y refinar las especificaciones de las vistas de la arquitectura del producto

software, las cuales permiten especificar el producto en función de las

responsabilidades de los subsistemas, módulos, y sus colaboraciones. Las vistas a

completar son: vista de casos de uso, vista lógica (tablas de datos, clases, interfaces,

servicios, mensajes), vista de implementación (componentes, paquetes), vista de

despliegue (nodos), vista de procesos (objetos activos, procesos, hilos, señales).

Elaboración de los modelos de análisis y diseño para los desarrollos a la

medida: Durante la fase de análisis y diseño se deben elaborar los diagramas que

soportan y desarrollan a detalle las diferentes vistas de la arquitectura del producto

software. El arquitecto de servicio o aplicación velará por el diseño y la compleción

de estos diagramas e igualmente, deberá velar porque los modelos que incluyen

estos diagramas sean verificados y aprobados por parte de los interesados antes de

proceder a la construcción de los componentes software del producto.



Página 12 de 51



Página 12

1.3 Reglas relacionadas con gestión de la disponibilidad del servicio de TI

Planeación de la disponibilidad: Se mantendrá un plan general de disponibilidad

que definirá las disponibilidades meta para cada servicio y establecerá los planes de

acción para lograr esas metas. La definición del plan de disponibilidad y de los

niveles de disponibilidad meta de cada servicio, es responsabilidad principal del

Gestor de disponibilidad de la Subdirección Tecnología de Información en estrecha

colaboración con los clientes y los Arquitectos de los servicios, para lo cual se

deberán considerar aspectos tales como necesidades de operación del negocio,

criticidad e impacto en el negocio de una interrupción del servicio, costos en los que

habría que incurrir para elevar los niveles de disponibilidad y capacidades de las

tecnologías disponibles en el mercado. El plan de disponibilidad deberá actualizarse

al menos una vez al año. Los niveles de disponibilidad establecidos para cada

servicio, se llevarán a los Acuerdos de Nivel de Sevicio (ANS).

Diseño de disponibilidad para nuevos servicios: Cada nuevo servicio que se

implemente en la organización de tecnología de información, antes de su liberación a

producción, deberá asegurar que tenga definido los niveles de disponibilidad

requeridos para éste y se incorporen en su diseño, los componentes necesarios para

la medición y monitoreo de la disponibilidad del servicio. Estos componentes

deberán verificarse durante la fase de pruebas.

Seguimiento de la disponibilidad: Se implementarán herramientas y componentes

tecnológicos que permitan hacer monitorio continuo y seguimiento del

comportamiento de la disponibilidad de los servicios de tecnología de información

activos. Esta información será consolidada y correlacionada con información de

eventos e interrupciones provenientes de los procesos de operación del servicio

(gestión de eventos y gestión de incidentes), para establecer con base en ella un

indicador de disponibilidad que se reportará mensualmente a los clientes.

Cumplimiento del nivel de disponibilidad de los servicios de TI: Los servicios de

TI deben estar disponibles y en funcionamiento correcto, cumpliendo los niveles de



Página 13 de 51



Página 13

disponibilidad y demás criterios establecidos en los acuerdos de niveles de servicios

(ANS) firmados con los clientes de TI.

Plan de mejoramiento de la disponibilidad: Como consecuencia de las actividades

de monitoreo de la disponibilidad, se deben identificar riesgos de fallas críticas en los

servicios y se deben elaborar y ejecutar planes de acción para restablecer o mejorar

los niveles de disponibilidad, con el fin de asegurar el cumplimiento de los ANS.

1.4 Reglas relacionadas con gestión de la capacidad del servicio de TI

Existencia de Línea Base: Los servicios incluidos en el Catálogo deben contar con

una línea de base de capacidad de sus componentes.

Capacidad Futura: Los procesos de GDP, PS y GCNS proveerán la información de

demanda de servicios, de planeación de versiones y de servicios y acuerdos de

servicio (nuevos o modificados), requerida para apoyar la identificación de los

requerimientos de capacidad futura.

Plan de Capacidad: Se debe crear y mantener actualizado un Plan de Capacidad

que refleje los requerimientos futuros de capacidad de los servicios. Este plan debe

tener revisiones anuales.

Escenarios de Negocio: Para crear y revisar el Plan de Capacidad, se deben

analizar los Escenarios de Negocio y la información financiera pertinentes.

Base de Datos de Capacidad: El proceso debe contar con las herramientas

necesarias para registrar y mantener actualizada la información tanto de capacidad y

desempeño de los servicios y componentes, como de los modelos y simulaciones

que permitan sustentar las decisiones y proponer mejoras a los servicios y a la

infraestructura.



Página 14 de 51



Página 14

Informe de Desempeño y Capacidad: Los Agentes de Capacidad entregarán el

resultado del análisis de los informes de desempeño en los primeros diez (10) días

del mes.

Herramientas de Monitoreo: El proceso GCP debe contar con las herramientas que

permitan monitorear el desempeño y la capacidad de los componentes de los

servicios.

Monitores y Umbrales: Todo elemento que forme parte de un servicio incluido en el

Catálogo de Servicios, debe contar con monitores de capacidad y desempeño

configurados, así como con valores umbrales para determinar alteraciones

significativas en la capacidad disponible y el desempeño esperado del componente.

Todos los componentes de servicio debe ser monitoreo del servicio.

Reportes: Los reportes de capacidad y desempeño se deben realizar a nivel de

servicios y componentes.

Protección de la Inversión: La adquisición de nueva capacidad debe ser

considerada luego que han sido evaluadas las diferentes opciones de reutilización o

redistribución de la capacidad existente y debe considerar las políticas y los planes

de reposición de equipos existentes.

Cobertura de ANS: El proceso GCP debe buscar el cumplimiento de todos los ANS

documentados en el Catálogo de Servicios.

1.5 Reglas relacionadas con gestión de la continuidad del servicio de TI.

1.5..1 Reglas Generales de la Continuidad del Servicio de TI.

Macroproceso: El Macroproceso Gestión de Tecnología de Información del Grupo Empresarial EPM es responsable de la evolución de la infraestructura de continuidad del servicio de TI en sus respectivos unidades de negocio y de la gestión de la continuidad del servicio de TI contenida en la infraestructura de TI, sin embargo es cada proceso el responsable de la continuidad del mismo,



Página 15 de 51



Página 15

implantando los controles no tecnológicos necesarios para garantizar la continuidad de su operación.

Definición y actualización: Se conformarán equipos de trabajo multidisciplinarios con conocimiento en los procesos de negocio y sus necesidades particulares, en la plataforma tecnológica, en los sistemas de información, en aspectos relacionados con el costeo de los servicios, en los procesos de gestión de Disponibilidad, Capacidad, Continuidad y Seguridad consultando la capacidad de la TI.

Continuidad de los servicios de TI: Debe considerar medidas tanto técnicas como administrativas y de vínculo con instituciones externas, probarse y revisarse periódica y continuamente.

Responsabilidad: Todas las personas que laboran para la Empresa EPM o estén conectadas a la red, son responsables por el cumplimiento de la política, lineamiento, reglas de negocio y procedimientos con respecto a la continuidad del servicio de TI.

Alineación con el Plan de Continuidad de Negocio BCP: Será responsabilidad del proceso, en él se deberá incluir las acciones para mitigar los riesgos ocasionados por la discontinuidad del servicio de TI e identificar los recursos de TI mínimos requeridos, será responsabilidad de los diferentes macroprocesos y procesos de apoyo, apoyar a los procesos en la identificación de riesgos y controles para cada proceso evaluado, acorde a los alcances del proceso de apoyo.

Alineación con el Plan Maestro de Manejo de Crisis PCM: La gestión de continuidad debe estar alineada con el Plan de Maestro de Manejo de Crisis (PMC), y por lo tanto propenderá por la mitigación de riesgos internos o externos a la Organización informática que pueden afectarle en caso de ocurrir su materialización. La mitigación de tales riesgos será responsabilidad del respectivo encargado de área.



Página 16 de 51



Página 16

Plan de Recuperación ante Desastres DRP: EPM debe poseer un Plan de Recuperación ante Desastres del servicio de TI que permita el desarrollo de las actividades de la empresa aún sin tener acceso a los sistemas de información o aplicaciones críticas por un tiempo no menor a aquel en que el sistema pueda ser atendido, restaurado o redireccionado.

1.5..2 Reglas para la Administración de la Continuidad del Servicio de TI

Alcance: Todas las Direcciones y Unidades de la Empresa requieren apoyo del Macroproceso Gestión de Tecnología de Información del Grupo Empresarial EPM para soportar eventos de emergencia o desastre implementando un Plan de Recuperación ante Desastres DRP que incluya, hardware, software, lineamiento, reglas de negocio, procedimientos e instructivos, consistentes con los estándares del Grupo Empresarial EPM.

Convenios con terceros: Ningún contrato o convenio con terceros puede vulnerar en forma alguna la política, lineamiento, reglas de negocio de continuidad del servicio de TI, ni las normas emitidas para su implantación.

Cumplimiento: Todas las dependencias que administren plataformas informáticas deben cumplir con las normas, procedimientos y estándares definidos para la continuidad del servicio de TI.

Cambios: Todo cambio realizado a los componentes de la infraestructura de TI (servidores, red, bases de datos, software base, software aplicativo, almacenamiento, respaldos, etc.) debe ser analizado a la luz de la continuidad de negocio en el comité de cambios de la organización.



Página 17 de 51



Página 17

1.5..3 Reglas para el Análisis de Impacto en los Objetivos Misionales del

Negocio.

Análisis de Impacto al Negocio (BIA1): Se deberá realizar un Análisis de Impacto al Negocio (BIA), de los aplicativos que afectan los objetivos misionales de EPM, el cual podrá indicar cuánto tiempo podría operar la entidad sin tener acceso a los sistemas de información MTO2 que fueron catalogados como muy críticos, el tiempo en que los administradores de infraestructura, analistas y líderes del servicio deberán decidir cambiar la operación a un sitio alterno y la configuración mínima que debe ser recuperada a nivel de producción en el menor tiempo posible.

Calcular variables de RTO3 y RPO4: En conjunto con el propietario de la información, los administradores de los sistemas de información deben periódicamente preparar o revisar una calificación sobre el grado de criticidad de todas las aplicaciones de producción; ésta clasificación se define mediante los RTO y RPO del BIA, teniendo en cuenta la disponibilidad de los aplicativos, servicios e información de EPM.

Criticidad: El número de categorías de criticidad podrá variar de una revisión a otra, y pueden surgir términos como “prioridad”. Generalmente, cada uno de esos términos implicará en un periodo de tiempo cuanto demorará la recuperación de una aplicación o servicio.

1 BIA: Análisis de Impacto al Negocio

2 MTO: Siglas de Maximun Tolerable Outage, refiere al Tiempo Máximo de Tolerancia a no disponibilidad de los sistemas y recursos..

3 RTO: Siglas de Recovery Time Objective, refiere el tiempo objetivo en el que el aplicativo debe recuperar su funcionalidad luego de una interrupción

para que no cause impactos graves en la entidad. 4 RPO: Siglas de Recovery Point Objective, refiere al punto objetivo en el que la información recuperada después de un evento es considerada aceptable,

en otras palabras la que no se recupere es la que se está dispuesto a perder ante la ocurrencia de una interrupción, sin causar impactos graves a la organización.



Página 18 de 51



Página 18

Clasificación del evento: Se clasifica el evento de acuerdo a los siguientes tipos:

Tipo 1 “Rutinario”: Los eventos rutinarios son aquellos que hacen parte de la

operación del día a día de la plataforma de TI. Se estima que el evento se puede

resolver con los medios (personal, inventario) existentes en la organización en un

lapso de tiempo no mayor a cuatro horas. Los factores como fallas de hardware o

software, cambios inadecuados en cualquiera de los componentes de la

plataforma de TI, son los principales eventos rutinarios.

Por lo general, los analistas de la USISS, USII y la USIN son los encargados de

resolver este tipo de eventos y deben comunicarlo al Coordinador Equipo de

Contingencias CEC.

Tipo 2 “No Rutinario”: Los eventos no rutinarios no hacen parte de la operación

normal de la plataforma de TI, pero están relacionados a tecnología. El evento no

rutinario demanda recursos adicionales a los que posee la organización en sus

instalaciones y se requiere la ayuda de los proveedores. Los eventos catalogados

como no rutinarios son: daños o pérdida parcial de componentes de la plataforma

de TI, falta de potencia eléctrica, pérdida de comunicaciones con los proveedores,

entre otros.

El Coordinador Equipo de Contingencias CEC se apersona de la situación y

mantiene informado al Comité de Administración de Contingencias CAC , quienes

toman la decisión de activar el plan de contingencias o el DRP. Este tipo de

evento se puede solucionar en un tiempo no mayor a 24 horas.

Tipo 3 “Catastrófico”: El evento catastrófico son circunstancias que no se tienen

contempladas, y/o están considerados de baja ocurrencia. Los solución de

eventos catastróficos toman más tiempo para recuperar al máximo permitido (24

horas), la plataforma de TI no se encuentra disponible y no se tienen los medios

necesarios para recuperar la operación localmente.



Página 19 de 51



Página 19

Los eventos catastróficos pueden ser: pérdida total de la plataforma de TI,

siniestros (incendios, terremotos), asonadas terroristas, huelgas prolongadas que

impiden el acceso a las instalaciones, entre otras. Los eventos rutinarios o no

rutinarios pueden convertirse en un factor de activación del DRP, cuando estos no

pueden ser resueltos dentro de las 24 horas siguientes a la ocurrencia del evento.

El Comité de Administración de Contingencias CAC se apersona de la situación,

evalúa y planea la activación del DRP. El Comandante Operativo CO es quien

debe dar la orden de activar el DRP.

1.5..4 Reglas para la Documentación e Implementación de Continuidad del

Servicio de TI.

Identificación de los sistemas críticos: Debido a la centralización de la gestión de las tecnologías de información, la administración de la operación tecnológica debe establecer y usar un marco lógico para clasificar todos los recursos de información para dar prioridades de recuperación que puedan permitir decidir qué recursos de información deberán recuperarse primero y en qué nivel.

Desarrollo del plan: Los administradores de los sistemas de información deben preparar, periódicamente actualizar y regularmente probar los planes de continuidad del servicio de TI de EPM, estos deben especificar qué facilidades deben ser entregadas a los funcionarios para continuar las operaciones de EPM.

Desarrollo de los procedimientos: Toda solución o servicio de TI deberá ser evaluado en el Plan de Recuperación ante Desastres con miras a asegurar la continuidad del servicio de TI dentro del Plan de Continuidad del proceso de negocio el cual es responsabilidad del dueño del proceso de negocio. Se debe diligenciar plantillas con información requerida para el funcionamiento del Procedimiento. (Notificación, Evaluación, Activación, Recuperación, Contingencia, Restauración) y actualizar el BCP/DRP.



Página 20 de 51



Página 20

Cumplimiento: Los nuevos desarrollos o adquisiciones de software deben considerar los aspectos de continuidad del servicio de TI dentro de las especificaciones técnicas mínimas exigidas a los proveedores, tales como:

Poseer puntos de recuperación, en caso de que se presente una falla en el software.

Tener la capacidad para re-direccionar la aplicación a un centro alterno de procesamiento de datos.

Capacidad para reportar eventos ocasionados al interior de la aplicación y que puedan afectar su desempeño o disponibilidad.

Capacidad para trabajar con disponibilidad continúa (en cluster o espejo).

Facilidad y compatibilidad con herramientas de gestión de la infraestructura informática.

Plan de recuperación definido por la clasificación de criticidad del modelo de datos, y/o sub-módulos del software

Facilidad para integrarse a la solución corporativa de recuperación adoptada porRla STI.

Esquema de actuación: Cualquier declaración de desastre o interrupción prolongada debe contar con los recursos mínimos especificados en el respectivo Plan de Recuperación ante Desastres DRP del servicio de TI.

Respaldo: Se debe considerar el almacenamiento fuera de las instalaciones de los medios de respaldo de aquellos sistemas de información sensibles o críticos de EPM.

Protección de la información: Se deben almacenar fuera de las instalaciones toda la documentación y otros recursos críticos necesarios para la ejecución de los planeas de continuidad del negocio.



Página 21 de 51



Página 21

1.5..5 Reglas para el Mantenimiento y Reevaluación del Plan de Recuperación

ante Desastres DRP.

Manejo de pares: Los funcionarios encargados de los procesos de continuidad y contingencia deben tener un elemento de respaldo y a través de este esquema garantizar la posibilidad de que una de estas personas esté en capacidad total de recuperar el sistema según la política y planes de continuidad de EPM. Estas personas en lo posible no deben estar en las mismas instalaciones y en forma individual deberán realizar las pruebas sobre el sistema de continuidad y contingencia.

Mejoramiento continuo: Las pruebas deben identificar las áreas de problemas y cualquier recomendación para la mejora del plan y al proceso de continuidad.

Revisión y actualización: Al menos cada año, se deben convenir y documentar los niveles de ayuda que serán proporcionados por los procesos de apoyo en el acontecimiento de un desastre o de una emergencia. Todo funcionario que participe de dicho proceso podrá ser contactado por más de un medio y en forma semestral deberá actualizarse dicha información.

Roles y Responsabilidades: Cada uno de los participantes en dicho proceso deberá tener su Rol definido durante las labores de recuperación del sistema así como las tareas y personas a cargo para el desarrollo de sus actividades.

1.5..6 Reglas para la Operación Activa (Revisión – Invocación) y Pruebas

Prueba del plan: Se debe probar el plan de continuidad del servicio de TI del

proceso de negocio de forma regular para asegurar la continuidad de los procesos de las empresas y la aplicabilidad del plan.



Página 22 de 51



Página 22

Escenario de prueba: La planeación de pruebas debe incluir el alcance, los objetivos, criterios de medición, personal involucrado, tareas y tiempos, para validar la efectividad del plan. Para cada prueba se deben definir indicadores y medirlos.

Documentación de las pruebas: Se debe mantener los registros de los resultados de las pruebas en el plan para los propósitos de planeación de pruebas futuras.

Ejecutar Prueba: Ejecutar Plan de Recuperación ante Desastres DRP a cargo del Comandante Operativo (CO), con el objetivo de validar los procedimientos diseñados, como son: Notificación, Evaluación, Activación, Recuperación, Contingencia, Restauración.

Notificación: El proceso de notificación constituye la fase inicial dentro de la activación del DRP, este procedimiento inicia con la comunicación de un evento que puede interrumpir las operaciones de tecnología. Éste puede ser informado inicialmente a la mesa de ayuda por los usuarios o puede ser descubierto por cualquier administrador o analista de tecnología.

Evaluación: El proceso de evaluación constituye la valoración preliminar de una interrupción o evento que afecta a uno o varios usuarios, en forma considerable. La evaluación se hace en sitio, teniendo en cuenta los perfiles y competencias necesarios para determinar: causa de la interrupción, población de usuarios afectada, apreciación de la magnitud, valoración del daño, escenario de soluciones, recursos involucrados y tiempo estimado de la solución.

Activación: En esta fase se describen las actividades requeridas para declarar y comunicar el desastre de forma tal que se active la contingencia y/o recuperación del servicio, y se comunique la interrupción a los equipos responsables de recuperar el servicio.

Recuperación: El proceso de recuperación aporta la guía procedimental para recuperar el servicio utilizando recursos del Centro Alterno de Procesamiento



Página 23 de 51



Página 23

contratado. Su ejecución depende del tiempo estimado de la solución a la falla o contingencia que activó el plan.

Contingencia: El proceso de contingencia aporta la guía procedimental para recuperar la funcionalidad de un componente en sitio y lograr mantener la prestación del servicio de tecnología de información a los usuarios desde el Centro de Datos Principal.

Restauración: El proceso de restauración consiste en definir la forma y/o procedimientos a utilizar para volver a la normalidad, una vez superada la contingencia y recuperada la tecnología necesaria para mantener la normalidad de las operaciones de TI en el Centro de Datos Principal.

Dentro de esta fase están definidos dos Procesos como actividades macro del

Retorno a la normalidad.

Recuperación del CPP.

Planeación y Ejecución del Retorno.

1.6 Reglas relacionadas con gestión de la seguridad del servicio de TI.

Propiedad de la información: Los activos de información son propiedad de EPM

y son entregados para su uso, operación o custodia a los funcionarios, contratistas

o terceros, de acuerdo a la función específica y necesidades del trabajo a realizar,

aunque dentro de las funciones específicas se nombre dentro del ciclo de vida del

activo de información u operación un propietario de cada activo. Este

nombramiento como propietario, se hará únicamente, con el fin de asignar las

responsabilidades operativas y de custodia sobre los diferentes activos.

Protección de la información: Los activos de información serán protegidos con

el nivel necesario, en proporción a su valor y al riesgo de pérdida en EPM. La

protección debe propender por la confidencialidad, integridad y disponibilidad del

activo de información.



Página 24 de 51



Página 24

Protección de los recursos tecnológicos: Los recursos tecnológicos en EPM

serán protegidos con el nivel necesario en proporción a su valor y a los riesgos a

los que puedan estar expuestos. Dichos recursos deben ser utilizados

exclusivamente para desarrollar actividades laborales y así mismo su utilización

se hará en forma adecuada, con el máximo de eficiencia y con ejemplar

racionalidad.

Autorización de usuarios: Todos los usuarios deben ser identificados

independientemente, con permisos de accesos específicos e individuales. Los

métodos de acceso de usuarios deben exigir un proceso robusto de autenticación,

autorización específica de acuerdo a las funciones de los usuarios y auditoria

confiable.

Responsabilidad: Los usuarios y custodios de los activos de información en EPM

son responsables por el uso apropiado, protección y privacidad de estos activos.

Los sistemas en EPM generarán y mantendrán unas apropiadas pistas de

auditoría para identificar usuarios, y documentar los eventos relacionados con la

seguridad.

Integridad: Los activos de información deben estar adecuadamente protegidos

para asegurar su integridad y precisión. Las medidas de validación definidas

permitirán detectar la modificación inapropiada, eliminación o adulteración de los

activos de información.

Confianza: Los socios y proveedores de productos y/o servicios de TI deben

demostrar capacidad para reunir o exceder los requerimientos de seguridad de TI,

y justificar la confianza en sus capacidades para asegurar los activos de

información en EPM. La confianza empieza a ser incrementalmente importante

cuando activos de información sensibles son compartidos con otras entidades,

asociaciones y proveedores de servicios.

Revisiones de seguridad en sistemas de Información: Se deberán tener

habilitados diferentes criterios para verificar el cumplimiento de los estándares de



Página 25 de 51



Página 25

configuración de seguridad de TI en las diferentes plataformas técnicas e

instalaciones de tecnología de información.

1.6..1 Reglas relacionadas con la Organización para la seguridad de TI

Responsabilidad con la seguridad de TI. Las responsabilidades para la gestión

de la seguridad de los activos de información deben estar claramente asignadas

en todos los niveles organizacionales. El cumplimiento de todos los requisitos de

ley y de los organismos de control deben ser presentadas y aprobadas por el

Grupo Primario de la STI con el fin de proveer un ambiente seguro y estable de

recursos de información que sea consistente con las metas y objetivos en EPM.

Todos los funcionarios, contratistas y personas externas con acceso a los activos

de información en EPM se hacen responsables de cumplir con el lineamiento de

Seguridad de TI.

1.6..2 Reglas relacionadas con la clasificación y control de activos de información

Identificación, Clasificación e inventario de activos de información: La

información de EPM, así como los activos donde ésta se almacena y se procesa

deben ser inventariados, asignados a un responsable y clasificados de acuerdo

con los requerimientos y los criterios que se definan para tal fin. Se debe

establecer un procedimiento de clasificación e inventario de activos de información

que permita claramente identificar el nivel de seguridad requerido por cada activo

de información, de acuerdo a las necesidades del negocio.

De acuerdo con la clasificación definida, se deben establecer los niveles de

protección orientados a determinar a quién se le permite el manejo de la

información, el nivel de acceso a la misma y los procedimientos para su

manipulación.

El nivel de clasificación de la información debe revisarse cada vez que se realice

un ciclo de gestión y cuando se presenten cambios en la información o en la

estructura que puedan afectarla.



Página 26 de 51



Página 26

Se debe llevar permanentemente para cada activo, información detallada sobre su

valoración en confidencialidad, integridad, disponibilidad y auditabilidad, así como

los procesos de tratamiento, marcación e información relevante para su gestión

Cada una de las dependencias que administran o utilizan la infraestructura

Informática de EPM gestionará que todos los activos de información estén

claramente identificados y deberá mantener y elaborar un inventario actualizado.

Proteger los activos de información de los riesgos que atenten contra su

confidencialidad, integridad y disponibilidad: La información que se genera en

los procesos de negocio de EPM y que resida en los diferentes medios de TI es

de propiedad de EPM y se constituye en un activo empresarial que se debe

proteger de los riesgos que atenten contra su confidencialidad, integridad y

disponibilidad.

1.6..3 Reglas relacionadas con la Propiedad y Clasificación de Información en EPM

Investigación de la información que reside en los diferentes medios

tecnológicos que posee EPM: La información que reside en los diferentes

medios tecnológicos podrá ser investigada por mandato de la Dirección Control

Interno y, Unidad Control Disciplinario mediante solicitud escrita y bajo la premisa

de cumplimiento de la ley.

Respaldo de la información: Toda información de EPM que el usuario almacene

en su equipo de trabajo asignado por las EPM, debe ser respaldada por el usuario

en las carpetas o sitios destinados para esto en los servidores de EPM siguiendo

el procedimiento establecido de respaldo de información para los usuarios.

Clasificación de la información: Toda información de EPM mientras no haya

sido clasificada, debe ser tratada con el nivel más alto de clasificación. Es

potestad y obligación de quien genera información clasificarla de acuerdo a los

criterios que se establezcan y esta clasificación mantenerla actualizada.



Página 27 de 51



Página 27

Propiedad de la información: EPM es propietaria de toda la información que

generan, procesan e intercambian y constituye parte de su activo.

1.6..4 Reglas relacionadas con Seguridad con el personal

Seguridad con el personal de EPM y terceros: Los términos y condiciones de

trabajo establecidos en los contratos en EPM deben establecer la responsabilidad

del funcionario por la seguridad de los activos de información y aclarar que va

más allá de la finalización de la relación laboral. Esto se hace extensivo a aquellos

contratistas y terceros que tengan acceso a la información en EPM por medio de

los contratos respectivos.

Los funcionarios de EPM deben cooperar en los esfuerzos por proteger la

información y son responsables de actualizarse en la materia, así como consultar

con el proceso de Gestión de Seguridad de TI en EPM en caso de duda o

desconocimiento de un procedimiento formal, ya que esto no lo exonerará del

proceso disciplinario correspondiente a violaciones de las directrices o normas de

seguridad.

1.6..5 Reglas relacionadas con Seguridad física

Seguridad física para los activos de información: EPM debe contar con

protecciones físicas y ambientales acordes con la clasificación de los activos que

protegen, incluyendo áreas seguras para la gestión, almacenamiento y

procesamiento de información en EPM.

Obligatoriedad de cumplir con seguridad física y lógica: Todo medio de

almacenamiento o centro de procesamiento de datos, que procese o almacene

datos o información de EPM, debe cumplir con la seguridad física y lógica

requerida, con el propósito de mantener la disponibilidad y confidencialidad de los

datos o información.



Página 28 de 51



Página 28

Perímetros de seguridad: Las instalaciones de procesamiento de datos que

procesen información crítica o sensible de EPM deben estar ubicadas en áreas

protegidas y resguardadas por un perímetro de seguridad definido.

Distribución de información física: La información crítica o sensible para EPM

debe permanecer distribuida en áreas seguras y protegidas físicamente contra

acceso no autorizado, daño o indisponibilidad.

Accesos físicos y lógicos a información crítica e instalaciones donde reside:

El acceso físico y lógico a la información crítica o sensible y a las instalaciones de

procesamiento de datos que procesen este tipo de información crítica o sensible

en EPM, debe ser controlado y limitado exclusivamente a las personas

autorizadas.

Los derechos de acceso a las instalaciones de procesamiento de datos que

procesen información crítica o sensible en EPM deben actualizarse cada vez que

ocurra una novedad del personal que tiene derecho de acceso a estas

instalaciones, de manera que se evite el acceso de personal no autorizado.

Debe mantenerse un registro protegido que permita auditar todos los accesos a

las instalaciones de procesamiento de datos críticos o sensibles en EPM.

Toda persona que ingrese a las instalaciones de procesamiento de datos que

procese información crítica o sensible debe portar el carné o tarjeta que lo

identifique, para efecto del respectivo control.

Ubicación de las instalaciones de procesamiento de datos que procesen

información crítica o sensible de EPM: Estas deben ubicarse en lugares a los

cuales no pueda acceder el público y no deben tener ningún tipo de señalamiento.

Materiales peligrosos o combustibles: Los materiales peligrosos o

combustibles deben ser almacenados en lugares seguros a una distancia que no

represente riesgo para las instalaciones de procesamiento de datos que procesen

información crítica o sensible de EPM.



Página 29 de 51



Página 29

Áreas desocupadas aledañas a las instalaciones de procesamiento de datos:

Aquellas áreas desocupadas aledañas a las instalaciones de las instalaciones de

procesamiento de datos que procesen información crítica o sensible en EPM

deben ser físicamente bloqueadas y periódicamente inspeccionadas.

Alimentos y bebidas: No se deben ingerir alimentos, ni beber, ni fumar en las

instalaciones de procesamiento de datos en EPM.

Condiciones ambientales: Las condiciones ambientales deben ser monitoreadas

para verificar desviaciones que afecten de manera adversa el funcionamiento de

los equipos de procesamiento en EPM.

Suministro de energía: Se debe contar con un adecuado suministro de energía

que sea acorde con las especificaciones del fabricante o proveedor de los equipos

de procesamiento de datos y asegurar su continuidad mediante un sistema de

energía no interrumpida (UPS).

Sistemas de cableado de energía y de comunicaciones: Los sistemas de

cableado de energía y de comunicaciones que se utilizan en los servicios de

información deben ser protegidos para evitar su intercepción o daño.

Medios de almacenamiento que contienen información sensible: Los medios

de almacenamiento que contienen información sensible (discos compactos, discos

duros, tarjetas de memoria portátiles, documentos, etc.) deben ser físicamente

destruidos o reescritos en forma segura, cuando dicho medio no esté bajo el

control en EPM.

Equipos que están por fuera de instalaciones de EPM: Los equipos de

procesamiento de datos en EPM (estaciones de trabajo, portátiles, etc.) utilizados

para realizar trabajos fuera de las sedes de las empresas, deben cumplir con las

directrices establecidas. La Seguridad de TI debe conservarse en los momentos

de mantenimiento, cuando los equipos informáticos que salen de la empresa, se

eliminan o dan de baja.



Página 30 de 51



Página 30

1.6..6 Reglas relacionadas con Gestión de Comunicaciones y Operación

Transmisión de información crítica o sensible: La información que sea

considerada crítica o sensible deberá ser transmitida y operada de manera segura

a través de una ruta o medio confiable con controles para brindar autenticidad de

contenido, prueba de envío, prueba de recepción y no rechazo de origen.

Uso de los servicios y productos de TI: Los servicios y productos de TI son

exclusivamente para actividades en EPM y la información intercambiada por

medios electrónicos tiene carácter de oficial5.

Provisión de infraestructura para investigaciones a equipos informáticos: Se

debe provisionar de infraestructura adecuada para la realización de

investigaciones a equipos informáticos en EPM.

1.6..7 Reglas relacionadas con los Procedimientos y Responsabilidades

Operacionales en EPM

Líneas bases de seguridad en sistemas operativos: Antes que cualquier

sistema operativo sea puesto en operación en EPM, el personal técnico debe

aplicar las líneas base de seguridad establecida en el proceso de Seguridad de TI.

Desinstalación y deshabilitación de módulos o software utilitario de los

sistemas operativos: Cada módulo del sistema operativo o software utilitario que

no sea utilizado, y que no sea necesario para la operación de otros programas,

debe ser desinstalado o deshabilitado.

5 El uso de los recursos tecnológicos y servicios de EPM hace que sea institucional y debe usarse como tal. La

información intercambiada a través de estos medios será definida como oficial.



Página 31 de 51



Página 31

Cambios en los sistemas operativos: Las modificaciones, aumento de

funcionalidad o reemplazos a los sistemas operativos de producción deben

ejecutarse solamente si ha pasado por el comité de cambios en el cual debe

participar el oficial de Seguridad de TI.

Revisiones de seguridad de los sistemas operativos: Se deben realizar

revisiones cada vez que se complete un ciclo de gestión de seguridad de la

información o realizar evaluaciones de vulnerabilidades sobre los sistemas

operativos de producción, para proteger la información asociada con la

interconexión de los sistemas de información en EPM.

Cambios en los sistemas de producción: Para todos los cambios en los

sistemas de producción se deben desarrollar procedimientos adecuados de Back-

Off, los cuales permitan devolverlos rápida y oportunamente a las condiciones

previas al cambio más reciente en el software.

Actualización de los sistemas operativos: Se debe procurar utilizar las

versiones más recientes de los sistemas operativos multiusuario, una vez que se

haya probado la estabilidad del software y los aplicativos hayan sido debidamente

probados en la nueva versión. Las actualizaciones deben llevarse al comité de

cambios.

1.6..8 Reglas acerca de la Protección Contra Software Malicioso en EPM

Protección Contra Software Malicioso en EPM: Debe instalarse software de

detección, eliminación y reparación de código malicioso a nivel de los Firewalls,

servidores FTP, servidores SMTP, servidores de la Intranet y en las estaciones de

trabajo de los usuarios y debe certificarse que todo el software, archivos o

ejecutables, se encuentran libres de virus antes de ser instalado en la

infraestructura de EPM o enviados a una entidad externa.



Página 32 de 51



Página 32

Todos los sistemas sin las actualizaciones de seguridad requeridas o los sistemas

infectados con cualquier tipo de malware6 deben ser desconectados de las redes

en EPM.

Se debe mantener activo continuamente un sistema de protección antimalware7,

en todos los servidores de la red y en todas las estaciones de trabajo en EPM.

Responsabilidades de los funcionarios de EPM en la detección de código

malicioso: Cualquier usuario quien sospeche de una infección por código

malicioso debe apagar inmediatamente el computador involucrado, desconectarlo

de cualquier red, llamar al soporte de Mesa de Ayuda y evitar hacer intentos de

eliminarlo. Una infección por código malicioso de computador solo debe ser

tratada por el responsable asignado en la STI.

Además:

Los usuarios seguirán las recomendaciones sobre la prevención y manejo de

virus u otras amenazas a los recursos informáticos.

No deben transferir (subir y bajar) software desde y hacia sistemas que se

encuentran por fuera o en EPM.

No deben utilizar software obtenido externamente desde Internet o de una

persona u organización diferente a los distribuidores confiables o conocidos a

menos que el software haya sido examinado en busca de código malicioso y

que haya sido aprobado por la STI-EPM.

Es responsabilidad del usuario que utilice medios de almacenamiento como

disquetes, CD-ROMs, cartuchos ópticos, cintas DAT, etc., provistos por

6 También llamado badware, software malicioso o software malintencionado.

7 Software diseñado para combatir o eliminar software malicioso en un sistema informático.



Página 33 de 51



Página 33

entidades externas analizar con sistemas antivirus antes de ser utilizados en

los sistemas de EPM.

Los usuarios no deben escribir, generar, compilar, copiar, almacenar,

propagar, ejecutar o intentar introducir cualquier código de computador

diseñado para auto replicar, deteriorar u obstaculizar el desempeño de

cualquier sistema en EPM o de cualquier entidad externa a ella.

Los usuarios no deben instalar software en sus estaciones de trabajo, en los

servidores de la red, o en otras máquinas, sin la previa autorización.

Análisis de integridad: Todos los servidores y computadores personales en

EPM, deben ejecutar continuamente el software de análisis de integridad que

detecte cambios en los archivos de configuración, archivos del sistema, archivos

de aplicaciones y de los recursos críticos.

Actualizaciones automáticas de software: No debe ejecutarse actualizaciones

automáticas de software en los sistemas en EPM, a través de tecnologías “push”,

a menos que el software haya sido probado y aprobado.

Confiabilidad de las fuentes desde donde se descarga software: El software

residente en sitios públicos de Internet o recibidos de entidades externas o

cualquier persona, no debe ser descargado a ningún sistema en EPM a menos

que sea recibido directamente de una fuente confiable, conocida y se hayan

empleado herramientas de verificación.

Antes que cualquier archivo sea restaurado en un sistema, desde un medio de

almacenamiento de respaldo, éste debe ser analizado con un sistema de

detección, eliminación y reparación de código malicioso actualizado.

Uso de programas o software autorizados: A las estaciones de trabajo de los

usuarios se le debe hacer una configuración donde se habiliten sólo los

programas ejecutables autorizados en EPM.



Página 34 de 51



Página 34

Legalidad del software: Se debe garantizar que todas las licencias de software

base y software de aplicación cumplen con las arquitecturas tecnológicas y de

aplicaciones de EPM, y que están legalizadas mediante una adquisición, antes de

proceder a su instalación y despliegue en la infraestructura de TI de EPM.

Software libre: Solo se autoriza la utilización de software libre cuando éste sea

parte de un servicio de TI en el catálogo de servicios de TI de EPM. En el caso de

no ser parte de un servicio de TI, su uso debe apoyarse en un estudio de

factibilidad técnica, y en cualquier caso, la instalación y despliegue en la

infraestructura de TI de EPM debe contar con el aval de de la Organización

Informática de EPM.

1.6..9 Reglas acerca de la Administración de Redes en EPM

Recolección de Información privada de los usuarios: La necesidad particular

de recolectar algún tipo de información privada de los usuarios debe ser

analizada, aprobada y autorizada por la competencia respectiva con la asesoría

del área Jurídica y Control Interno de la organización.

Configuración de seguridad: Todas las máquinas conectadas a la red en EPM

deben cumplir con Las configuraciones definidas.

Monitoreo de seguridad en la infraestructura de red: Se deben monitorear

continuamente las conexiones remotas de los computadores conectados a las

redes en busca de tráfico malicioso para asegurar el uso de software aprobado,

prevenir la detección e instrucción no deseadas y no aprobadas y para monitorear

la actividad generada por estos sistemas.

Diseño de la red libre de puntos de falla: El diseño de redes se deben hacer

teniendo en cuenta que no existan puntos únicos de falla en general y en

particular en seguridad; que puedan comprometer la disponibilidad de los servicios

de la red, que las comunicaciones críticas puedan ser enviadas a través de

transportadores (carriers) múltiples sobre diferentes rutas físicas.



Página 35 de 51



Página 35

Restricciones a usuarios y sistemas para acceso a la red de EPM: Las

direcciones de sistemas internos, las configuraciones y la información de diseño

de sistemas relacionada con la red en EPM, debe ser restringida para que los

usuarios y sistemas por fuera de la red interna no puedan acceder a esta

información.

Además, la información relacionada con el acceso a los computadores, sistemas

de comunicación y las conexiones remotas externas, es considerada confidencial

y no debe ser publicada en Internet, listada en directorios telefónicos, puesta en

tarjetas de presentación o puesta a disposición de terceras partes.

La información de los procesos de la empresa deberá ser almacenada por los

usuarios en los servidores centrales. La Organización Informática de EPM es

responsable de respaldar dicha información, y los usuarios son responsables de

proteger dichos activos y alertar a la STI-EPM cuando un activo digital de

información requiera medidas especiales de protección.

Los usuarios respaldarán y protegerán, con medidas que eviten accesos de

personas no autorizadas, aquellos activos digitales de información que estén

almacenados en elementos de TI de uso personal, que les hayan sido asignados.

Los usuarios no instalarán, desinstalarán o cambiarán la configuración de sus

componentes de hardware o software, accesorios internos o externos, en los

elementos de TI asignados, sin la autorización previa del área de TI.

Prevención y detección de intrusiones no autorizadas: Todos los

computadores multiusuario conectados a Internet deben ser monitoreados con un

sistema de detección y prevención de intrusiones.

Un sistema de detección y prevención de intrusiones debe ejecutarse

continuamente en todos los servidores de Internet, servidores de bases de datos,

servidores de aplicaciones, dispositivos de red y Firewalls que estén conectados a

redes externas a la red de EPM.



Página 36 de 51



Página 36

Protección con Firewall: Todas las estaciones de trabajo conectadas a Internet a

través de línea telefónica, DSL, ISDN, cable módem o cualquier sistema similar,

deben tener su propio firewall personal activo y activado permanentemente.

Todos los Firewalls de Internet, deben tener un canal de respaldo que permita a

un administrador autorizado establecer una conexión, en el eventual caso de un

ataque de denegación de servicio distribuida.

Todos los servidores publicados en Internet deben ser ubicados en una zona

desmilitarizada, protegida por un firewall.

La aprobación escrita es requerida para habilitar un servicio en todos los Firewalls

conectados a Internet, dado que por defecto todos los servicios son deshabilitados

Todos los Firewalls y sus estaciones de administración en EPM, deben ejecutar

en computadores dedicados sin otras funciones adicionales.

La configuración de las reglas de los Firewalls y los servicios permitidos serán

cambiados mediante el procedimiento de control de cambios definido para EPM.

Todas las conexiones entre los computadores de las redes de datos en EPM e

Internet o cualquier red pública, deben incluir un firewall aprobado y los controles

de acceso relacionados.

Sistemas y las redes: Solo se permitirá el uso de interfaces de red externas y de

protocolos que hayan sido aprobados para el uso de los diseñadores de sistemas

y los desarrolladores.

El establecimiento de una conexión directa entre los sistemas en EPM y

computadores de organizaciones externas, debe seguir los procedimientos

definidos en el proceso.

Todos los sistemas de computación y los segmentos de red deben cumplir con los

criterios de seguridad establecidos en el proceso de Seguridad TI, pero no



Página 37 de 51



Página 37

limitado a, cumplimiento regulatorio, la justificación de la existencia del mismo, el

manejo de un firewall aceptable, un sistema aceptable de autenticación de

usuarios, un sistema aceptable de control de privilegios de usuarios, un proceso

establecido de control de cambios, una definición escrita de las responsabilidades

de administración del sistema y una documentación operacional adecuada.

Después de esto, el sistema puede ser conectado a la Intranet en EPM.

Inventario de conexiones de red: Se debe mantener un inventario actualizado

de las todas las conexiones en EPM con redes externas.

Manejo de redes inalámbricas: Las redes inalámbricas que llegara a utilizar

EPM deben estar configuradas para utilizar cifrado y autenticación fuerte en sus

comunicaciones.

Todas las comunicaciones provenientes de los dispositivos de acceso inalámbrico

que brinden acceso a la red LAN en EPM, deberán estar controladas a través de

un dispositivo de control de acceso (Firewall, ACL, otros) donde se establezca la

forma de acceso a la red LAN. Los cables módems y módems 3G no deben ser

utilizados para comunicaciones misionales en EPM, a menos que se utilice un

firewall y una red privada virtual con cifrado en los computadores involucrados.

1.6..10 Reglas relacionadas con el Manejo y Seguridad en los Medios en EPM

Toda la documentación relacionada con los sistemas en EPM, es considerada

confidencial, debe estar protegida contra el acceso no autorizado y no debe ser

conservada por los funcionarios que dejen de laborar en EPM.

1.6..11 Reglas para el Intercambio de Información y Comercio Electrónico (CE) en EPM

Adopción de estándares generalmente aceptados para la calificación del

contenido: EPM debe adoptar y soportar los estándares generalmente aceptados

para la calificación del contenido, para la protección de la privacidad en el sitio

web y para la seguridad del comercio electrónico en Internet.



Página 38 de 51



Página 38

Intercambio de información entre aplicaciones de EPM y otras empresas: Se

deben implementar mecanismos de intercambio de información seguros entre

aplicaciones de EPM y otras empresas.

Servidores WEB que participan en intercambio de información y CE en EPM:

Los servidores web en EPM no deben interrogar las cookies ubicadas en los

sistemas de otras organizaciones. Además Los servidores de Internet ubicados en

la zona desmilitarizada (DMZ) no deben ser utilizados para almacenar información

crítica o sensible de las actividades en EPM.

Todos los servidores de comercio de Internet en EPM que soportan

comunicaciones sensibles con organizaciones externas, deben emplear

certificados digitales emitidos por autoridades certificadoras (CA) reconocidas en

Internet y deben utilizar cifrado para transferir información entre los sistemas

involucrados.

Información que se intercambia por medios electrónicos en actividades de

CE: Toda información calificada como secreta o reservada por ley8, debe ser

cifrada mientras esté almacenada en computadores accesibles desde Internet o

desde redes externas.

Toda información privada, confidencial y de reserva bancaria, debe permanecer

cifrada cuando sea transmitida o almacenada en medios de respaldo y

transportada.

8 Ley 142 de 1994 aplicable a los servicios públicos domiciliarios; de los derechos de los usuarios para solicitar y

obtener información; y la ley 1266 de 2008 que regula el manejo de la información contenida en la base de datos personales, financieras, crediticias, comerciales, de servicios y proveniente de terceros países.



Página 39 de 51



Página 39

1.6..12 Reglas de negocio para el uso del Correo Electrónico en EPM

Confidencialidad del contenido del correo electrónico: El contenido de los

mensajes de correo se considera confidencial y sólo perderá este carácter en

casos de investigaciones administrativas, judiciales o incidentes relacionados con

seguridad informática. (Con el debido tratamiento y cumplimiento en el marco de

las leyes Colombianas). Por lo tanto, no se puede monitorear los sistemas de

correo electrónico para asegurar el cumplimiento de la normatividad, por sospecha

de actividades criminales o por cualquier otra labor administrativa, a menos que la

Dirección Control Interno o la Unidad Control Disciplinario hayan aprobado y

asignado esta tarea.

Transmisión de información crítica por correo electrónico: La información

crítica o sensible, privada debe permanecer cifrada y no debe ser trasmitida por

correo electrónico, a menos que el propietario de la información o un funcionario

de primer nivel autorice específicamente.

Todos los mensajes de correo electrónico que contengan información

concerniente, pero no limitada a, reserva bancaria, números de tarjetas de crédito,

claves de acceso, información de investigación y desarrollo e información sensible

de entidades externas, debe ser cifrado antes de ser transmitidos.

Uso de direcciones de correo electrónico oficiales: No se pueden emplear

direcciones de correo electrónico diferentes a las cuentas oficiales para atender

asuntos de la entidad.

Correos electrónicos dirigidos a los clientes con contenido de Mercadeo:

Todas las comunicaciones de mercadeo realizadas por correo electrónico,

dirigidas a clientes o usuarios encontrados en la base de datos de contactos en

EPM, deben incluir instrucciones de cómo los destinatarios pueden solicitar ser

removidos rápidamente de la base de datos de contactos y detener

comunicaciones, correos o mensajes posteriores.



Página 40 de 51



Página 40

Reenvió de correos electrónicos a direcciones externas: Los usuarios no

deben reenviar correo electrónico a direcciones externas a EPM, a menos que

exista autorización previa del propietario de la información o que la información

sea pública por naturaleza.

Contenido de los correos electrónicos: Todos los mensajes de correo

electrónico deben contener el nombre y apellidos del remitente, su cargo, unidad

organizacional y número telefónico.

En todos los mensajes de correo electrónico salientes, debe agregarse un pie de

página avalado por la Secretaria General que indique que el mensaje puede

contener información confidencial, que es para el uso de los destinatarios

nombrados, que ha sido registrado para propósitos de archivo, que puede ser

analizado por otras áreas en EPM, no constituye necesariamente una oficial

representación, no vincula a EPM a ningún contrato, posición o curso de acción, a

menos que el funcionario sea específicamente autorizado legalmente para

suscribir contratos en nombre de EPM.

Además los usuarios no pueden crear, enviar o retransmitir mensajes de correo

electrónico que puedan constituir acoso o que puedan contribuir a un ambiente de

trabajo hostil.

Registro, retención y destrucción de mensajes de correo: Se debe establecer

y mantener esquemas para el registro, retención y destrucción de mensajes de

correo electrónico y sus archivos de logs.

Un mensaje de correo electrónico debe retener y conservar para futuras

referencias solamente si contiene información relevante para la finalización de una

transacción, información de referencia potencialmente importante o valor como

evidencia de una decisión administrativa en EPM.

Responsabilidades de los funcionarios de EPM en el uso del correo

electrónico: Los usuarios del servicio del correo electrónico no pueden modificar,



Página 41 de 51



Página 41

falsificar o eliminar cualquier información contenida en los mensajes, incluyendo el

cuerpo y los encabezados.

Además, no pueden utilizar comentarios obscenos, despectivos u ofensivos en

contra de cualquier persona o entidad en mensajes de correo electrónico.

Tampoco puede reenviar correos recibidos con contenidos como los mencionados

que hayan recibido, los mismos deben ser borrados o entregados a la Dirección

de Control Interno para que esa dependencia determine las acciones que

considere necesario realizar. Así mismo deben desistir de enviar correo

electrónico personal no solicitado, si el destinatario ha requerido que así se haga

Tampoco deben transmitir correos masivos no aprobados, no deben utilizar las

cuentas de correo oficiales para participar en grupos de discusión en Internet,

listas de correo o cualquier otro foro público, a menos que su participación haya

sido expresamente autorizada por la organización y no deben emplear versiones

digitalizadas de sus firmas manuscritas en los mensajes de correo electrónico.

Correos electrónicos con archivos adjuntos y/o software malicioso: Todos

los servidores de correo en EPM deben analizar todos los mensajes de correo

electrónico entrantes, en busca de software malicioso y contenido ajeno a la

entidad y no deben abrir archivos adjuntos a los correos electrónicos, a menos

que este seguro de que ya han sido analizados por el software de detección,

eliminación y reparación de código malicioso aprobado.

1.6..13 Reglas de negocios para los Sistemas de Mensajería Instantánea en EPM

Mensajería instantánea pública: No está permitida la mensajería instantánea

pública en EPM, a menos que se cuente con la autorización respectiva. No se

debe utilizar la mensajería instantánea en conversaciones confidenciales o para

transmitir o recibir información crítica o sensible. Los usuarios del servicio de

mensajería instantánea no pueden utilizar comentarios obscenos, despectivos u

ofensivos en contra de cualquier persona o entidad.



Página 42 de 51



Página 42

Monitoreo de los sistemas de mensajería instantánea: No se puede monitorear

los sistemas de mensajería instantánea, a menos que la Dirección Control Interno

o la Unidad Control Disciplinario hayan aprobado y asignado esta tarea.

1.6..14 Reglas de negocio para el manejo del Registro Histórico de Actividades en EPM

Registro de operaciones críticas y/o sensibles: Las operaciones críticas o

sensibles de la entidad, son registradas, para detectar y reducir el riesgo de

violación o fraudes.

Manejo de logs: Todos los sistemas fuente y las aplicaciones de producción que

manejen información sensible deben generar logs que muestren cada

modificación, incorporación y borrado de la información.

Los sistemas que manejen información sensible o crítica deben además contener

y activar el log sobre todos los eventos o procesos relacionados con la seguridad

de acceso y que se tengan procedimientos adecuados para su explotación.

Los logs de procesos relevantes deben de proveer información que sirva como

evidencia en auditorías contribuir a la eficiencia y cumplimiento de medidas de

seguridad.

El Propietario de la Información debe definir la característica especial que estos

logs deban incluir, de acuerdo a requerimientos internos o con autoridades

externas.

Un log debe activarse y depurarse por lo menos cada mes. Durante este período,

el log no debe ser modificado, ni leído por personal no autorizado. Los logs deben

ser conservados de forma tal, que no puedan ser revisados o visualizados por

personas no autorizadas. Los funcionarios autorizados deben contar con una

autorización del dueño de la información en cuestión para realizar tal acceso.

Además todas las actividades de los usuarios que afecten producción deben ser

trazables desde el log.



Página 43 de 51



Página 43

Se deben tener registros o logs de las transacciones de los sistemas de

información con información crítica o sensible en EPM para facilitar la

identificación y solución de incidencias o eventos de Seguridad de TI.

Las aplicaciones y otros manejadores de Bases de Datos, deben tener logs para

las actividades de los usuarios y estadísticas relacionadas a estas actividades.

Además los mecanismos para detectar y registrar eventos de seguridad

significativos, deben ser resistentes a los ataques y aun cuando el log sea

apagado o modificado, esta suspensión o modificación quede registradas en el

mismo.

Sincronización de horarios y calendarios: Todos los sistemas y equipos

conectados a la red, deben tener un mismo horario y calendario, utilizando

sincronía con los servidores, cuando sea posible. Esto facilita el análisis de los

logs.

1.6..15 Reglas relacionadas con Control de Acceso

Manejo de contraseñas: La cuenta de usuario y la contraseña de acceso a la red

corporativa es personal e intransferible. La contraseña de acceso a la red

corporativa en EPM se debe cambiar al menos una vez al mes con el fin de

minimizar los riesgos de pérdida de información.

Mecanismos de seguridad para equipos que no están en uso: Cuando no

estén en uso, las estaciones de trabajo, portátiles, terminales e impresoras deben

estar protegidas por mecanismos de seguridad que impidan la extracción de la

información de los equipos.

Acceso a las bases de datos: No se otorgarán permisos para modificar datos en

forma directa en las bases de datos de los aplicativos de TI. Las modificaciones

deben hacerse a través de los programas del sistema. Las excepciones para

modificaciones de datos en las bases de datos deben ser tratadas como



Página 44 de 51



Página 44

situaciones de emergencia y por tiempo limitado y contar con la autorización de la

dependencia propietaria de la información; dicha dependencia será responsable

civil, penal y disciplinariamente por los incidentes de seguridad ocurridos a raíz del

acceso habilitado.

Permisos para acceso a recursos informáticos y servicios de red: Los

permisos de acceso a los recursos informáticos y servicios de la red de datos

deben ser solicitados y aprobados por los niveles jerárquicos de la estructura

administrativa.

Solicitudes de autorización para que usuarios externos puedan usar y/o

acceder a los elementos de TI: La organización informática de EPM evaluarán,

de acuerdo a la disponibilidad de recursos y a los aspectos de seguridad, la

pertinencia y establecerán las acciones de mitigación de riesgos para atender esta

solicitud. El directivo que autorice el acceso será responsable por garantizar que

se implementen los mecanismos legales o de control de dichas acciones, y de

esta manera cubrir adecuadamente las consecuencias del accionar del usuario

externo autorizado.

1.6..16 Reglas relacionadas con la Adquisición, Desarrollo y Mantenimiento de Software

Requerimientos de seguridad que deben manejarse en los sistemas de

información: Se debe realizar un adecuado análisis e implementación de los

requerimientos de seguridad del software, ya sea interno o adquirido, que incluya

garantías de validación de usuarios, datos de entrada y salida, y del

procesamiento de los mismos, de acuerdo con la clasificación de los activos a

tratar en el sistema.

Los propietarios de la información deben considerar los requerimientos de seguridad

necesarios para mantener la integridad y confidencialidad de su información por

ellos administrada. Es responsabilidad del propietario de la información la

incorporación de los controles relevantes en el nuevo sistema. Esta regla debe ser



Página 45 de 51



Página 45

expandida a sistemas que reciban modificaciones significativas9, no solo para

nuevos desarrollos.

Controles para cifrar información considerada confidencial: Se deben

establecer controles para cifrar la información que sea considerada confidencial y

evitar la posibilidad de repudio de una acción por parte de un usuario del sistema.

Igualmente, se deben asegurar los archivos del sistema y mantener un control

adecuado de los cambios que puedan presentarse.

Programas especiales para acceder, crear o modificar datos en un sistema:

Se deben diseñar procedimientos controlados (programas o porciones de

programa), las cuales deben ser los únicos que se puedan seguir para poder

crear, acceder y modificar datos en los sistemas. Se debe evitar el uso de

instrucciones primarias para realizar las operaciones sobre datos.

Autorización para modificar información: Únicamente personas autorizadas

pueden modificar la información sensitiva, crítica10 en EPM. La manera más

frecuente de establecer esto es a través de contraseñas fijas, si bien la utilización

de contraseñas dinámicas se está convirtiendo en la norma a seguir. La

confirmación de la autorización puede realizarse así mismo a través de tarjetas

inteligentes, firmas digitales, certificados digitales o mensajes de autenticación de

código. Los sistemas deben estar en capacidad de manejar estas tecnologías.

Autenticación, trazabilidad y auditoria de información modificada: Los

sistemas deben disponer de funcionalidad que permitan autenticar todos los

mensajes y actualizaciones a los registros de las bases de datos de información,

así como preservar la integridad de los registros en EPM. Si son ingresadas

9 Una modificación significativa incluye cambios de TI, funcionalidades del negocio en el sistema, o impactan el

sistema actual. 10

La clasificación de la información crítica o sensible de acuerdo a la metodología de valoración y clasificación de

información



Página 46 de 51



Página 46

transacciones no autorizadas a los registros, entonces éstos pasan a ser de valor

cuestionable. Los sistemas deben tener la opción de configurar auditorias y tener

opciones de poder determinar la trazabilidad de la información cuando fue creada

o modificada.

Copias de los programas que generen o verifiquen firmas digitales: Se deben

mantener copias confiables de los programas de computador que se utilicen para

generar o verificar firmas digitales, o para cifrar o descifrar archivos., con el fin de

tener la posibilidad de que un usuario pueda probar que firmó un archivo en casos

judiciales, procedimientos de arbitramento o procesos de mediación y para

recuperar un archivo previamente encriptado.

Almacenamiento de programas fuentes: Se debe mantener un sistema de

almacenamiento seguro y centralizado de programas fuente.

Autenticación fuerte en sistemas y servidores de EPM: Los servidores de EPM

involucrados en comunicaciones con terceros, deben utilizar esquemas de

autenticación fuerte que permitan a un tercero verificar que está accediendo un

sistema genuino en EPM.

Cifrado de información que se maneje en sistemas o servidores de EPM:

Para el cifrado se deben utilizar algoritmos fuertes y probados. Los sistemas de

cifrado utilizados para las actividades regulares en EPM deben incluir funciones

de recuperación de llaves. Las llaves de cifrado deben ser protegidas con las

medidas de seguridad más exigentes. Esto requiere que las llaves de cifrado sean

a su vez cifradas y se almacenan en archivos u otras locaciones donde no puedan

ser accedidas por personas no autorizadas.

1.6..17 Reglas relacionadas con Atención de Incidentes de Seguridad de TI

Impacto de los incidentes: Se debe realizar la evaluación del impacto de los

incidentes de seguridad de TI relevantes, así como aplicar los mecanismos de

atención y manejo de los incidentes.



Página 47 de 51



Página 47

Obligación de reportar incidentes de seguridad de TI: Todos los funcionarios,

contratistas y demás personal interno o externo que tenga un vínculo contractual

con EPM y que maneje activos de información, debe reportar como incidente de

seguridad cualquier anomalía o mal uso de los recursos en EPM. Todos los

incidentes de seguridad de TI deben ser registrados, gestionados y documentados

en sus diferentes etapas para mantener los ANS negociados con los clientes y

mejorar la seguridad de TI.

Nota: Los incidentes de seguridad de TI asociados a falta de disponibilidad, por

problemas técnicos, serán tratados como incidentes de Tecnologías de

Información y serán tratados acorde a los lineamientos definidos para la gestión

de incidentes de TI.

Problemas de Seguridad de TI: Confidencialidad de los incidentes de

seguridad de TI: Los incidentes de seguridad de TI que involucren compromiso

de la reputación o buen nombre de las personas, deben asegurar la

confidencialidad más alta y la inclusión del mínimo número de personas necesario

para su evaluación y ser en todo momento seguido a través de los mecanismos

definidos por la Dirección Control Interno o la Unidad Control Disciplinario

Responsabilidad en la valoración de las pruebas técnicas recolectadas: Sólo

se suministrarán pruebas técnicas para la investigación; la valoración de las

mismas estará a cargo de la entidad competente responsable de la investigación y

serán canalizadas a través de la Dirección Control Interno o la Unidad Control

Disciplinario.

1.7 Reglas relacionadas con gestión de catálogo y niveles de servicios de TI

Existencia del catálogo de servicios de TI. El Catálogo de servicios describe los

servicios de tecnología de información disponibles, en un lenguaje no técnico,

comprensible para clientes y usuarios el cual estará dispuesto en un medio digital de

fácil consulta. El catálogo de Servicios debe utilizarse como guía para orientar y



Página 48 de 51



Página 48

definir los Acuerdos de Nivel de Servicio con los clientes de tecnología de

Información y la gestión interna de servicios en la Organización Informática de EPM.

Contenido del Catálogo de servicios: Los servicios de tecnología de información

que preste la Organización Informática de EPM deberán estar definidos, actualizados

y clasificados de forma precisa, para un mejor entendimiento de los mismos en el

Catálogo de Servicios de TI, incluyendo la información de los atributos más

relevantes de los servicios tales como: La descripción del servicio, alcance del

servicio, público objetivo, niveles de servicio comprometidos, directivas para

distribución del costo, entre otros. Los servicios del Catálogo se utilizarán como base

para generar ofertas de servicio estándar, que utilicen la mayoría de los clientes u

ofertas de servicio específicas para satisfacer necesidades particulares de algún

cliente, cuando el negocio así lo requiera. En todo caso con el fin de simplificar y

optimizar la administración de servicios se procurará mantener el mayor nivel de

estandarización posible.

Definición y Actualización del Catálogo de servicios de TI. Para la definición y

actualización de los Servicios de TI contenidos en Catálogo de Servicios, se

conformarán equipos de trabajo multidisciplinarios y transversales a la Organización

Informática de EPM, conformados por personas que posean conocimiento de los

procesos de EPM, la plataforma tecnológica, los sistemas de información, los

procesos propios de tecnología de información y aspectos relacionados con el costeo

de los servicios, con el fin de asegurar una adecuada definición de los mismos.

Acuerdos de Niveles de Servicios (ANS): La Organización Informática de EPM

teniendo en cuenta su ámbito de actuación, negociará y acordará la prestación de

servicios de tecnología de información con sus clientes internos (GEN, UEN y

dependencias dueñas de procesos) y sus clientes externos (filiales), mediante la

instauración de Acuerdos de Nivel de Servicio (ANS), con el propósito de lograr un

compromiso de expectativas con respecto al alcance y los niveles de servicio que se

deben lograr. Para facilitar este proceso de negociación y conciliación de

expectativas, la Organización Informática designará personas encargadas de

administrar la relación con sus clientes a las cuales se les denominará Ejecutivos de



Página 49 de 51



Página 49

Cuenta de tecnología de información y los Clientes designarán personas que los

representen ante la Organización informática a través de un rol que se denominará

Representante del Cliente. El Ejecutivo de cuenta y el Representante del cliente

serán las personas encargadas de establecer y negociar los Acuerdos de Nivel de

Servicio, con base en el Catálogo de Servicios de TI.

Contenido de los Acuerdos de Niveles de Servicios (ANS): Los Acuerdos de

Niveles de Servicio (ANS) se definirán en función de los requerimientos del Cliente,

las capacidades de tecnología de información disponibles en EPM y los niveles de

inversión y gasto en tecnología de información que EPM esté dispuesta a asumir en

el tiempo y deben contener información que lo defina claramente tal como

Dependencias u organizaciones involucradas, descripción del ANS, servicios

cubiertos, tiempos de atención de los servicios (TAS), niveles de servicio

comprometidos, directrices de continuidad de los servicios, métodos de costeo

(precios) y distribución de costos a los distintos clientes de los servicios, vigencia del

ANS, esquema de seguimiento y verificación de cumplimiento del ANS, entre otros.

Seguimiento a los Acuerdos de Nivel de Servicio. Los ANS deberán ser

monitoreados y gestionados periódicamente para verificar su cumplimiento; actividad

de la cual se dejará registro escrito, manteniendo al menos la información de

medición del los últimos 12 meses para cada ANS.

Reporte de cumplimiento de los ANS: La Organización Informática de EPM,

deberá presentar informes al Cliente de TI en forma periódica acerca del

cumplimiento de los Acuerdos de Nivel de Servicios pactados. El Ejecutivo de

Cuenta conciliará con el Cliente y el Representante del Cliente los niveles de servicio

obtenidos con relación a los establecidos en el ANS, con el propósito de conocer su

percepción y real satisfacción y establecer acciones de mejoramiento de los

servicios, los cuales se incorporarán posteriormente en los planes de versiones o los

planes de mejoramiento continuo de los procesos y servicios de tecnología de

información.



Página 50 de 51



Página 50

Acciones de Mejoramiento para lograr los ANS: El Líder o arquitecto del servicio

acordará con el ejecutivo y demás roles/responsables involucrados en la prestación

de servicios de TI, las acciones de mejoramiento al servicio que deberán ser

definidas y priorizadas para que se ejecuten se programen y ejecuten siguiendo el

proceso de Gestión de Demanda y Portafolio.

Acuerdos Operativos (OLA´s): Para asegurar el cumplimiento de los acuerdos de

niveles de servicio (ANS) pactados con los clientes de tecnología de información, en

aquellos servicios donde sea necesario la intervención de distintas dependencias

organizacionales y cuando las condiciones de prestación de los mismos así lo

requieran, se definirán y negociarán Acuerdos operativos (OLAs) entre las

dependencias involucradas en la operación del servicio. Estos Acuerdos Operativos

deberán ceñirse a las condiciones establecidas en los ANS con los clientes y

servirán de vehículo para facilitar su cumplimiento.

Contratos de Apoyo (UCs) con proveedores: Los contratos que suscriba la

Organización Informática con proveedores externos (terceros), con el fin de operar,

evolucionar o dar soporte a uno o varios componentes de los servicios de tecnología

de información, deben tener establecidos niveles de servicio que estén acorde con

los ANS pactados con los clientes, los cuales se deberán gestionar a través del

monitoreo de indicadores que permitan medir la oportunidad y calidad del servicio

entregado por el tercero.

Aseguramiento del cumplimiento de los niveles de servicio comprometidos en

contratos con terceros: Los interventores de los contratos de apoyo que soportan

los ANS, deben asegurar el cumplimiento de los niveles de servicio comprometidos

en los contratos vigentes con proveedores y generar los informes periódicos, así

como elaborar y ejecutar planes de mejoramiento para corregir posibles fallas.

Métricas de desempeño de servicios: Los responsables de procesos, proyectos y

servicios de TI trabajarán en conjunto con los responsables de los procesos de EPM

para definir un conjunto balanceado de objetivos y mediciones de desempeño. Las

personas que participan en todos los procesos de tecnología de información deben



Página 51 de 51



Página 51

generar la información para las mediciones de manera oportuna, válida y

consistente. El grupo primario de TI, deberá validar y aprobar las mediciones de

desempeño acordadas, teniendo en cuenta el costo beneficio y su contribución del

cumplimiento de los objetivos estratégicos.

manual de reglas de negocio asociadas al proceso diseño ... · pdf fileestructura...

Documents