Fundamentos de Seguridad Informática

Estandares ISO 27000

ISO/IEC 27000 es un conjunto de estándares desarrollados -o en fase de desarrollo- por

ISO (International Organization for Standardization) e IEC (International Electrotechnical
Commission), que proporcionan un marco de gestión de la seguridad de la información
utilizable por cualquier tipo de organización, pública o privada, grande o pequeña.

El ISO-27000 se basa en la segunda parte del estándar británico BS7799 (BS7799:2). Está
compuesta a grandes rasgos por:

 ISMS(Information Security Management System).

 Valoración de Riesgo.
 Controles.

A semejanza de otras normas ISO, la 27000 es realmente una serie de estándares.

 ISO 27000: En fase de desarrollo. Contendrá términos y definiciones que se

emplean en toda la serie 27000. La aplicación de cualquier estándar necesita de un
vocabulario claramente definido, que evite distintas interpretaciones de conceptos técnicos
y de gestión. Esta norma será gratuita, a diferencia de las demás de la serie, que tendrán un
coste.
 ISO 27001: Es la norma principal de requisitos del sistema de gestión de seguridad
de la información. Tiene su origen en la BS 7799-2:2002 y es la norma con arreglo a la cual
se certifican por auditores externos los SGSI de las organizaciones. Fue publicada el 15 de
Octubre de 2005 y sustituye a la BS 7799-2, habiéndose establecido unas condiciones de
transición para aquellas empresas certificadas en esta última.

Servicios de Seguridad Informática

Un servicio de seguridad es aquel que mejora la seguridad de un sistema de información y

el flujo de información de una organización. Los servicios están dirigidos a evitar los
ataques de seguridad y utilizan uno o más mecanismos de seguridad para proveer el
servicio.

Clasificación

Una clasificación muy utilizada de los servicios de seguridad es la siguiente:

 Confidencialidad

 Autenticación

 Integridad

 No repudio

 Control de acceso

 Disponibilidad

Servicios de Seguridad Informática

Confidencialidad

Servicio de seguridad o condición que asegura que la información no pueda estar

disponible o ser descubierta por o para personas, entidades o procesos no autorizados.
También puede verse como la capacidad del sistema para evitar que personas no
autorizadas puedan acceder a la información almacenada en él.

La confidencialidad es importante porque la consecuencia del descubrimiento no autorizado

puede ser desastrosa. Los servicios de confidencialidad proveen protección de los recursos
y de la información en términos del almacenamiento y de la información, para asegurarse
que nadie pueda leer, copiar, descubrir o modificar la información sin autorización. Así
como interceptar las comunicaciones o los mensajes entre entidades.
 Mecanismos para salvaguardar la confidencialidad de los datos:

 El uso de técnicas de control de acceso a los sistemas.

 El cifrado de la información confidencial o de las comunicaciones.

Autenticación
Es el servicio que trata de asegurar que una comunicación sea auténtica, es decir, verificar
que el origen de los datos es el correcto, quién los envió y cuándo fueron enviados y
recibidos también sean correctos.

Algunos métodos de autenticación son:

 Biomédicas, por huellas dactilares, retina del ojo, etc.

 Tarjetas inteligentes que guardan información de los certificados de un usuario

 Métodos clásicos basados en contraseña:

o Comprobación local o método tradicional en la propia máquina

o Comprobación en red o método distribuido, más utilizado actualmente

Integridad
Servicio de seguridad que garantiza que la información sea modificada, incluyendo su
creación y borrado, sólo por el personal autorizado.

El sistema no debe modificar o corromper la información que almacene, o permitir que

alguien no autorizado lo haga. El problema de la integridad no sólo se refiere a
modificaciones intencionadas, sino también a cambios accidentales.

No repudio
El no repudio sirve a los emisores o a los receptores para negar un mensaje transmitido. Por
lo que cuando un mensaje es enviado, el receptor puede probar que el mensaje fue enviado
por el presunto emisor. De manera similar, cuando un mensaje es recibido, el remitente
puede probar que el mensaje fue recibido por el presunto receptor.
Control de Acceso
Un control de acceso se ejecuta con el fin de que un usuario sea identificado y autenticado
de manera exitosa para que entonces le sea permitido el acceso.

Los componentes básicos de un mecanismo de control de acceso son las entidades de red,
los recursos de la red y los derechos de acceso. Estos últimos describen los privilegios de la
entidad o los permisos con base en qué condiciones las entidades pueden tener acceso a un
recurso de la red y cómo estas entidades son permitidas para tener acceso a un recurso de la
red.

El control de acceso puede ejecutarse de acuerdo con los niveles de seguridad y puede
ejecutarse mediante la administración de la red o por una entidad individual de acuerdo con
las políticas de control de acceso.
Disponibilidad

En un entorno donde las comunicaciones juegan un papel importante es necesario asegurar

que la red esté siempre disponible.

La disponibilidad es un servicio que garantiza que los usuarios autorizados tengan acceso a
la información y a otros activos de información asociados en el lugar, momento y forma en
que es requerido. Un sistema seguro debe mantener la información disponible para los
usuarios. El sistema, tanto hardware como software, debe mantenerse funcionando
eficientemente y ser capaz de recuperarse rápidamente en caso de fallo.

Amenazas Humanas

Surge por ignorancia en el manejo de la información, por descuido, por negligencia, por
inconformidad. Para este caso se pueden considerar a los hackers, crakers, phreakers,
carding, trashing, gurús, lamers o scriptkiddies, copyhackers, bucaneros, newbie,
wannabers, samurai, creadores de virus y los que se listan a continuación:
 Ingeniería social:es la manipulación de las personas para convencerlas de que ejecuten
acciones o actos que normalmente no realizan de forma que revelen datos indispensables
que permitan superar las barreras de seguridad. Esta técnica es una de las más usadas y
efectivas al momento de averiguar nombres de usuarios y contraseñas.
 Amenazas Hardware
 Este tipo de amenazas se da por fallas físicas que se encuentra presente en cualquier
elemento de dispositivos que conforman la computadora. Los problemas más
identificados para que el suministro de energía falle son el bajo voltaje, ruido
electromagnético, distorsión, interferencias, alto voltaje, variación de frecuencia,
etc.


 Amenazas Red
  Se presenta una amenaza cuando no se calcula bien el flujo de información que va a
circular por el canal de comunicación, es decir, que un atacante podría saturar el
canal de comunicación provocando la no disponibilidad de la red. Otro factor es la
desconexión del canal.


Amenazas Lógica

Se presenta una amenaza cuando no se calcula bien el flujo de información que va a

circular por el canal de comunicación, es decir, que un atacante podría saturar el canal de
comunicación provocando la no disponibilidad de la red. Otro factor es la desconexión del
canal.

La amenaza se hace presente cuando un diseño bien elaborado de un mecanismo de

seguridad se implementa mal, es decir, no cumple con las especificaciones del diseño. La
comunicación entre procesos puede resultar una amenaza cuando un intruso utilice una
aplicación que permita evitar y recibir información, ésta podría consistir en enviar
contraseñas y recibir el mensaje de contraseña válida; dándole al intruso elementos para un
posible ataque.

En la mayoría de los sistemas, los usuarios no pueden determinar si el hardware o el

software con que funcionan son los que supone que deben ser. Esto facilita al intruso para
que pueda reemplazar un programa sin conocimiento del usuario y éste pueda
inadvertidamente teclear su contraseña en un programa de entrada falso al cual también se
le denomina códigos maliciosos.

Los tipos de códigos maliciosos más comunes son: caballos de Troya, virus, gusanos,
bombas de tiempo y keyloggers.
 Caballos de Troya Es un programa aparentemente útil que contiene funciones escondidas y
además pueden explotar los privilegios de un usuario dando como resultado una amenaza
hacia la seguridad. Un caballo de Troya es más peligroso que un administrador del sistema
o un usuario con ciertos privilegios, ya que se introducen al sistema bajo una apariencia
totalmente diferente a la de su objetivo final; esto es, que se presente como información
pérdida o basura, sin ningún sentido. Pero al cabo de algún tiempo, y esperando la
indicación del programa, despierta y comienzan a ejecutarse y a mostrar sus verdaderas
intenciones. También pueden aparentar ser un programa de juegos o entretener al usuario
mostrando pantallas de espectáculos y sonidos agradables, mientras realizan operaciones
dañinas para el sistema.
¿Podría mi empresa trabajar en la NUBE en caso de desastre?
Por Arturo Rubio, Director Comercial en Datadec
Los sistemas de información son uno de los activos más valiosos de cualquier organización.
En Datadec Online sabemos que, hoy en día, la importancia estratégica de la
información implica la necesidad de estar preparados antesituaciones críticas que supongan
paradas inesperadas en nuestras empresas, y tener también un plan B para una rápida
recuperación desde el mismo punto en que se produjo la parada.
En muchas ocasiones se relaciona el concepto de “catástrofe” con desastres ambientales
(incendios, inundaciones, seísmos, etc.). La probabilidad de que ocurran este tipo de
acontecimientos, aunque es ciertamente real (recordemos la tragedia de las Torres Gemelas,
el edificio Windsor, la nava de Fontestad, etc.), sin embargo, es mínima, y por ese motivo,
se baja la guardia a la hora de implantar estrategias de continuidad de negocio, ya que por
lo general constituyen un “gasto” para la organización y se dejan llevar por la frase
“recemos porque no me pase a mí”.
Sin embargo, varios informes indican que un porcentaje importante de situaciones críticas
de inactividad en las empresas vienen originadas por motivos técnicos (paradas de sistemas,
fallos en suministro eléctrico, etc.).
Aunque, por encima de todo lo anterior, la principal causa de caída o pérdidas de datos en
los sistemas de información son los ataques o errores humanos, sobre todo provenientes del
interior de la propia organización.
Somos conscientes del riesgo que supondría una parada inesperada en los sistemas
informáticos de nuestra organización, pero… ¿hacemos algo para evitarlo?
A pesar de que las incidencias anteriormente comentadas están ahí y son evidentes para
cualquier dirigente, muchas compañías “arriesgan al límite” y confían la disponibilidad de
su empresa a estrategias de copias de seguridad (backups), sin pararse a pensar en la
pérdida de tiempo y costes que provocaría la inactividad de la organización. En ocasiones,
la imposibilidad de conseguir recuperar la situación existente en el momento previo a la
caída ha sido motivo, incluso, de la desaparición de estas empresas.
En la mayoría de los casos, el motivo principal de la no implantación de un plan de
continuidad y recuperación es el elevado volumen de inversión que debe afrontar una
compañía para garantizar, no sólo la alta disponibilidad de sus sistemas de información,
sino mecanismos rápidos y eficaces para una reactivación de los sistemas en caso de caída.
Cuando una empresa se plantea este tipo de estrategias debe de tener claro que su data
center deberá de disponer de una infraestructura redundante (equipos, personal, energía,
comunicaciones, aire acondicionado, sistemas anti-incendio, etc.) Además de esto, estará
obligado también a establecer políticas de replicación de sus aplicaciones y de sus bases de
datos.
La realidad, y más en la situación económica global en la que nos encontramos, es que las
empresas piensan ahora en invertir todo el dinero y el esfuerzo en su actividad empresarial,
y dejan a la “providencia” su suerte en lo referente a sus sistemas de información.
A excepción de los denominados “grandes” (banca, administración pública, gran cuenta,
etc.), pocas compañías tienen entre sus prioridades estratégicas la de asegurar la alta
disponibilidad de sus tecnologías de la información.
Solución: La Externalización
Desarrollar y construir sitios para albergar tecnología requiere de unas inversiones muy
importantes que, en ocasiones, pueden descapitalizar a una empresa.
Por ello, una estrategia acertada sería confiar las políticas de contingencia a compañías
especializadas en la materia, que no sólo le asesorarán en cómo poner en marcha estas
políticas, sino que le proporcionarán una infraestructura de alta disponibilidad mediante
data centers, los cuales servirán como plataforma de respaldo para los sistemas alojados en
las instalaciones de la empresa.
Estos data centers, dotados de sistemas redundantes y preparados para ser escalables según
las necesidades de recursos de sus clientes, serán los que realicen las inversiones
necesarias, mientras las empresas únicamente pagarán una cuota por la utilización de los
servicios de respaldo ofrecidos desde estos centros.
Un escenario posible de respaldo y recuperación podría ser el de establecer mecanismos de
replicado de datos en un data center mediante backups remotos (en diferido o en tiempo
real). En caso de producirse una catástrofe en los sistemas alojados en la propia empresa el
data center podría entregar a la mayor celeridad posible una copia tanto de aplicaciones
como de datos a la empresa para que ésta pusiera en marcha el proceso de recuperación en
sus propios equipos.
Esta modalidad es útil en supuestos en los que la empresa, a pesar de la parada inesperada,
puede volver a reactivar su actividad en sus instalaciones o en otro centro destinado a tal
fin.
Sin embargo, ¿qué ocurriría en situaciones graves en las que incluso los equipos e
instalaciones de la empresa han sido destruidos? ¿Cómo podríamos volver a trabajar en
estos casos de catástrofe?
La nube al servicio de las estrategias de continuidad de negocio
El servicio RECOVERY AS A SERVICE (RaaS) es un nuevo concepto de replicación y
recuperación ante desastres basado en el modelo de Cloud Computing que permite a las
empresas disponer de una réplica exacta de sus sistemas y aplicaciones en un data center
remoto especializado, el cual actuará como plataforma de contingencia en caso de desastre
en las propias instalaciones de la empresa.
Gracias a este nuevo modelo, cualquier empresa tendrá a su alcance la puesta en marcha de
una estrategia de continuidad de negocio de primer nivel, a semejanza de las grandes
corporaciones, y todo mediante una modalidad de pago por uso, asequible para la tesorería
de su empresa, de igual modo que si estuviera contratando un seguro de robo, de incendios,
etc.
Los beneficios para la empresa son claros:
 Rápida reactivación de su negocio en caso de catástrofe grave
 Drástica reducción de tiempos y costes por periodos de inactividad provocados por
desastres
 Inversión Cero en infraestructuras de respaldo: hardware, licencias de software,
mantenimientos, personal dedicado, comunicaciones, energía, aire acondicionado,
sistemas anti-incendio, etc.
 Escalabilidad y personalización de la arquitectura de respaldo y recuperación para
cumplir con los requerimientos de cada empresa
 Múltiples usos adicionales de la plataforma alojada en el data center: Realización de
pruebas contra la plataforma de respaldo para no afectar al entorno de producción,
explotación y análisis de la información respaldada en el data center remoto
mediante herramientas de Business Intelligence, etc.
Metodología para la implantación del modelo RaaS
A la hora de elegir el proveedor RaaS no bastará solamente con asegurarse de que nos
proporciona una infraestructura de alta disponibilidad segura y escalable.
Además, será necesario que dicho proveedor ponga a disposición de la empresa un equipo
experto de ingenieros altamente cualificados en entornos de alta disponibilidad, capaces de
implantar el modelo más óptimo para cada organización, estableciendo estrategias
preventivas, elaborando planes de contingencia ante desastres y gestionando eficientemente
las operaciones de respaldo y recuperación.
De forma muy resumida, la metodología idónea para una correcta implantación del modelo
RaaS debería seguir las siguientes fases:
FASE I: Consultoría
Se determinarán los mecanismos de replicación idóneos y el alcance de aplicaciones y
datos a respaldar, para garantizar que, en caso de caída de los sistemas del cliente, todas las
aplicaciones puedan iniciar sus servicios en el data center del proveedor RaaS en el tiempo
adecuado a sus necesidades.
FASE II: Preparación de la plataforma
Instalación, configuración y puesta en marcha en el data center del proveedor RaaS de la
plataforma de respaldo, procediendo a la realización de pruebas para comprobar el correcto
funcionamiento de la infraestructura de contingencia.
FASE III: Gestión del Servicio
Una vez puesto en marcha el servicio de respaldo se realizarán servicios de monitorización
continua, así como pruebas periódicas para garantizar el correcto funcionamiento del
servicio. Estas pruebas de recuperación se realizarán sin afectar a los sistemas alojados en
el cliente.
DATADEC ONLINE: Más de 12 años de experiencia como proveedor SaaS
Datadec Online es un data center pionero en servicios en Cloud Computing, que nació en el
año 2000 con la misión de ofrecer aplicaciones y servicios empresariales sobre plataformas
tecnológicas de alta disponibilidad, para ser utilizados por sus clientes sin la necesidad de
realizar ninguna inversión.
Un experto equipo de ingenieros asesorará a su organización en el diseño del plan de
continuidad idóneo para su negocio, aportando el siguiente valor añadido:
 Garantía de continuidad para que los datos y aplicaciones de una organización estén
siempre disponibles, evitando la pérdida de ingresos y reputación empresarial
como resultado de paradas inesperadas o daños accidentales en sus sistemas de
información.
 Rápida recuperación ante desastres, mediante estrategias de recuperación adecuadas
a cada necesidad, minimizando el tiempo de inactividad y garantizando dicha
recuperación desde el mismo punto temporal en el que se produjo la incidencia.
 El enfoque proactivo de seguridad de la información en las empresas busca evitar o
reducir las consecuencias de los riesgos existentes en su entorno. En esta categoría
se incluyen elementos como el análisis de riesgos o el plan de respuesta a
incidentes, pero hay otra opción a considerar: el Plan de Recuperación ante
 Desastres (DRP por sus siglas en inglés) y su relación con otros planes como el Plan
de Continuidad del Negocio (BCP). Veamos de qué se trata.
 Diferencias entre el DRP y BCP

 En ocasiones, suelen utilizarse de manera indistinta los términos BCP y DRP

cuando se hace referencia a planes encaminados a restablecer las operaciones
primordiales de una organización en caso de alguna contingencia. Sin embargo,
existen diferencias sustanciales entre un plan y otro, y la principal característica que
permite identificarlos es su alcance.
 Ambos son componentes utilizados para contribuir a que los sistemas esenciales
para el funcionamiento de la organización, estén disponibles cuando sean
necesarios, con la característica de que el DRP se limita a los procesos e
infraestructura de TI de la organización y está considerado dentro del BCP.
 Por su parte, la continuidad del negocio está encaminada a describir los pasos a
seguir por una organización cuando no puede funcionar de manera normal debido a
un desastre natural o uno causado por el hombre. El BCP puede ser escrito para un
proceso de negocio específico o para todos aquellos de misión crítica, y se compone
de un conjunto de planes, incluido el DRP.
 Otros que lo conforman, como el de reanudación del negocio (BRP), emergencia de
ocupantes (OEP) y continuidad de operaciones (COP) no están relacionados con la
infraestructura y procesos de TI.

 El Plan de Gestión de Incidentes (IMP) que también está incluido en el BCP, está
relacionado con TI y establece la estructura y los procedimientos para hacer frente a
algún incidente de seguridad de la información, aunque generalmente no involucra
la activación del DRP. La siguiente imagen muestra los planes considerados en el
BCP.

 Entonces, la recuperación ante desastres se enfoca en el restablecimiento de los
sistemas e infraestructura de TI que soportan los procesos de negocio críticos
después de eventos de interrupción, mientras que la continuidad del negocio está
orientada a la recuperación de los procesos de negocio críticos que son necesarios
para la operación, por lo que no solo incluye lo anterior, sino también todos los
demás aspectos operativos necesarios dentro de la organización.
 Desarrollo y activación del DRP

 Existen diferentes maneras de abordar el desarrollo de un plan de recuperación, pero

éste siempre debe estar alineado con el plan de continuidad, por lo que debe
considerar los elementos que definen la razón de ser de una organización.

 Además, el DRP debe incluir los criterios para determinar cuándo un incidente de
seguridad no se puede resolver mediante los procedimientos comunes de atención y
se considera como un desastre, es decir, cuando se presenta un evento catastrófico y
repentino que nulifica la capacidad de las organizaciones para llevar a cabo los
procesos esenciales.
 Un desastre podría ser el resultado de un daño importante a una parte de las
operaciones, la pérdida total de una instalación o la incapacidad de los empleados
para acceder a las instalaciones, generado por algún tipo de desastre natural, una
contingencia sanitaria o una huelga, por ejemplo.
 Una propuesta para el desarrollo y aplicación del DRP se considera en los siguientes
6 puntos:
 1. Desarrollar una política de continuidad del negocio

 Todas las actividades deben estar alineadas con los objetivos de continuidad del
negocio, por lo que un punto de partida puede ser el desarrollo de una política
encargada de establecer el marco de operación de los planes, así como la
clasificación de los sistemas o aplicaciones para identificar aquellos que sean
considerados como críticos.

 2. Realizar una evaluación de riesgos

 Llevar a cabo una evaluación de riesgos permite identificar, analizar y evaluar las
amenazas que podrían afectar a la organización, especialmente aquellos que puedan
provocar un evento que se incluya en la categoría de desastre.
 3. Realizar un análisis de impacto al negocio (BIA)

 En este paso se definen principalmente los objetivos de recuperación para los

sistemas que soportan los procesos de negocio. Se define el Tiempo Objetivo de
Recuperación (RTO por sus siglas en inglés), que es el período permitido para la
recuperación de una función o recurso de negocio a un nivel aceptable luego de un
desastre, y el Punto Objetivo de Recuperación (RPO) que describe la antigüedad
máxima de los datos para su restauración, con base en los requisitos del negocio.
 4. Desarrollar estrategias de recuperación y continuidad del negocio

 En este paso se busca dejar en claro todas las medidas a poner en práctica para
regresar a la operación tan pronto como sea posible, con base en una priorización
derivada de la clasificación del primer punto.

 5. Concientizar, capacitar y probar los planes

 Un elemento necesario con relación a los planes consiste en realizar su difusión

entre los miembros de la organización, especialmente entre aquellos que serán los
encargados de ponerlo en ejecución en caso de ser requerido. Además, es necesario
que se lleven a cabo pruebas del mismo, para ello, se puede hacer uso de diferentes
opciones, desde una revisión de la lista de verificación (checklist) de la
recuperación hasta una prueba de interrupción completa (full interruption test)
donde las operaciones se interrumpen en el sitio primario y se transfieren a un sitio
de recuperación.
 6. Mantener y mejorar el plan de recuperación ante desastres

 A partir de los resultados de la prueba de los planes se deben llevar los ajustes
correspondientes para contar con documentación actualizada y apropiada a los
intereses de la organización, una vez que han sido consideradas las situaciones de
desastre que podrían afectarla, las actividades y recursos necesarias para restablecer
las operaciones críticas.

 De manera general, las organizaciones que desarrollan los planes de recuperación

deberán considerar los recursos a su alcance, los servicios previamente identificados
y que se desean recuperar tan pronto como sea posible, así como los tipos y
severidad de las amenazas que enfrenta la organización y pueden llegar a
convertirse en un problema de mayor magnitud para la misma.

 Otro elemento necesario es la propensión al riesgo de la organización, ya que de

ello también dependerán los esfuerzos y recursos destinados al desarrollo y
aplicación del DRP.
 La consideración de este plan ofrece la ventaja de responder de forma planeada ante
una catástrofe y minimizar su impacto en contra de los objetivos y misión de la
empresa de manera proactiva.
 El enfoque proactivo de seguridad de la información en las empresas busca evitar o
reducir las consecuencias de los riesgos existentes en su entorno. En esta categoría
se incluyen elementos como el análisis de riesgos o el plan de respuesta a
incidentes, pero hay otra opción a considerar: el Plan de Recuperación ante
Desastres (DRP por sus siglas en inglés) y su relación con otros planes como el Plan
de Continuidad del Negocio (BCP). Veamos de qué se trata.
 Diferencias entre el DRP y BCP

 En ocasiones, suelen utilizarse de manera indistinta los términos BCP y DRP

cuando se hace referencia a planes encaminados a restablecer las operaciones
primordiales de una organización en caso de alguna contingencia. Sin embargo,
existen diferencias sustanciales entre un plan y otro, y la principal característica que
permite identificarlos es su alcance.
 Ambos son componentes utilizados para contribuir a que los sistemas esenciales
para el funcionamiento de la organización, estén disponibles cuando sean
necesarios, con la característica de que el DRP se limita a los procesos e
infraestructura de TI de la organización y está considerado dentro del BCP.
 Por su parte, la continuidad del negocio está encaminada a describir los pasos a
seguir por una organización cuando no puede funcionar de manera normal debido a
un desastre natural o uno causado por el hombre. El BCP puede ser escrito para un
 proceso de negocio específico o para todos aquellos de misión crítica, y se compone
de un conjunto de planes, incluido el DRP.
 Otros que lo conforman, como el de reanudación del negocio (BRP), emergencia de
ocupantes (OEP) y continuidad de operaciones (COP) no están relacionados con la
infraestructura y procesos de TI.

 El Plan de Gestión de Incidentes (IMP) que también está incluido en el BCP, está
relacionado con TI y establece la estructura y los procedimientos para hacer frente a
algún incidente de seguridad de la información, aunque generalmente no involucra
la activación del DRP. La siguiente imagen muestra los planes considerados en el
BCP.


 Entonces, la recuperación ante desastres se enfoca en el restablecimiento de los
sistemas e infraestructura de TI que soportan los procesos de negocio críticos
después de eventos de interrupción, mientras que la continuidad del negocio está
orientada a la recuperación de los procesos de negocio críticos que son necesarios
para la operación, por lo que no solo incluye lo anterior, sino también todos los
demás aspectos operativos necesarios dentro de la organización.
 Desarrollo y activación del DRP

 Existen diferentes maneras de abordar el desarrollo de un plan de recuperación, pero

éste siempre debe estar alineado con el plan de continuidad, por lo que debe
considerar los elementos que definen la razón de ser de una organización.

 Además, el DRP debe incluir los criterios para determinar cuándo un incidente de
seguridad no se puede resolver mediante los procedimientos comunes de atención y
se considera como un desastre, es decir, cuando se presenta un evento catastrófico y
 repentino que nulifica la capacidad de las organizaciones para llevar a cabo los
procesos esenciales.
 Un desastre podría ser el resultado de un daño importante a una parte de las
operaciones, la pérdida total de una instalación o la incapacidad de los empleados
para acceder a las instalaciones, generado por algún tipo de desastre natural, una
contingencia sanitaria o una huelga, por ejemplo.
 Una propuesta para el desarrollo y aplicación del DRP se considera en los siguientes
6 puntos:

 1. Desarrollar una política de continuidad del negocio

 Todas las actividades deben estar alineadas con los objetivos de continuidad del
negocio, por lo que un punto de partida puede ser el desarrollo de una política
encargada de establecer el marco de operación de los planes, así como la
clasificación de los sistemas o aplicaciones para identificar aquellos que sean
considerados como críticos.

 2. Realizar una evaluación de riesgos

 Llevar a cabo una evaluación de riesgos permite identificar, analizar y evaluar las
amenazas que podrían afectar a la organización, especialmente aquellos que puedan
provocar un evento que se incluya en la categoría de desastre.
 3. Realizar un análisis de impacto al negocio (BIA)

 En este paso se definen principalmente los objetivos de recuperación para los

sistemas que soportan los procesos de negocio. Se define el Tiempo Objetivo de
Recuperación (RTO por sus siglas en inglés), que es el período permitido para la
recuperación de una función o recurso de negocio a un nivel aceptable luego de un
desastre, y el Punto Objetivo de Recuperación (RPO) que describe la antigüedad
máxima de los datos para su restauración, con base en los requisitos del negocio.
 4. Desarrollar estrategias de recuperación y continuidad del negocio

 En este paso se busca dejar en claro todas las medidas a poner en práctica para
regresar a la operación tan pronto como sea posible, con base en una priorización
derivada de la clasificación del primer punto.
 5. Concientizar, capacitar y probar los planes

 Un elemento necesario con relación a los planes consiste en realizar su difusión

entre los miembros de la organización, especialmente entre aquellos que serán los
encargados de ponerlo en ejecución en caso de ser requerido. Además, es necesario
que se lleven a cabo pruebas del mismo, para ello, se puede hacer uso de diferentes
opciones, desde una revisión de la lista de verificación (checklist) de la
recuperación hasta una prueba de interrupción completa (full interruption test)
donde las operaciones se interrumpen en el sitio primario y se transfieren a un sitio
de recuperación.
 6. Mantener y mejorar el plan de recuperación ante desastres

 A partir de los resultados de la prueba de los planes se deben llevar los ajustes
correspondientes para contar con documentación actualizada y apropiada a los
intereses de la organización, una vez que han sido consideradas las situaciones de
desastre que podrían afectarla, las actividades y recursos necesarias para restablecer
las operaciones críticas.

 De manera general, las organizaciones que desarrollan los planes de recuperación

deberán considerar los recursos a su alcance, los servicios previamente identificados
y que se desean recuperar tan pronto como sea posible, así como los tipos y
severidad de las amenazas que enfrenta la organización y pueden llegar a
convertirse en un problema de mayor magnitud para la misma.

 Otro elemento necesario es la propensión al riesgo de la organización, ya que de

ello también dependerán los esfuerzos y recursos destinados al desarrollo y
aplicación del DRP.
 La consideración de este plan ofrece la ventaja de responder de forma planeada ante
una catástrofe y minimizar su impacto en contra de los objetivos y misión de la
empresa de manera proactiva.
ITIL

Éste es un primer artículo de una serie que pretende explicar, desde un punto de vista
pragmático, qué es ITIL y para qué puede ser usado en las organizaciones en la actualidad.
En esta entrega se cubren algunos temas preliminares y se revisa un poco de la historia de
ITIL.

Introducción

Si usted se dedica a algo relacionado con TI es altamente probable que haya escuchado de
ITIL e incluso puede que sea de los afortunados (¿afortunados?) que ya están involucrados
en un proyecto de implantación de ITIL.

ITIL está de moda en el mundo, todos hablan, bien o mal según les haya ido, de ITIL. En
las revistas de auditoría ITIL, en las revistas de seguridad ITIL, por todos lados ITIL…
pero, ¿qué es ITIL y para qué sirve? En esta serie de artículos trataré de dar respuesta a las
preguntas anteriores, de tal manera que los lectores hagan un mejor uso de ITIL en sus
organizaciones, sacándole el mejor provecho y sin pedirle que haga cosas que no sabe o no
puede hacer.

Una aclaración importante: no pretendo hacer una revisión técnica con detalle de ITIL en
cualquiera de sus versiones, así que si está buscando capacitación o profundización de sus
conocimientos en ese sentido, este no es el texto adecuado (en una serie posterior de
artículos prometo revisar la versión 2, la versión 3 y las diferencias entre ambas). La idea
aquí es entender “la filosofía” de ITIL y dar algunas ideas de cómo, cuándo y por qué
aplicarlo en la vida real. Así pues, emplearé la versión 2 para desarrollar mis ideas, aunque
todos los conceptos aplican de igual manera si usted está pensando en la versión 3.

Dos temas preliminares

Antes de entrar en materia, es preciso hablar de dos temas relevantes y muy relacionados
con ITIL:

1. Administración de servicios de TI.

2. Administración por procesos.

¿Por qué es necesario? Fácil, porque algunas de las premisas básicas de ITIL descansan en
esos temas y, por lo tanto, entender ITIL implica, inevitablemente, entenderlos.
¿Qué es eso de administración de servicios de TI? Veamos: si reconocemos la creciente
dependencia en las áreas de TI para el cumplimiento de los objetivos estratégicos, entonces
esta dependencia implica una mayor calidad de los servicios de TI. Por ello, la calidad debe
alinearse a los objetivos de negocio y a las necesidades de los usuarios, lo que nos lleva a
un cambio de paradigma: las áreas de TI deben cambiar su visión de administradores de
dispositivos a administradores de servicios de TI.

Tradicionalmente al preguntarle a alguien de TI “¿a qué te dedicas?”, estamos

acostumbrados a escuchar respuestas como “soy administrador de firewalls”, “soy
administrador de servidores”, etc., pero, ¿cuál es el problema con ello? Si lo pensamos
bien, los usuarios no piensan, como dicen los técnicos, en “cajas”. Ellos pueden incluso no
saber, ni les importa, qué es o para qué sirve un firewall, un switch, un router, etcétera. Lo
que los usuarios quieren es hacer uso de ciertos servicios, los famosos servicios de TI,
como el correo electrónico, el acceso a Internet, el servicio de impresión, etcétera.

Es precisamente esta dicotomía entre un área de TI y sus usuarios la que puede causar en
muchas ocasiones que sus opiniones sean diametralmente opuestas en cuanto a lo que la
primera ofrece: mientras que los técnicos se enfocan en “administrar cajas”, sin darse
cuenta que las relaciones entre ellas son relevantes, los usuarios lo que ven son servicios,
los cuales se proporcionan a través de todo un conjunto de cajas diferentes, por lo que una
falla o deficiencia en una de ellas se propaga por todo el sistema. Es así como, por ejemplo,
llegamos a ver reportes de TI que presumen de 99.9999% de disponibilidad en
el firewall de acceso a Internet, mientras que los usuarios se quejan de que el servicio de
acceso a Internet es muy malo por lento, intermitente, o por otras razones.

¿Cuál es el meollo del asunto? Precisamente está en que un servicio de TI es entregado a

los usuarios mediante un conjunto de cajas (tecnología), personas que manejan las cajas
(gente) e instructivos y relaciones entre ellos (procesos). Es por ello que el área de TI debe
entender que lo que administra y da a sus usuarios son servicios de TI, no dispositivos. El
reto es lograr la integración eficiente de gente, procesos y tecnología para una mejor
administración de los servicios de TI, optimizando el uso de los recursos y mejorando
constantemente los niveles de servicio.
Figura 1.

Administración de servicios de TI: integrando gente, procesos y tecnología

¿Y qué es la administración por procesos? Para facilitar la explicación, un poco de historia:

tradicionalmente, las organizaciones se han estructurado con base en departamentos
funcionales que dificultan la orientación hacia el cliente (por ejemplo, Dirección de
Finanzas, Dirección de Producción, Dirección de Ventas y Dirección de Sistemas), con
organigramas muy jerárquicos divididos en múltiples niveles. Normalmente este tipo de
organizaciones adolece de dos grandes problemas:

1. La comunicación “oficial” fluye verticalmente y puede ser muy lenta. Incluso a

veces propicia el conocido juego del “teléfono descompuesto”. Por ejemplo, dos
operarios de áreas distintas que requieren de un acuerdo oficial deben “subir” por el
organigrama hasta la rama común, pasando por todos los niveles del mismo
(operador A –> supervisor de A–> coordinador de A –> gerente de A -> director de
A -> director de B -> gerente de B -> coordinador de B -> supervisor de B ->
operador B).
2. Se crean “cotos de poder” e “islas ideológicas” que nada tienen que ver con la
satisfacción de las necesidades del cliente final. Algunos ejemplos: El director de
cierta área defiende a capa y espada sus privilegios y, en muchas ocasiones, más que
colaborador de otros directores es un enemigo de ellos, y ellos de él. La gente de
Finanzas sólo ve a la empresa desde su punto de vista (estados financieros, costos,
gastos, etc.) y no considera otras variables y otros puntos de vista como satisfacción
del cliente, clima laboral, etcétera.
Sin embargo, en la vida diaria de la organización lo que se tiene son procesos que fluyen
horizontalmente, atravesando los organigramas jerárquicos.

Es por ello que surge la administración por procesos, que percibe la organización como un
sistema interrelacionado de procesos que contribuyen conjuntamente a incrementar la
satisfacción del cliente. La administración por procesos coexiste con la administración
funcional, asignando “propietarios” a los procesos clave, haciendo posible una gestión
interfuncional generadora de valor para el cliente y que, por tanto, procura su satisfacción;
determina qué procesos necesitan ser mejorados o rediseñados, establece prioridades y
provee de un contexto para iniciar y mantener planes de mejora que permitan alcanzar
objetivos; y hace posible la comprensión del modo en que están configurados los procesos
de negocio, de sus fortalezas y de sus debilidades.

Así mismo da la forma en que la organización administra y mejora continuamente los

procesos de negocio para lograr sus objetivos y crear valor para sus accionistas, clientes y
colaboradores. Al final, lo que la administración de procesos intenta cambiar es: ir de una
organización orientada a productos (en la que existen procesos no coordinados ni
administrados), por una organización que administra sus procesos en ciclos de mejora
continua mediante el famoso ciclo de “plan-do-check-act” o PDCA, por sus siglas en
inglés.

Historia de ITIL

Pues bien, parece que ya es hora de entrar en materia. Empecemos como los clásicos con
una definición:

ITIL (IT Infrastructure Library, biblioteca de infraestructura de TI) = Marco de referencia

que describe un conjunto de mejores prácticas y recomendaciones para la administración de
servicios de TI, con un enfoque de administración de procesos.

¿Suena bien no? Pero para qué sirve y cómo se usa, eso es harina de otro costal y es lo que
trataré de explicar en esta serie de artículos, pero antes veamos un poco de sus
antecedentes: en 1987 la CCTA, un organismo del gobierno británico (ahora llamado la
OGC) inició un proyecto llamado GITIMM (Government IT Infrastructure Management
Method), en el cual involucraron a varias firmas de consultoría para investigar y
documentar las mejores prácticas para planear y operar la infraestructura de TI. Poco
después, conforme el proyecto evolucionaba de administración de infraestructura a
administración de servicios de TI, se le cambió el nombre a ITIL.

Como marco de referencia, ITIL se creó como un modelo para la administración de

servicios de TI e incluye información sobre las metas, las actividades generales, las
entradas y las salidas de los procesos que se pueden incorporar a las áreas de TI.

Desde sus inicios ITIL fue puesta a disposición del público en forma de un conjunto de
libros, de ahí su nombre, para que las organizaciones de todo el mundo pudieran adoptarlo.
La primera versión consistía de 10 libros principales que cubrían dos grandes temas:
“Soporte al servicio” y “Entrega del servicio”, amén de una serie de libros
complementarios que cubrían temas tan disímbolos como la administración de la
continuidad o cuestiones relacionadas con cableado. Posteriormente, en 2001 se hizo una
reestructura importante que reunió los 19 libros principales en sólo 2, mientras que otros
temas siguieron en libros separados, dando así un total de 7 libros para la segunda versión
de ITIL:

 Soporte al servicio (1).

 Entrega del servicio (2).
 Administración de la seguridad (3).
 Administración de la infraestructura ICT (4).
 Administración de las aplicaciones (5).
  La perspectiva del negocio (6).
 Planeación para implantar la administración de servicios (7).

Precisamente con la versión 2, a mediados de los años 90, ITIL fue reconocido como un
“estándar de facto” para la administración de servicios de TI, el cual, como siempre, tuvo
que seguir evolucionando para considerar las nuevas escuelas de pensamiento y alinearse
mejor a otros estándares, metodologías y mejores prácticas, lo que llevó en 2007 a la
liberación de la versión 3 de ITIL.

ITIL V3 sólo consta de cinco libros, que están estructurados en torno al ciclo de vida del
servicio:

 Estrategia de servicios.
 Diseño de servicios
 Transición de servicios.
 Operación de servicios.
 Mejora continua de servicios.

Esta nueva estructura organiza los procesos de ITIL V2 con contenido y procesos
adicionales encaminados a una mejor administración del periodo de vida de los servicios de
TI. Partiendo de esta observación, podemos afirmar que la V3 refuerza el foco en los
servicios de TI, sin dejar de lado los procesos, pero haciendo patente que aunque los
procesos son importantes son secundarios y sólo existen para planificar, entregar y dar
soporte a los servicios.

Recuadro 1. Definiendo “las mejores prácticas”

Aunque existen diversas definiciones, para efectos prácticos podemos decir que las
“mejores prácticas” son un conjunto de prácticas que alguien obtiene analizando y
estudiando qué hacen y qué no hacen los mejores exponentes de un tema en particular. La
idea es que al terminar el análisis se tendrá un conjunto de prácticas comunes a todos
aquellos que están a la vanguardia, y es precisamente ese conjunto el que se recopila y se
lanza como “las mejores prácticas” para un tema dado.

Así pues, las mejores prácticas no tienen un fundamento matemático o analítico puro,
simplemente son obtenidas del mundo real y representan lo que “parece ser lo mejor” hasta
el momento. Como tales, las mejores prácticas pueden cambiar con el transcurso del tiempo
y, lo que también es muy importante, ser muy cuidadoso al establecerlas para no llegar a
conclusiones erradas o ilógicas que lleven a unas “mejores prácticas” absurdas.
Recuadro 2. Certificaciones en ITIL

Dado que ITIL no es un estándar, es importante comprender que una empresa no puede
certificarse en ITIL. Lo más que puede obtenerse es una especie de diagnóstico en el que
alguna empresa de consultoría puede opinar que, desde su punto de vista, cierta
organización “está alineada” con ITIL. Las únicas certificaciones disponibles actualmente
son para personas, que de esta manera reciben un aval sobre sus conocimientos de parte de
los organismos que desarrollan ITIL.

En ITIL V2 existen tres niveles de certificación:

1. Foundations. Diseñada para asegurar el entendimiento de los principios, la

terminología y el contenido de los libros de Administración del servicio (Soporte de
servicios y Entrega de servicios).
2. Practitioner. Enfocada a aquellos responsables de diseñar e implantar los procesos
de Administración del servicio en una organización. Existen varias certificaciones,
de acuerdo a las diversas áreas cubiertas en la administración de servicios según
ITIL:
o 5 Practitioners de soporte de servicios (administración de cambios,
administración de configuraciones, administración de problemas,
administración de liberaciones, administración de incidentes y mesa de
ayuda).
o 5 Practitioners de entrega de servicios (administración de la disponibilidad,
administración de la capacidad, administración financiera de TI,
administración de la continuidad de servicios de TI, y administración de
niveles de servicio).
o 4 Practitioners combinados (mesa de ayuda, administración de incidentes y
de problemas -IPSR-, administración de cambios, configuración y
liberaciones -IPRC-, administración financiera y de niveles de servicio -
IPAD-, y administración de disponibilidad, de capacidad y de continuidad
de servicios de TI -IPPI-).
3. Service Manager. Destinada a consultores y administradores que deben tener
conocimientos profundos de todos los temas relacionados con la administración de
servicios de TI de acuerdo a ITIL V2.

Por su parte, ITIL V3 considera cuatro niveles de certificación:

1. Foundations. Asegura el entendimiento de los principios, la terminología y el

contenido de los procesos y funciones considerados en ITIL V3.
2. Nivel intermedio. Diseñada para reforzar las habilidades para analizar y aplicar los
conceptos de ITIL. Es análoga a la certificación Practitioner de V2, por lo que
existen varias opciones:
o 5 de ciclo de vida de los servicios (estrategia de servicios, diseño de
servicios, transición de servicios, operación de servicios y mejora continua
de servicios).
o 4 de Capacidad (Soporte y análisis operacional -OS&A-, oferta y acuerdos
de servicios -SO&A-, liberación, control y validación -RC&V- y planeación,
protección y optimización -PP&O-).
3. ITIL Expert. Destinada a aquellos que requieren consolidar el conocimiento
obtenido en los niveles de certificación anteriores.
4. ITIL Master. Es el nivel máximo de certificación en V3 y se enfoca en asegurar la
habilidad para analizar y aplicar los conceptos de ITIL en nuevas áreas. Aún está en
desarrollo.

5. La adopción de un marco de referencia por parte de los departamentos de Sistemas

de Información, mejora la eficiencia y eficacia de los mismos, gracias a la
aplicación de procesos estandarizados y probados por multitud de empresas de
todos los sectores, y la aplicación de metodologías y buenas prácticas.
6. ITIL (Information Technology Infraestructure Library) es uno de los marcos de
referencia para la Gestión de Servicios Informáticos, más importantes y con mayor
repercusión a nivel mundial, creado en los años 80 por el Gobierno Británico, con la
intención de mejorar la calidad de los servicios de IT.
7. Algunos piensan que ITIL es una moda, o burocracia añadida para obtener
beneficios por parte de las empresas consultoras, sin embargo cada vez son más las
empresas que se basan en ITIL para mejorar la gestión de sus departamentos de
sistemas.
8. ITIL lo constituye una colección de libros que aportan una serie de
recomendaciones y buenas prácticas, para la correcta gestión de los departamentos
de IT, especificando procesos y procedimientos para ello. No habla de cómo
implantarlo, ni de software para gestión o hardware que se deba utilizar.

9.
10. De forma coloquial podríamos decir que ITIL propone una forma de trabajar más
ordenada y dirigida a servir a negocio. De forma rigurosa, se trata del conjunto de
mejores prácticas para le gestión de los procesos que son usados para el ciclo de
vida del servicio:
11. – Estrategia del Servicio.
– Diseño del Servicio.
– Transición del Servicio.
– Operación del Servicio.
– Mejora Continua del Servicio.
12. La decisión de adoptar un marco de referencia para la gestión del departamento de
sistemas, ya sea ITIL o cualquier otro, está en manos de cada empresa o Manager de
Sistemas, y el éxito de una implantación de este tipo dependerá sobre todo de una
buena gestión del proyecto de implementación.
13. Bueno, me temo que la Gestión de Proyectos es otro tema fundamental que pronto
habrá que abordar… Saludos.
 COBOL

El COBIT es precisamente un modelo para auditar la gestión y control de los sistemas de

información y tecnología, orientado a todos los sectores de una organización, es decir,
administradores IT, usuarios y por supuesto, los auditores involucrados en el proceso. El
COBIT es un modelo de evaluación y monitoreo que enfatiza en el control de negocios y
la seguridad IT y que abarca controles específicos de IT desde una perspectiva de negocios.
Las siglas COBIT significan Objetivos de Control para Tecnología de Información y
Tecnologías relacionadas (Control Objectives for Information Systems and related
Technology). El modelo es el resultado de una investigación con expertos de varios países,
desarrollado por ISACA (Information Systems Audit and Control Association).
COBIT, lanzado en 1996, es una herramienta de gobierno de TI que ha cambiado la forma
en que trabajan los profesionales de tecnología. Vinculando tecnología informática y
prácticas de control, el modelo COBIT consolida y armoniza estándares de fuentes globales
prominentes en un recurso crítico para la gerencia, los profesionales de control y los
auditores.
COBIT se aplica a los sistemas de información de toda la empresa, incluyendo los
computadores personales y las redes. Está basado en la filosofía de que los recursos TI
necesitan ser administrados por un conjunto de procesos naturalmente agrupados para
proveer la información pertinente y confiable que requiere una organización para lograr sus
objetivos.
Misión del COBIT
Buscar, desarrollar, publicar y promover un autoritario y actualizado conjunto internacional
de objetivos de control de tecnologías de la información, generalmente aceptadas, para el
uso diario por parte de gestores de negocio y auditores.
BENEFICIOS COBIT
 Mejor alineación basado en una focalización sobre el negocio.
 Visión comprensible de TI para su administración.
 Clara definición de propiedad y responsabilidades.
 Aceptabilidad general con terceros y entes reguladores.
 Entendimiento compartido entre todos los interesados basados en un lenguaje común.
 Cumplimiento global de los requerimientos de TI planteados en el Marco de Control
Interno de Negocio COSO.
Estructura
La estructura del modelo COBIT propone un marco de acción donde se evalúan los
criterios de información, como por ejemplo la seguridad y calidad, se auditan los recursos
que comprenden la tecnología de información, como por ejemplo el recurso humano,
instalaciones, sistemas, entre otros, y finalmente se realiza una evaluación sobre los
procesos involucrados en la organización.
 "La adecuada implementación de un modelo COBIT en una organización, provee una
herramienta automatizada, para evaluar de manera ágil y consistente el cumplimiento de los
objetivos de control y controles detallados, que aseguran que los procesos y recursos de
información y tecnología contribuyen al logro de los objetivos del negocio en
un mercado cada vez más exigente, complejo y diversificado.
Dominios COBIT

El conjunto de lineamientos y estándares internacionales conocidos como COBIT, define

un marco de referencia que clasifica los procesos de las unidades de tecnología de
información de las organizaciones en cuatro "dominios" principales, a saber:
 PLANIFICACION Y ORGANIZACION: Este dominio cubre la estrategia y las tácticas y
se refiere a la identificación de la forma en que la tecnología de información puede
contribuir de la mejor manera al logro de los objetivos del negocio. Además, la consecución
de la visión estratégica necesita ser planeada, comunicada y administrada desde diferentes
perspectivas. Finalmente, deberán establecerse una organización y una infraestructura
tecnológica apropiadas.
 ADQUISION E IMPLANTACION: Para llevar a cabo la estrategia de TI, las soluciones de
TI deben ser identificadas, desarrolladas o adquiridas, así como implementadas e integradas
dentro del proceso del negocio. Además, este dominio cubre los cambios y
el mantenimiento realizados a sistemas existentes.
 SOPORTE Y SERVICIOS: En este dominio se hace referencia a la entrega de los servicios
requeridos, que abarca desde las operaciones tradicionales hasta el entrenamiento, pasando
por seguridad y aspectos de continuidad. Con el fin de proveer servicios, deberán
establecerse los procesos de soporte necesarios. Este dominio incluye el procesamiento de
los datos por sistemas de aplicación, frecuentemente clasificados como controles de
aplicación.
 MONITOREO: Todos los procesos necesitan ser evaluados regularmente a través
del tiempo para verificar su calidad y suficiencia en cuanto a los requerimientos de control.
 Estos dominios agrupan objetivos de control de alto nivel, que cubren tanto los aspectos de
información, como de la tecnología que la respalda. Estos dominios y objetivos de control
facilitan que la generación y procesamiento de la información cumplan con las
características de efectividad, eficiencia, confidencialidad, integridad, disponibilidad,
cumplimiento y confiabilidad.
Usuarios
 La Gerencia: Para apoyar sus decisiones de inversión en TI y control sobre el rendimiento
de las mismas, analizar el costo beneficio del control.
 Los Usuarios Finales: Quienes obtienen una garantía sobre la seguridad y el control de
los productos que adquieren interna y externamente.
 Los Auditores: Para soportar sus opiniones sobre los controles de los proyectos de TI, su
impacto en la organización y determinar el control mínimo requerido.
 Los Responsables de TI: Para identificar los controles que requieren en sus áreas.
También puede ser utilizado dentro de las empresas por el responsable de un proceso de
negocio en su responsabilidad de controlar los aspectos de información del proceso, y por
todos aquellos con responsabilidades en el campo de la TI en las empresas.
Características
 Orientado al negocio.
 Alineado con estándares y regulaciones "de facto".
 Basado en una revisión crítica y analítica de las tareas y actividades en TI.
 Alineado con estándares de control y auditoria (COSO, IFAC, IIA, ISACA, AICPA).
PRINCIPIOS:
El enfoque del control en TI se lleva a cabo visualizando la información necesaria para dar
soporte a los procesos de negocio y considerando a la información como el resultado de la
aplicación combinada de recursos relacionados con las TI que deben ser administrados por
procesos de TI.
 Requerimientos de la información del negocio: Para alcanzar los requerimientos de
negocio, la información necesita satisfacer ciertos CRITERIOS:
 Requerimientos de Calidad: Calidad, Costo y Entrega.
 Requerimientos Fiduciarios: Efectividad y Eficiencia operacional, Confiabilidad de los
reportes financieros y Cumplimiento le leyes y regulaciones.
 Requerimientos de Seguridad: Confidencialidad, Integridad y Disponibilidad.

En COBIT se establecen los siguientes recursos en TI necesarios para alcanzar los objetivos
de negocio:
 Niveles COBIT
Se divide en 3 niveles, los cuales son los siguientes:
 Dominios: Agrupación natural de procesos, normalmente corresponden a un dominio o una
responsabilidad organizacional.
 Procesos: Conjuntos o series de actividades unidas con delimitación o cortes de control.
 Actividades: Acciones requeridas para lograr un resultado medible.
COMPONENTES COBIT
 Resumen Ejecutivo: Es un documento dirigido a la alta gerencia presentando los
antecedentes y la estructura básica de COBIT Además, describe de manera general los
procesos, los recursos y los criterios de información, los cuales conforman la "Columna
Vertebral" de COBIT.
 Marco de Referencia (Framework): Incluye la introducción contenida en el resumen
ejecutivo y presenta las guías de navegación para que los lectores se orienten en la
exploración del material de COBIT haciendo una presentación detallada de los 34 procesos
contenidos en los cuatro dominios.
 Objetivos de Control: Integran en su contenido lo expuesto tanto en el resumen ejecutivo
como en el marco de referencia y presenta los objetivos de control detallados para cada uno
de los 34 procesos.
 PLANEAR Y ORGANIZAR
PO1 Definir el plan estratégico de TI.
PO2 Definir la arquitectura de la información
PO3 Determinar la dirección tecnológica.
PO4 Definir procesos, organización y relaciones de TI.
PO5 Administrar la inversión en TI.
PO6 Comunicar las aspiraciones y la dirección de la gerencia.
 PO7 Administrar recursos humanos de TI.
PO8 Administrar calidad.
PO9 Evaluar y administrar riesgos de TI
PO10 Administrar proyectos.
PO11Administración de Calidad
 ADQUIRIR E IMPLANTAR
AI1 Identificar soluciones automatizadas.
AI2 Adquirir y mantener el software aplicativo.
AI3 Adquirir y mantener la infraestructura tecnológica
AI4 Facilitar la operación y el uso.
AI5 Adquirir recursos de TI.
AI6 Administrar cambios.
 MONITOREAR Y EVALUAR
ME1 Monitorear y evaluar el desempeño de TI.
ME2 Monitorear y evaluar el control interno
ME3 Garantizar cumplimiento regulatorio.
ME4 Proporcionar gobierno de TI.
 PRESTACIÓN Y SOPORTE
DS1 Definir y administrar niveles de servicio.
DS2 Administrar servicios de terceros.
DS3 Administrar desempeño y capacidad.
DS4 Garantizar la continuidad del servicio.
DS5 Garantizar la seguridad de los sistemas.
DS6 Identificar y asignar costos.
DS7 Educar y entrenar a los usuarios.
DS8 Administrar la mesa de servicio y los incidentes.
DS9 Administrar la configuración.
DS10 Administrar los problemas.
DS11 Administrar los datos.
DS12 Administrar el ambiente físico.
DS13 Administrar las operaciones.
Quiénes han adoptado el COBIT
Advirtiendo la necesidad de contar con un adecuado marco de referencia para el gobierno
de los sistemas de información y las tecnologías relacionadas, muchas organizaciones en el
ámbito nacional e internacional ya han adoptado el COBIT como una de las mejores
prácticas. Sin intención de ser exhaustivo, sólo mencionaré las que desde hace tiempo lo
vienen haciendo: Gobierno de la Provincia de Mendoza; Superintendencia de
Administradoras de Fondos de Jubilaciones y Pensiones; Superintendencia de Entidades
Financieras y Cambiarias; la Reserva Federal de los Estados Unidos de América; Daimler-
Chrysler en Alemania y los EE.UU., entre otras.
Conclusiones
Si bien COBIT es un marco general, su flexibilidad y versatilidad nos permite adaptarlo a
cualquier tipo y tamaño de empresa, realizando una implementación gradual y progresiva
acorde a los recursos disponibles y acompasando la estrategia empresarial.
Si bien aún no es requerido formalmente en forma regulatoria, es un estándar de facto en
toda Latinoamérica y es una fuerte recomendación en los ámbitos financieros.Es parte de
la misión de ISACA, la divulgación de COBIT y apoyo en la implementación como forma
de promover la eficiencia y buena gestión de los procesos de tecnología que nos permita
compararnos y mejorar día a día en pos de la concreción de los Objetivos de Negocio.En el
futuro, continuaremos viendo el crecimiento de COBIT en sus facetas de administración y
dirección de los recursos de tecnología. Aparecerán nuevas herramientas de la familia de
productos COBIT y nuevos recursos con los cuales mejorar la administración. Se
continuará refinando el producto en sí, mejorando la calidad de sus referencias cruzadas, su
relacionamiento con otros modelos, estándares y normas. Se procurará institucionalizar y
mejorar la calidad de las versiones en otras lenguas y, sin duda, continuará el esfuerzo
fundamental del ITGI en la difusión del uso de esta importante base de dirección.