Gestion TI - Reglas de Negocio

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 001
Junio 2012
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
Página 2 de 51
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 2
Página 3 de 51
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 3
Página 4 de 51
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 4
Página 5 de 51
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 5
Página 6 de 51
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 6
Página 7 de 51
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 7
Página 8 de 51
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 8
Página 9 de 51
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 9
Página 10 de 51
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 10
Página 11 de 51
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 11
Página 12 de 51
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 12
Página 13 de 51
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 13
Página 14 de 51
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 14
Página 15 de 51
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 15
Página 16 de 51
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 16
Página 17 de 51
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 17
Página 18 de 51
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 18
Página 19 de 51
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 19
Página 20 de 51
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 20
Página 21 de 51
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 21
Página 22 de 51
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 22
Página 23 de 51
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 23
Página 24 de 51
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 24
Página 25 de 51
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 25
Página 26 de 51
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 26
Página 27 de 51
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 27
Página 28 de 51
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 28
Página 29 de 51
Á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 29
Página 30 de 51
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 30
Página 31 de 51
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 31
Página 32 de 51
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 32
Página 33 de 51
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 33
Página 34 de 51
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 34
Página 35 de 51
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 35
Página 36 de 51
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 36
Página 37 de 51
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 37
Página 38 de 51
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 38
Página 39 de 51
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 39
Página 40 de 51
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 40
Página 41 de 51
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 41
Página 42 de 51
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 42
Página 43 de 51
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 43
Página 44 de 51
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 44
Página 45 de 51
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 45
Página 46 de 51
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 46
Página 47 de 51
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 47
Página 48 de 51
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 48
Página 49 de 51
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 49
Página 50 de 51
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 50
Página 51 de 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.
Página 51

Gestion TI - Reglas de Negocio

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Gestion TI - Reglas de Negocio

Cargado por

Copyright:

Formatos disponibles

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

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

MANUAL DE REGLAS DE NEGOCIO ASOCIADAS AL PROCESO

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

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.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.7 Reglas relacionadas con gestión de catálogo y niveles de servicios de TI ...................... 47

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

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

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

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

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

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

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

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

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

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

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

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

DIAGRAMAS ESTRUCTURALES DE UN SISTEMA SOFTWARE: Existen para especificar,

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

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

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

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

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

DIAGRAMAS DE COMPORTAMIENTO DE UN SISTEMA SOFTWARE: Se emplean para

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

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

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

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

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

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

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

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

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

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

1 REGLAS DE NEGOCIO PARA EL PROCESO DISEÑO DEL

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 funcionales y no funcionales: Los requisitos funcionales se usan para

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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