Catedra 1auditoria

TEMARIO CATEDRA I
Lectura 1
1.5 Controles Internos
Cobit 4.1
AI6 Administrar Cambios
ISO 27002
11. Control de Acceso
Lectura 2
2.11 Estructura Organizativa y responsabilidades de SI
2.11.2 Segregacin de funciones dentro de SI
2.13 Planeacin de Continuidad del Negocio (BCP)

PRINCIPALMENTE LO DESTACADO EN AMARILLO
Seccin Dos: Contenido
Captulo 1 - Proceso de Auditora de
Sistemas de Informacin
e
. Certified lnformation
M Systems Auditor'
Luego, durante la etapa de mitigacin de riesgos, se identifican
los controles para mitigar los riesgos identificados. Estos controles
son contramedidas para la mitigacin de riesgos que buscan
prevenir o reducir la probabilidad de que ocurra un evento de
riesgo, detectar la ocurrencia del mismo, minimizar el impacto
o transferir el riesgo a otra organizacin.
La evaluacin de contramedidas debera realizarse mediante
un anlisis costo-beneficio, en el que los controles para mitigar
riesgos se seleccionan de manera que se logre reducir los riesgos
hasta un nivel aceptable para la gerencia. Este proceso de anlisis
puede basarse en cualquiera de las siguientes opciones:
El costo del control comparado con el beneficio de minimizar
el riesgo
La tolerancia a riesgos de la gerencia (por ejemplo, el nivel
de riesgo residual que la gerencia est preparada para aceptar)
Mtodos preferidos de reduccin de riesgos (por ejemplo,
eliminar el riesgo, minimizar la probabilidad de ocurrencia,
minimizar el impacto, transferir el riesgo a travs del seguro)
La etapa final se relaciona con el monitoreo de los niveles de
desempeo de los riesgos gestionados cuando se identifiquen
cambios significativos en el ambiente, que daran lugar a una
nueva evaluacin de riesgos, con lo que se garantizan cambios
a su ambiente de control. Ello abarca tres procesosevaluacin
de riesgos, mitigacin de riesgos y reevaluacin de riesgos-
para determinar si los riesgos se estn mitigando hasta un
nivel aceptable para la gerencia. Se debe notar que, para ser
efectiva, la evaluacin de riesgos debe ser un proceso continuo
en una organizacin que se esfuerza por identificar y evaluar
constantemente los riesgos a medida que stos surgen y
evolucionan. Consulte la figura 1.3 para obtener un resumen
del proceso de evaluacin de riesgos.
Figura 1.3-Resumen de Proceso de Evaluacin de Riesgos
.. Identificar objetivos
"'
del negocio (80)

Identificar activos de
informacin que respalden
los 80

Realizar reevaluaciones de
Realizar evaluacin de
riesgos peridicas
riesgos (RA) [Amenaza-+
(80/RA/RM/Rn
Vulnerabilidad -+ Probabilidad
-+Impacto]

Realizar mitigacin de
riegos (RM) [Correlacionar
riesgos con controles
implementados]
...
Realizar tratamiento de
riesgos (Rn [Tratar riesgos
significativos no mitigados por
controles existentes]
50
AniSACA"CirtilkatJon
Desde la perspectiva del auditor de SI, el anlisis de riesgos tiene
ms de un propsito:
Apoya al auditor de SI en la identificacin de riesgos y
amenazas para un ambiente de TI y los sistemas de SI, que debe
tratar la gerencia, y en la identificacin de los controles internos
especficos del sistema. Dependiendo del nivel de riesgo, este
anlisis apoya al auditor de SI en la seleccin de ciertas reas
para examinar.
Ayuda al auditor de SI en su evaluacin de los controles durante
la planificacin de la auditora.
Apoya al auditor de SI a determinar los objetivos de la auditora.
Respalda la toma de decisiones de la auditora basada en riesgos.
1.5 CONTROLES INTERNOS
Los controles internos estn normalmente constituidos por
polticas, procedimientos, prcticas y estructuras organizacionales
implementadas para reducir los riesgos para la organizacin.
Los controles internos son desarrollados para proveer una certeza
razonable a la gerencia de que se alcanzarn los objetivos de
negocio de la organizacin y de que se prevendrn o detectarn y
corregirn los eventos de riesgo. Las actividades de control interno
y los procesos que las respaldan pueden ser manuales o manejados
por recursos de informacin automatizados. Los controles internos
operan en todos los niveles dentro de una organizacin para mitigar
su exposicin a riesgos que potencialmente podran impedirle
alcanzar sus objetivos de negocio. El consejo de direccin y la
alta direccin son responsables de establecer la cultura apropiada
para facilitar un sistema efectivo y eficiente de control interno y
de monitorear continuamente la efectividad del sistema de control
interno, aunque toda persona dentro de una organizacin debe
participar en este proceso.
Existen dos aspectos clave que los controles deben atender: qu
debera lograrse y qu debera evitarse. Los controles internos no
slo tratan los objetivos de negocio/operativos, sino que tambin
deberan estar preparados para tratar eventos no deseados a travs
de la prevencin, deteccin y correccin.
Los elementos de control que se deberan considerar al evaluar
la fortaleza de un control, estn clasificados como preventivos,
detectivos o correctivos de acuerdo a su naturaleza .
La figura 1.4 muestra las categoras de control, funciones y usos.
Nota: Un candidato a CISA debe conocer las diferencias
entre los controles correctivos, preventivos y de deteccin.
Un ejemplo de una pregunta en el examen sera: Cul de los
siguientes controles detectara MEJOR ...
Manual de Preparacin al Examen CISA 2012
ISACA. Todos los derechos reservados.
e
. Certifled lnlormaUoo
Systems Auditor'
Sistemas de Informacin Seccin Dos: Contenido
AniSACKCertlllcatlo!l
Figura 1.4-Ciasificaciones de control
Clase Funcin
Preventivos Detectan los problemas antes de que aparezcan.
Monitorean tanto la operacin como las entradas.
Intentan predecir los problemas potenciales antes de que
ocurran y realizan ajustes.
Evitan que ocurra un error, omisin o acto malicioso.
Detectivos Utilizan controles que detectan e informan la ocurrencia de
un error, omisin o acto fraudulento.
Correctivo Minimizar el impacto de una amenaza.
Remediar problemas descubiertos por controles detectivos.
Identificar la causa de un problema.
Corregir errores que surgen de un problema.
Modificar los sistemas de procesamiento para minimizar
futuras ocurrencias del problema.
1.5.1 OBJETIVOS DEL CONTROL INTERNO
Los objetivos de control interno son declaraciones del resultado
deseado o del propsito a ser alcanzado con la implementacin
deactividades de control (procedimientos).
Por ejemplo, los objetivos de control incluyen:
Salvaguarda de los activos de TI
Cumplimiento con las polticas corporativas y los
requerimientos legales
Autorizacin y autenticacin
Confidencialidad
Exactitud e integridad de datos
Confiabilidad de proceso
Disponibilidad de los servicios de TI
Eficiencia y economa de las operaciones
1.5.2 OBJETIVOS DE CONTROL DE SI
Los objetivos de control interno se aplican a todas las reas,
ya sean manuales, automatizadas, o una combinacin de las
mismas (es decir, revisiones de registros (logs)). Por lo tanto,
conceptualmente, los objetivos de control en un ambiente de SI
permanecen sin cambios respecto de los de un ambiente manual.
Sin embargo, la manera como se implementan estos controles
pudiera ser diferente. Por lo tanto, los objetivos de control interno
se deben tratar de forma relevante para los procesos especficos
relacionados con SI.
Los objetivos de control de SI pueden incluir:
La salvaguardia de activos. La informacin en los sistemas
automatizados est protegida contra accesos inadecuados y
se la mantiene actualizada.
Ejemplos
Emplean slo personal calificado.
Segregan funciones (factor disuasivo).
Controlan el acceso a instalaciones fsicas.
Utilizan documentos bien diseados (evita errores).
Establecen procedimientos adecuados para la autorizacin
de transacciones.
Completan verificaciones de edicin programadas.
Utilizan software de control de acceso que permita que slo
el personal autorizado tenga acceso a archivos sensibles.
Utilizan software de encriptacin para evitar la divulgacin
no autorizada de datos.
Totales de comprobacin (hash totals)
Puntos de verificacin en trabajos de produccin
Controles de eco en telecomunicaciones
Mensajes de error en etiquetas de cintas
Verificacin duplicada de clculos
Reporte de rendimiento peridico con variaciones
Informes de cuentas vencidas
Funciones de auditora interna
Revisin de registros (logs) de actividad para detectar intentos
de acceso no autorizado
Planificacin de contingencia
Procedimientos de respaldo
Procedimientos de nueva ejecucin
Asegurar la integridad de los ambientes de sistemas operativos
en general, incluyendo las operaciones y gestin de la red.
Asegurar la integridad de los ambientes de sistemas de
aplicacin sensibles y crticos, incluyendo informacin
contable/financiera y de gestin (objetivos de informacin)
y de los datos del cliente a travs de:
-Autorizacin para el ingreso de datos. Cada transaccin
es autorizada e introducida una sola vez.
- Validacin de la entrada de datos. Cada dato ingresado es
validado y no causar impacto negativo al procesamiento
de las transacciones.
- Exactitud e integridad del procesamiento de transacciones.
Todas las transacciones son registradas e ingresadas en la
computadora en el perodo correcto.
- Confiabilidad de las actividades de procesamiento de
informacin en general
- Exactitud, integridad y seguridad de la informacin de salida
- Integridad, disponibilidad y confidencialidad de la base
de datos
Asegurar la identificacin y autenticacin apropiada de los
usuarios de los recursos de SI (usuarios finales as como
tambin soporte de infraestructura).
Aseguramiento de la eficiencia y efectividad de las operaciones
(objetivos operativos).
Cumplimiento con los requerimientos de los usuarios, con
las polticas y los procedimientos organizacionales, as como
con las leyes y reglamentaciones aplicables (objetivos de
cumplimiento).
Aseguramiento de la disponibilidad de los servicios de TI
desarrollando planes de continuidad del negocio (BCP) y
de recuperacin de desastres (DRP).
51
Sistemas de Informacin
e Certified lnformation
o ~ ~ : : : ~ ~ i t o r
Mejora de la proteccin de datos y sistemas desarrollando
un plan de respuesta a incidentes.
Aseguramiento de la integridad y confiabilidad de los sistemas
implementando procedimientos efectivos de gestin de cambios.
!SACA publica un marco de gobierno y control de TI que
incorpora buenas prcticas de gestin de TI -COBIT es el
marco principal para el gobierno, el control y el aseguramiento de
la informacin y la tecnologa relacionada.
1.5.3 COBIT
COBIT respalda el gobierno y la gestin de TI dando un marco
para asegurar que la tecnologa de la informacin {TI) est
alineada con el negocio, que TI habilita el negocio y maximiza los
beneficios, que los recursos de TI se usan de forma responsable
y que los riesgos de TI se gestionan adecuadamente. COBIT
provee buenas prcticas a travs de un dominio y marco de
proceso y presenta actividades en una estructura manejable y
lgica. Las buenas prcticas de COBIT representan el consenso
de los expertos. COBIT tiene un marco general con un conjunto
de 34 procesos de TI agrupados en cuatro dominios: Planeacin
y organizacin, adquisicin e implementacin, entrega y soporte,
y monitoreo y evaluacin. Adaptando y usando estas prcticas
de los 34 procesos relevantes de TI, las organizaciones pueden
garantizar que han implementado un sistema de gobierno de TI y
controles relacionados segn sea necesario para su entorno de TI.
Como soporte a estos procesos de TI, hay ms de 200 objetivos
de control que son necesarios para una implementacin efectiva.
El componente de los objetivos de control de COBIT proporciona
un marco de referencia sobre que controles deben estar instalados,
mientras que el documento Prcticas de Control de COBJT": Gua
para lograr los Objetivos de Control para Gobierno Exitoso de JT
facilita la implementacin de estos controles.
Las buenas prcticas de COBIT estn ms fuertemente centradas
en el control, menos en la ejecucin. Estas prcticas ayudarn a
optimizar las inversiones habilitadas por TI, asegurar la entrega de
servicio y proveer una medida contra la cual comparar cuando las
cosas salen mal.
Para que TI tenga xito en la entrega de los requerimientos del
negocio, la gerencia debe implementar un marco o un sistema de
control interno. El marco de control COBIT contribuye a estas
necesidades:
Creando un enlace con los requerimientos del negocio
Organizando las actividades de TI en un modelo de proceso
generalmente aceptado
Identificando los principales recursos de TI que se aprovecharn
Definiendo los objetivos de control de gestin a ser
considerados
La orientacin al negocio de COBIT consiste en vincular metas
de negocio con las metas de TI, proveer mtricas y modelos de
madurez para medir su logro, e identificar las responsabilidades
del negocio asociadas y los propietarios de los procesos de TI.
En resumen, para proveer la informacin que necesita la empresa
para lograr sus objetivos, los recursos de TI necesitan ser
gestionados por un conjunto de procesos agrupados naturalmente.
52
COBIT provee un marco integral para la gestin y entrega
de servicios de alta calidad basados en TI. COBIT establece
buenas prcticas para los procesos de creacin de valor. Val IT
agrega buenas prcticas para medir, monitorear y optimizar
sin ambigedad la realizacin de valor de negocio a partir
de inversin en TI. Val IT complementa COBIT desde una
perspectiva de negocio y financiera y ayuda a aquellos que tienen
inters en la entrega de valor de TI. Risk IT es un conjunto de
prcticas probadas en casos reales que ayudan a las empresas a
lograr sus metas, aprovechar las oportunidades y buscar un mayor
retorno con menor riesgo. Ampla COBIT proporcionando a las
empresas un mtodo para centrarse de forma efectiva en las reas
de riesgos del negocio relacionadas con TI. El marco de Val TI
presenta prcticas clave de gestin para tres procesos: gobierno
de valor, gestin de portafolio y gestin de inversin.
Nota: No se solicitar a un candidato a CISA que identifique
de forma especfica el proceso COBIT, los dominios COBIT
ni el conjunto de procesos de TI definido en cada uno.
Sin embargo, los candidatos deben saber qu es un marco
general, qu hace y por qu se usa en las empresas. El
conocimiento de la existencia, estructura y principios clave de
los estndares ms importantes y marcos relacionados con el
gobierno, el aseguramiento y la seguridad de TI ser tambin
ventajoso. COBIT se puede usar como material de estudio
complementario para comprender los objetivos y principios
de control que estn detallados en este material de repaso.
Consulte el apndice A o las referencias entre las reas de
certificacin CISA y el marco COBIT.
1.5.4 CONTROLES GENERALES
Los controles incluyen polticas, procedimientos y prcticas
(tareas y actividades) que son establecidos por la gerencia para
proveer una certeza razonable de que se alcanzarn objetivos
especficos.
Los controles generales son aplicables a todas las reas de la
organizacin, incluyendo infraestructura y servicios de soporte
de TI. Los controles generales incluyen:
Controles internos de contabilidad que estn principalmente
dirigidos a las operaciones de contabilidad. Ellos se refieren a
la salvaguarda de activos y a la confiabilidad de los registros
financieros
Controles operativos que se ocupan de las operaciones,
funciones y actividades cotidianas y aseguran que la operacin
est cumpliendo los objetivos del negocio
Controles administrativos relacionados con la eficiencia
operacional en un rea funcional y la adhesin a las polticas
de gestin (los controles administrativos que respaldan
los controles operacionales relacionados especficamente
con la eficiencia operacional y la adhesin a polticas
organizacionales)
Polticas y procedimientos organizacionales de seguridad
para asegurar el uso apropiado de activos de informacin
y tecnologa
Polticas generales para el diseo y uso de documentos y
registros (manuales/automatizados) adecuados para ayudar a
asegurar el registro apropiado de las transacciones-pista de
auditora de transacciones
e
. Certified lnformalion
M Systems Auctnor
Sistemas de Informacin Seccin Dos: Contenido
Mls.\CA"c.rtitlcatloll
Procedimientos y prcticas para asegurar la proteccin
adecuada en el acceso y el uso de activos e instalaciones
Polticas de seguridad fisica y lgica para todos los centros
de datos y recursos de TI (por ejemplo, servidores e
infraestructura de telecomunicaciones)
1.5.5 CONTROLES DE SI
Cada control general puede ser traducido a un control especfico
de SI. Un sistema de informacin bien diseado debera contar
con controles construidos en el mismo para todas sus funciones
sensitivas o criticas. Por ejemplo, el procedimiento general
para asegurar la adecuada custodia del acceso a los activos e
instalaciones puede traducirse en un conjunto de procedimientos
de control relacionado con sistemas de informacin, que
abarque controles de acceso a los programas de computacin,
datos y equipos informticos. El auditor de SI debera entender
los objetivos bsicos de control que existen para todas las
funciones. Los procedimientos de control de SI incluyen:
Estrategia y direccin
Organizacin general y gestin
Acceso a los recursos de TI , incluyendo datos y programas
Metodologas de desarrollo de sistemas y control de cambios
Procedimientos de operaciones
Programacin de sistemas y funciones de soporte tcnico
Procedimientos de aseguramiento de calidad (QA)
Controles de acceso fisico
Pl anificacin de continuidad del negocio (BCP)/recuperacin
en caso de desastre (DRP)
Redes y comunicaciones
Administracin de la base de datos
Proteccin y mecanismos de deteccin contra ataques internos
y externos
El auditor de SI debe entender los conceptos relacionados con
los controles de SI y cmo aplicarlos en la planificacin de
una auditora.
Nota: Los controles de SI enumerados en esta seccin deben
ser considerados por el candidato a CISA dentro del rea de
prctica de trabajo relacionado; es decir, Proteccin de los
Activos de Informacin.
1.6 REALIZACIN DE UNA AUDITORA DE SI
Para realizar una auditora, se requieren varios pasos. Una
planificacin adecuada es el primer paso necesario para realizar
auditoras de SI efectivas. Para usar efectivamente los recursos
de auditora de SI, las organizaciones de auditora deben evaluar
todos los riesgos de las reas generales y de aplicacin y
servicios relacionados a auditar y luego desarrollar un programa
de auditora que comprenda objetivos y procedimientos de
auditora que satisfagan los objetivos de la auditora. El proceso
de auditora requiere que el auditor de SI recolecte evidencia,
evale las fortalezas y debilidades de los controles basndose en
la evidencia reunida a travs de pruebas de auditora, y prepare
un informe de auditora que presente a la gerencia en una forma
objetiva dichos asuntos (debilidades de las reas de control con
recomendaciones para su solucin).
La gerencia de auditora debe asegurarse de que haya disponibilidad
de recursos de auditora adecuados y una agenda para llevar a
cabo las auditoras y, en el caso de una auditora interna de SI, para
realizar revisiones de seguimiento respecto al avance de las acciones
correctivas emprendidas por la gerencia. El proceso de auditora
incluye la defmicin del alcance de la auditora, la formulacin de
los objetivos de la auditora, la realizacin de los procedimientos
de auditora, la revisin y evaluacin de la evidencia, la elaboracin
de conclusiones y opiniones, y el reporte a la gerencia despus de
discusin con los dueos clave del proceso.
Las tcnicas de gestin de proyectos para gestionar y administrar
proyectos de auditora, ya sea automatizados o manuales, incluyen
los siguientes pasos bsicos:
Desarrollar un plan detallado--El plan debe distribuir los
pasos de auditora necesarios en toda la lnea de tiempo. Se
deben hacer estimados realistas de los requerimientos de tiempo
para cada tarea con la debida consideracin a la disponibilidad
del auditado.
Informar la actividad del proyecto respecto al plan-Debera
haber algn tipo de sistema de reporte instalado de modo que
los auditores de SI puedan reportar su progreso real con respecto
a los pasos planificados de auditora.
Ajustar el plan y tomar medidas correctivas-Se deberan
comparar los logros reales con el plan establecido de manera
continua. Se deberan hacer cambios en las asignaciones del
auditor de SI o en los cronogramas planificados, a medida que
se requiera.
1.6.1 CLASIFICACIN DE LAS AUDITORAS
El auditor de SI debera entender los diversos tipos de
auditoras que pueden efectuarse interna o externamente, y los
procedimientos de auditora asociados con cada uno de ellos:
Auditoras financieras-El propsito de una auditora
financiera es determinar la exactitud de los estados financieros
de una organizacin. Una auditora financiera a menudo
implicar pruebas sustantivas detalladas, aunque cada vez ms,
los auditores estn poniendo ms nfasis en un enfoque de
auditora basado en riesgo y control. Este tipo de auditora se
relaciona con la integridad y confiabilidad de la informacin
financiera.
Auditoras Operativas- Una auditora operativa est diseada
para evaluar la estructura del control interno en un proceso o
rea determinada. Las auditoras de SI sobre controles de las
aplicaciones o de sistemas de seguridad lgica son algunos
ejemplos de auditoras operativas.
Auditoras integradas-Una auditora integrada combina
pasos de auditora financiera y operativa. Tambin se realiza
para evaluar los objetivos generales dentro de una organizacin,
relacionados con la informacin financiera y la salvaguarda de
activos, la eficiencia y el cumplimiento. Una auditora integrada
puede ser ejecutada por auditores externos o internos e incluira
pruebas de cumplimiento a los controles internos y los pasos de
auditora sustantiva.
Auditoras administrativas-Estas estn orientadas a evaluar
aspectos relacionados con la eficiencia de la productividad
operativa dentro de una organizacin.
53
Adquirir e Implementar
Administrar Cambios
AI6
2007 IT Governance Institute. All rights reserved. www.itgi.org
93

DE .
mantenimiento de emergencia y parches, relacionados con la infraestructura y las aplicaciones
ientos,
mplantacin. Esto garantiza la reduccin de riesgos que impactan negativamente la estabilidad
dministrar cambios
Que satisface el requerimiento del negocio de TI para
Responder a los requerimientos del negocio de acuerdo con la estrategia de negocio, mientras se reducen los defectos y la
repeticin de trabajos en la prestacin del servicio y en la solucin.
Enfocndose en
Controlar la evaluacin de impacto, autorizacin e implantacin de todos los cambios a la infraestructura de TI,
aplicaciones y soluciones tcnicas, minimizando errores que se deben a especificaciones incompletas de la
solicitud y detener la implantacin de cambios no autorizados
Se logra con
La definicin y comunicacin de los procedimientos de cambio, que incluyen cambios de emergencia
La evaluacin, la asignacin de prioridad y autorizacin de cambios
Seguimiento del estatus y reporte de los cambios
Y se mide con
El nmero de interrupciones o errores de datos provocados por especificaciones inexactas o
una evaluacin de impacto incompleta
La repeticin de aplicaciones o infraestructura debida a especificaciones de cambio
inadecuadas
El porcentaje de cambios que siguen procesos de control de cambio formales

SCRIPCIN DEL PROCESO
Todos los cambios, incluyendo el
dentro del ambiente de produccin, deben administrarse formalmente y controladamente. Los cambios (incluyendo procedim
procesos, sistema y parmetros del servicio) se deben registrar, evaluar y autorizar previo a la implantacin y revisar contra los
resultados planeados despus de la i
o integridad del ambiente de produccin.

Planear y
Organizar
Adquirir e

Implementar

Entregar y Dar
Soporte

Control sobre el proceso TI de
Monitorear y
Evaluar
A
AI6
Administrar Cambios

OBJETIVOS DE CONTROL
94
AI6.1 Est Procedimientos para Cambios
E ece tracin de cambio for es r todas l ici ncluyend
mantenim bios a aplicaciones, pro armetros de sistema y servicio, y las
p m
A Ev torizacin
Garantiza as las solicitudes de cambio se evalan de una estructurada manera en cuanto a impactos en el sistema
o on ta evaluacin deber incl tegorizacin y priorizacin de los cambios. Previo a la migracin hacia
ci spondientes autorizan los cambios.
AI6.3 Cambios de Emergencia
est umentacin y pruebas se realizan, posible de la implantacin del cambio de emergencia.
I6.4 Seguimiento y Reporte del Estatus de Cambio
stablecer un sistema de seguimiento y reporte para mantener actualizados a los solicitantes de cambio y a los interesados
levantes, acerca del estatus del cambio a las aplicaciones, a los procedimientos, a los procesos, parmetros del sistema y del
ervicio y las plataformas fundamentales.
I6.5 Cierre y Documentacin del Cambio
iempre que se implantan cambios al sistema, actualizar el sistema asociado y la documentacin de usuario y procedimientos
orrespondientes. Establecer un proceso de revisin para garantizar la implantacin completa de los cambios.
ndares y
stabl r procedimientos de adminis males para manejar de manera
cedimientos, procesos, p
tnda as sol tudes (i o
iento y parches) para cam
latafor as fundamentales.
I6.2 aluacin de Impacto, Priorizacin y Au
r que tod
peraci al y su funcionalidad. Es uir ca
produc n, los interesados corre
Establecer un proceso para definir, plantear, evaluar y autorizar los camb
mente, despus
ios de emergencia que no sigan el proceso de cambio
ablecido. La doc
A
E
re
s
A
S
c
Administrar Cambios
AI6
95
DI S RECTRICES GERENCIALE
Desde Entradas
PO1 Portafolio de proyectos TI
PO8 Acciones de mejora de la calidad
PO9 Planes de accin para solucin de riesgos
relacionados con TI
PO10 Directrices de administracin de proyecto y plan de
proyecto detallado
DS3 Cambios requeridos
DS5 Cambios de seguridad requeridos
DS8 Solicitudes de servicio / solicitudes de cambio
DS9-10 Solicitudes de cambio (dnde y cmo aplicar la
solucin)
DS10 Registros de problemas

Salidas Hacia
Descripcin de proceso de cambio AI1..AI3
Reportes de estatus de cambio ME1
Autorizacin de cambio AI7 DS8 DS10

Matriz RACI

Metas y Mtricas
Responder a los requerimientos de
negocio de acuerdo con la estrategia del
negocio.
Reducir los defectos y repeticin de
Realizar cambios autorizados a la
infraestructura y aplicaciones de TI.
Evaluar el impacto de cambios a la
infraestructura, aplicaciones y soluciones
Definir y comunicar los procedimientos de
cambio incluyendo cambios de
emergencia y parches)
Evaluar, priorizar y autorizar cambios
trabajos en la entr
servicios.
ega de soluciones y
y la infraestructura de procedimiento.
tcnicos de TI.
Programar cambios
% de cambios registrados y rastreados
con herramientas automatizadas
% de cambios que siguen procesos de
control de cambio formales
Proporcin de solicitudes de cambio
aceptadas y rechazadas
# de versiones diferentes de cada
aplicacin de negocios o infraestructura
en mantenimiento
# y tipo de cambios de emergencia a los
componentes de la infraestructura
# y tipo de parches a los componentes de
la infraestructura
Repeticin de trabajo aplicativo causado
por especificaciones de cambio
inadecuadas
Reduccin de tiempo y de esfuerzo
requeridos para realizar los cambios
% de cambios totales que son soluciones
de emergencia
% de cambios no exitosos a la
infraestructura debida a especificaciones
de cambio inadecuadas
# de cambios que no se rastrean
formalmente o no se reportan o no se
autorizan
Solicitudes de cambio pendientes
# de interrupciones o errores de datos
provocados por especificaciones
inexactas o evaluacin incompleta de
impacto
Garantizar el impacto mnimo al negocio
en el evento de una interrupcin o
cambio de servicio de TI.
Definir cmo se traducen los
requerimientos de negocio funcionales y
de control a soluciones automatizadas
efectivas y eficientes.
Mantener la integridad de la informacin
Rastrear y reportar estatus de cambio a
interesados clave.
Minimizar errores debidos a
especificaciones de solicitud incompletas.
Rastrear estatus y reporte de cambios
Funciones
AI6
Administrar Cambios

MODELO DE MADUREZ
96
los cambios se pueden realizar virtualmente s
onciencia de que el cambio puede causar una interrupcin para TI y las operaciones del negocio y no hay conciencia de los
eficios de la buena administracin de cambio.
icial / Ad Hoc cuando
e reconoce que los cambios se deben administrar y controlar. Las prcticas varan y es muy probable que se puedan dar cambios sin
utorizacin. Hay documentacin de cambio pobre o no existente y la documentacin de configuracin es incompleta y no confiable.
Es posible que ocurran errores junto con interrupciones al ambiente de produccin, provocados por una pobre administracin de
ambios.
2 Repetible pero Intuitivo cuando
xiste un proceso de administracin de cambio informa y la mayora de los cambios siguen este enfoque; sin embargo, el proceso no
est estructurado, es rudimentario y propenso a errore La exactitud de la documentacin de la configuracin es inconsistente y de
cin de impacto se da previa al cambio.
al definido para la administracin del cambio, que incluye la categorizacin, asignacin de prioridades,
procedimientos de emergencia, autorizacin del cambio y administracin de liberacin, y va surgiendo el cumplimiento. Se dan
solucione se omiten o se hacen a un lado. An pueden ocurrir errores y los
cambios no autorizados ocurren ocasionalmente. El anlisis de impacto de los cambios de TI en operaciones de negocio se est
volviendo
4 Admini
El proceso de admi o se desarrolla bien y es consistente para todos los cambios, y la gerencia confa que hay
excepciones mnimas. El proceso es eficiente y efectivo, pero se basa en manuales de procedimientos y controles considerables para
garantizar el logro de la calidad. Todos los cambios estn sujetos a una planeacin minuciosa y a la evaluacin del impacto para
minimizar la proba n
de administracin es
generalmente exac ios en TI se van integrando con los cambios en los
procesos de negocio, para asegurar que se resuelven los asuntos referentes al entrenamiento, cambio organizacional y continuidad
del negocio. Existe una coordinacin creciente entre la administracin de cambio de TI y el rediseo del proceso de negocio. Hay un
proceso consistente para monitorear la calidad y el desempeo del proceso de administracin de cambios.
5 Optimizado cuando
El proceso de administraci e lnea con las buenas prcticas.
El proceso de revisin refleja los figuracin es computarizada y proporciona un
control de versin. El rastreo del cam e incluye herramientas para detectar software no autorizado y sin licencia. La
administracin de cambio de TI se integr nistracin de cambio del negocio para garantizar que TI sea un factor que hace
posible el incremento de productividad y la creacin de

La administracin del proceso de Administrar cambios que satisfaga el requerimiento de negocio de TI de responder a los
requerimientos de acuerdo con la estrategia del negocio, mientras que se reducen los defectos y repeticiones de trabajos en la
entrega de soluciones y servicios es:
0 No Existente cuando
No existe un proceso definido de administracin de cambio y in control. No hay
c
ben
1 In
S
a
c
E l
s.
planeacin limitada y la evalua
3 Definido cuando
Existe un proceso form
s temporales a los problemas y los procesos a menudo
formal, para apoyar la implantacin planeada de nuevas aplicaciones y tecnologas.
strado y Medible cuando
nistracin de cambi
bilidad de tener problemas de post-produccin. Se da un proceso de aprobacin para cambios. La documentaci
de cambios es vigente y correcta, con seguimiento formal a los cambios. La documentacin de configuracin
ta. La planeacin e implantacin de la administracin de camb
n d cambios se revisa con regularidad y se actualiza para permanecer en
resultados del monitoreo. La informacin de la con
bio es sofisticado
a con la admi
nuevas oportunidades de negocio para la organizacin.
que algunos relojes se atrasan o adelantan a lo largo del tiempo, debiera existir un
procedimiento que los chequee y corrija cualquier variacin significativa.
La correcta interpretacin de un formato fecha/hora es importante para asegurar que el sello
de fecha/hora refleje la fecha/hora real. Se debieran tomar en cuenta las especificaciones
locales (por ejemplo, ahorro por luz solar).
Otra informacin
El ajuste correcto de los relojes del computador es importante para asegurar la exactitud de los
registros de auditora, los cuales se pueden requerir para investigaciones o como evidencia en
casos legales o disciplinarios. Registros de auditora inexactos pueden entorpecer estas
investigaciones y daar la credibilidad de tales evidencias. Se puede utilizar un reloj vinculado
con la difusin de la hora de un reloj atmico nacional como reloj maestro para los registros de
los sistemas. Se puede utilizar un protocolo de hora de red para mantener todos los
servidores sincronizados con el reloj maestro.
Control del acceso
11.1 Requerimiento del negocio para el control del acceso
Objetivo: Controlar el acceso a la informacin.
Se debiera controlar el acceso a la informacin, medios de procesamiento de la informacin
y procesos comerciales sobre la base de los requerimientos comerciales y de seguridad.
Las reglas de control del acceso debieran tomar en cuenta las polticas para la divulgacin y
autorizacin de la informacin.
11.1.1 Poltica de control del acceso
Control
Se debiera establecer, documentar y revisar la poltica de control de acceso en base a los
requerimientos comerciales y de seguridad para el acceso.
Lineamiento de implementacin
Las reglas de control del acceso y los derechos para cada usuario o grupos de usuarios se
debieran establecer claramente en la poltica de control de acceso. Los controles de acceso
son tanto lgicos como fsicos (ver tambin la seccin 9) y estos debieran ser considerados
94
juntos. Se debiera proporcionar a los usuarios y proveedores del servicio un enunciado claro
de los requerimientos comerciales que debieran cumplir los controles de acceso.
La poltica debiera tomar en cuenta lo siguiente:
a)
b)
c)
d)
e)
f)
g)
h)
i)
j)
k)
los requerimientos de seguridad de las aplicaciones comerciales individuales;
identificacin de toda la informacin relacionada con las aplicaciones comerciales y
los riesgos que enfrenta la informacin;
las polticas para la divulgacin y autorizacin de la informacin; por ejemplo, la
necesidad de conocer el principio y los niveles de seguridad, y la clasificacin de la
informacin (ver 7.2);
consistencia entre el control del acceso y las polticas de clasificacin de la
informacin de los diferentes sistemas y redes;
legislacin relevante y cualquier obligacin contractual relacionada con la proteccin
del acceso a la data o los servicios (ver 15.1);
los perfiles de acceso de usuario estndar para puestos de trabajo comunes en la
organizacin;
gestin de los derechos de acceso en un ambiente distribuido y en red que
reconoce todos los tipos de conexiones disponibles;
segregacin de roles del control del acceso; por ejemplo, solicitud de acceso,
autorizacin de acceso, administracin del acceso;
requerimientos para la autorizacin formal de las solicitudes de acceso;
requerimientos para la revisin peridica de los controles de acceso (ver 11.2.4);
revocacin de los derechos de acceso (ver 8.3.3).
Otra informacin
Se debiera tener cuidado cuando se especifican los controles de acceso para considerar:
a) la diferenciacin entre las reglas que siempre se debieran seguir y los lineamientos
que son opcionales o condicionales;
b)
c)
d)
e)
establecer reglas basadas en la premisa "Generalmente todo est prohibido a no ser
que est expresamente permitido" en lugar de la regla ms dbil, "Generalmente
todo est permitido a no ser que est expresamente prohibido";
cambios en las etiquetas de la informacin (ver 7.2) que son iniciados
automticamente por los medios de procesamiento de la informacin y aquellos
iniciados por un administrador;
cambios en los permisos del usuario que son iniciados automticamente por el
sistema de informacin y aquellos iniciados por el administrador;
reglas que requieren aprobacin especfica antes de ser promulgadas, y aquellas
que no.
95
Las reglas de control del acceso debieran ser respaldadas por procedimientos formales y
responsabilidades claramente definidas (ver, por ejemplo, 6.13, 11.3, 10.4.1, 11.6).
11.2 Gestin de acceso del usuario
Objetivo: Asegurar el acceso del usuario autorizado y evitar el acceso no autorizado a los
sistemas de informacin
Se debieran establecer procedimientos formales para controlar la asignacin de los
derechos de acceso a los sistemas y servicios de informacin.
Los procedimientos debieran abarcar todas las etapas en el ciclo de vida del acceso del
usuario, desde el registro inicial de usuarios nuevos hasta el des-registro final de los
usuarios que ya no requieren acceso a los sistemas y servicios de informacin. Cuando sea
apropiado, se debiera prestar atencin especial a la necesidad de controlar la asignacin de
derechos de acceso privilegiados, lo que permite a los usuarios superar los controles del
sistema.
11.2.1 Registro del usuario
Control
Debiera existir un procedimiento formal para el registro y des-registro del usuario para otorgar
y revocar el acceso a todos los sistemas y servicios de informacin.
El procedimiento de control del acceso para el registro y des-registro del usuario debiera
incluir:
a) utilizar IDs de usuarios nicos para permitir a los usuarios vincularse y ser
responsables de sus acciones; slo se debiera permitir el uso de IDs grupales
cuando son necesarios por razones comerciales u operacionales, y debieran ser
aprobados y documentados;
b) chequear que el usuario tenga la autorizacin dada por el propietario del sistema
para el uso del sistema o servicio de informacin; tambin puede ser apropiado una
aprobacin separada de la gerencia para los derechos de acceso;
c) chequear que el nivel de acceso otorgado sea apropiado para el propsito comercial
(ver 11.1) y que sea consistente con la poltica de seguridad de la organizacin; por
ejemplo, no compromete la segregacin de los debierares (ver 10.1.3);
d) proporcionar a los usuarios un enunciado escrito de sus derechos de acceso;
96
e)
f)
g)
h)
i)
j)
requerir a los usuarios que firmen los enunciados indicando que entienden las
condiciones de acceso;
asegurar que los proveedores del servicio no proporcionen acceso hasta que se
hayan completado los procedimientos de autorizacin;
mantener un registro formal de todas las personas registradas para usar el servicio;
eliminar o bloquear inmediatamente los derechos de acceso de los usuarios que han
cambiado de puesto o trabajo o han dejado la organizacin;
chequeo peridico para eliminar o bloquear los IDs de usuario y cuentas
redundantes (ver 11.2.4);
asegurar que no se emitan IDs de usuario redundantes a otros usuarios.
Otra informacin
Se debiera considerar establecer roles de acceso de usuarios basados en los requerimientos
que resuman un nmero de derechos de acceso en perfiles de acceso de usuario tpicos. Las
solicitudes y revisiones del acceso (ver 11.2.4) son ms fciles de manejar en el nivel de
dichos roles en lugar de en el nivel de derechos particulares.
Se debiera considerar incluir en los contratos del personal y contratos de servicio clusulas
que especifiquen las sanciones si el personal o los agentes de servicio intentan un acceso no
autorizado (ver tambin 6.1.5, 8.1.3 y 8.2.3).
11.2.2 Gestin de privilegios
Control
Se debiera restringir y controlar la asignacin y uso de privilegios.
Los sistemas multi-usuario que requieren proteccin contra el acceso no autorizado debieran
controlar la asignacin de privilegios a travs de un proceso de autorizacin formal. Se
debieran considerar los siguientes pasos:
a) los privilegios de acceso asociados con cada producto del sistema; por ejemplo,
sistema de operacin, sistema de gestin de base de datos y cada aplicacin, y se
debieran identificar los usuarios a quienes se les necesita asignar privilegios;
b) los privilegios se debieran asignar a los usuarios sobre la base de "slo lo que
necesitan saber" y sobre una base de evento-por-evento en lnea con la poltica de
control del acceso (11.1.1); es decir, los requerimientos mnimos para su rol
funcional, slo cuando se necesitan;
97
c) se debiera mantener un proceso de autorizacin y un registro de todos los privilegios
asignados. No se debieran otorgar privilegios hasta que se complete el proceso de
autorizacin.
d) Se debiera promover el desarrollo y uso de rutinas del sistema para evitar la
necesidad de otorgar privilegios a los usuarios;
e) se debiera promover el desarrollo y uso de los programas que evitan la necesidad de
correr con privilegios;
f) los privilegios se debieran asignar a un ID de usuario diferente de aquellos utilizados
para el uso normal del negocio.
Otra informacin
El uso inapropiado de los privilegios de administracin del sistema (cualquier dispositivo o
medio de un sistema de informacin que permite al usuario superar los controles del sistema o
aplicacin) puede ser un factor que contribuye mucho a las fallas o violaciones del sistema.
11.2.3 Gestin de las claves secretas de los usuarios
Control
La asignacin de claves secretas se debiera controlar a travs de un proceso de gestin
formal.
El proceso debiera incluir los siguientes requerimientos:
a) se debiera requerir que los usuarios firmen un enunciado para mantener
confidenciales las claves secretas y mantener las claves secretas grupales slo
dentro de los miembros el grupo; este enunciado firmado se puede incluir en los
trminos y condiciones de empleo (ver 8.1.3);
b) cuando se requiere que los usuarios mantengan sus propias claves secretas,
inicialmente se les debiera proporcionar una clave secreta temporal segura (ver
11.3.1), la cual estn obligados a cambiar inmediatamente;
c) establecer procedimientos para verificar la identidad de un usuario antes de
proporcionar una clave secreta nuevo, sustituta o temporal;
d) las claves secretas temporales debieran ser proporcionadas a los usuarios de una
manera segura, se debiera evitar el uso de mensajes de correo electrnico de
terceros o no protegidos (sin texto);
e) las claves secretas temporales debieran ser nicas para la persona y no debieran
ser fciles de adivinar;
98
f) los usuarios debieran reconocer la recepcin de las claves secretas;
g) las claves secretas nunca debieran ser almacenadas en los sistemas de cmputo de
una forma desprotegida;
h) las claves secretas predeterminadas por el vendedor debieran ser cambiadas
despus de la instalacin de sistemas o software.
Otra informacin
Las claves secretas son un medio comn para verificar la identidad del usuario antes de
otorgar acceso a un sistema o servicio de informacin en concordancia con la autorizacin del
usuario. Estn disponibles, y se debiera considerar la idoneidad, de otras tecnologas para la
identificacin y autenticacin del usuario; tales como biomtricas, por ejemplo verificacin de
huellas digitales, verificacin de firmas; y el uso de dispositivos de hardware como tarjetas
inteligentes.
11.2.4 Revisin de los derechos de acceso del usuario
Control
La gerencia debiera revisar los derechos de acceso de los usuarios a intervalos regulares
utilizando un proceso formal.
La revisin de los derechos de acceso debiera considerar los siguientes lineamientos:
a)
b)
c)
d)
e)
los derechos de acceso de los usuarios debieran ser revisados a intervalos
regulares; por ejemplo, un perodo de 6 meses, y despus de cualquier cambio,
como un ascenso, democin o terminacin del empleo (ver 11.2.1);
los derechos de acceso del usuario se debieran revisar y re-asignar cuando se
traslada de un empleo a otro dentro de la misma organizacin;
las autorizaciones para derechos de acceso privilegiados especiales (ver 11.2.2) se
debieran revisar a intervalos ms frecuentes; por ejemplo, un perodo de 3 meses;
se debiera chequear la asignacin de privilegios a intervalos regulares para
asegurar que no se hayan obtenido privilegios no autorizados;
se debieran registrar los cambios en las cuentas privilegiadas para una revisin
peridica.
Otra informacin
Es necesario revisar regularmente los derechos de acceso de los usuarios para mantener un
control efectivo sobre el acceso a la data y los servicios de informacin.
99
11.3 Responsabilidades del usuario
Objetivo: Evitar el acceso de usuarios no-autorizados, evitar poner en peligro la informacin
y evitar el robo de informacin y los medios de procesamiento de la informacin.
La cooperacin de los usuarios autorizados es esencial para una seguridad efectiva.
Los usuarios debieran estar al tanto de sus responsabilidades para mantener controles de
acceso efectivos, particularmente con relacin al uso de claves secretas y la seguridad del
equipo del usuario.
Se debiera implementar una poltica de escritorio y pantalla limpios para reducir el riesgo de
acceso no autorizado o dao a los papeles, medios y medios de procesamiento de la
informacin.
11.3.1 Uso de claves secretas
Control
Se debiera requerir a los usuarios que sigan buenas prcticas de seguridad en la seleccin y
uso de claves secretas.
Se debiera advertir a todos los usuarios que:
a)
b)
c)
d)
mantener confidenciales las claves secretas;
evitar mantener un registro (por ejemplo, papel, archivo en software o dispositivo
manual) de las claves secretas, a no ser que este se pueda mantener almacenado de
manera segura y el mtodo de almacenaje haya sido aprobado;
cambio de claves secretas cuando haya el menor indicio de un posible peligro en el
sistema o la clave secreta;
seleccionar claves secretas de calidad con el largo mnimo suficiente que sean:
1)
2)
3)
4)
fciles de recordar;
no se basen en nada que otro pueda adivinar fcilmente u obtener utilizando la
informacin relacionada con la persona; por ejemplo, nombres, nmeros
telefnicos y fechas de nacimiento, etc.
no sean vulnerables a los ataques de diccionarios (es decir, que no consista de
palabras incluidas en los diccionarios);
libre de caracteres consecutivos idnticos, todos numricos o todos alfabticos;
e) cambio de las claves secretas a intervalos regulares o en base al nmero de accesos
(las claves secretas para las cuentas privilegiadas se debieran cambiar con mayor
100
f)
g)
h)
i)
frecuencia que las claves secretas normales), y evitar el re-uso de reciclaje de claves
secretas antiguas;
cambiar la clave secreta temporal en el primer registro de ingreso;
no incluir las claves secretas en ningn proceso de registro automatizado; por
ejemplo, almacenado en un macro o funcin clave;
no compartir las claves secretas individuales;
no usar la misma clave personal para propsitos comerciales y no-comerciales
Si los usuarios necesitan tener acceso a mltiples servicios, sistemas o plataformas, y
requieren mantener mltiples claves secretas separadas, se les debiera advertir que pueden
utilizar una sola clave secreta de calidad (ver d) en el prrafo anterior) para todos los servicios
donde se le asegura al usuario que se ha establecido un nivel de proteccin razonable para el
almacenaje de la clave secreta dentro de cada servicio, sistema o plataforma.
Otra informacin
Se necesita tener especial cuidado con el manejo del sistema de 'help desk' para las claves
secretas perdidas u olvidadas ya que este tambin puede ser un medio para atacar al sistema
de clave secretas.
11.3.2 Equipo del usuario desatendido
Control
Los usuarios debieran asegurar que el equipo desatendido tenga la proteccin apropiada.
Todos los usuarios debieran estar al tanto de los requerimientos de seguridad y los
procedimientos para proteger el equipo desatendido, as como sus responsabilidades para
implementar dicha proteccin. Se debiera comunicar a los usuarios que debieran:
a)
b)
c)
cerrar las sesiones activas cuando se termina, a no ser que puedan asegurarse con
un mecanismo de cierre apropiado; por ejemplo, protector de pantalla asegurado
mediante clave secreta;
salir de las computadoras mainframe, servidores y PCs de oficina cuando se termina
la sesin (es decir, no slo apagar la pantalla de la PC o Terminal);
asegurar las PCs o terminales contra un uso no autorizado mediante un seguro con
clave o un control equivalente; por ejemplo, acceso con clave secreta, cuando no
est en uso (ver tambin 11.3.3).
Otra informacin
101
El equipo instalado en las reas de usuarios; por ejemplo estaciones de trabajo o servidores
de archivo; puede requerir proteccin especfica contra el acceso no autorizado cuando se
deja desatendido durante un perodo e tiempo extendido.
11.3.3 Poltica de escritorio y pantalla limpios
Control
Se debiera adoptar una poltica de escritorio limpio para papeles y medios de almacenaje
removibles y una poltica de pantalla limpia para los medios de procesamiento de la
informacin.
La polticas de escritorio limpio y pantalla limpia debieran tomar en cuenta las clasificaciones
de informacin (ver 7.2), requerimientos legales y contractuales (ver 15.1), y los
correspondientes riesgos y aspectos culturales de la organizacin. Se debieran considerar los
siguientes lineamientos:
a) la informacin comercial confidencial o crtica; por ejemplo, en papel o medios de
almacenamiento electrnicos; debiera ser guardada bajo llave (idealmente en una
caja fuerte o archivador u otra forma de mueble seguro) cuando no est siendo
utilizada, especialmente cuando la oficina est vaca;
b) cuando se dejan desatendidas, las computadoras y terminales debieran dejarse
apagadas o protegidas con mecanismos para asegurar la pantalla y el teclado,
controlados mediante una clave secreta, dispositivo o un mecanismo de
autenticacin de usuario similar y se debieran proteger con llave, claves secretas u
otros controles cuando no estn en uso;
c) se debieran proteger los puntos de ingreso y salida de correo y las mquinas de fax
desatendidas;
d) se debiera evitar el uso no autorizado de fotocopiadoras y otra tecnologa de
reproduccin (por ejemplo, escners, cmaras digitales);
e) los documentos que contienen informacin confidencial o clasificada debieran
sacarse inmediatamente de la impresora.
Otra informacin
Una poltica de escritorio/pantalla limpia reduce el riesgo de accesos no-autorizados, prdida y
dao a la informacin durante y fuera el horario de trabajo normal. Los seguros u otras formas
de medios de almacenaje seguro tambin podran proteger la informacin almacenada contra
desastres como fuego, terremotos, inundaciones o explosiones.
102
Considere el uso de impresoras con la funcin de clave secreta, de manera que slo los
creadores de un documento puedan imprimirlo, y slo cuando estn parados junto a la
impresora.
11.4 Control de acceso a la red
Objetivo: Evitar el acceso no autorizado a los servicios de la red.
Se debiera controlar el acceso a los servicios de redes internas y externas.
El acceso del usuario a las redes y servicios de las redes no debieran comprometer la
seguridad de los servicios de la red asegurando:
a)
b)
c)
que existan las interfases apropiadas entre la red de la organizacin y las
redes de otras organizaciones, y redes pblicas;
se apliquen los mecanismos de autenticacin apropiados para los usuarios y el
equipo;
el control del acceso del usuario a la informacin sea obligatorio.
11.4.1 Poltica sobre el uso de los servicios de la red
Control
Los usuarios slo debieran tener acceso a los servicios para los cuales hayan sido
especficamente autorizados.
Se debiera formular una poltica relacionada con el uso de las redes y los servicios de la red.
Esta poltica debiera abarcar:
a)
b)
c)
d)
las redes y servicios de la red a las cuales se tiene acceso;
los procedimientos de autorizacin para determinar quin est autorizado a tener
acceso a cules redes y servicios en red;
controles y procedimientos gerenciales para proteger el acceso a las conexiones de
la red y los servicios en red;
los medios utilizados para tener acceso a las redes y los servicios de la red (por
ejemplo, las condiciones para permitir acceso va discado a un proveedor del servicio
de Internet o sistema remoto).
La poltica sobre el uso de los servicios de la red debiera ser consistente con la poltica de
control de acceso del negocio (ver 11.1)
103
Otra informacin
Las conexiones no autorizadas e inseguras a los servicios de la red pueden afectar a toda la
organizacin. Este control es particularmente importante para las conexiones de la red con
aplicaciones comerciales confidenciales o crticas o con usuarios en ubicaciones de alto
riesgo; por ejemplo, reas pblicas o externas que estn fuera de la gestin y control de
seguridad de la organizacin.
11.4.2 Autenticacin del usuario para las conexiones externas
Control
Se debieran utilizar mtodos de autenticacin apropiados para controlar el acceso de usuarios
remotos.
La autenticacin de los usuarios remotos se puede lograr utilizando, por ejemplo, una tcnica
basada en criptografa, dispositivos de hardware o un protocolo de desafo/respuesta. Las
posibles implementaciones de tales tcnicas se pueden encontrar en varias soluciones de la
red privada virtual (VPN). Tambin se pueden utilizar las lneas privadas dedicadas para
proporcionar la seguridad de la fuente de conexiones.
Los procedimientos y controles de discado; por ejemplo, utilizando mdems de discado;
pueden proporcionar proteccin contra conexiones no autorizadas e indeseadas a los medios
de procesamiento de la informacin de una organizacin. Este tipo de control ayuda a
autenticar a los usuarios que tratan de establecer una conexin con la red de la organizacin
desde ubicaciones remotas. Cuando se utiliza este control, una organizacin no debiera
utilizar los servicios de red, los cuales incluyen reenvo de llamadas, y si lo hacen, debieran
deshabilitar el uso de tales dispositivos para evitar las debilidades asociadas con el reenvo de
llamadas. El proceso de llamada de verificacin debierara asegurar que ocurra una
desconexin real en el lado de la organizacin. De otra manera, el usuario remoto podra
tomar la lnea abierta pretendiendo que ha ocurrido la llamada de verificacin. Los
procedimientos y controles de la llamada de verificacin debieran ser comprobados
concienzudamente para evitar esta posibilidad.
La autenticacin del nodo puede servir como un medio alternativo para la autenticacin de los
grupos de usuarios remotos, cuando estn conectados a un medio de cmputo seguro y
compartido. Se pueden utilizar tcnicas criptogrficas; por ejemplo, basadas en los
certificados de las mquinas; para la autenticacin del nodo.
104
Se debieran implementar controles de autenticacin adicionales para controlar el acceso a las
redes inalmbricas. En particular, se necesita prestar cuidado especial a la seleccin de
controles para las redes inalmbricas debido a las mayores oportunidades para una
intercepcin e insercin no-detectada de trfico de la red.
Otra informacin
Las conexiones externas proporcionan un potencial para el acceso no autorizado a la
informacin comercial; por ejemplo, acceso mediante mtodos de discado. Existen diferentes
tipos de mtodos de autenticacin, algunos de estos proporcionan un mayor nivel de
proteccin que otros; por ejemplo, los mtodos basados en el uso de las tcnicas
criptogrficas pueden proporcionar una autenticacin slida. Es importante determinar el nivel
de proteccin requerido mediante una evaluacin del riesgo.
seleccin apropiada de un mtodo de autenticacin.
Esto es necesario ara la
Un medio para la conexin automtica con una computadora remota podra proporcionar una
manera de obtener acceso no autorizado a la aplicacin comercial. Esto es especialmente
importante si la conexin utiliza una red que est fuera del control de la gestin de seguridad
de la organizacin.
11.4.3 Identificacin del equipo en las redes
Control
La identificacin automtica del equipo se debiera considerar como un medio para autenticar
las conexiones de ubicaciones y equipos especficos.
La identificacin del equipo se puede utilizar si es importante que la comunicacin slo sea
iniciada desde una ubicacin o equipo especfico. Se puede utilizar un identificador dentro o
incorporado en el equipo para indicar si este equipo est autorizado a conectarse a la red.
Estos identificadores debieran indicar claramente a cul red est autorizado a conectarse el
equipo, si existe ms de una red y particularmente si estas redes tienen diferentes grados de
confidencialidad. Puede ser necesario considerar la proteccin fsica del equipo para
mantener la seguridad del identificador del equipo.
Otra informacin
Este control puede complementarse con otras tcnicas para autenticar al usuario del equipo
(ver 11.4.2). Adicionalmente, se puede aplicar la identificacin del equipo para la autenticacin
del usuario.
105
11.4. Proteccin del puerto de diagnstico y configuracin remoto
Control
Se debiera controlar el acceso fsico y lgico a los puertos de diagnstico y configuracin.
Los controles potenciales para el acceso a los puertos de diagnostico y configuracin incluyen
el uso de un seguro y procedimientos de soporte para controlar el acceso fsico al puerto. Un
ejemplo de un procedimiento de soporte es asegurar que los puertos de diagnstico y
configuracin slo sean accesibles a travs de un acuerdo entre el gerente del servicio de
cmputo y el personal de soporte de hardware/software que requiere acceso.
Los puertos, servicios y medios similares instalados en una computadora o red, que no son
requeridos especficamente por funcionalidad comercial, debieran ser desactivados o
removidos.
Otra informacin
Muchos sistemas de cmputo, sistemas de redes y sistemas de comunicaciones estn
instalados con un medio de diagnstico o configuracin remoto para ser utilizado por los
ingenieros de mantenimiento. Si no estn protegidos, estos puertos de diagnstico
proporcionan un medio de acceso no autorizado.
11.4.5 Segregacin en redes
Control
Los grupos de servicios de informacin, usuarios y sistemas de informacin debieran ser
segregados en redes.
Un mtodo para controlar la seguridad de grandes redes es dividirlas en dominios de red
lgicos separados; por ejemplo, dominios de red internos y dominios de red externos de una
organizacin; cada uno protegido por un permetro de seguridad definido. Se puede aplicar un
conjunto de controles graduados en dominios de red lgicos diferentes para segregar an ms
los ambientes de seguridad de la red; por ejemplo, sistemas de acceso pblico, redes internas
106
y activos crticos. Los dominios debieran ser definidos en base a una evaluacin del riesgo y
los requerimientos de seguridad diferentes dentro de cada uno de los dominios.
Este tipo de permetro de red se puede implementar instalando un gateway seguro entre dos
redes para mantenerlas interconectadas y controlar el acceso y el flujo de informacin entre
los dos dominios. Este gateway debiera estar configurado para filtrar el trfico entre estos
dominios (ver 11.4.6 y 11.4.7) y para bloquear el acceso no-autorizado en concordancia con la
poltica de control de acceso de la organizacin. Un ejemplo de este tipo de gateway es lo que
comnmente se conoce como un firewall. Otro mtodo para segregar dominios lgicos
separados es restringir el acceso a la red utilizando redes privadas virtuales para grupos de
usuarios dentro de la organizacin.
Las redes tambin pueden ser segregadas utilizando la funcionalidad del dispositivo de red;
por ejemplo, IP switching. Los dominios separados tambin se pueden implementar
controlando los flujos de data a la red utilizando capacidades routing/switching, como listas de
control de acceso.
El criterio de segregacin de las redes en dominios se debiera basar en la poltica de control
de acceso y los requerimientos de acceso (ver 10.1), y tambin debiera tomar en cuenta el
costo relativo y el impacto en el desempeo al incorporar una adecuada tecnologa de routing
o gateway de red.
Adems, la segregacin de las redes se debiera basar en el valor y la clasificacin de la
informacin almacenada o procesada en la red, niveles de confianza o lneas comerciales;
para as reducir el impacto total de una interrupcin del servicio.
Se debiera tener en consideracin la segregacin de las redes inalmbricas de las redes
internas y privadas. Como los permetros de las redes inalmbricas no estn bien definidos,
se debiera llevar a cabo una evaluacin del riesgo para identificar los controles (por ejemplo,
autenticacin slida, mtodos criptogrficos y seleccin de frecuencia) para mantener la
segregacin de la red.
Otra informacin
Las redes se estn extendiendo cada vez ms all de los lmites organizacionales
tradicionales, conforme se forman sociedades comerciales que puedan requerir la
interconexin o intercambio de medios de procesamiento de la informacin y redes. Estas
extensiones podran incrementar el riesgo de un acceso no-autorizado a los sistemas de
informacin existentes que utilizan la red, algunos de los cuales pueden requerir proteccin de
otros usuarios de la red debido a la confidencialidad o grado crtico.
107
C
,...,.... Certified Information
CISASystemsuditor'
i
ISAGYCertilkahm
Captulo 2 - Gobierno y Gestin de TI Seccin Dos: Contenido
Figura 2.12Organizacin del Departamento de SI
Oficial Jefe de Informacin
o Gerente / Director de TI
Gestin de Riesgos Aplicaciones Datos Soporte Tcnico Soporte al Usuario Operaciones
Administrador de
la Seguridad
Coordinador de
Recuperacin Ante
Desastres
Desarrollo /
Administrador de Soporte
Administrador de Datos /
Administrador de Base
de Datos
Administrador de
Soporte Tcnico
Mesa de Servicio
Administrador de
Operaciones
Programadores
(Aplicaciones)
Analistas de Sistemas
(Aplicaciones)
Aseguramiento
de la Calidad
Administrador de Redes
(LAN/WAN)
Administrador
de Sistemas
(Sistema Operativo)
Programadores de Sistemas
(Sistema Operativo)
(Operacin de Sistemas)
Operador de Computadora
2.11 ESTRUCTURAORGANIZATIVAY
RESPONSABILIDADES DE SI
Un departamento de SI puede estar estructurado de diferentes
maneras. Este tipo de formato se muestra en la figura 2.12.
El organigrama descrito incluye funciones relacionadas con
seguridad, desarrollo y mantenimiento de aplicaciones, soporte
tcnico para administracin de redes y sistemas, y operaciones.
La estructura organizacional muestra el departamento de
SI tpicamente encabezado por un gerente/director de TI o,
en las organizaciones grandes, por un director general de
informacin (CIO).
Nota: El examen CISA no prueba responsabilidades
especficas del trabajo, ya que pueden variar dentro de las
organizaciones. Sin embargo, las responsabilidades conocidas
universalmente tales como los propietarios del negocio, las
funciones de seguridad de la informacin y la direccin
ejecutiva podran examinarse en la prueba, en especial
cuando se prueban los controles de acceso y la propiedad de
los datos. Un CISA debe estar familiarizado con la separacin
de responsabilidades.
2.11.1 ROLESY RESPONSABILIDADESDE SI
Los organigramas son elementos importantes que deben tener
todos los empleados, ya que ellos proveen una definicin clara
de la jerarqua y autoridad del departamento. Adicionalmente, las
descripciones de los puestos de trabajo brindan a los empleados
del departamento de SI una orientacin clara respecto a sus roles
y responsabilidades. El auditor de SI debe dedicar tiempo en un
rea auditada para observar y determinar si las descripciones de
tareas y las estructuras son adecuadas. Generalmente se deben
revisar las siguientes funciones de SI:
Gestin de desarrollo de sistemasResponsable de los
programadores y analistas que implementan los nuevos sistemas
y que mantienen los sistemas existentes.
Gestin de proyectosLos gerentes de proyectos son
responsables de planificar y ejecutar los proyectos de SI y
pueden reportar a una oficina de gestin de proyectos o a la
organizacin de desarrollo. El personal de gestin de proyectos
utiliza el presupuesto que se les asigna para la entrega de
iniciativas de SI e informar sobre el progreso de los proyectos
al comit de direccin. Los gerentes de proyectos juegan un
papel central en la ejecucin de la visin de la estrategia de TI
y del comit de direccin al planificar, coordinar y entregar los
proyectos de SI a la empresa.
Mesa de servicio (mesa de ayuda)En el entorno actual de
SI, cada vez ms compaas consideran importante tener una
funcin de mesa de servicio. Esta es una unidad dentro de una
organizacin que responde a preguntas y problemas tcnicos que
enfrentan los usuarios. La mayora de las compaas de software
tienen mesas de servicio. Las preguntas y respuestas pueden ser
realizadas por telfono, fax o correo electrnico o mensajera
instantnea. El personal de la mesa de servicio puede utilizar
software especial de mesa de ayuda de terceros que les posibilita
hallar rpidamente las respuestas a las preguntas ms frecuentes.
Debe existir un procedimiento para registrar el problema
reportado, su resolucin y escalamiento a efectos de un posterior
anlisis de problemas/preguntas. Este procedimiento debe
ayudar a monitorear los grupos de usuarios y para mejorar
los servicios de software/(instalaciones de procesamiento de
informacin IPF) brindados.
La administracin de mesa de ayuda/soporte incluye las siguientes
actividades:
Adquisicin de hardware/software (HW/SW) en
representacin de los usuarios
Apoyar a los usuarios finales con las dificultades de HW/SW
Capacitar a los usuarios para usar HW/SW y bases de datos
Responder las preguntas de los usuarios finales
Monitorear desarrollos tcnicos e informar a los usuarios
finales de desarrollos que podran ser pertinentes para ellos
Determinar la fuente de problemas con sistemas de produccin
e iniciar acciones correctivas
Informar a los usuarios finales sobre problemas con HW/
SW o bases de datos que podran afectar sus controles por la
instalacin de actualizaciones de HW/SW
Iniciar cambios para mejorar la eficiencia
Manual de Preparacin al Examen CISA 2012 121
ISACA. Todoslosderechosreservados.
e
. Certified lntormatioo Captulo 2 - Gobierno y Gestin de TI
M Systems Audotor"
MISACA"C.Ufbtlon
Figura 2.12-0rganizacin del Departamento de SI
Mesa de Servicio
Programadores
(Aplicaciones)
Administrador de Redes
(LAN!WAN)
Programadores de Sistemas
(Sistema Operativo)
(Aplicaciones)
Administrador Analistas de Sistemas
(Operacin de Sistemas)
Aseguramiento
de la Calidad
de Sistemas
(Sistema Operativo)
2.11 ESTRUCTURA ORGANIZATIVA Y
RESPONSABILIDADES DE SI
Un departamento de SI puede estar estructurado de diferentes
maneras. Este tipo de formato se muestra en la figura 2.12.
El organigrama descrito incluye funciones relacionadas con
seguridad, desarrollo y mantenimiento de aplicaciones, soporte
tcnico para administracin de redes y sistemas, y operaciones.
La estructura organizacional muestra el departamento de
SI tpicamente encabezado por un gerente/director de TI o,
en las organizaciones grandes, por un director general de
informacin (CIO).
Nota: El examen CISA no prueba responsabilidades
especficas del trabajo, ya que pueden variar dentro de las
organizaciones. Sin embargo, las responsabilidades conocidas
universalmente tales como los propietarios del negocio, las
funciones de seguridad de la informacin y la direccin
ejecutiva podran examinarse en la prueba, en especial
cuando se prueban los controles de acceso y la propiedad de
los datos. Un CISA debe estar familiarizado con la separacin
de responsabilidades.
2.11.1 ROLES Y RESPONSABILIDADES DE SI
Los organigramas son elementos importantes que deben tener
todos los empleados, ya que ellos proveen una definicin clara
de la jerarqua y autoridad del departamento. Adicionalmente, las
descripciones de los puestos de trabajo brindan a los empleados
del departamento de SI una orientacin clara respecto a sus roles
y responsabilidades. El auditor de SI debe dedicar tiempo en un
rea auditada para observar y determinar si las descripciones de
tareas y las estructuras son adecuadas. Generalmente se deben
revisar las siguientes funciones de SI:
Gestin de desarrollo de sistemas-Responsable de los
programadores y analistas que implementan los nuevos sistemas
y que mantienen los sistemas existentes.
Gestin de proyectos-Los gerentes de proyectos son
responsables de planificar y ejecutar los proyectos de SI y
pueden reportar a una oficina de gestin de proyectos o a la
organizacin de desarrollo. El personal de gestin de proyectos
utiliza el presupuesto que se les asigna para la entrega de
iniciativas de SI e informar sobre el progreso de los proyectos
al comit de direccin. Los gerentes de proyectos juegan un
papel central en la ejecucin de la visin de la estrategia de TI
y del comit de direccin al planificar, coordinar y entregar los
proyectos de SI a la empresa.
Mesa de servicio (mesa de ayuda)---En el entorno actual de
SI, cada vez ms compaas consideran importante tener una
funcin de mesa de servicio. Esta es una unidad dentro de una
organizacin que responde a preguntas y problemas tcnicos que
enfrentan los usuarios. La mayora de las compaas de software
tienen mesas de servicio. Las preguntas y respuestas pueden ser
realizadas por telfono, fax o correo electrnico o mensajera
instantnea. El personal de la mesa de servicio puede utilizar
software especial de mesa de ayuda de terceros que les posibilita
hallar rpidamente las respuestas a las preguntas ms frecuentes.
Debe existir un procedimiento para registrar el problema
reportado, su resolucin y escalamiento a efectos de un posterior
anlisis de problemas/preguntas. Este procedimiento debe
ayudar a monitorear los grupos de usuarios y para mejorar
los servicios de software/(instalaciones de procesamiento de
informacin - IPF) brindados.
La administracin de mesa de ayuda/soporte incluye las siguientes
actividades:
-Adquisicin de hardware/software (HW /SW) en
representacin de los usuarios
-Apoyar a los usuarios finales con las dificultades de HW/SW
- Capacitar a los usuarios para usar HW /SW y bases de datos
- Responder las preguntas de los usuarios finales
- Monitorear desarrollos tcnicos e informar a los usuarios
finales de desarrollos que podran ser pertinentes para ellos
- Determinar la fuente de problemas con sistemas de produccin
e iniciar acciones correctivas
- Informar a los usuarios finales sobre problemas con HW/
SW o bases de datos que podran afectar sus controles por la
instalacin de actualizaciones de HW/SW
- Iniciar cambios para mejorar la eficiencia
121
Certilled Information
Captulo 2 - Gobierno y Gestin de TI
CISA systems Auditor'
eo ISAC,Cenificallon
Usuario finalResponsable de las operaciones relacionadas
con los servicios de aplicaciones del negocio; utilizado
para distinguir la persona para quien se dise el producto
(generalmente a nivel de aplicacin) de la persona que
programa, sirve o instala aplicaciones. Vale la pena sealar que
hay una pequea distincin entre los trminos "usuario final"
y "usuario". El usuario final es levemente ms especfico, y se
refiere a alguien que tendr acceso a una aplicacin de negocio,
como se expres aqu anteriormente. El trmino usuario es ms
amplio, y podra referirse a cuentas administrativas y cuentas
para acceso a plataformas.
Gestin de soporte al usuario finalResponsable del enlace
entre el departamento de SI y los usuarios finales.
Gestin de datosResponsable de la arquitectura de los datos
en los ambientes ms grandes de TI y encargado de gestionar
los datos como un activo corporativo.
Gestin de aseguramiento de la calidad (QA)Responsable
de negociar y facilitar actividades de calidad en todas las reas
de tecnologa de informacin.
Gestin de la seguridad de la informacinEsta es una
funcin que generalmente se debe separar del departamento
de SI y debe estar encabezada por un CISO. El CISO puede
reportar al CIO o tener una relacin indirecta (reporte indirecto)
con el CIO. Incluso cuando el oficial de seguridad se reporta al
CIO, existe una posibilidad de conflicto, ya que las metas del
CIO son proporcionar de modo eficiente servicios continuos
de Ti, mientras que el CISO puede estar menos interesado en
la reduccin de costos si esto tiene un impacto en la calidad de
la proteccin.
Gestin de proveedores y contratistas de
externalizacin
Con el aumento de externalizacin, que incluye el uso de
mltiples proveedores, el personal dedicado puede estar obligado
a gestionar proveedores y contratistas de servicios externos,
incluyendo realizar las siguientes funciones:
Actuar como el primer contacto para el vendedor y el contratista
de externalizacin dentro de la funcin de SI
Proveer indicaciones al contratista de externalizacin sobre los
problemas y escalar internamente dentro de la organizacin y la
funcin de SI
Monitorear y reportar sobre los niveles de servicio a la gerencia
Revisar los cambios al contrato debidos a nuevos
requerimientos y obtener aprobaciones de SI
Operaciones y mantenimiento de infraestructura
El gerente de operaciones es responsable del personal de
operaciones informticas. Esto incluye todo el personal
requerido para operar las computadoras de las instalaciones
de procesamiento de informacin (IPF) de manera eficiente y
efectiva (por ejemplo, operadores de computadora, cintotecarios,
programadores y personal de control de datos). Las instalaciones
de procesamiento de informacin (IPF) incluyen la computadora,
los perifricos, los medios magnticos y los datos almacenados
en los medios. Constituye una inversin importante de activos
y tiene un impacto en la capacidad de la organizacin para
funcionar eficazmente. La sala de computadoras debe tener
seguridad y slo el personal autorizado debe tener acceso a
la misma. Nadie con excepcin del personal de operaciones,
debe tener acceso a las instalaciones. Dentro de las operaciones
informticas, los controles de gestin se pueden subdividir en tres
categoras relacionadas con la seguridad fsica, la seguridad de los
datos y los controles de procesamiento.
El grupo de control es responsable de la recoleccin, conversin
y control del ingreso de datos y el balanceo y distribucin de
los datos salientes a la comunidad de usuarios. El supervisor del
grupo de control usualmente reporta al gerente de operaciones
de las instalaciones de procesamiento de informacin (IPF). El
grupo de control de entrada/salida debe estar en un rea separada
donde slo se permita personal autorizado, ya que ellos manejan
datos sensibles.
Gestin de medios
La gestin de medios se requiere para registrar, emitir, recibir
y salvaguardar todos los archivos de programa y de datos que
se mantienen en medios extrables. Dependiendo del tamao de
la organizacin, esta funcin se puede asignar a un individuo a
tiempo completo o a un miembro de operaciones que tambin
desempee otras funciones.
Esta es una funcin crucial y por tanto, muchas organizaciones le
proveen soporte adicional mediante el uso de software que ayuda
a mantener el inventario as como tambin maneja el movimiento
de medios de almacenamiento. El uso de este software tambin
ayuda a mantener el control de versiones y la gestin de
configuracin de los programas.
Ingreso de datos
El ingreso de datos es crtico para la actividad de procesamiento
de informacin. El ingreso de datos puede incluir ingreso en lote
o ingreso en lnea.
En la mayora de las organizaciones, el personal de los
departamentos de usuarios hace su propio ingreso de datos en
lnea. En muchos ambientes en lnea, los datos son capturados
desde la fuente original (por ejemplo, intercambio electrnico
de datos [EDI], datos capturados va cdigos de barra para
gestin de tiempo, inventario de almacenes por departamento).
El departamento de usuarios as como tambin la aplicacin
del sistema deben tener implantados controles para asegurar
que los datos estn validados, sean correctos, estn completos y
autorizados.
Con el avance de la tecnologa y la necesidad de adquirir datos
desde que se originan, las organizaciones estn desplegando
sistemas automatizados para la adquisicin de datos. Estos
sistemas incluyen lectores de cdigo de barras, o sistemas a los
que se hace referencia como SCADA (Adquisicin de datos,
supervisin y control). El trmino SCADA comnmente se
refiere a sistemas centralizados los cuales monitorean y controlan
sitios enteros, o a complejos de sistemas propagados en reas
grandes (en la escala de kilmetros o millas). La mayor parte
del control del sitio se realiza automticamente por terminales
remotos (RTUs) o por controladores lgicos programables
(PLCs). Las funciones de control del anfitrin (host) suelen
restringirse a autorizaciones bsicas del sitio o intervencin a
nivel de supervisin. Por ejemplo, medir y controlar la extraccin
122Manual de Preparacin al Examen CISA 2012
Seccin Dos: Contenido Captulo 2 - Gobierno y Gestin de TI eiSA Certifled lnformatioo
Systems Audotor
AniSACA" Cifl lllcltlon
Usuario final-Responsable de las operaciones relacionadas
con los servicios de aplicaciones del negocio; utilizado
para distinguir la persona para quien se dise el producto
(generalmente a nivel de aplicacin) de la persona que
programa, sirve o instala aplicaciones. Vale la pena sealar que
hay una pequea distincin entre los trminos "usuario final"
y "usuario". El usuario final es levemente ms especfico, y se
refiere a alguien que tendr acceso a una aplicacin de negocio,
como se expres aqu anteriormente. El trmino usuario es ms
amplio, y podra referirse a cuentas administrativas y cuentas
para acceso a plataformas.
Gestin de soporte al usuario final-Responsable del enlace
entre el departamento de SI y los usuarios finales.
Gestin de datos-Responsable de la arquitectura de los datos
en los ambientes ms grandes de TI y encargado de gestionar
los datos como un activo corporativo.
Gestin de aseguramiento de la calidad (QA}--Responsable
de negociar y facilitar actividades de calidad en todas las reas
de tecnologa de informacin.
Gestin de la seguridad de la informacin-Esta es una
funcin que generalmente se debe separar del departamento
de SI y debe estar encabezada por un CISO. El CISO puede
reportar al CIO o tener una relacin indirecta (reporte indirecto)
con el CIO. Incluso cuando el oficial de seguridad se reporta al
CIO, existe una posibilidad de conflicto, ya que las metas del
CIO son proporcionar de modo eficiente servicios continuos
de TI, mientras que el CISO puede estar menos interesado en
la reduccin de costos si esto tiene un impacto en la calidad de
la proteccin.
Gestin de proveedores y contratistas de
externallzacln
Con el aumento de externalizacin, que incluye el uso de
mltiples proveedores, el personal dedicado puede estar obligado
a gestionar proveedores y contratistas de servicios externos,
incluyendo realizar las siguientes funciones:
Actuar como el primer contacto para el vendedor y el contratista
de externalizacin dentro de la funcin de SI
Proveer indicaciones al contratista de externalizacin sobre los
problemas y escalar internamente dentro de la organizacin y la
funcin de SI
Monitorear y reportar sobre los niveles de servicio a la gerencia
Revisar los cambios al contrato debidos a nuevos
requerimientos y obtener aprobaciones de SI
Operaciones y mantenimiento de infraestructura
El gerente de operaciones es responsable del personal de
operaciones informticas. Esto incluye todo el personal
requerido para operar las computadoras de las instalaciones
de procesamiento de informacin (IPF) de manera eficiente y
efectiva (por ejemplo, operadores de computadora, cintotecarios,
programadores y personal de control de datos). Las instalaciones
de procesamiento de informacin (IPF) incluyen la computadora,
los perifricos, los medios magnticos y los datos almacenados
en los medios. Constituye una inversin importante de activos
y tiene un impacto en la capacidad de la organizacin para
funcionar eficazmente. La sala de computadoras debe tener
seguridad y slo el personal autorizado debe tener acceso a
la misma. Nadie con excepcin del personal de operaciones,
122
debe tener acceso a las instalaciones. Dentro de las operaciones
informticas, los controles de gestin se pueden subdividir en tres
categoras relacionadas con la seguridad fisica, la seguridad de los
datos y los controles de procesamiento.
El grupo de control es responsable de la recoleccin, conversin
y control del ingreso de datos y el balanceo y distribucin de
los datos salientes a la comunidad de usuarios. El supervisor del
grupo de control usualmente reporta al gerente de operaciones
de las instalaciones de procesamiento de informacin (IPF). El
grupo de control de entrada/salida debe estar en un rea separada
donde slo se permita personal autorizado, ya que ellos manejan
datos sensibles.
Gestin de medios
La gestin de medios se requiere para registrar, emitir, recibir
y salvaguardar todos los archivos de programa y de datos que
se mantienen en medios extrables. Dependiendo del tamao de
la organizacin, esta funcin se puede asignar a un individuo a
tiempo completo o a un miembro de operaciones que tambin
desempee otras funciones.
Esta es una funcin crucial y por tanto, muchas organizaciones le
proveen soporte adicional mediante el uso de software que ayuda
a mantener el inventario as como tambin maneja el movimiento
de medios de almacenamiento. El uso de este software tambin
ayuda a mantener el control de versiones y la gestin de
configuracin de los programas.
Ingreso de datos
El ingreso de datos es crtico para la actividad de procesamiento
de informacin. El ingreso de datos puede incluir ingreso en lote
o ingreso en lnea.
En la mayora de las organizaciones, el personal de los
departamentos de usuarios hace su propio ingreso de datos en
lnea. En muchos ambientes en lnea, los datos son capturados
desde la fuente original (por ejemplo, ntercambio electrnico
de datos [EDI], datos capturados va cdigos de barra para
gestin de tiempo, inventario de almacenes por departamento).
El departamento de usuarios as como tambin la aplicacin
del sistema deben tener implantados controles para asegurar
que los datos estn validados, sean correctos, estn completos y
autorizados.
Con el avance de la tecnologa y la necesidad de adquirir datos
desde que se originan, las organizaciones estn desplegando
sistemas automatizados para la adquisicin de datos. Estos
sistemas incluyen lectores de cdigo de barras, o sistemas a los
que se hace referencia como SCADA (Adquisicin de datos,
supervisin y control). El trmino SCADA comnmente se
refiere a sistemas centralizados los cuales monitorean y controlan
sitios enteros, o a complejos de sistemas propagados en reas
grandes (en la escala de kilmetros o millas). La mayor parte
del control del sitio se realiza automticamente por terminales
remotos (RTUs) o por controladores lgicos programables
(PLCs). Las funciones de control del anfitrin (host) suelen
restringirse a autorizaciones bsicas del sitio o intervencin a
nivel de supervisin. Por ejemplo, medir y controlar la extraccin
Certilled Information
CISA Systerns Auditor'
Seccin Dos: Contenido Captulo 2 - Gobierno y Gestin de TI
An %ACP' Cal-11.11w
de petrleo de plataformas petrolferas o controlar la temperatura
y el flujo de agua, etc.
La adquisicin de datos comienza en el nivel de RTU o PLC e
incluye lecturas de medidores y reportes de estado de equipos
que se comunican a SCADA segn se requiera. Luego, los datos
se compilan y formatean de tal manera que un operador de la
sala de control utilizando redes de interfaces hombre-mquina
(HMI) puede tomar decisiones de supervisin para ajustar o
anular controles de RTU (PLC) normales. Los datos tambin se
pueden ingresar a un registro histrico, comnmente creado en un
sistema de gestin de bases de datos de uso general, para permitir
anlisis de tendencias y otras auditoras analticas.
Administracin de sistemas
El administrador de sistemas es responsable de mantener los
principales sistemas informticos de multiusuario, incluyendo
redes de rea local (LANs), redes inalmbricas de rea local
(WLANs), redes de rea amplia (WANs), redes de rea personal
(PANs), redes de rea de almacenamiento (SANs), intranets
y extranets, y sistemas de rango medio, adems de sistemas
mainframe. Sus deberes tpicos incluyen:
Agregar y configurar nuevas estaciones de trabajo y perifricos
Establecer cuentas de usuarios
Instalar software en todo el sistema
Realizar procedimientos para prevenir/detectar/corregir la
divulgacin de virus
Asignar espacio de almacenamiento masivo
Las organizaciones pequeas pueden tener slo un administrador
de sistemas, mientras que las organizaciones ms grandes tienen
por lo general un equipo de administradores de sistemas. Algunas
organizaciones centradas en mainframes pueden referirse a un
administrador de sistemas como un programador de sistemas.
Administracin de la seguridad
La administracin de seguridad comienza con el compromiso de
la gerencia. La gerencia debe entender y evaluar los riesgos de la
seguridad y debe desarrollar y hacer cumplir una poltica escrita
que establezca con claridad los estndares y los procedimientos
que se deben seguir. Las funciones del administrador de
seguridad deben estar definidas en la poltica. Para proveer
una adecuada segregacin de funciones, esta persona debe ser
un empleado de tiempo completo que reporte directamente al
director de la instalacin. Sin embargo, en una empresa pequea,
puede no ser prctico contratar a una persona de tiempo completo
para esta posicin. La persona que realice esta funcin debe
asegurar que los diferentes usuarios estn cumpliendo con la
poltica de seguridad corporativa y que los controles sean los
adecuados para prevenir el acceso no autorizado a los activos de la
compaa (incluyendo datos, programas y equipos). Usualmente,
las funciones del administrador de seguridad incluyen:
Mantener las reglas de acceso a los datos y a otros recursos de TI.
Mantener la seguridad y la confidencialidad sobre la emisin y
mantenimiento de las identificaciones de usuario y contraseas
(passwords).
Monitorear las violaciones de seguridad y aplicar acciones
correctivas para asegurar que se provea la seguridad adecuada.
Revisar y evaluar peridicamente la poltica de seguridad y
sugerir a la gerencia los cambios necesarios.
Preparar y monitorear el programa de concienciacin sobre la
seguridad para todos los empleados.
Probar la arquitectura de seguridad para evaluar la fortaleza de
la seguridad y para detectar las posibles amenazas.
Trabajar con la gestin de cumplimiento, de riesgos y las
funciones de auditora para asegurar que la seguridad est
diseada de manera apropiada y actualizada sobre la base de
retroalimentacin de auditora o de pruebas.
Aseguramiento de la calidad
El personal de aseguramiento de la calidad realiza usualmente
dos funciones distintas, a saber:
Aseguramiento de la calidad (QA)Ayuda al departamento
de SI a asegurar que el personal est siguiendo los procesos de
calidad establecidos. Por ejemplo, QA ayudar a asegurar que
los programas y documentacin se adhieren a los estndares y
convenciones de nomenclatura.
Control de calidad (QC)Responsable de realizar las
pruebas o revisiones para verificar y asegurar que el software
est libre de defectos y llene las expectativas del usuario. Esto
podra hacerse en varias etapas del desarrollo de un sistema de
aplicacin, pero debe hacerse antes de que los programas sean
llevados a produccin.
El grupo de QA est encargado de desarrollar, promulgar y
mantener estndares para la funcin de SI. Esto incluye la
capacitacin en estndares y procedimientos de QA. El grupo de
QA puede tambin apoyar mediante la verificacin peridica la
exactitud y autenticidad de los datos ingresados, el procesamiento
y el resultado de las diversas aplicaciones.
Para que este grupo pueda cumplir un papel efectivo debe ser
independiente. En algunas organizaciones, este grupo puede
ser parte del grupo de control. En organizaciones ms pequeas
puede no ser posible tener un grupo de QA separado, en cuyo
caso las personas pueden tener ms de una funcin. Sin embargo,
bajo ninguna circunstancia debe ser efectuado por una persona
cuya funcin est en conflicto, por ejemplo, programador de
sistemas que realiza una revisin de calidad de los cambios del
sistema de aplicacin.
Administracin de base de datos
El administrador de base de datos (DBA) como custodio de
los datos de una organizacin, define y mantiene la estructura
de los datos en el sistema de base de datos corporativo. El
DBA debe tener una comprensin de la organizacin y de los
requerimientos de datos del usuario y de la relacin entre los
datos (estructura). Esta posicin es responsable de la seguridad de
los datos compartidos almacenados en la base de datos. El DBA
es responsable del diseo real, la definicin y el mantenimiento
adecuado de las bases de datos corporativas. Usualmente, el DBA
reporta directamente al director del IPF. El rol del DBA incluye:
Especificar la definicin fsica de los datos (orientados a la
computadora).
Cambiar la definicin fisica de datos para mejorar el
desempeo.
Seleccionar e implementar herramientas de optimizacin de la
base de datos.
A Captulo 2 - Gobierno y Gestin de TI
o ....... "",. .....
de petrleo de plataformas petrolferas o controlar la temperatura
y el flujo de agua, etc.
La adquisicin de datos comienza en el nivel de RTU o PLC e
incluye lecturas de medidores y reportes de estado de equipos
que se comunican a SCADA segn se requiera. Luego, los datos
se compilan y formatean de tal manera que un operador de la
sala de control utilizando redes de interfaces hombre-mquina
(HMI) puede tomar decisiones de supervisin para ajustar o
anular controles de RTU (PLC) normales. Los datos tambin se
pueden ingresar a un registro histrico, comnmente creado en un
sistema de gestin de bases de datos de uso general, para permitir
anlisis de tendencias y otras auditoras analticas.
Administracin de sistemas
El administrador de sistemas es responsable de mantener los
principales sistemas informticos de multiusuario, incluyendo
redes de rea local (LANs), redes inalmbricas de rea local
(WLANs), redes de rea amplia (WANs), redes de rea personal
(PANs), redes de rea de almacenamiento (SANs), intranets
y extranets, y sistemas de rango medio, adems de sistemas
mainframe. Sus deberes tpicos incluyen:
Agregar y configurar nuevas estaciones de trabajo y perifricos
Establecer cuentas de usuarios
Instalar software en todo el sistema
Realizar procedimientos para prevenir/detectar/corregir la
divulgacin de virus
Asignar espacio de almacenamiento masivo
Las organizaciones pequeas pueden tener slo un administrador
de sistemas, mientras que las organizaciones ms grandes tienen
por lo general un equipo de administradores de sistemas. Algunas
organizaciones centradas en mainframes pueden referirse a un
administrador de sistemas como un programador de sistemas.
Administracin de la seguridad
La administracin de seguridad comienza con el compromiso de
la gerencia. La gerencia debe entender y evaluar los riesgos de la
seguridad y debe desarrollar y hacer cumplir una poltica escrita
que establezca con claridad los estndares y los procedimientos
que se deben seguir. Las funciones del administrador de
seguridad deben estar definidas en la poltica. Para proveer
una adecuada segregacin de funciones, esta persona debe ser
un empleado de tiempo completo que reporte directamente al
director de la instalacin. Sin embargo, en una empresa pequea,
puede no ser prctico contratar a una persona de tiempo completo
para esta posicin. La persona que realice esta funcin debe
asegurar que los diferentes usuarios estn cumpliendo con la
poltica de seguridad corporativa y que Jos controles sean Jos
adecuados para prevenir el acceso no autorizado a los activos de la
compaa (incluyendo datos, programas y equipos). Usualmente,
las funciones del administrador de seguridad incluyen:
Mantener las reglas de acceso a Jos datos y a otros recursos de TI.
Mantener la seguridad y la confidencialidad sobre la emisin y
mantenimiento de las identificaciones de usuario y contraseas
(passwords).
Monitorear las violaciones de seguridad y aplicar acciones
correctivas para asegurar que se provea la seguridad adecuada.
Revisar y evaluar peridicamente la poltica de seguridad y
sugerir a la gerencia los cambios necesarios.
Preparar y monitorear el programa de concienciacin sobre la
seguridad para todos Jos empleados.
Probar la arquitectura de seguridad para evaluar la fortaleza de
la seguridad y para detectar las posibles amenazas.
Trabajar con la gestin de cumplimiento, de riesgos y las
funciones de auditora para asegurar que la seguridad est
diseada de manera apropiada y actualizada sobre la base de
retroalimentacin de auditora o de pruebas.
Aseguramiento de la calidad
El personal de aseguramiento de la calidad realiza usualmente
dos funciones distintas, a saber:
Aseguramiento de la calidad (QA)-Ayuda al departamento
de SI a asegurar que el personal est siguiendo los procesos de
calidad establecidos. Por ejemplo, QA ayudar a asegurar que
los programas y documentacin se adhieren a los estndares y
convenciones de nomenclatura.
Control de calidad (QC}-Responsable de realizar las
pruebas o revisiones para verificar y asegurar que el software
est libre de defectos y llene las expectativas del usuario. Esto
podra hacerse en varias etapas del desarrollo de un sistema de
aplicacin, pero debe hacerse antes de que los programas sean
llevados a produccin.
El grupo de QA est encargado de desarrollar, promulgar y
mantener estndares para la funcin de SI. Esto incluye la
capacitacin en estndares y procedimientos de QA. El grupo de
QA puede tambin apoyar mediante la verificacin peridica la
exactitud y autenticidad de los datos ingresados, el procesamiento
y el resultado de las diversas aplicaciones.
Para que este grupo pueda cumplir un papel efectivo debe ser
independiente. En algunas organizaciones, este grupo puede
ser parte del grupo de control. En organizaciones ms pequeas
puede no ser posible tener un grupo de QA separado, en cuyo
caso las personas pueden tener ms de una funcin. Sin embargo,
bajo ninguna circunstancia debe ser efectuado por una persona
cuya funcin est en conflicto, por ejemplo, programador de
sistemas que realiza una revisin de calidad de los cambios del
sistema de aplicacin.
Administracin de base de datos
El administrador de base de datos (DBA) como custodio de
Jos datos de una organizacin, define y mantiene la estructura
de los datos en el sistema de base de datos corporativo. El
DBA debe tener una comprensin de la organizacin y de los
requerimientos de datos del usuario y de la relacin entre Jos
datos (estructura). Esta posicin es responsable de la seguridad de
Jos datos compartidos almacenados en la base de datos. El DBA
es responsable del diseo real, la definicin y el mantenimiento
adecuado de las bases de datos corporativas. Usualmente, el DBA
reporta directamente al director del IPF. El rol del DBA incluye:
Especificar la definicin fisica de los datos (orientados a la
computadora).
Cambiar la definicin fisica de datos para mejorar el
desempeo.
Seleccionar e implementar herramientas de optimizacin de la
base de datos.
123
CISA Itled elT IS 1=1 "
IS P er C er L i m
P r obar y evaluar her r am i entas de los pr ogr am ador es y de
opti m i zaci n.
Responder las consultas de los pr ogr am ador es y for m ar los
acer ca de las estr uctur as de la base de datos.
Im plem entar los contr oles de defi ni ci n, acceso, actuali zaci n y
concur r enci a de la base de datos.
Moni tor ear el uso de la base de datos, r ecopi lar estadsti cas de
desem peo, y ajustar la base de datos.
Defi ni r e i ni ci ar los pr ocedi m i entos de r espaldo y de
r ecuper aci n.
El DBA ti ene las her r am i entas par a establecer los contr oles
sobr e la base de datos y la capaci dad de i gnor ar estos contr oles.
El DBA ti ene tam bi n la capaci dad de tener acceso a todos los
datos, i ncluyendo los datos de pr oducci n. Usualm ente no es
pr cti co pr ohi bi r o i m pedi r por com pleto el acceso por par te del
DBA a los datos de pr oducci n. P or lo tanto, el depar tam ento de
S Idebe ejer cer un contr ol estr i cto sobr e la adm i ni str aci n de la
base de datos m edi ante:
S egr egaci n de funci ones
Apr obaci n de las acti vi dades del DBA por par te de la ger enci a
Revi si n de los r egi str os de acceso y acti vi dades por par te del
super vi sor
C ontr oles de detecci n sobr e el uso de las her r am i entas de la
base de datos
Analista de sistemas
Los analistas de sistemas son especi ali stas que di sean si stem as
basados en las necesi dades del usuar i o. Gener alm ente par ti ci pan
dur ante la fase i ni ci al del ci clo de vi da de desar r ollo de los
si stem as (S DL C ). Estas per sonas i nter pr etan las necesi dades del
usuar i o y desar r ollan los r equer i m i entos y las especi fi caci ones
funci onales y docum entos de di seo de alto ni vel. Estos
docum entos per m i ten que los pr ogr am ador es cr een una
apli caci n especfi ca.
Arquitecto de seguridad
L os arquitectos de seguridad evalan tecnologas de segur i dad;
di sean aspectos de segur i dad de topologa de la r ed, contr oles
de acceso, gesti n de i denti dades y otr os si stem as de segur i dad;
y establecen polti cas y r equer i m i entos de segur i dad. S e puede
ar gum entar que los anali stas de si stem as r eali zan la m i sm a
funci n, si n em bar go, los conjuntos de destr ezas r equer i das son
m uy di fer entes. S us pr oductos (por ejem plo, especi fi caci ones
de pr ogr am a vs. polti cas, r equer i m i entos, di agr am as de
ar qui tectur a) tam bi n son di fer entes. L os ar qui tectos de segur i dad
deber an tam bi n tr abajar con la gesti n de cum pli m i ento,
de r i esgos y las funci ones de audi tor a par a i ncor por ar sus
r equer i m i entos y r ecom endaci ones par a la segur i dad en las
polti cas y la ar qui tectur a de segur i dad.
Desarrollo y mantenimiento de aplicaciones
El personal de aplicaciones es r esponsable de desar r ollar y
m antener las apli caci ones. El desar r ollo puede i nclui r desar r ollar un
nuevo cdi go o cam bi ar la confi gur aci n de la apli caci n exi stente.
Ellos desar r ollan los pr ogr am as o cam bi an la confi gur aci n de
la apli caci n que en lti m a i nstanci a cor r er n en un entor no de
pr oducci n. P or lo tanto, la ger enci a debe asegur ar que el per sonal
no pueda m odi fi car los pr ogr am as de pr oducci n ni los datos
de apli caci n. Ellos deben tr abajar ni cam ente en un am bi ente
de pr ueba y deben entr egar su tr abajo a otr o gr upo que lleve los
pr ogr am as y los cam bi os de apli caci n al am bi ente de pr oducci n.
Desarrollo y mantenimiento de infraestructura
El personal de infraestructura es r esponsable de m antener
el softwar e de si stem as, i ncluyendo el si stem a oper ati vo. Esta
funci n puede r equer i r que ellos tengan acceso i r r estr i cto a todo el
si stem a. L a gesti n de S Idebe m oni tor ear de cer ca sus acti vi dades
r equi r i endo que ellos lleven r egi str os electr ni cos de esta acti vi dad
y que no sean suscepti bles de cam bi o. El per sonal de i nfr aestr uctur a
slo debe tener acceso a las li br er as de si stem as del softwar e
especfi co que ellos m anti enen. El uso de la adm i ni str aci n
de dom i ni os y de cuentas de sper usuar i os debe contr olar se y
m oni tor ear se m uy de cer ca.
Gestin de red
Hoy m uchas or gani zaci ones ti enen IP Fs am pli am ente
descentr ali zadas. P ueden tener una IP F centr al, per o tam bi n
hacen un uso extensi vo de:
L ANsRedes de r ea local en sucur sales y en si ti os di stantes.
WANsRedes de r ea am pli a (WANs) donde los L ANs se
pueden i nter conectar par a conveni enci a de acceso del per sonal
autor i zado desde otr os lugar es.
Redes inalmbricasEstablecidas a tr avs de asi stentes
di gi tales per sonales (P DAs) y otr os di sposi ti vos m vi les.
L os administradores de red son r esponsables de los
com ponentes clave de esta i nfr aestr uctur a, (enr utador es
(r outer s), conm utador es, cor tafuegos (fi r ewalls), segm entaci n
de r edes, gesti n de desem peo, acceso r em oto, etc.). Es
posi ble que cada L AN r equi er a de un adm i ni str ador debi do
a la di sper si n geogr fi ca. Dependi endo de la polti ca de la
com paa, estos adm i ni str ador es pueden r epor tar al di r ector
del IP F o, en una oper aci n descentr ali zada, pueden r epor tar le
al ger ente de usuar i os fi nales. Esta posi ci n es r esponsable del
contr ol tcni co y adm i ni str ati vo sobr e la L AN. Esto i ncluye
asegur ar que los enlaces de tr ansm i si n estn funci onando
cor r ectam ente, que las copi as de r espaldo del si stem a se
estn haci endo y que las com pr as de softwar e/har dwar e estn
autor i zadas y sean i nstaladas debi dam ente. En i nstalaci ones
pequeas, esta per sona puede ser r esponsable de la
adm i ni str aci n de la segur i dad sobr e la L AN. El adm i ni str ador
de L AN no debe tener r esponsabi li dades de pr ogr am aci n
de apli caci ones, per o puede tener r esponsabi li dades de
pr ogr am aci n de si stem as y usuar i o fi nal.
2.11.2 SEGREGACIN DE FUNCIONES DENTRO DE SI
L os ttulos de puestos de tr abajo r eales y estr uctur as
or gani zaci onales var an m ucho de una or gani zaci n a otr a,
dependi endo del tam ao y de la natur aleza del negoci o. S i n
em bar go, es i m por tante que un audi tor de S Iobtenga i nfor m aci n
par a valor ar la r elaci n entr e las funci ones, r esponsabi li dad y
autor i dad de los puestos de tr abajo, par a valor ar la adecuada
segr egaci n de funci ones. L a segr egaci n de funci ones evi ta
la posi bi li dad de que una sola per sona pueda ser r esponsable
de funci ones di ver sas y cr ti cas de tal for m a que pudi er an
ocur r i r er r or es o apr opi aci ones i ndebi das y no ser detectadas
opor tunam ente, en el cur so nor m al de los pr ocesos de negoci o.
124 Manual de Preparacin al Examen CISA 2012
Capitulo 2. Gobierno y Gestin de TI e
Probar y evaluar herramientas de los programadores y de
optimizacin.
Responder las consultas de los programadores y formarlos
acerca de las estructuras de la base de datos.
Implementar los controles de definicin, acceso, actualizacin y
concurrencia de la base de datos.
Monitorear el uso de la base de datos, recopilar estadsticas de
desempeo, y ajustar la base de datos.
Definir e iniciar los procedimientos de respaldo y de
recuperacin.
El DBA tiene las herramientas para establecer los controles
sobre la base de datos y la capacidad de ignorar estos controles.
El DBA tiene tambin la capacidad de tener acceso a todos los
datos, incluyendo los datos de produccin. Usualmente no es
prctico prohibir o impedir por completo el acceso por parte del
DBA a los datos de produccin. Por lo tanto, el departamento de
SI debe ejercer un control estricto sobre la administracin de la
base de datos mediante:
Segregacin de funciones
Aprobacin de las actividades del DBA por parte de la gerencia
Revisin de los registros de acceso y actividades por parte del
supervisor
Controles de deteccin sobre el uso de las herramientas de la
base de datos
Analista de sistemas
Los analistas de sistemas son especialistas que disean sistemas
basados en las necesidades del usuario. Generalmente participan
durante la fase inicial del ciclo de vida de desarrollo de los
sistemas (SDLC). Estas personas interpretan las necesidades del
usuario y desarrollan los requerimientos y las especificaciones
funcionales y documentos de diseo de alto nivel. Estos
documentos permiten que los programadores creen una
aplicacin especfica.
Arquitecto de seguridad
Los arquitectos de seguridad evalan tecnologas de seguridad;
disean aspectos de seguridad de topologa de la red, controles
de acceso, gestin de identidades y otros sistemas de seguridad;
y establecen polticas y requerimientos de seguridad. Se puede
argumentar que los analistas de sistemas realizan la misma
funcin, sin embargo, los conjuntos de destrezas requeridas son
muy diferentes. Sus productos (por ejemplo, especificaciones
de programa vs. polticas, requerimientos, diagramas de
arquitectura) tambin son diferentes. Los arquitectos de seguridad
deberan tambin trabajar con la gestin de cumplimiento,
de riesgos y las funciones de auditora para incorporar sus
requerimientos y recomendaciones para la seguridad en las
polticas y la arquitectura de seguridad.
Desarrollo y mantenimiento de aplicaciones
El personal de aplicaciones es responsable de desarrollar y
mantener las aplicaciones. El desarrollo puede incluir desarrollar un
nuevo cdigo o cambiar la configuracin de la aplicacin existente.
Ellos desarrollan los programas o cambian la configuracin de
la aplicacin que en ltima instancia corrern en un entorno de
produccin. Por lo tanto, la gerencia debe asegurar que el personal
no pueda modificar los programas de produccin ni los datos
124
de aplicacin. Ellos deben trabajar nicamente en un ambiente
de prueba y deben entregar su trabajo a otro grupo que lleve los
programas y los cambios de aplicacin al ambiente de produccin.
Desarrollo y mantenimiento de infraestructura
El personal de infraestructura es responsable de mantener
el software de sistemas, incluyendo el sistema operativo. Esta
funcin puede requerir que ellos tengan acceso irrestricto a todo el
sistema. La gestin de SI debe monitorear de cerca sus actividades
requiriendo que ellos lleven registros electrnicos de esta actividad
y que no sean susceptibles de cambio. El personal de infraestructura
slo debe tener acceso a las libreras de sistemas del software
especfico que ellos mantienen. El uso de la administracin
de dominios y de cuentas de sper usuarios debe controlarse y
monitorearse muy de cerca.
Gestin de red
Hoy muchas organizaciones tienen IPFs ampliamente
descentralizadas. Pueden tener una IPF central, pero tambin
hacen un uso extensivo de:
LANs-Redes de rea local en sucursales y en sitios distantes.
WANs--Redes de rea amplia (WANs) donde los LANs se
pueden interconectar para conveniencia de acceso del personal
autorizado desde otros lugares.
Redes inalmbricas-Establecidas a travs de asistentes
digitales personales (PDAs) y otros dispositivos mviles.
Los administradores de red son responsables de los
componentes clave de esta infraestructura, ( enrutadores
(routers), conmutadores, cortafuegos (firewalls), segmentacin
de redes, gestin de desempeo, acceso remoto, etc.). Es
posible que cada LAN requiera de un administrador debido
a la dispersin geogrfica. Dependiendo de la poltica de la
compaa, estos administradores pueden reportar al director
del IPF o, en una operacin descentralizada, pueden reportarle
al gerente de usuarios finales. Esta posicin es responsable del
control tcnico y administrativo sobre la LAN. Esto incluye
asegurar que los enlaces de transmisin estn funcionando
correctamente, que las copias de respaldo del sistema se
estn haciendo y que las compras de software/hardware estn
autorizadas y sean instaladas debidamente. En instalaciones
pequeas, esta persona puede ser responsable de la
administracin de la seguridad sobre la LAN. El administrador
de LAN no debe tener responsabilidades de programacin
de aplicaciones, pero puede tener responsabilidades de
programacin de sistemas y usuario final.
2.11.2 SEGREGACIN DE FUNCIONES DENTRO DE SI
Los ttulos de puestos de trabajo reales y estructuras
organizacionales varan mucho de una organizacin a otra,
dependiendo del tamao y de la naturaleza del negocio. Sin
embargo, es importante que un auditor de SI obtenga informacin
para valorar la relacin entre las funciones, responsabilidad y
autoridad de los puestos de trabajo, para valorar la adecuada
segregacin de funciones. La segregacin de funciones evita
la posibilidad de que una sola persona pueda ser responsable
de funciones diversas y crticas de tal forma que pudieran
ocurrir errores o apropiaciones indebidas y no ser detectadas
oportunamente, en el curso normal de los procesos de negocio.
Certilied form
r
tion a
CISA Sy In u d stems Aito
AnC....
G
r
u
p
o

d
e

c
o
n
t
r
o
l

A
n
a
l
i
s
t
a

d
e

s
i
s
t
e
m
a
s

P
r
o
g
r
a
m
a
d
o
r

d
e

a
p
l
i
c
a
c
i
o
n
e
s

M
e
s
a

d
e

a
y
u
d
a

y

=

L
E

G
e
r
e
n
t
e

d
e

S
o
p
o
r
t
e

U
s
u
a
r
i
o

f
i
n
a
l

O
p
e
r
a
d
o
r

d
e

E
:

c
o
m
p
u
t
a
d
o
r
a
s

B
a
s
e

d
e

d
a
t
o
s

o

C
D

C
D

1111
.S
i
s
t
e
m
a
s

A
d
m
i
n
i
s
t
r
a
d
o
r

d
e

l
a

S
e
g
u
r
i
d
a
d

P
r
o
g
r
a
m
a
d
o
r

d
e

s
i
s
t
e
m
a
s

A
s
e
g
u
r
a
m
i
e
n
t
o

d
e

l
a

c
a
l
i
d
a
d

G r u p o d e c on tr ol X X X X X X X X X
A n a lista d e
siste m a s
X X X X X X
P r og r a m a d or
d e a p lic a c ion e s
X X X X X X X X X X X
M e sa d e a y u d a y
G e r e n te d e S op or te
X X X X X X X X X
U su a r io fin a l X X X X X X X X
In g r e so d e d a tos X X X X X X X X X
O p e r a d or d e
c om p u ta d or a s
X X X X X X X X X X
A d m in istr a d or d e
la b a se d e d a tos
X X X X X X X X X
r e d e s
X X X X X X X
siste m a s
X X X X X X X
la S e g u r id a d
X X X X X
P r og r a m a d or d e
siste m a s
X X X X X X X X X X
A se g u r a m ie n to d e
la c a lid a d
X X X X
X L a c om b in a c in d e e sta s fu n c ion e s p u e d e c r e a r u n a p osib le d e b ilid a d d e c on tr ol.
La segregacinde funciones es unimportante medio por el cual
se puedenprevenir y disuadir actos fraudulentos y/o maliciosos.
Las funciones que debenser segregadas incluyen:
Custodia de los activos.
Autorizacin.
Registro de transacciones.
Si no existiera una segregacinde funciones adecuada, podra
ocurrir lo siguiente:
Apropiacinindebida de activos.
Estados financieros falsos.
Documentacinfinanciera inexacta (por ejemplo, errores o
irregularidades).
Uso indebido de fondos o la modificacinde datos podra pasar
inadvertida.
Es posible que no se detectencambios o modificaciones de
datos y programas no autorizados y errneos.
Cuando las funciones estnsegregadas, se puedenrestringir los
accesos a la computadora, la biblioteca de datos de produccin,
los programas de produccin, la documentacinde programacin,
el sistema operativo y sus utilitarios asociados. El dao potencial
por las acciones de cualquier persona queda por lo tanto reducido.
Los departamentos de SI y de usuarios finales debenorganizarse
para lograr una adecuada segregacinde funciones. Vase la
figura 2.13, para obtener una directriz de las responsabilidades
de trabajo que no deberanser combinadas.
Nota: La matriz de control de segregacinde funciones
(figura 2.13) no es unestndar de la industria, sino una
directriz que indica cules posiciones de debenseparar y cules
requierencontroles de compensacincuando se combinan.
La matriz describe posibles problemas de la segregacinde
funciones y no se debe ver o usar como una verdad absoluta;
por el contrario, se debe usar para ayudar a identificar posibles
conflictos de manera que se puedanplantear las preguntas
apropiadas para identificar controles de compensacin.
Enla prctica real, las funciones y designaciones puedenvariar
endiferentes empresas. Adems, dependiendo de la naturaleza
de los procesos de negocio y de la tecnologa desplegada, los
riesgos puedenvariar. Sinembargo, es importante que unauditor
de SI entienda las funciones de cada una de las designaciones
especificadas enel manual. Los auditores de SI necesitan
entender el riesgo de combinar funciones indicadas enla matriz
de control de segregacinde funciones. Adems, dependiendo de
e
eertifiedlntormatioo e , 1 2 G b' G t', d ... ,
A ap1tu o - o 1erno y es 10n e , .
Figura 2.13-Matriz de segregacin de funciones
>-

"C
"'
.,
"'
"C
.S
l5"
-g

"C {

l5{g
l5 "-e
"'
"C Q

"'
ii

"'
"C
l5]l
"C

&:S
]!
ca=

. Q

""'
{l
E

8''
i
g "C
"'
e .!S!

=>'-'

:!i
d:{l E
c. o
"'
"C "'
"'"C O u
"'
e:: en <-e
Grupo de control X X X X X X X X X
Analista de
X X X X X X
sistemas
Programador
X X X X X X X X X X X
de aplicaciones
Mesa de ayuda y
X X X X X X X X X
Gerente de Soporte
Usuario final X X X X X X X X
Ingreso de datos X X X X X X X X X
Operador de
X X X X X X X X X X
computadoras
Administrador de
la base de datos
X X X X X X X X X
Administrador de
X X X X X X X
redes
Administrador de
X X X X X X X
sistemas
Administrador de
X X X X X
la Seguridad
Programador de
X X X X X X X X X X
sistemas
Aseguramiento de
X X X X
la calidad
X-La combinacin de estas funciones puede crear una posible debilidad de control.
La segregacin de funciones es un importante medio por el cual
se pueden prevenir y disuadir actos fraudulentos y/o maliciosos.
Las funciones que deben ser segregadas incluyen:
Custodia de los activos.
Autorizacin.
Registro de transacciones.
Si no existiera una segregacin de funciones adecuada, podra
ocurrir lo siguiente:
Apropiacin indebida de activos.
Estados financieros falsos.
Documentacin financiera inexacta (por ejemplo, errores o
irregularidades).
Uso indebido de fondos o la modificacin de datos podra pasar
inadvertida.
Es posible que no se detecten cambios o modificaciones de
datos y programas no autorizados y errneos.
Cuando las funciones estn segregadas, se pueden restringir los
accesos a la computadora, la biblioteca de datos de produccin,
los programas de produccin, la documentacin de programacin,
el sistema operativo y sus utilitarios asociados. El dao potencial
por las acciones de cualquier persona queda por lo tanto reducido.
Los departamentos de SI y de usuarios finales deben organizarse
para lograr una adecuada segregacin de funciones. Vase la
figura 2.13, para obtener una directriz de las responsabilidades
de trabajo que no deberan ser combinadas.
Nota: La matriz de control de segregacin de funciones
(figura 2.13) no es un estndar de la industria, sino una
directriz que indica cules posiciones de deben separar y cules
requieren controles de compensacin cuando se combinan.
La matriz describe posibles problemas de la segregacin de
funciones y no se debe ver o usar como una verdad absoluta;
por el contrario, se debe usar para ayudar a identificar posibles
conflictos de manera que se puedan plantear las preguntas
apropiadas para identificar controles de compensacin.
En la prctica real , las funciones y designaciones pueden variar
en diferentes empresas. Adems, dependiendo de la naturaleza
de los procesos de negocio y de la tecnologa desplegada, los
riesgos pueden variar. Sin embargo, es importante que un auditor
de SI entienda las funciones de cada una de las designaciones
especificadas en el manual. Los auditores de SI necesitan
entender el riesgo de combinar funciones indicadas en la matriz
de control de segregacin de funciones. Adems, dependiendo de
, P.-.
'""';..H1
125
CISA
Cerned Information
ems Auditor
An lucre cartrikation
la complejidad de las aplicaciones y de los sistemas desplegados,
se puede requerir una herramienta automatizada para evaluar el
acceso real que tiene un usuario contra la matriz de la segregacin
de funciones. La mayora de las herramientas vienen con una
matriz de segregacin de funciones predefinidas que deben ser
adaptadas a los procesos de TI y de negocio de una organizacin,
incluyendo cualquier funcin adicional o riesgos que no estn
incluidos en la matriz de segregacin de funciones entregada.
Los controles compensatorios son controles internos que
pretenden reducir el riesgo de una debilidad existente o potencial
de control cuando las funciones no pueden ser segregadas de
una manera apropiada. La estructura de la organizacin y las
funciones deben ser tomadas en cuenta para determinar los
controles apropiados para el ambiente relevante. Por ejemplo,
una organizacin puede no tener todas las posiciones descritas en
la matriz o una persona puede ser responsable de muchas de las
funciones descritas. El tamao del departamento de SIITI puede
tambin ser un factor importante que se debe considerar, es decir,
ciertas combinaciones de funciones en un departamento de TI
de un cierto tamao nunca se deberan usar. Sin embargo, si por
alguna razn se requieren funciones combinadas, entonces se
deben describir controles de mitigacin.
El propsito de la segregacin de funciones es reducir o eliminar
los riesgos de negocio a travs de la identificacin de controles
compensatorios. La magnitud y probabilidad de riesgo se puede
valorar desde baja hasta alta, dependiendo de la organizacin.
2.11.3 CONTROLES DE SEGREGACIN DE
FUNCIONES
Se pueden emplear varios mecanismos de control para lograr la
segregacin de funciones. Los controles estn descritos en las
siguientes secciones.
Autorizacin de transacciones
La autorizacin de transacciones es responsabilidad del
departamento de usuarios. La autorizacin es delegada en
la medida en que se relacione con el nivel particular de
responsabilidad de la persona autorizada en el departamento.
Se deben realizar verificaciones peridicas tanto por parte de la
gerencia como por parte de auditora para detectar el ingreso de
transacciones no autorizadas.
Custodia de activos
Se debe determinar y asignar debidamente la custodia de los
activos corporativos. El propietario de los datos usualmente se
asigna a un departamento de usuarios particular, y sus funciones
se deben especificar por escrito. El dueo de los datos tiene la
responsabilidad de determinar niveles de autorizacin requeridos
para proporcionar seguridad adecuada, mientras que el grupo de
administracin suele ser responsable de implementar y reforzar el
sistema de seguridad.
Acceso a los datos
Los controles sobre el acceso a los datos son provistos
mediante una combinacin de seguridad fisica, de sistemas
y de aplicaciones tanto en el rea de los usuarios como en
la IPE El ambiente fsico debe ser seguro para impedir el
acceso de personas no autorizadas a los diversos dispositivos
tangibles conectados a la unidad central de procesamiento y que
permiten as, el acceso a los datos. La seguridad del sistema
y de la aplicacin son capas adicionales de seguridad que
pueden impedir que personas no autorizadas logren acceder
a los datos corporativos. El acceso a los datos proveniente de
conexiones externas es una preocupacin creciente desde la
aparicin de Internet. Por lo tanto, la gestin de TI ha agregado
responsabilidades para proteger los activos de informacin de
acceso no autorizado.
Las decisiones de control de acceso estn basadas en la poltica
organizacional y en dos estndares de prctica generalmente
aceptadossegregacin (separacin) de funciones y el menor
privilegio. Los controles para el uso efectivo no deben alterar el
flujo usual de trabajo ms de lo necesario o colocar demasiada
carga sobre los administradores, auditores o usuarios autorizados.
El acceso adicional no debe ser incondicional y los controles de
acceso deben proteger adecuadamente todos los recursos de la
organizacin.
Las polticas establecen niveles de sensibilidad tales como secreto
mximo, secreto, confidencial y no clasificado, para los datos
y otros recursos. Estos niveles deben usarse para orientacin
sobre los procedimientos apropiados para manejar los recursos
de informacin. Ellos tambin se pueden usar como base para
las decisiones sobre control de acceso. A las personas se les
otorga acceso slo a los recursos que estn en un nivel especfico
de sensibilidad o por debajo de ste. Las etiquetas se usan para
indicar el nivel de sensibilidad de los documentos almacenados
electrnicamente. Los controles basados en polticas pueden
caracterizarse bien como obligatorios o como discrecionales.
Para obtener ms detalles, consulte la seccin Controles de
acceso obligatorios y discrecionales, en el tema Importancia de
los activos de informacin del captulo 5.
FORMULARIOS DE AUTORIZACIN
Los gerentes de los departamentos de usuarios deben proveer a
SI formularios de autorizacin formales (ya sea en copia fisica o
electrnica) en los que se definan los derechos de acceso de sus
empleados. En otras palabras, los gerentes deben definir quin
tendr acceso a qu. Los formularios de autorizacin deben ser
debidamente evidenciados con la aprobacin a nivel de gerencia.
En general, todos los usuarios deben ser autorizados a un acceso al
sistema especfico, por va de solicitud formal de la gerencia. En
las compaas grandes o en las que tienen sucursales distantes, se
deben mantener registros de firmas autorizadas y las solicitudes
formales recibidas por escrito deben ser comparadas contra el
registro de firmas. Los privilegios de acceso deben ser revisados
peridicamente para asegurar que estn actualizados y que sean
apropiados para las funciones del puesto de trabajo del usuario.
TABLAS DE AUTORIZACIN DE USUARIO
El departamento de SI debe usar los datos provenientes de los
formularios de autorizacin para crear y mantener tablas de
autorizaciones de usuarios. Estas definirn quin est autorizado
para actualizar, modificar, eliminar o consultar datos. Estos
privilegios son asignados a nivel de sistema, de transaccin o de
campo. En efecto, stas son listas de control de acceso de usuario.
Estas tablas de autorizacin deben ser protegidas contra el acceso
no autorizado mediante contraseas (passwords) adicionales
--- --------------- ---
e
. Certilied lnlormatlon
M Systems Auditor
la complejidad de las aplicaciones y de los sistemas desplegados,
se puede requerir una herramienta automatizada para evaluar el
acceso real que tiene un usuario contra la matriz de la segregacin
de funciones. La mayora de las herramientas vienen con una
matriz de segregacin de funciones predefinidas que deben ser
adaptadas a los procesos de TI y de negocio de una organizacin,
incluyendo cualquier funcin adicional o riesgos que no estn
incluidos en la matriz de segregacin de funciones entregada.
Los controles compensatorios son controles internos que
pretenden reducir el riesgo de una debilidad existente o potencial
de control cuando las funciones no pueden ser segregadas de
una manera apropiada. La estructura de la organizacin y las
funciones deben ser tomadas en cuenta para determinar los
controles apropiados para el ambiente relevante. Por ejemplo,
una organizacin puede no tener todas las posiciones descritas en
la matriz o una persona puede ser responsable de muchas de las
funciones descritas. El tamao del departamento de Slffi puede
tambin ser un factor importante que se debe considerar, es decir,
ciertas combinaciones de funciones en un departamento de TI
de un cierto tamao nunca se deberan usar. Sin embargo, si por
alguna razn se requieren funciones combinadas, entonces se
deben describir controles de mitigacin.
El propsito de la segregacin de funciones es reducir o eliminar
los riesgos de negocio a travs de la identificacin de controles
compensatorios. La magnitud y probabilidad de riesgo se puede
valorar desde baja hasta alta, dependiendo de la organizacin.
2.11.3 CONTROLES DE SEGREGACIN DE
FUNCIONES
Se pueden emplear varios mecanismos de control para lograr la
segregacin de funciones. Los controles estn descritos en las
siguientes secciones.
Autorizacin de transacciones
La autorizacin de transacciones es responsabilidad del
departamento de usuarios. La autorizacin es delegada en
la medida en que se relacione con el nivel particular de
responsabilidad de la persona autorizada en el departamento.
Se deben realizar verificaciones peridicas tanto por parte de la
gerencia como por parte de auditora para detectar el ingreso de
transacciones no autorizadas.
Custodia de activos
Se debe determinar y asignar debidamente la custodia de los
activos corporativos. El propietario de los datos usualmente se
asigna a un departamento de usuarios particular, y sus funciones
se deben especificar por escrito. El dueo de los datos tiene la
responsabilidad de determinar niveles de autorizacin requeridos
para proporcionar seguridad adecuada, mientras que el grupo de
administracin suele ser responsable de implementar y reforzar el
sistema de seguridad.
Acceso a los datos
Los controles sobre el acceso a los datos son provistos
mediante una combinacin de seguridad fisica, de sistemas
y de aplicaciones tanto en el rea de los usuarios como en
la IPF. El ambiente fisico debe ser seguro para impedir el
acceso de personas no autorizadas a los diversos dispositivos
126
AniSACA"Cifllllel!lafl
tangibles conectados a la unidad central de procesamiento y que
permiten as, el acceso a los datos. La seguridad del sistema
y de la aplicacin son capas adicionales de seguridad que
pueden impedir que personas no autorizadas logren acceder
a los datos corporativos. El acceso a los datos proveniente de
conexiones externas es una preocupacin creciente desde la
aparicin de Internet. Por lo tanto, la gestin de TI ha agregado
responsabilidades para proteger los activos de informacin de
acceso no autorizado.
Las decisiones de control de acceso estn basadas en la poltica
organizacional y en dos estndares de prctica generalmente
aceptadossegregacin (separacin) de funciones y el menor
privilegio. Los controles para el uso efectivo no deben alterar el
flujo usual de trabajo ms de lo necesario o colocar demasiada
carga sobre los administradores, auditores o usuarios autorizados.
El acceso adicional no debe ser incondicional y los controles de
acceso deben proteger adecuadamente todos los recursos de la
organizacin.
Las polticas establecen niveles de sensibilidad tales como secreto
mximo, secreto, confidencial y no clasificado, para los datos
y otros recursos. Estos niveles deben usarse para orientacin
sobre los procedimientos apropiados para manejar los recursos
de informacin. Ellos tambin se pueden usar como base para
las decisiones sobre control de acceso. A las personas se les
otorga acceso slo a los recursos que estn en un nivel especfico
de sensibilidad o por debajo de ste. Las etiquetas se usan para
indicar el nivel de sensibilidad de los documentos almacenados
electrnicamente. Los controles basados en polticas pueden
caracterizarse bien como obligatorios o como discrecionales.
Para obtener ms detalles, consulte la seccin Controles de
acceso obligatorios y discrecionales, en el tema Importancia de
los activos de informacin del captulo 5.
FORMULARIOS DE AUTORIZACIN
Los gerentes de Jos departamentos de usuarios deben proveer a
SI formularios de autorizacin formales (ya sea en copia fsica o
electrnica) en los que se defman los derechos de acceso de sus
empleados. En otras palabras, Jos gerentes deben defmir quin
tendr acceso a qu. Los formularios de autorizacin deben ser
debidamente evidenciados con la aprobacin a nivel de gerencia.
En general, todos los usuarios deben ser autorizados a un acceso al
sistema especfico, por va de solicitud formal de la gerencia. En
las compaas grandes o en las que tienen sucursales distantes, se
deben mantener registros de firmas autorizadas y las solicitudes
formales recibidas por escrito deben ser comparadas contra el
registro de firmas. Los privilegios de acceso deben ser revisados
peridicamente para asegurar que estn actualizados y que sean
apropiados para las funciones del puesto de trabajo del usuario.
TABLAS DE AUTORIZACIN DE USUARIO
El departamento de SI debe usar Jos datos provenientes de los
formularios de autorizacin para crear y mantener tablas de
autorizaciones de usuarios. Estas definirn quin est autorizado
para actualizar, modificar, eliminar o consultar datos. Estos
privilegios son asignados a nivel de sistema, de transaccin o de
campo. En efecto, stas son listas de control de acceso de usuario.
Estas tablas de autorizacin deben ser protegidas contra el acceso
no autorizado mediante contraseas (passwords) adicionales
CISA
c elt : _ r n e d n i s h iloc r on on
JMI CerlIfIra.
de proteccin o mediante de datos. En un registro de control
debe registrarse la actividad de todos los usuarios y la gerencia
correspondiente debe revisar este registro. Todos los casos de
excepcin deben ser investigados.
Controles compensatorios por falta de segregacin de
funciones
En negocios pequeos donde el departamento de SI puede estar
constituido por slo cuatro o cinco personas, debe existir medidas
de control compensatorio para mitigar el riesgo resultante de
una falta de segregacin de funciones. Antes de basarse en
reportes generados por el sistema o en funciones como controles
compensatorios, el auditor de SI debe evaluar cuidadosamente los
reportes, las aplicaciones y los procesos relacionados con SI en
busca de controles apropiados, incluyendo pruebas y controles de
acceso para hacer cambios a los reportes o a las funciones. Los
controles compensatorios incluiran:
Pistas de auditoraLas pistas de auditora son un
componente esencial de los sistemas bien diseados, ayudan
tanto al departamento de SI como al auditor de SI brindando un
mapa para trazar por segunda vez el flujo de una transaccin.
Ellas permiten a los departamentos de SI y de usuarios as como
tambin al auditor de SI recrear el flujo real de transacciones
a partir del punto en que se originan hasta su ubicacin en
un archivo actualizado. Ante la ausencia de una adecuada
segregacin de funciones, las pistas de auditora pueden ser un
control compensatorio aceptable. Con las pistas de auditora
el auditor de SI debe ser capaz de determinar quin inici la
transaccin, la hora y la fecha de ingreso, el tipo de ingreso, qu
campos de informacin contena y qu archivos actualiz.
ConciliacinLa conciliacin es en ltima instancia
responsabilidad del usuario. En algunas organizaciones, el
grupo de control de datos puede realizar una conciliacin
limitada de las aplicaciones mediante el uso de totales
de control y hojas de balance. Este tipo de verificacin
independiente, incrementa el nivel de confianza de que la
aplicacin ejecut exitosamente y de que los datos estn
correctamente balanceados.
Reportes de excepcinLos reportes de excepcin deben
ser manejados a nivel de supervisin para lo cual se requiere
evidencia, como por ejemplo las iniciales en el reporte,
haciendo notar que la excepcin ha sido debidamente tratada.
Tambin, la gerencia debe asegurarse que las excepciones se
hayan atendido oportunamente.
Registros de transaccionesUn registro de transacciones puede
ser manual o automatizado. Un ejemplo de un registro manual es
un registro de transacciones (agrupadas o en lote) antes que las
mismas sean entregadas para su procesamiento. Un registro de
transacciones o diario automatizado provee un registro de todas
las transacciones procesadas y es mantenido por el sistema de
computacin.
Revisiones de supervisinLas revisiones de supervisin
pueden ser efectuadas a travs de observacin, investigacin o
remotamente.
Revisiones independientesLas revisiones independientes se
llevan a cabo para compensar los errores o fallas intencionales
al seguir los procedimientos prescritos. Estas revisiones son
particularmente importantes cuando las funciones en una
organizacin pequea no pueden ser segregadas debidamente.
Dichas revisiones ayudarn a detectar errores o irregularidades.
2.12 AUDITORA A LA ESTRUCTURA E
IMPLEMENTACIN DEL GOBIERNO DE TI
Aunque son muchos los aspectos que le preocupan al auditor
de SI cuando audita el funcionamiento de SI, algunos de los
indicadores ms significativos de los problemas potenciales
incluyen:
Actitudes desfavorables del usuario final
Costos excesivos
Gasto por encima del presupuesto
Proyectos atrasados
Alta rotacin de personal
Personal con poca experiencia
Errores frecuentes de HW/SW
Exceso de solicitudes atrasadas de usuarios
Largo tiempo de respuesta de computadora
Numerosos proyectos de desarrollo interrumpidos o
suspendidos
Compras de HW/SW sin soporte o sin autorizacin
Frecuentes ampliaciones de capacidad de HW/SW
Informes de excepcin largos
Reportes de excepciones a los que no se les hizo seguimiento
Motivacin deficiente
Ausencia de planes de reemplazo
Confianza en uno o dos miembros clave del personal
Falta de capacitacin adecuada
2.12.1 REVISIN DE LA DOCUMENTACIN
La siguiente documentacin debe ser revisada:
Las estrategias, planes y presupuestos de TIProveen
evidencia de planificacin y control de gestin sobre el
ambiente de SI y el alineamiento con la estrategia del negocio.
Documentacin de polticas de seguridadProvee
el estndar a cumplir. Debe establecer la posicin de la
organizacin respecto de todos y cada uno de los riesgos
de seguridad. Debe identificar quin es responsable de
salvaguardar los activos de la compaa, incluyendo los
programas y los datos. Debe establecer las medidas preventivas
a tomarse para brindar la proteccin adecuada y las acciones
que se deben seguir en contra de los transgresores. Por esta
razn, esta parte del documento de poltica debe ser tratado
como un documento confidencial.
Cuadros organizativos/funcionalesProveen al auditor de
SI una comprensin de la lnea de subordinacin dentro de un
departamento u organizacin determinados. Ellos ilustran una
divisin de responsabilidades y dan una indicacin del grado de
segregacin de funciones dentro de la organizacin.
Descripciones de los puestos de trabajoDefinen las
funciones y las responsabilidades de los cargos en toda la
organizacin. Estas proveen a la organizacin la capacidad de
agrupar puestos de trabajo similares en distintos niveles de
categora para garantizar una compensacin justa a la fuerza de
trabajo. Adems, las descripciones de los puestos de trabajo dan
una indicacin del grado de segregacin de funciones dentro de
la organizacin y pueden ayudar a identificar las funciones de
posible conflicto. Las descripciones de los puestos de trabajo
deben identificar la posicin a la que se subordina este personal.
El auditor de SI debe entonces verificar que los niveles de
ISACA. Tod os los d e r e c h os r e s e r vad os .
e
. Captulo 2 - Gobierno y Gestin de TI
MISACA"c.rtlllc:IUon
de proteccin o mediante de datos. En un registro de control
debe registrarse la actividad de todos los usuarios y la gerencia
correspondiente debe revisar este registro. Todos los casos de
excepcin deben ser investigados.
Controles compensatorios por falta de segregacin de
funciones
En negocios pequeos donde el departamento de SI puede estar
constituido por slo cuatro o cinco personas, debe existir medidas
de control compensatorio para mitigar el riesgo resultante de
una falta de segregacin de funciones. Antes de basarse en
reportes generados por el sistema o en funciones como controles
compensatorios, el auditor de SI debe evaluar cuidadosamente los
reportes, las aplicaciones y los procesos relacionados con SI en
busca de controles apropiados, incluyendo pruebas y controles de
acceso para hacer cambios a los reportes o a las funciones. Los
controles compensatorios incluiran:
Pistas de auditora-Las pistas de auditora son un
componente esencial de los sistemas bien diseados, ayudan
tanto al departamento de SI como al auditor de SI brindando un
mapa para trazar por segunda vez el flujo de una transaccin.
Ellas permiten a los departamentos de SI y de usuarios as como
tambin al auditor de SI recrear el flujo real de transacciones
a partir del punto en que se originan hasta su ubicacin en
un archivo actualizado. Ante la ausencia de una adecuada
segregacin de funciones, las pistas de auditora pueden ser un
control compensatorio aceptable. Con las pistas de auditora
el auditor de SI debe ser capaz de determinar quin inici la
transaccin, la hora y la fecha de ingreso, el tipo de ingreso, qu
campos de informacin contena y qu archivos actualiz.
Conciliacin-La conciliacin es en ltima instancia
responsabilidad del usuario. En algunas organizaciones, el
grupo de control de datos puede realizar una conciliacin
limitada de las aplicaciones mediante el uso de totales
de control y hojas de balance. Este tipo de verificacin
independiente, incrementa el nivel de confianza de que la
aplicacin ejecut exitosamente y de que los datos estn
correctamente balanceados.
Reportes de excepcin-Los reportes de excepcin deben
ser manejados a nivel de supervisin para lo cual se requiere
evidencia, como por ejemplo las iniciales en el reporte,
haciendo notar que la excepcin ha sido debidamente tratada.
Tambin, la gerencia debe asegurarse que las excepciones se
hayan atendido oportunamente.
Registros de transacciones--Un registro de transacciones puede
ser manual o automatizado. Un ejemplo de un registro manual es
un registro de transacciones (agrupadas o en lote) antes que las
mismas sean entregadas para su procesamiento. Un registro de
transacciones o diario automatizado provee un registro de todas
las transacciones procesadas y es mantenido por el sistema de
computacin.
Revisiones de supervisin-Las revisiones de supervisin
pueden ser efectuadas a travs de observacin, investigacin o
remotamente.
Revisiones independientes-Las revisiones independientes se
llevan a cabo para compensar los errores o fallas intencionales
al seguir los procedimientos prescritos. Estas revisiones son
particularmente importantes cuando las funciones en una
organizacin pequea no pueden ser segregadas debidamente.
Dichas revisiones ayudarn a detectar errores o irregularidades.
2.12 AUDITORA A LA ESTRUCTURA E
IMPLEMENTACIN DEL GOBIERNO DE TI
Aunque son muchos los aspectos que le preocupan al auditor
de SI cuando audita el funcionamiento de SI, algunos de los
indicadores ms significativos de los problemas potenciales
incluyen:
Actitudes desfavorables del usuario final
Costos excesivos
Gasto por encima del presupuesto
Proyectos atrasados
Alta rotacin de personal
Personal con poca experiencia
Errores frecuentes de HW/SW
Exceso de solicitudes atrasadas de usuarios
Largo tiempo de respuesta de computadora
Numerosos proyectos de desarrollo interrumpidos o
suspendidos
Compras de HW/SW sin soporte o sin autorizacin
Frecuentes ampliaciones de capacidad de HW/SW
Informes de excepcin largos
Reportes de excepciones a los que no se les hizo seguimiento
Motivacin deficiente
Ausencia de planes de reemplazo
Confianza en uno o dos miembros clave del personal
Falta de capacitacin adecuada
2.12.1 REVISIN DE LA DOCUMENTACIN
La siguiente documentacin debe ser revisada:
Las estrategias, planes y presupuestos de TI- Proveen
evidencia de planificacin y control de gestin sobre el
ambiente de SI y el alineamiento con la estrategia del negocio.
Documentacin de polticas de seguridad-Provee
el estndar a cumplir. Debe establecer la posicin de la
organizacin respecto de todos y cada uno de los riesgos
de seguridad. Debe identificar quin es responsable de
salvaguardar los activos de la compaa, incluyendo los
programas y los datos. Debe establecer las medidas preventivas
a tomarse para brindar la proteccin adecuada y las acciones
que se deben seguir en contra de los transgresores. Por esta
razn, esta parte del documento de poltica debe ser tratado
como un documento confidencial.
Cuadros organizativos/funcionales-Proveen al auditor de
SI una comprensin de la lnea de subordinacin dentro de un
departamento u organizacin determinados. Ellos ilustran una
divisin de responsabilidades y dan una indicacin del grado de
segregacin de funciones dentro de la organizacin.
Descripciones de los puestos de trabajo-Definen las
funciones y las responsabilidades de los cargos en toda la
organizacin. Estas proveen a la organizacin la capacidad de
agrupar puestos de trabajo similares en distintos niveles de
categora para garantizar una compensacin justa a la fuerza de
trabajo. Adems, las descripciones de los puestos de trabajo dan
una indicacin del grado de segregacin de funciones dentro de
la organizacin y pueden ayudar a identificar las funciones de
posible conflicto. Las descripciones de los puestos de trabajo
deben identificar la posicin a la que se subordina este personal.
El auditor de SI debe entonces verificar que los niveles de
127
CISA S y s t e m s 1 2f ultmorn
An 1 6.e rCarLat ion
re lacin de s ubordin acin e s t n bas ados e n con ce pt os corre ct os
de l n e gocioy n oaf e ct e n la s e gre gacin de f un cion e s .
Re port e s de l comit directivoProveen in f orm acin
docum e n t ada e n re lacin con los n ue vos proy e ct os de s is t e m as .
Es t os re port e s s on re vis ados porla alt a dire ccin y s on
divulgados e n t re las dif e re n t e s un idade s de l n e gocio.
Procedimientos de desarrollo de sistemas y de cambio de
programasEstos proce dim ie n t os prove e n un m arcode n t ro
de l cual e m pre n de re l de s arrollode s is t e m as oe l cam biode
program as .
Procedimientos de operacionesEstos proce dim ie n t os
de s cribe n las re s pon s abilidade s de l pe rs on al de ope racion e s .
Los proce dim ie n t os de m e dicin de de s e m pe oge n e ralm e n t e
s e e n cue n t ran de n t rode los proce dim ie n t os ope rat ivos y s e
re port an pe ridicam e n t e a la alt a dire ccin y /olos com it s
dire ct ivos . Los audit ore s de S I de be n garan t izarque e s t os
proce dim ie n t os f orm e n part e de los proce dim ie n t os ope rat ivos .
Manuales de RR.HH.Proveen las re glas y las re gulacion e s
(de t e rm in adas porun a organ izacin ) s obre cm os e e s pe ra que
s us e m ple ados s e con duzcan .
Procedimientos de QAEstos proce dim ie n t os proporcion an
e l m arcoy los e s t n dare s que de be s e guire l de part am e n t o
de S I.
Ade m s s e de be n valorarlos dif e re n t e s docum e n t os re vis ados
para de t e rm in ars i:
Fue ron cre ados com oloaut oriz la ge re n cia y com os t a que ra
que f ue ran cre ados .
Es t n vige n t e s y act ualizados .
2.12.2 REVISIN DE COMPROMISOS
CONTRACTUALES
Hay dif e re n t e s e t apas para los con t rat os de hardware , s of t ware y
s e rviciode S I que in cluy e n :
De s arrollode los re que rim ie n t os de con t rat acin
Proce s ode licit acin de con t rat os
Proce s ode s e le ccin de con t rat os
Ace pt acin de con t rat os
Man t e n im ie n t ode con t rat os
Cum plim ie n t ode con t rat os
Cada un a de e s t as e t apas de be e s t arre s paldada pordocum e n t os
le gale s , s uje t oa la aut orizacin de la ge re n cia. El audit orde
S I de be ve rif icarla part icipacin de la ge re n cia e n e l proce s o
de con t rat acin y de be as e gurarun n ive l ade cuadode re vis in
oport un a de l cum plim ie n t ode l con t rat o. El audit orde S I podr
e f e ct uarun a re vis in pors e paradode l cum plim ie n t oe n un a
m ue s t ra de dichos con t rat os .
Al re vis arun a m ue s t ra de con t rat os , e l audit orde S I de be e valuar
la ade cuacin de los s iguie n t e s t rm in os y con dicion e s :
Nive le s de s e rvicio.
De re choa audit arore port e de audit ora de t e rce ro.
Pon e re l s of t ware e n cus t odia de un t e rce ro.
Pe n alizacion e s porin cum plim ie n t o.
Acat am ie n t ode las polt icas y proce dim ie n t os de s e guridad.
Prot e ccin de in f orm acin de clie n t e s .
Proce s ode cam biode con t rat o.
Te rm in acin de con t rat oy cualquie rpe n alizacin apropiada.
Nota: Un audit orde S I de be e s t arf am iliarizadocon e l
proce s ode s olicit ud de propue s t a (RFP) y con oce rqu e s lo
que n e ce s it a s e rre vis adoe n un a RFR Tam bin e s im port an t e
s e alarque un CIS A de be s abe r, de s de la pe rs pe ct iva de
gobie rn o, los crit e rios de e valuacin y la m e t odologa de un a
RFP, y los re que rim ie n t os para cum plircon los e s t n dare s
organ izacion ale s .
2.13 PLANEACIN DE CONTINUIDAD DEL
NEGOCIO (BCP)
El props it ode la con t in uidad de l n e gocio/re cupe racin e n cas ode
de s as t re e s pe rm it irque un a e m pre s a con t in e of re cie n dos e rvicios
crt icos e n cas ode que ocurra un a in t e rrupcin y que s obre viva a
un a in t e rrupcin de s as t ros a de las act ividade s . Es n e ce s ariocon t ar
con un a plan if icacin y un com prom is origuros os de los re curs os
para pre ve rt ale s e ve n t os de f orm a ade cuada.
El prim e rpas oe n la pre paracin de un n ue voBCP e s ide n t if icarlos
proce s os de n e gociode im port an cia e s t rat gica, aque llos proce s os
clave que s on re s pon s able s de l cre cim ie n t ode l n e gocioy de la
con s e cucin de las m e t as de l n e gocio. Loide al e s que e l BCP/DRP
s e a re s paldadoporun a polt ica e je cut iva f orm al que e s t able zca
e l obje t ivoge n e ral de la organ izacin e n loque re s pe ct a a la
re cupe racin y as ign e at ribucion e s a las pe rs on as que part icipan
e n e l de s arrollo, las prue bas y e l m an t e n im ie n t ode los plan e s .
Bas adoe n los proce s os clave , e l proce s ode ge s t in de rie s gos
de be ra com e n zarcon un a e valuacin de rie s gos . El rie s goe s
dire ct am e n t e proporcion al al im pact os obre la organ izacin y la
probabilidad de que ocurra la am e n aza pe rcibida. Porlot an t o, la
e valuacin de rie s gos de be ra pe rm it iride n t if icarlos iguie n t e :
Los re curs os hum an os , los dat os , los e le m e n t os de la
in f rae s t ruct ura y ot ros re curs os (in cluy e n dolos proporcion ados
port e rce ros ) que re s paldan los proce s os clave
Un a lis t a de las pos ible s vuln e rabilidade s , e s de cir, los pe ligros
oam e n azas para la organ izacin
La probabilidad e s t im ada de que ocurran e s t as am e n azas
La e f icie n cia y e f icacia de los con t role s e xis t e n t e s de m it igacin
de rie s gos (con t ram e didas para af ron t arrie s gos )
El BCP e s bs icam e n t e re s pon s abilidad de la alt a ge re n cia, de bido
a que a s t a s e le con f i la prot e ccin de los act ivos y la viabilidad
de la organ izacin , t al com os e de f in i e n la polt ica de BCP/DRP.
En ge n e ral, las un idade s de n e gocioy s oport e s igue n e l BCP para
of re ce run n ive l de f un cion alidad re ducidope ros uf icie n t e e n las
ope racion e s de n e gocioin m e diat am e n t e de s pus de e n f re n t arun a
in t e rrupcin , m ie n t ras ocurre la re cupe racin . El plan de be ra
t rat art odas las f un cion e s y los act ivos re que ridos para con t in uar
com oun a organ izacin viable . Es t oin cluy e proce dim ie n t os de
con t in uidad con s ide rados com on e ce s arios para s obre viviry
m in im izarlas con s e cue n cias de la in t e rrupcin de l n e gocio.
El BCP t om a e n con s ide racin :
Las ope racion e s crt icas que s on n e ce s arias para la
s upe rvive n cia de la organ izacin
Los re curs os hum an os /m at e riale s que los s oport an
Seccin Dos: Contenido e
- 1 2 G b' G - d ,.., O Certifiedlnformatioo
apttu o - o terno y estton e , o ~ ~ .. i t o r
relacin de subordinacin estn basados en conceptos correctos
del negocio y no afecten la segregacin de funciones.
Reportes del comit directivo-Proveen informacin
documentada en relacin con los nuevos proyectos de sistemas.
Estos reportes son revisados por la alta direccin y son
divulgados entre las diferentes unidades del negocio.
Procedimientos de desarrollo de sistemas y de cambio de
programas- Estos procedimientos proveen un marco dentro
del cual emprender el desarrollo de sistemas o el cambio de
programas.
Procedimientos de operaciones- Estos procedimientos
describen las responsabilidades del personal de operaciones.
Los procedimientos de medicin de desempeo generalmente
se encuentran dentro de los procedimientos operativos y se
reportan peridicamente a la alta direccin y/o los comits
directivos. Los auditores de SI deben garantizar que estos
procedimientos formen parte de los procedimientos operativos.
Manuales de RR.HH.-Proveen las reglas y las regulaciones
(determinadas por una organizacin) sobre cmo se espera que
sus empleados se conduzcan.
Procedimientos de QA-Estos procedimientos proporcionan
el marco y los estndares que debe seguir el departamento
de SI.
Adems se deben valorar los diferentes documentos revisados
para determinar si:
Fueron creados como lo autoriz la gerencia y como sta quera
que fueran creados.
Estn vigentes y actualizados.
2.12.2 REVISIN DE COMPROMISOS
CONTRACTUALES
Hay diferentes etapas para los contratos de hardware, software y
servicio de SI que incluyen:
Desarrollo de los requerimientos de contratacin
Proceso de licitacin de contratos
Proceso de seleccin de contratos
Aceptacin de contratos
Mantenimiento de contratos
Cumplimiento de contratos
Cada una de estas etapas debe estar respaldada por documentos
legales, sujeto a la autorizacin de la gerencia. El auditor de
SI debe verificar la participacin de la gerencia en el proceso
de contratacin y debe asegurar un nivel adecuado de revisin
oportuna del cumplimiento del contrato. El auditor de SI podr
efectuar una revisin por separado del cumplimiento en una
muestra de dichos contratos.
Al revisar una muestra de contratos, el auditor de SI debe evaluar
la adecuacin de los siguientes trminos y condiciones:
Niveles de servicio.
Derecho a auditar o reporte de auditora de tercero.
Poner el software en custodia de un tercero.
Penalizaciones por incumplimiento.
Acatamiento de las polticas y procedimientos de seguridad.
Proteccin de informacin de clientes.
Proceso de cambio de contrato.
Terminacin de contrato y cualquier penalizacin apropiada.
128
Nota: Un auditor de SI debe estar familiarizado con el
proceso de solicitud de propuesta (RFP) y conocer qu es lo
que necesita ser revisado en una RFP. Tambin es importante
sealar que un CISA debe saber, desde la perspectiva de
gobierno, los criterios de evaluacin y la metodologa de una
RFP, y los requerimientos para cumplir con los estndares
organizacionales.
2.13 PLANEACIN DE CONTINUIDAD DEL
NEGOCIO (BCP)
El propsito de la continuidad del negocio/recuperacin en caso de
desastre es permitir que una empresa contine ofreciendo servicios
criticos en caso de que ocurra una interrupcin y que sobreviva a
una interrupcin desastrosa de las actividades. Es necesario contar
con una planificacin y un compromiso rigurosos de los recursos
para prever tales eventos de forma adecuada.
El primer paso en la preparacin de un nuevo BCP es identificar los
procesos de negocio de importancia estratgica, aquellos procesos
clave que son responsables del crecimiento del negocio y de la
consecucin de las metas del negocio. Lo ideal es que el BCP/DRP
sea respaldado por una poltica ejecutiva formal que establezca
el objetivo general de la organizacin en lo que respecta a la
recuperacin y asigne atribuciones a las personas que participan
en el desarrollo, las pruebas y el mantenimiento de los planes.
Basado en los procesos clave, el proceso de gestin de riesgos
debera comenzar con una evaluacin de riesgos. El riesgo es
directamente proporcional al impacto sobre la organizacin y la
probabilidad de que ocurra la amenaza percibida. Por lo tanto, la
evaluacin de riesgos deberla permitir identificar lo siguiente:
Los recursos humanos, los datos, los elementos de la
infraestructura y otros recursos (incluyendo los proporcionados
por terceros) que respaldan los procesos clave
Una lista de las posibles vulnerabilidades, es decir, los peligros
o amenazas para la organizacin
La probabilidad estimada de que ocurran estas amenazas
La eficiencia y eficacia de los controles existentes de mitigacin
de riesgos (contramedidas para afrontar riesgos)
El BCP es bsicamente responsabilidad de la alta gerencia, debido
a que a sta se le confi la proteccin de los activos y la viabilidad
de la organizacin, tal como se defini en la poltica de BCP/DRP.
En general, las unidades de negocio y soporte siguen el BCP para
ofrecer un nivel de funcionalidad reducido pero suficiente en las
operaciones de negocio inmediatamente despus de enfrentar una
interrupcin, mientras ocurre la recuperacin. El plan deberla
tratar todas las funciones y los activos requeridos para continuar
como una organizacin viable. Esto incluye procedimientos de
continuidad considerados como necesarios para sobrevivir y
minimizar las consecuencias de la interrupcin del negocio.
El BCP toma en consideracin:
Las operaciones criticas que son necesarias para la
supervivencia de la organizacin
Los recursos humanos/materiales que los soportan
CISA s=titr"
ro,.
Adems del plan para la continuidad de las operaciones, el BCP
incluye:
El DRP que se utiliza para recuperar una instalacin que se haya
vuelto inoperable, incluyendo la reubicacin de las operaciones
en una nueva ubicacin
El plan de restauracin que se utiliza para normalizar las
operaciones en una instalacin restaurada o nueva
Dependiendo de la complejidad de la organizacin, podra
haber uno o ms planes para tratar los diferentes aspectos de la
continuidad del negocio y la recuperacin ante desastres. Estos
planes no necesariamente tienen que integrarse en un nico plan.
Sin embargo, cada uno tiene que ser consistente con otros planes
para contar con una estrategia de BCP viable.
Es muy recomendable tener un plan integrado nico para
asegurar que:
todos los aspectos estn cubiertos.
los recursos comprometidos se utilicen de la manera ms
efectiva y exista la confianza de que, a travs de su aplicacin,
la organizacin sobrevivir a una interrupcin.
Aun cuando procesos similares de la misma organizacin se
manejen en una ubicacin geogrfica diferente, las soluciones
de BCP y DRP pudieran ser diferentes para escenarios diferentes.
Las soluciones pudieran ser diferentes debido a requerimientos
contractuales (por ejemplo, la misma organizacin est procesando
una transaccin en lnea para un cliente y la back office est
procesando una transaccin para otro cliente). Una solucin
de BCP para el servicio en lnea ser significativamente diferente
a la solucin para el procesamiento de la back office.
2.13.1 PLANEACIN DE CONTINUIDAD DEL NEGOCIO
DE SI
En el caso de los planes de continuidad del negocio de SI, el
enfoque es el mismo que en el BCP con la excepcin de que
est amenazado el procesamiento de SI. El procesamiento de
SI es de importancia estratgicaes un componente crtico
porque la mayora de los procesos clave de negocios dependen
de la disponibilidad de los componentes y los datos de la
infraestructura de sistemas clave.
El plan de continuidad del negocio de SI debe estar alineado con la
estrategia de la organizacin. La criticidad de los diferentes sistemas
de aplicaciones de la organizacin depende de la naturaleza del
negocio, as como del valor de cada aplicacin para el negocio.
El valor de cada aplicacin para el negocio es directamente
proporcional al rol que desempea el sistema de informacin
en el apoyo a la estrategia de la organizacin. Los componentes
del sistema de informacin (entre ellos los componentes de la
infraestructura de tecnologa) se asocian posteriormente con las
aplicaciones (por ejemplo, el valor de una computadora o una red
depende de la importancia del sistema de aplicaciones que la utiliza).
Por lo tanto, el BCP/DRP del sistema de informacin es un
componente principal de la estrategia general de continuidad del
negocio y recuperacin en caso de desastre de una organizacin.
Si el plan de SI es un plan separado, debe ser consistente con y
apoyar el BCP corporativo.
A lo largo de todo el proceso de planificacin de la continuidad
del negocio de SI (a veces mencionada como continuidad de los
servicios de TI), se debe tener en consideracin el plan general de
continuidad del negocio de la organizacin: de nuevo, ste debe
contar con el respaldo de la poltica ejecutiva. Todos los planes de
SI deben ser consistentes con y apoyar el BCP corporativo. Esto
significa que las instalaciones alternas de procesamiento que apoyan
las operaciones clave deben estar preparadas, ser compatibles
con la instalacin original de procesamiento y contar con planes
actualizados en lo que respecta a su uso.
Nuevamente, se deben tomar todas las medidas posibles para
reducir o eliminar la probabilidad de una interrupcin utilizando
el mtodo descrito en otras secciones de este Manual. Un ejemplo
sera minimizar las amenazas al centro de datos considerando la
ubicacin: no establecerlo en una llanura inundable, sobre una
falla ssmica ni cerca de un rea donde se utilicen regularmente
dispositivos explosivos o materiales txicos. Otro ejemplo es
utilizar topografas de red resilientes, como las de Bucle o Malla,
con instalaciones alternas de procesamiento ya integradas a la
infraestructura de red.
Desarrollar y probar el BCP/DRP del sistema de informacin es un
El plan se basa en el uso coordinado de las contramedidas para
afrontar riesgos que estn disponibles para la organizacin
(es decir, instalacin alterna de procesamiento, redes de
datos redundantes, equipos resilientes, sistemas de respaldo y
recuperacin, replicacin de datos, etc.). Si el plan de SI es un plan
separado (o varios planes separados), debe ser consistente con y
Establecer dependencias entre los procesos crticos de negocio, las
aplicaciones, el sistema de informacin y los componentes de la
infraestructura de TI es uno de los pasos de la evaluacin de riesgos.
El mapa de dependencias resultante con las amenazas para y las
vulnerabilidades de los componentes/dependencias (junto con las
aplicaciones clave agrupadas por su criticidad) es el resultado de la
evaluacin de riesgos.
Una vez que la evaluacin de riesgos identifica la importancia
de los componentes de SI para la organizacin, y las amenazas y
las vulnerabilidades de esos componentes, se puede desarrollar
un plan de acciones correctivas para establecer los mtodos
ms apropiados para proteger los componentes. Siempre hay
diferentes opciones de mitigacin de riesgos para escoger
(contramedidas para afrontar riesgos), bien sea para eliminar la
amenaza y/o corregir la vulnerabilidad.
El riesgo se puede calcular bien sea de forma cualitativa
(asignando valores cualitativos al impacto de la amenaza y
su probabilidad) o cuantitativa (asignando valor monetario al
impactoes decir, la prdiday asignando una probabilidad).
Nota: El candidato a CISA no sera evaluado con respecto al
calculo real del analisis de riesgo; sin embargo, el auditor de SI
debe estar familiarizado con el clculo del anlisis de riesgo.
e :::=? Capitulo 2 - Gobierno y Gestin de TI
Adems del plan para la continuidad de las operaciones, el BCP
incluye:
El DRP que se utiliza para recuperar una instalacin que se haya
vuelto inoperable, incluyendo la reubicacin de las operaciones
en una nueva ubicacin
El plan de restauracin que se utiliza para normalizar las
operaciones en una instalacin restaurada o nueva
Dependiendo de la complejidad de la organizacin, podra
haber uno o ms planes para tratar los diferentes aspectos de la
continuidad del negocio y la recuperacin ante desastres. Estos
planes no necesariamente tienen que integrarse en un nico plan.
Sin embargo, cada uno tiene que ser consistente con otros planes
para contar con una estrategia de BCP viable.
Es muy recomendable tener un plan integrado nico para
asegurar que:
todos los aspectos estn cubiertos.
los recursos comprometidos se utilicen de la manera ms
efectiva y exista la confianza de que, a travs de su aplicacin,
la organizacin sobrevivir a una interrupcin.
Aun cuando procesos similares de la misma organizacin se
manejen en una ubicacin geogrfica diferente, las soluciones
de BCP y DRP pudieran ser diferentes para escenarios diferentes.
Las soluciones pudieran ser diferentes debido a requerimientos
contractuales (por ejemplo, la misma organizacin est procesando
una transaccin en lnea para un cliente y la back office est
procesando una transaccin para otro cliente). Una solucin
de BCP para el servicio en lnea ser significativamente diferente
a la solucin para el procesamiento de la back office.
2.13.1 PLANEACIN DE CONTINUIDAD DEL NEGOCIO
DE SI
En el caso de los planes de continuidad del negocio de SI, el
enfoque es el mismo que en el BCP con la excepcin de que
est amenazado el procesamiento de SI. El procesamiento de
SI es de importancia estratgica--es un componente critico
porque la mayora de los procesos clave de negocios dependen
de la disponibilidad de los componentes y los datos de la
infraestructura de sistemas clave.
El plan de continuidad del negocio de SI debe estar alineado con la
estrategia de la organizacin. La criticidad de los diferentes sistemas
de aplicaciones de la organizacin depende de la naturaleza del
negocio, as como del valor de cada aplicacin para el negocio.
El valor de cada aplicacin para el negocio es directamente
proporcional al rol que desempea el sistema de informacin
en el apoyo a la estrategia de la organizacin. Los componentes
del sistema de informacin (entre ellos los componentes de la
infraestructura de tecnologa) se asocian posteriormente con las
aplicaciones (por ejemplo, el valor de una computadora o una red
depende de la importancia del sistema de aplicaciones que la utiliza).
Por lo tanto, el BCP/DRP del sistema de informacin es un
Si el plan de SI es un plan separado, debe ser consistente con y
A lo largo de todo el proceso de planificacin de la continuidad
del negocio de SI (a veces mencionada como continuidad de los
servicios de TI), se debe tener en consideracin el plan general de
continuidad del negocio de la organizacin: de nuevo, ste debe
contar con el respaldo de la poltica ejecutiva. Todos los planes de
SI deben ser consistentes con y apoyar el BCP corporativo. Esto
significa que las instalaciones alternas de procesamiento que apoyan
las operaciones clave deben estar preparadas, ser compatibles
con la instalacin original de procesamiento y contar con planes
actualizados en lo que respecta a su uso.
Nuevamente, se deben tomar todas las medidas posibles para
reducir o eliminar la probabilidad de una interrupcin utilizando
el mtodo descrito en otras secciones de este Manual. Un ejemplo
seria minimizar las amenazas al centro de datos considerando la
ubicacin: no establecerlo en una llanura inundable, sobre una
falla ssmica ni cerca de un rea donde se utilicen regularmente
dispositivos explosivos o materiales txicos. Otro ejemplo es
utilizar topografias de red resilientes, como las de Bucle o Malla,
con instalaciones alternas de procesamiento ya integradas a la
infraestructura de red.
Desarrollar y probar el BCP/DRP del sistema de informacin es un
El plan se basa en el uso coordinado de las contramedidas para
afrontar riesgos que estn disponibles para la organizacin
(es decir, instalacin alterna de procesamiento, redes de
datos redundantes, equipos resilientes, sistemas de respaldo y
recuperacin, replicacin de datos, etc.). Si el plan de SI es un plan
separado (o varios planes separados), debe ser consistente con y
Establecer dependencias entre los procesos crticos de negocio, las
aplicaciones, el sistema de informacin y los componentes de la
infraestructura de TI es uno de los pasos de la evaluacin de riesgos.
El mapa de dependencias resultante con las amenazas para y las
vulnerabilidades de los componentes/dependencias Gunto con las
aplicaciones clave agrupadas por su criticidad) es el resultado de la
evaluacin de riesgos.
Una vez que la evaluacin de riesgos identifica la importancia
de los componentes de SI para la organizacin, y las amenazas y
las vulnerabilidades de esos componentes, se puede desarrollar
un plan de acciones correctivas para establecer los mtodos
ms apropiados para proteger los componentes. Siempre hay
diferentes opciones de mitigacin de riesgos para escoger
(contramedidas para afrontar riesgos), bien sea para eliminar la
amenaza y/o corregir la vulnerabil idad.
El riesgo se puede calcular bien sea de forma cualitativa
(asignando valores cualitativos al impacto de la amenaza y
su probabilidad) o cuantitativa (asignando valor monetario al
impacto--es decir, la prdida-y asignando una probabilidad).
Nota: El candidato a CISA no sera evaluado con respecto al
calculo real del analisis de riesgo; sin embargo, el auditor de SI
debe estar familiarizado con el clculo del anlisis de riesgo.
129
CISA
Information
Systems Auditor'
ISAC A.C elleatIon
Si la organizacin est dispuesta a investigar la magnitud
de las prdidas que sufrir el negocio por la interrupcin, la
organizacin puede llevar a acabo un BIA (explicado en otra
seccin de este manual). El BIA permite a la organizacin
determinar el mximo tiempo posible de inactividad para
una aplicacin en particular y cuntos datos se podran perder.
El BIA tambin permite a la organizacin cuantificar las
prdidas a medida que aumentan despus de la interrupcin,
con lo cual la organizacin puede tomar una decisin sobre
la tecnologa (y las instalaciones) utilizada para la proteccin
y recuperacin de sus activos de informacin clave (sistema
de informacin, componentes de TI, datos, etc.).
Los resultados de la evaluacin de riesgos y el BIA se incorporan
a la estrategia de continuidad del negocio de SI, la cual describe
la tecnologa principal y los principios que sirven de base a
la proteccin y recuperacin de SI, as como la directriz para
implementar la tecnologa y los principios.
A medida que se ejecuta la estrategia de continuidad del negocio
de SI y su estrategia global de TI, la estructura de TI de la
organizacin cambia. Se introducen nuevas contramedidas para
afrontar riesgos y las anteriores se vuelven obsoletas. El BCP del
sistema de informacin se debe cambiar segn corresponda y
se debe volver a probar peridicamente para asegurar que estos
cambios sean satisfactorios.
Igual que cualquier BCP, un BCP del sistema de informacin es
mucho ms que un plan para los sistemas de informacin. Un
BCP identifica lo que har el negocio en caso de que suceda
un desastre. Por ejemplo, adnde se reportarn los empleados
para trabajar, cmo se tomarn los pedidos mientras se restablece
el sistema informtico, a cules proveedores se llamar para que
suministren las provisiones necesarias. Un subcomponente del BCP
es el plan de recuperacin de TI en caso de desastre. Normalmente
detalla el proceso que utilizar el personal de TI para restablecer
los sistemas informticos, las comunicaciones, las aplicaciones y
sus datos. Los planes de recuperacin en caso de desastre (DRP)
se pueden incluir en el BCP o como un documento separado,
dependiendo de las necesidades del negocio.
No todos los sistemas requerirn una estrategia de recuperacin.
Basndose en los resultados de la evaluacin de riesgos y el
BIA, la gerencia podra considerar que no es conveniente desde el
punto de vista econmico restaurar ciertas aplicaciones en caso de
desastre. Un factor primordial cuando se determinan las opciones
de recuperacin es que el costo nunca debe exceder el beneficio
(esto suele determinarse claramente despus de un BIA).
La recuperacin de SI en caso de desastre suele ocurrir en
circunstancias poco comunes y estresantes (incendio, inundacin,
devastacin por huracn). Con frecuencia sucede que los
controles de seguridad (tanto fsicos como de SI) no funcionan.
Por lo tanto, se recomienda que la organizacin implemente un
sistema de gestin de la seguridad de la informacin (ISMS) para
mantener la integridad, confidencialidad y disponibilidad del SI,
y no solamente bajo condiciones normales.
2.13.2 DESASTRES Y OTROS EVENTOS QUE PUEDEN
CAUSAR INTERRUPCIONES
Los desastres son interrupciones que causan que recursos de
informacin crticos queden inoperantes durante un perodo,
afectando de manera adversa las operaciones organizacionales.
La interrupcin podra durar de algunos minutos a varios
meses, dependiendo del grado del dao causado al recurso de
informacin. Es importante conocer que, ante situaciones de
desastre, es necesario desplegar esfuerzos de recuperacin para
restaurar el estado operacional.
Un desastre pudiera ser el resultado de desastres naturales,
como terremotos, inundaciones, tornados, tormentas elctricas
severas e incendios, que causan daos extensos a la instalacin
de procesamiento y a la localidad en general. Otros eventos
desastrosos que causan interrupciones pueden ocurrir cuando los
servicios esperados, como energa elctrica, telecomunicaciones,
suministro de gas natural u otro servicio pblico, ya no estn
disponibles para la compaa debido a un desastre natural u otra
causa. Un desastre podra ser tambin el resultado de eventos
causados por seres humanos, tales como ataques terroristas,
ataques de intrusos informticos, virus o error humano.
No todas las interrupciones fsicas del servicio son causadas por
un desastre. Por ejemplo, la interrupcin del servicio algunas
veces es causada por desperfectos del sistema, eliminaciones de
archivos por accidente, versiones de aplicaciones que no han sido
probadas, prdida de los datos de respaldo, ataques de negacin
de servicio (DoS) de red, intrusiones y virus. Estos eventos
pueden requerir acciones para recuperar el estado operacional
a fin de reanudar el servicio. Las acciones pueden necesitar del
restablecimiento del hardware, software o archivos de datos.
Muchas interrupciones comienzan con simples incidentes.
Normalmente, si la organizacin posee un centro de soporte
(help desk) o un centro de servicio, ste actuar como el sistema
de advertencia temprana para reconocer las primeras seales
de una interrupcin inminente. A menudo, tales interrupciones
(por ejemplo, un rendimiento de la base de datos que desmejora
gradualmente) pasan desapercibidas. Hasta que estallan estos
"desastres progresivos" (la base de datos se detiene), slo causan
quejas espordicas de parte de los usuarios.
Basndose en la evaluacin de riesgos, se formulan escenarios
del peor caso y estrategias de contingencia a largo y corto plazo
dentro de la estrategia de continuidad del negocio de SI para luego
incorporarlos en el BCP (u otro plan). A corto plazo, se puede
requerir una instalacin de procesamiento alterna para satisfacer
necesidades operativas inmediatas (como en el caso de un desastre
natural). A largo plazo, se debe identificar una nueva instalacin
permanente para recuperacin en caso de desastre, y esta se
debe equipar para proporcionar continuidad de los servicios de
procesamiento de SI regularmente.
Planificacin pandmica
Las pandemias pueden ser definidas como las epidemias o
brotes de enfermedades infecciosas en los seres humanos, y
que tienen la capacidad de propagarse rpidamente en grandes
(SACA. Todos los derechos reservados.
Seccin Dos: Contenido Captulo 2 - Gobierno y Gestin de TI elsa eertifiedlntormatioo
M Systems Auditor'
An i$ACA"c.rtll lcll..,
Si la organizacin est dispuesta a investigar la magnitud
de las prdidas que sufrir el negocio por la interrupcin, la
organizacin puede llevar a acabo un BIA (explicado en otra
seccin de este manual). El BIA permite a la organizacin
determinar el mximo tiempo posible de inactividad para
una aplicacin en particular y cuntos datos se podran perder.
El BIA tambin permite a la organizacin cuantificar las
prdidas a medida que aumentan despus de la interrupcin,
con lo cual la organizacin puede tomar una decisin sobre
la tecnologa (y las instalaciones) utilizada para la proteccin
y recuperacin de sus activos de informacin clave (sistema
de informacin, componentes de TI, datos, etc.).
Los resultados de la evaluacin de riesgos y el BIA se incorporan
a la estrategia de continuidad del negocio de SI, la cual describe
la tecnologa principal y los principios que sirven de base a
la proteccin y recuperacin de SI, as como la directriz para
implementar la tecnologa y los principios.
A medida que se ejecuta la estrategia de continuidad del negocio
de SI y su estrategia global de TI, la estructura de TI de la
organizacin cambia. Se introducen nuevas contramedidas para
afrontar riesgos y las anteriores se vuelven obsoletas. El BCP del
sistema de informacin se debe cambiar segn corresponda y
se debe volver a probar peridicamente para asegurar que estos
cambios sean satisfactorios.
Igual que cualquier BCP, un BCP del sistema de informacin es
mucho ms que un plan para los sistemas de informacin. Un
BCP identifica lo que har el negocio en caso de que suceda
un desastre. Por ejemplo, adnde se reportarn los empleados
para trabajar, cmo se tomarn los pedidos mientras se restablece
el sistema informtico, a cules proveedores se llamar para que
suministren las provisiones necesarias. Un subcomponente del BCP
es el plan de recuperacin de TI en caso de desastre. Normalmente
detalla el proceso que utilizar el personal de TI para restablecer
los sistemas informticos, las comunicaciones, las aplicaciones y
sus datos. Los planes de recuperacin en caso de desastre (DRP)
se pueden incluir en el BCP o como un documento separado,
dependiendo de las necesidades del negocio.
No todos los sistemas requerirn una estrategia de recuperacin.
Basndose en los resultados de la evaluacin de riesgos y el
BIA, la gerencia podria considerar que no es conveniente desde el
punto de vista econmico restaurar ciertas aplicaciones en caso de
desastre. Un factor primordial cuando se determinan las opciones
de recuperacin es que el costo nunca debe exceder el beneficio
(esto suele determinarse claramente despus de un BIA).
La recuperacin de SI en caso de desastre suele ocurrir en
circunstancias poco comunes y estresantes (incendio, inundacin,
devastacin por huracn). Con frecuencia sucede que los
controles de seguridad (tanto fisicos como de SI) no funcionan.
Por lo tanto, se recomienda que la organizacin implemente un
sistema de gestin de la seguridad de la informacin (ISMS) para
mantener la integridad, confidencialidad y disponibilidad del SI,
y no solamente bajo condiciones normales.
130
2.13.2 DESASTRES Y OTROS EVENTOS QUE PUEDEN
CAUSAR INTERRUPCIONES
Los desastres son interrupciones que causan que recursos de
informacin crticos queden inoperantes durante un perodo,
afectando de manera adversa las operaciones organizacionales.
La interrupcin podra durar de algunos minutos a varios
meses, dependiendo del grado del dao causado al recurso de
informacin. Es importante conocer que, ante situaciones de
desastre, es necesario desplegar esfuerzos de recuperacin para
restaurar el estado operacional.
Un desastre pudiera ser el resultado de desastres naturales,
como terremotos, inundaciones, tomados, tormentas elctricas
severas e incendios, que causan daos extensos a la instalacin
de procesamiento y a la localidad en general. Otros eventos
desastrosos que causan interrupciones pueden ocurrir cuando los
servicios esperados, como energa elctrica, telecomunicaciones,
suministro de gas natural u otro servicio pblico, ya no estn
disponibles para la compaa debido a un desastre natural u otra
causa. Un desastre podra ser tambin el resultado de eventos
causados por seres humanos, tales como ataques terroristas,
ataques de intrusos informticos, virus o error humano.
No todas las interrupciones fisicas del servicio son causadas por
un desastre. Por ejemplo, la interrupcin del servicio algunas
veces es causada por desperfectos del sistema, eli minaciones de
archivos por accidente, versiones de aplicaciones que no han sido
probadas, prdida de los datos de respaldo, ataques de negacin
de servicio (DoS) de red, intrusiones y virus. Estos eventos
pueden requerir acciones para recuperar el estado operacional
a fin de reanudar el servicio. Las acciones pueden necesitar del
restablecimiento del hardware, software o archivos de datos.
Muchas interrupciones comienzan con simples incidentes.
Normalmente, si la organizacin posee un centro de soporte
(help desk) o un centro de servicio, ste actuar como el sistema
de advertencia temprana para reconocer las primeras seales
de una interrupcin inminente. A menudo, tales interrupciones
(por ejemplo, un rendimiento de la base de datos que desmejora
gradualmente) pasan desapercibidas. Hasta que estallan estos
"desastres progresivos" (la base de datos se detiene), slo causan
quejas espordicas de parte de los usuarios.
Basndose en la evaluacin de riesgos, se formulan escenarios
del peor caso y estrategias de contingencia a largo y corto plazo
dentro de la estrategia de continuidad del negocio de SI para luego
incorporarlos en el BCP (u otro plan). A corto plazo, se puede
requerir una instalacin de procesamiento alterna para satisfacer
necesidades operativas inmediatas (como en el caso de un desastre
natural). A largo plazo, se debe identificar una nueva instalacin
permanente para recuperacin en caso de desastre, y esta se
debe equipar para proporcionar continuidad de los servicios de
procesamiento de SI regularmente.
Planificacin pandmica
Las pandemias pueden ser definidas como las epidemias o
brotes de enfermedades infecciosas en los seres humanos, y
que tienen la capacidad de propagarse rpidamente en grandes
Certified Information
CIZiffli
,
Systems Auditor
reas, posiblemente en todo el mundo. A lo largo de la historia
han ocurrido varias pandemias, y recientemente las amenazas
de pandemias como los brotes de gripe aviar o porcina han
concientizado an ms a la gente sobre este tema. Hay claras
diferencias entre planificacin para una pandemia y planificacin
de continuidad del negocio tradicional, y por lo tanto, el auditor
de SI debe evaluar la preparacin de la organizacin para brotes
de pandemia. La planificacin para una pandemia presenta
desafios nicos; a diferencia de los desastres naturales, los
desastres tcnicos, los actos maliciosos o los actos terroristas, el
impacto de una pandemia es mucho ms dificil de determinar
debido a la diferencia prevista en magnitud y duracin.
Enfrentar daos a imagen, reputacin o marca
Los rumores perjudiciales pueden surgir de muchas fuentes
(incluso internas). Pueden estar o no relacionados con un
incidente serio o crisis. Independientemente de que sean
"espontneos" o un efecto colateral de un problema de
continuidad del negocio o recuperacin ante desastres, sus
consecuencias pueden ser devastadoras. Una de las peores
consecuencias de las crisis es la prdida de confianza.
Las actividades efectivas de relaciones pblicas (RP) en una
organizacin pueden desempear un papel importante en la
tarea de contener el dao a la imagen y asegurar que la crisis no
empeore. Ciertas industrias (por ejemplo, bancos, organizaciones
de servicios de salud, aerolneas, refineras petroleras, productos
qumicos, transporte, plantas de energa nuclear u otras
organizaciones con impacto social relevante) deberan contar
con protocolos elaborados para tratar accidentes y catstrofes.
Una organizacin que experimente un incidente importante
debera considerar y aplicar algunas mejores prcticas bsicas.
Independientemente de las consecuencias objetivas resultantes
de un incidente (demora o interrupcin de servicio, prdidas
econmicas, etc.), de existir alguna, una opinin pblica negativa o
rumores negativos pueden ser costosos. Reaccionar apropiadamente
en pblico (o ante los medios) durante una crisis no es simple.
Es necesario designar y preparar con antelacin a un portavoz
entrenado para estos casos. En general, un asesor legal senior o
un funcionario de relaciones pblicas es la mejor opcin. Nadie,
independientemente de su rango en la jerarqua organizacional,
excepto el portavoz, debera emitir declaraciones pblicas.
Como parte de la preparacin, el portavoz debera redactar y
guardar en archivo un comunicado general con espacios en blanco
que se llenarn con datos especficos de cada circunstancia. Este
procedimiento no debera eludirse debido a la improvisacin o
presin del tiempo. El comunicado no debera establecer las causas
del incidente, sino indicar que se inici una investigacin y que se
reportarn los resultados. No se deberan asumir responsabilidades.
No se debera responsabilizar al sistema o al proceso.
Nota: Aunque tratar los daos a la imagen, reputacin o marca
es una preocupacin de muchas organizaciones pblicas, el
candidato a CISA no ser sometido a prueba sobre este tema.
2.13.3 PROCESO DE PLANIFICACIN DE
CONTINUIDAD DEL NEGOCIO
El proceso de BCP puede dividirse en las fases de ciclo de vida
que se muestran en la figura 2.14.
2.13.4 POLTICA DE CONTINUIDAD DEL NEGOCIO
Una poltica de continuidad del negocio es un documento aprobado
por la alta gerencia que define la magnitud y el alcance del esfuerzo
de continuidad del negocio (un proyecto o un programa continuo)
dentro de la organizacin. La poltica de continuidad del negocio
Figura 2.14Ciclo de vida de la planificacin de la continuidad del negocio
\
Planificacin del
proyecto (poltica
de BC, alcance
del proyecto)
Evaluacin y anlisis
de riesgos
Monitoreo,
mantenimiento
y actualizacin
del plan de BC
Pruebas
del plan
de BC
Desarrollo
del plan
de BC
A
Ciclo de vida de la
planificacin de continuidad
del negocio

y
Anlisis de
impacto del
negocio

BC
Plan
Development
Estrategia de
desarrollo de BC
Ejecucin de estrategia
(implementacin de
contramedidas para
enfrentar riesgos)

131
e
eertified lntormatioo e -t 1 2 G b G - d ..... ,
A ap1 u o - o 1erno y est1on e , ,
reas, posiblemente en todo el mundo. A lo largo de la historia
han ocurrido varias pandemias, y recientemente las amenazas
de pandemias como los brotes de gripe aviar o porcina han
concientizado an ms a la gente sobre este tema. Hay claras
diferencias entre planificacin para una pandemia y planificacin
de continuidad del negocio tradicional, y por lo tanto, el auditor
de SI debe evaluar la preparacin de la organizacin para brotes
de pandemia. La planificacin para una pandemia presenta
desafios nicos; a diferencia de los desastres naturales, los
desastres tcnicos, los actos maliciosos o los actos terroristas, el
impacto de una pandernia es mucho ms dificil de determinar
debido a la diferencia prevista en magnitud y duracin.
Enfrentar daos a imagen, reputacin o marca
Los rumores peijudiciales pueden surgir de muchas fuentes
(incluso internas). Pueden estar o no relacionados con un
incidente serio o crisis. Independientemente de que sean
"espontneos" o un efecto colateral de un problema de
continuidad del negocio o recuperacin ante desastres, sus
consecuencias pueden ser devastadoras. Una de las peores
consecuencias de las crisis es la prdida de confianza.
Las actividades efectivas de relaciones pblicas (RP) en una
organizacin pueden desempear un papel importante en la
tarea de contener el dao a la imagen y asegurar que la crisis no
empeore. Ciertas industrias (por ejemplo, bancos, organizaciones
de servicios de salud, aerolneas, refineras petroleras, productos
qumicos, transporte, plantas de energa nuclear u otras
organizaciones con impacto social relevante) deberan contar
con protocolos elaborados para tratar accidentes y catstrofes.
Una organizacin que experimente un incidente importante
debera considerar y aplicar algunas mejores prcticas bsicas.
Independientemente de las consecuencias objetivas resultantes
de un incidente (demora o interrupcin de servicio, prdidas
econmicas, etc.), de existir alguna, una opinin pblica negativa o
rumores negativos pueden ser costosos. Reaccionar apropiadamente
en pblico (o ante los medios) durante una crisis no es simple.
Es necesario designar y preparar con antelacin a un portavoz
entrenado para estos casos. En general, un asesor legal senior o
un funcionario de relaciones pblicas es la mejor opcin. Nadie,
independientemente de su rango en la jerarqua organizacional,
excepto el portavoz, debera emitir declaraciones pblicas.
Como parte de la preparacin, el portavoz debera redactar y
guardar en archivo un comunicado general con espacios en blanco
que se llenarn con datos especficos de cada circunstancia. Este
procedimiento no debera eludirse debido a la improvisacin o
presin del tiempo. El comunicado no debera establecer las causas
del incidente, sino indicar que se inici una investigacin y que se
reportarn los resultados. No se deberan asumir responsabilidades.
No se debera responsabilizar al sistema o al proceso.
Nota: Aunque tratar los daos a la imagen, reputacin o marca
es una preocupacin de muchas organizaciones pblicas, el
candidato a CISA no ser sometido a prueba sobre este tema.
2.13.3 PROCESO DE PLANIFICACIN DE
CONTINUIDAD DEL NEGOCIO
El proceso de BCP puede dividirse en las fases de ciclo de vida
que se muestran en la figura 2.14.
2.13.4 POLTICA DE CONTINUIDAD DEL NEGOCIO
Una poltica de continuidad del negocio es un documento aprobado
por la alta gerencia que define la magnitud y el alcance del esfuerzo
de continuidad del negocio (un proyecto o un programa continuo)
dentro de la organizacin. La poltica de continuidad del negocio
Figura 2.14-Ciclo de vida de la planificacin de la continuidad del negocio
Planificacin del Monitoreo,
proyecto (poltica
..... mantenimiento
.....
de BC, alcance
......
y actualizacin
......
del proyecto) del plan de BC
+
Ciclo de vida de la
Evaluacin y anlisis
planificacin de continuidad
de riesgos
del negocio
+
Anlisis de
impacto del
....
Estrategia de
negocio
...
desarrollo de BC
...
...
Pruebas
del plan
de BC
Desarrollo
del plan
de BC
t
BC
Plan
Development
Ejecucin de estrategia
(implementacin de
contramedidas para
enfrentar riesgos)
131
Reducir la probabilidad
r
Mitigar las consecuencias
Figura 2.15 Diagrama de relacin entre incidente e impacto
Controles
defectivos
Controles
(contramedidas
para enfrentar
riesgos)
Controles
correctivos
Controles
preventivos
CISA rstre d m s kAttn i orn
An ISPer cer tication
se puede dividir en dos partes: pblica e interna. La poltica de
continuidad del negocio sirve para otros diversos propsitos:
Su parte interna es un mensaje para las partes interesadas de la
organizacin (por ejemplo, empleados, gerencia, directores) de
que la compaa realiza esfuerzos, compromete sus recursos y
espera que el resto de la organizacin haga lo mismo.
Su parte pblica es un mensaje para las partes interesadas
externas (accionistas, reguladores, autoridades, etc.) de que la
organizacin se toma en serio sus obligaciones (por ejemplo,
prestacin de servicios, cumplimiento).
Es una declaracin para la organizacin que empodera a los
responsables de la continuidad del negocio.
Puede establecer de manera amplia los principios generales en
los cuales se basa la continuidad del negocio.
Una poltica de continuidad del negocio debe ser proactiva.
El mensaje que se debe transmitir a la organizacin es que se
tienen que usar todos los controles posibles para detectar y evitar
interrupciones y que, aunque ocurran, se deben tener los controles
necesarios para mitigar las consecuencias. Posteriormente, esto
se refleja en la estrategia de continuidad del negocio de SI y en su
ejecucin. Existen controles preventivos y detectivos para reducir
la probabilidad de una interrupcin y controles correctivos para
mitigar las consecuencias.
El BCP (o DRP de TI) es el control correctivo ms crtico. Depende
de que otros controles sean efectivos; en particular, depende de la
gestin de incidentes y de las soluciones de respaldo y recuperacin.
Los incidentes y sus impactos se pueden, hasta cierto punto,
mitigar a travs de controles preventivos. Estas relaciones se
describen en la fi gura 2.15.
Esto requiere que el grupo de gestin de incidentes (centro de
servicio) est adecuadamente dotado de personal, respaldado y
capacitado en gestin de crisis, y que el BCP est bien diseado,
documentado, probado en profundidad, financiado y auditado.
2.13.5 GESTIN DE INCIDENTES EN LA
PLANIFICACIN DE LA CONTINUIDAD DEL NEGOCIO
Los incidentes y las crisis son dinmicas por naturaleza.
Evolucionan, cambian en el tiempo y segn las circunstancias y a
menudo son rpidos e imprevisibles. En vista de esto, su gestin
debe ser dinmica, proactiva y bien documentada. Un incidente
es cualquier evento inesperado, aun cuando no cause daos
significativos.
Dependiendo de una estimacin del nivel del dao a la organizacin,
es necesario categorizar todos los tipos de incidentes. Un sistema
de clasificacin podra incluir las siguientes categoras:
insignificante, menor, mayor y crisis. La clasificacin puede
cambiar de manera dinmica mientras se resuelve el incidente.
Estos niveles pueden describirse como sigue:
Los incidentes insignificantes son los que causan daos
no perceptibles o significativos, tales como colapsos muy
breves del sistema operativo (SO) con recuperacin total de
informacin o cortes momentneos de energa con suministro
permanente de energa (UPS).
Los eventos menores son los que, aunque no sean insignificantes,
no generan impactos materiales (de importancia relativa) o
financieros negativos.
Los incidentes mayores causan un impacto material negativo
sobre los procesos de negocio y pueden afectar otros sistemas,
departamentos o incluso clientes externos.
La crisis es un incidente mayor que puede tener un impacto
material (de importancia relativa) serio sobre el funcionamiento
permanente del negocio y pudiera afectar de manera adversa
otros sistemas o a terceros. La severidad del impacto depende
de la industria y circunstancias, pero en general es directamente
proporcional al tiempo transcurrido desde el inicio del incidente
hasta su solucin.
Es necesario documentar, clasificar y revisar los incidentes
menores, mayores y de crisis hasta que se corrijan o resuelvan.
ISACA. Tod os los d e re chos re se rvad os.
Seccin Dos: Contenido Captulo 2 - Gobierno y Gestin de TI esa Certilied
M Systems Audi tor
AIIISACA"c.rtlllean.>
Figura 2.15 -Diagrama de relacin entre incidente e impacto
se puede dividir en dos partes: pblica e interna. La poltica de
continuidad del negocio sirve para otros diversos propsitos:
Su parte interna es un mensaje para las partes interesadas de la
organizacin (por ejemplo, empleados, gerencia, directores) de
que la compaa realiza esfuerzos, compromete sus recursos y
espera que el resto de la organizacin haga lo mismo.
Su parte pblica es un mensaje para las partes interesadas
externas (accionistas, reguladores, autoridades, etc.) de que la
organizacin se toma en serio sus obligaciones (por ejemplo,
prestacin de servicios, cumplimiento).
Es una declaracin para la organizacin que empodera a los
responsables de la continuidad del negocio.
Puede establecer de manera amplia los principios generales en
los cuales se basa la continuidad del negocio.
Una poltica de continuidad del negocio debe ser proactiva.
El mensaje que se debe transmitir a la organizacin es que se
tienen que usar todos los controles posibles para detectar y evitar
interrupciones y que, aunque ocurran, se deben tener los controles
necesarios para mitigar las consecuencias. Posteriormente, esto
se refleja en la estrategia de continuidad del negocio de SI y en su
ejecucin. Existen controles preventivos y detectivos para reducir
la probabilidad de una interrupcin y controles correctivos para
mitigar las consecuencias.
El BCP (o DRP de TI) es el control correctivo ms crtico. Depende
de que otros controles sean efectivos; en particular, depende de la
gestin de incidentes y de las soluciones de respaldo y recuperacin.
Los incidentes y sus impactos se pueden, hasta cierto punto,
mitigar a travs de controles preventivos. Estas relaciones se
describen en la figura 2.15.
Esto requiere que el grupo de gestin de incidentes (centro de
servicio) est adecuadamente dotado de personal, respaldado y
capacitado en gestin de crisis, y que el BCP est bien diseado,
documentado, probado en profundidad, financiado y auditado.
132
Mitigar las consecuencias
Respaldo y
recuperacin
Pllln deBC
o OR den"
2.13.5 GESTIN DE INCIDENTES EN LA
PLANIFICACIN DE LA CONTINUIDAD DEL NEGOCIO
Los incidentes y las crisis son dinmicas por naturaleza.
Evolucionan, cambian en el tiempo y segn las circunstancias y a
menudo son rpidos e imprevisibles. En vista de esto, su gestin
debe ser dinmica, proactiva y bien documentada. Un incidente
es cualquier evento inesperado, aun cuando no cause daos
significativos.
Dependiendo de una estimacin del nivel del dao a la organizacin,
es necesario categorizar todos los tipos de incidentes. Un sistema
de clasificacin podria incluir las siguientes categoras:
insignificante, menor, mayor y crisis. La clasificacin puede
cambiar de manera dinmica mientras se resuelve el incidente.
Estos niveles pueden describirse como sigue:
Los incidentes insignificantes son los que causan daos
no perceptibles o significativos, tales como colapsos muy
breves del sistema operativo (SO) con recuperacin total de
informacin o cortes momentneos de energa con suministro
permanente de energa (UPS).
Los eventos menores son los que, aunque no sean insignificantes,
no generan impactos materiales (de importancia relativa) o
financieros negativos.
Los incidentes mayores causan un impacto material negativo
sobre los procesos de negocio y pueden afectar otros sistemas,
departamentos o incluso clientes externos.
La crisis es un incidente mayor que puede tener un impacto
material (de importancia relativa) serio sobre el funcionamiento
permanente del negocio y pudiera afectar de manera adversa
otros sistemas o a terceros. La severidad del impacto depende
de la industria y circunstancias, pero en general es directamente
proporcional al tiempo transcurrido desde el inicio del incidente
hasta su solucin.
Es necesario documentar, clasificar y revisar los incidentes
menores, mayores y de crisis hasta que se corrijan o resuelvan.
REACCIONES ANTE LOS NIVELES DE NMENTES/CRISIS
1 NIVEL
c..als
114CICE.NTE
,4 ,44OR
1NcIDEATE
VENOR
NOS EGINFICATtve
NIVEL
CRIS I S
14Cie..E 4.1-E
14440]P
11410ENTE
MEN4OR
ht, S 47.4 4,11FICAW2
CRITERIOPRINCIPAL
(En h01-35)
1 lempo Fuere de Servicio
PRONSTICO ACTUAL
24
24 12
12
2 1
O E
1.) SM Senior Management k Adrrinistradar Senior)
1") SO Securti Oficer (Oficial de Seguridad)
2 ACCIONES
CRITERIOS COMPLEMENTARIOS
ATO PLATAFORMAS
neyBO tle Necl I ng a Ne acIn
Vitus. gusanos, teles 401
814
Segur el Plan de Continuidad del Negocio
Se m' el Plan de Continuidad del Negocio
Correrpnirroar/Reelauraneerrpialar
CorregictrnpartRestaurarneemplaz
Corregir
Corregir
Alertar al SMy eventualmente a las Agencias
Alertar al SM y eventualmente a las Agencias regionales
Alertar 1 SM
Alertar SM
Si se confrma, alertar al SO
Corregr
Anaizar Reoularrnante Loa
CISA
C
se
ed
m s
IAnf uodrm aon

ISAC4
Figura 2.16Niveles de incidente/crisis
Fuente: Personas & Tcnicas Multimedia SL 2007. Todos los derechos reservados. Usado con autorizacin.
Es un proceso dinmico, debido a que un incidente mayor puede
disminuir en grado momentneamente y extenderse luego para
convertirse en una crisis.
Los incidentes insignificantes se pueden analizar en trminos
estadsticos para identificar cualquier causa sistmica o evitable.
La figura 2.16 muestra un ejemplo de un sistema de clasificacin
de incidentes y protocolo de reaccin.
El director de seguridad (SO) u otro individuo designado debe
ser notificado de todos los incidentes relevantes tan pronto como
cualquier evento desencadenante ocurra. Luego, esta persona
debe seguir un protocolo de escalamiento pre-establecido
(por ejemplo, llamar a un portavoz, alertar a la alta gerencia e
involucrar a las agencias regulatorias), el cual puede estar seguido
por la invocacin de un plan de recuperacin, como el DRP de
tecnologa de la informacin.
En general, el principal criterio de severidad (nivel) de incidentes
es el estimado de tiempo improductivo de servicio. Otros
criterios pueden incluir cun extenso es el impacto sobre datos
o plataformas. El servicio se puede definir como compromisos
incluyentes con clientes que pueden ser consumidores externos o
departamentos internos. Generalmente, la prestacin de servicios
es regulada por acuerdos de nivel de servicio (SLA), los cuales
pueden establecer el tiempo improductivo mximo y los estimados
de recuperacin. Aunque no es siempre cierto, la severidad suele
basarse en gran medida en el tiempo improductivo estimado. Otros
criterios pueden incluir el impacto sobre datos o plataformas y
el grado en el cual el funcionamiento de la organizacin sufre un
impacto adverso. Un enfoque conservador e infalible seria asignar
a cualquier incidente significativo un nivel inicial de severidad
provisional (ver la figura 2.16). A medida que el incidente
evoluciona, este nivel debe ser reevaluado regularmente por la
persona o el equipo a cargo, al que comnmente se hace referencia
como equipo de respuesta a incidentes o "firecall".
2.13.6 ANLISIS DE IMPACTO DEL NEGOCIO
El BIA es un paso critico en el desarrollo de la estrategia de
continuidad del negocio y la subsiguiente implementacin de las
contramedidas de riesgo y el BCP en particular.
El BIA se utiliza para evaluar los procesos crticos (y
componentes de TI que los respaldan) y para determinar marcos
de tiempo, prioridades, recursos e interdependencias. Incluso
si se ha realizado una extensa evaluacin de riesgos antes del
BIA, y la criticidad y los riesgos se incluyen en el BIA, la regla
general es verificar dos veces. Comnmente, el BIA descubre
algn componente menos visible, pero aun as vital, que respalda
el proceso de negocio crtico. En los casos en que se hayan
externalizado actividades de TI a proveedores de servicio,
tambin se deben considerar los compromisos contractuales (en el
contexto de un BCP).
Para cumplir esta fase con xito, se debe alcanzar una comprensin
de la organizacin, los procesos clave del negocio y los recursos de
SI utilizados por la organizacin para respaldar los procesos clave
del negocio. Por lo general, esto se obtiene a partir de los resultados
de la evaluacin de riesgos. El BIA requiere un alto grado de
respaldo por parte de la alta gerencia y una amplia participacin del
personal de TI y de usuario final. La criticidad de los recursos de
informacin (por ejemplo, aplicaciones, datos, redes, software del
sistema, instalaciones) que respaldan los procesos de negocio de una
organizacin deben ser aprobados por la alta gerencia.
Para el BIA, es importante incluir todos los tipos de recursos de
informacin y ver ms all de aquellos tradicionales (por ejemplo,
servidores de base de datos).
Los sistemas de informacin constan de mltiples componentes.
Algunos de los componentes (por ejemplo, servidores de base de
datos o matrices de almacenamiento) son bastante visibles. Otros
(por ejemplo, pasarelas (gateways), servidores de transporte,
dispositivos de red) pueden quedar fuera de alcance y permanecer
e
. Certifled lntormatioo Captulo 2 - Gobierno y Gestin de TI
M Systems Audotor'
MISACA"c.tllbtkln
Figura 2.16-Niveles de incidente/crisis
REACCIONES ANTE LOS NIVELES CE INCIDENTES/ CRISIS
CRITERIO PRINCIPAL CRITERIOS COMPLEMENTARIOS
(En horas)
DATOS PLATAFORMAS 1 oem po era de "erv coo
PRON STICO ACTUAL
1 NIVEL
2
2 12
CRtSIS
12 6 P&rdlda de lnteonaad c e la BO Ataques de Haek111 g o Ne ac<H, Oe .serA o o
6

\1rti S. cusanos. tl!l ii as del he.r<Mer:

2
2 1 de tran.sacoones
1 os
2 ACCIONES

UAYOP
u e. NOR
Alertar al SM evertuafmente atas
A lertar al SM evenlualrrent e a
rtaral
Alertar al SM
Si se contrma. al so V
Analz.ar R uarrrente
r SM Sen"' M:naemant Seroor)
("' so SeOJrt y oncer rOftcial de SeQ.XIdad)
Fuente: Personas & Tcnicas Multimedia SL 2007. Todos los derechos reservados. Usado con autorizacin.
Es un proceso dinmico, debido a que un incidente mayor puede
disminuir en grado momentneamente y extenderse luego para
convertirse en una crisis.
Los incidentes insignificantes se pueden analizar en trminos
estadsticos para identificar cualquier causa sistmica o evitable.
La figura 2.16 muestra un ejemplo de un sistema de clasificacin
de incidentes y protocolo de reaccin.
El director de seguridad (SO) u otro individuo designado debe
ser notificado de todos los incidentes relevantes tan pronto como
cualquier evento desencadenan te ocurra. Luego, esta persona
debe seguir un protocolo de escalamiento pre-establecido
(por ejemplo, llamar a un portavoz, alertar a la alta gerencia e
involucrar a las agencias regulatorias), el cual puede estar seguido
por la invocacin de un plan de recuperacin, como el DRP de
tecnologa de la informacin.
En general, el principal criterio de severidad (nivel) de incidentes
es el estimado de tiempo improductivo de servicio. Otros
criterios pueden incluir cun extenso es el impacto sobre datos
o plataformas. El servicio se puede defmir como compromisos
incluyentes con clientes que pueden ser consumidores externos o
departamentos internos. Generalmente, la prestacin de servicios
es regulada por acuerdos de nivel de servicio (SLA), los cuales
pueden establecer el tiempo improductivo mximo y los estimados
de recuperacin. Aunque no es siempre cierto, la severidad suele
basarse en gran medida en el tiempo improductivo estimado. Otros
criterios pueden incluir el impacto sobre datos o plataformas y
el grado en el cual el funcionamiento de la organizacin sufre un
impacto adverso. Un enfoque conservador e infalible seria asignar
a cualquier incidente significativo un nivel inicial de severidad
provisional (ver la figura 2.16). A medida que el incidente
evoluciona, este nivel debe ser reevaluado regularmente por la
persona o el equipo a cargo, al que comnmente se hace referencia
como equipo de respuesta a incidentes o "firecall".
2.13.6 ANLISIS DE IMPACTO DEL NEGOCIO
El BIA es un paso crtico en el desarrollo de la estrategia de
continuidad del negocio y la subsiguiente implementacin de las
contramedidas de riesgo y el BCP en particular.
El BIA se utiliza para evaluar los procesos crticos (y
componentes de TI que los respaldan) y para determinar marcos
de tiempo, prioridades, recursos e interdependencias. Incluso
si se ha realizado una extensa evaluacin de riesgos antes del
BIA, y la criticidad y los riesgos se incluyen en el BIA, la regla
general es verificar dos veces. Comnmente, el BIA descubre
algn componente menos visible, pero aun as vital, que respalda
el proceso de negocio critico. En los casos en que se hayan
externalizado actividades de TI a proveedores de servicio,
tambin se deben considerar los compromisos contractuales (en el
contexto de un BCP).
Para cumplir esta fase con xito, se debe alcanzar una comprensin
de la organizacin, los procesos clave del negocio y los recursos de
SI utilizados por la organizacin para respaldar los procesos clave
del negocio. Por lo general, esto se obtiene a partir de los resultados
de la evaluacin de riesgos. El BIA requiere un alto grado de
respaldo por parte de la alta gerencia y una amplia participacin del
personal de TI y de usuario fmal. La criticidad de los recursos de
informacin (por ejemplo, aplicaciones, datos, redes, software del
sistema, instalaciones) que respaldan los procesos de negocio de una
organizacin deben ser aprobados por la alta gerencia.
Para el BIA, es importante incluir todos los tipos de recursos de
informacin y ver ms all de aquellos tradicionales (por ejemplo,
servidores de base de datos).
Los sistemas de informacin constan de mltiples componentes.
Algunos de los componentes (por ejemplo, servidores de base de
datos o matrices de almacenamiento) son bastante visibles. Otros
(por ejemplo, pasarelas (gateways), servidores de transporte,
dispositivos de red) pueden quedar fuera de alcance y permanecer
133
Figura 2.17Consideraciones del BIA
1. Cules son los diferentes procesos del negocio? Cada proceso debe
ser evaluado para determinar su importancia relativa. Las indicaciones
de criticidad incluyen, por ejemplo:
El proceso respalda asuntos de salud y seguridad, tales como registros
de pacientes hospitalizados y sistemas de control de trfico areo
La interrupcin del proceso causa una prdida de ingresos a la
organizacin o costos excepcionales inaceptables
El proceso cumple con requerimientos legales o estatutarios
El nmero de segmentos del negocio o nmero de usuarios afectados
Un proceso puede ser crtico o no crtico dependiendo de factores tales
como tiempo de operacin y modo de operacin (por ejemplo, horas
hbiles u operaciones de cajeros automticos).
2. Cules son los recursos de informacin crticos relacionados con los
procesos del negocio crticos de una organizacin? Esta es la primera
consideracin ya que la interrupcin de un recurso de informacin no
es un desastre de por s, a menos que est relacionado con un proceso
del negocio crtico. Por ejemplo, una organizacin pierde su ingreso, lo
que genera procesos del negocio debido a una falla de SI.
Otros ejemplos de procesos del negocio crticos pueden incluir:
Recepcin de pagos
Produccin
Pago de empleados
Publicidad
Despacho de productos terminados
Cumplimiento con las leyes y regulaciones
3. Cul es el perodo de tiempo de recuperacin crtico para recursos
de informacin en el cual los procesos del negocio se deben reanudar
antes de sufrir prdidas significativas o inaceptables? En gran
medida, la duracin del perodo de tiempo de recuperacin depende
de la naturaleza del negocio o servicio interrumpido. Por ejemplo, las
instituciones financieras, tales como bancos y casas de corretaje,
suelen tener un perodo de tiempo de recuperacin crtico mucho ms
corto que las fbricas. Igualmente, el momento del ao o el da de la
semana pueden afectar la ventana de tiempo de recuperacin. Por
ejemplo, un banco que experimenta una interrupcin importante el
sbado a medianoche tiene ms tiempo para recuperarse que el lunes
a medianoche, suponiendo que el banco no realiza procesos el lunes.
Seccin Dos: Contenido Captulo 2 - Gobierno y Gestin de TI C
ISA s=111:rn
I Cerrficaton
"invisibles". Por ejemplo, una aplicacin de banca no puede
realizar sus servicios si las pasarelas (gateways) de pago no estn
activas. Con frecuencia, las partes vitales de la aplicacin o los
datos crticos pueden residir en las estaciones de trabajo del
usuario. Idealmente, al completarse el BIA, estos componentes
"ocultos" se deben descubrir e incluir en el campo del programa
(proyecto) de continuidad del negocio para incorporarlos
posteriormente en el BCP.
Nota: El auditor de SI debera poder evaluar el BIA. El
enunciado de tarea en la prctica laboral establece: evaluar
el BCP de la organizacin para asegurar su capacidad de
continuar con operaciones empresariales esenciales durante
el perodo de una interrupcin de TI. El auditor necesita saber
en qu consiste el desarrollo de un BIA, de manera de poder
evaluarlo apropiadamente. Sin embargo, el candidato a CISA
no ser sometido a prueba sobre cmo se realiza un BIA o
qu mtodo se utiliza para realizar un BIA.
La informacin que se recolecta para el BIA proviene de
diferentes partes de la organizacin, la cual posee aplicaciones/
procesos crticos. Para evaluar el impacto de tiempo improductivo
para un proceso/aplicacin particular, se desarrollan las bandas
de impacto (por ejemplo, alto, medio, bajo) y, para cada proceso,
el impacto se estima en tiempo (horas, das, semanas). El mismo
enfoque se usa al estimar el impacto de la prdida de datos. Si es
necesario, el impacto financiero se puede estimar utilizando las
mismas tcnicas, para asignar el valor financiero a la banda de
impacto particular.
Adems, los datos del BIA se pueden recolectar en las ventanas
de tiempo necesarias para suministrar recursos vitalescunto
tiempo puede funcionar la organizacin si se daa un suministro o
cundo lleg el reemplazo. Por ejemplo, cunto tiempo funcionar
el banco sin tarjetas plsticas con chips para personalizarlos en
las tarjetas de crdito o cundo necesitar TI que se traigan las
estaciones de trabajo de escritorio despus de un desastre?
Existen diferentes enfoques para realizar un BIA. Uno de los
enfoques populares es el cuestionario. Este enfoque involucra
el desarrollo de un cuestionario detallado y su distribucin a los
usuarios clave en las reas de TI y usuario final. La informacin
recopilada se tabula y analiza. En caso de que se requiera
informacin adicional, el equipo de BIA contactara a los usuarios
relevantes para obtener esa informacin. Otro enfoque popular es
entrevistar a grupos de usuarios clave. La informacin recopilada
durante estas sesiones de entrevistas se tabula y analiza para
desarrollar un plan de BIA y estrategia detallados. Un tercer
enfoque es reunir a miembros del personal de TI y usuarios
finales relevantes (es decir, los que son dueos de los procesos
crticos) en una habitacin para llegar a una conclusin sobre el
impacto potencial de varios niveles de interrupciones sobre el
negocio. El ltimo mtodo se puede utilizar despus de recolectar
todos los datos. Un grupo mixto decidir rpidamente sobre el
tiempo improductivo aceptable y los recursos vitales.
De ser posible, los auditores de SI deberan analizar el volumen
de transacciones pasado al determinar el impacto sobre el negocio
si el sistema no estuvo disponible durante un largo perodo.
Esto sustentara el proceso de entrevistas que los auditores de SI
realizan para ejecutar el BIA.
Las tres preguntas principales que deberan considerarse durante
la fase de BIA se muestran en la figura 2.17.
Para tomar esta decisin, es necesario considerar dos factores
de costo independientes, tal como se muestra en la figura 2.18.
Uno es el costo del tiempo fuera de servicio del desastre. Este
componente, en el corto plazo (por ejemplo, horas, das, semanas),
crece rpidamente en el tiempo, en cuyo caso el impacto de una
interrupcin aumenta a medida que se extiende su duracin. En
un momento determinado, deja de crecer, reflejando el momento
o punto en que el negocio ya no puede funcionar. El costo del
tiempo fuera de servicio (que crece en el tiempo) tiene muchos
componentes (dependiendo de la industria y la compaa y
circunstancias especficas), entre stos: costo de recursos inactivos
(por ejemplo, en produccin), cada en las ventas (por ejemplo,
ISACA. Todoslosderechosreservados.
Seccin Dos: Contenido Captulo 2- Gobierno y Gestin de TI 9sa Certifiedlntormation
M Systems Au<htor'
MISACA"Cirtllleltion
"invisibles". Por ejemplo, una aplicacin de banca no puede
realizar sus servicios si las pasarelas (gateways) de pago no estn
activas. Con frecuencia, las partes vitales de la aplicacin o los
datos crticos pueden residir en las estaciones de trabajo del
usuario. Idealmente, al completarse el BIA, estos componentes
"ocultos" se deben descubrir e incluir en el campo del programa
(proyecto) de continuidad del negocio para incorporarlos
posteriormente en el BCP.
Nota: El auditor de SI debera poder evaluar el BIA. El
enunciado de tarea en la prctica laboral establece: evaluar
el BCP de la organizacin para asegurar su capacidad de
continuar con operaciones empresariales esenciales durante
el perodo de una interrupcin de TI. El auditor necesita saber
en qu consiste el desarrollo de un BIA, de manera de poder
evaluarlo apropiadamente. Sin embargo, el candidato a CISA
no ser sometido a prueba sobre cmo se realiza un BIA o
qu mtodo se utiliza para realizar un BIA.
La informacin que se recolecta para el BIA proviene de
diferentes partes de la organizacin, la cual posee aplicaciones/
procesos crticos. Para evaluar el impacto de tiempo improductivo
para un proceso/aplicacin particular, se desarrollan las bandas
de impacto (por ejemplo, alto, medio, bajo) y, para cada proceso,
el impacto se estima en tiempo (horas, das, semanas). El mismo
enfoque se usa al estimar el impacto de la prdida de datos. Si es
necesario, el impacto financiero se puede estimar utilizando las
mismas tcnicas, para asignar el valor financiero a la banda de
impacto particular.
Adems, los datos del BIA se pueden recolectar en las ventanas
de tiempo necesarias para suministrar recursos vitales--cunto
tiempo puede funcionar la organizacin si se daa un suministro o
cundo lleg el reemplazo. Por ejemplo, cunto tiempo funcionar
el banco sin tatjetas plsticas con chips para personalizarlos en
las tatjetas de crdito o cundo necesitar TI que se traigan las
estaciones de trabajo de escritorio despus de un desastre?
Existen diferentes enfoques para realizar un BIA. Uno de los
enfoques populares es el cuestionario. Este enfoque involucra
el desarrollo de un cuestionario detallado y su distribucin a los
usuarios clave en las reas de TI y usuario final. La informacin
recopilada se tabula y analiza. En caso de que se requiera
informacin adicional, el equipo de BIA contactara a los usuarios
relevantes para obtener esa informacin. Otro enfoque popular es
entrevistar a grupos de usuarios clave. La informacin recopilada
durante estas sesiones de entrevistas se tabula y analiza para
desarrollar un plan de BIA y estrategia detallados. Un tercer
enfoque es reunir a miembros del personal de TI y usuarios
finales relevantes (es decir, los que son dueos de los procesos
crticos) en una habitacin para llegar a una conclusin sobre el
impacto potencial de varios niveles de interrupciones sobre el
negocio. El ltimo mtodo se puede utilizar despus de recolectar
todos los datos. Un grupo mixto decidir rpidamente sobre el
tiempo improductivo aceptable y los recursos vitales.
De ser posible, los auditores de SI deberan analizar el volumen
de transacciones pasado al determinar el impacto sobre el negocio
si el sistema no estuvo disponible durante un largo perodo.
134
Esto sustentara el proceso de entrevistas que los auditores de SI
realizan para ejecutar el BIA.
Las tres preguntas principales que deberan considerarse durante
la fase de BIA se muestran en la figura 2.17.
Figura 2.17-Consideraciones del BIA
1. Cules son los diferentes procesos del negocio? Cada proceso debe
ser evaluado para determinar su importancia relativa. Las indicaciones
de criticidad incluyen, por ejemplo:
El proceso respalda asuntos de salud y seguridad, tales como registros
de pacientes hospitalizados y sistemas de control de trfico areo
La interrupcin del proceso causa una prdida de ingresos a la
organizacin o costos excepcionales inaceptables
El proceso cumple con requerimientos legales o estatutarios
El nmero de segmentos del negocio o nmero de usuarios afectados
Un proceso puede ser crtico o no crtico dependiendo de factores tales
como tiempo de operacin y modo de operacin (por ejemplo, horas
hbiles u operaciones de cajeros automticos).
2. Cules son los recursos de informacin crticos relacionados con los
procesos del negocio crticos de una organizacin? Esta es la primera
consideracin ya que la interrupcin de un recurso de informacin no
es un desastre de por s, a menos que est relacionado con un proceso
del negocio crtico. Por ejemplo, una organizacin pierde su ingreso, lo
que genera procesos del negocio debido a una falla de SI.
Otros ejemplos de procesos del negocio crticos pueden incluir:
Recepcin de pagos
Produccin
Pago de empleados
Publicidad
Despacho de productos terminados
Cumplimiento con las leyes y regulaciones
3. Cul es el perodo de tiempo de recuperacin crtico para recursos
de informacin en el cual los procesos del negocio se deben reanudar
antes de sufrir prdidas significativas o inaceptables? En gran
medida, la duracin del perodo de tiempo de recuperacin depende
de la naturaleza del negocio o servicio interrumpido. Por ejemplo, las
instituciones financieras, tales como bancos y casas de corretaje,
suelen tener un perodo de tiempo de recuperacin crtico mucho ms
corto que las fbricas. Igualmente, el momento del ao o el da de la
semana pueden afectar la ventana de tiempo de recuperacin. Por
ejemplo, un banco que experimenta una interrupcin importante el
sbado a medianoche tiene ms tiempo para recuperarse que el lunes
a medianoche, suponiendo que el banco no realiza procesos el lunes.
Para tomar esta decisin, es necesario considerar dos factores
de costo independientes, tal como se muestra en la figura 2.18.
Uno es el costo del tiempo fuera de servicio del desastre. Este
componente, en el corto plazo (por ejemplo, horas, das, semanas),
crece rpidamente en el tiempo, en cuyo caso el impacto de una
interrupcin aumenta a medida que se extiende su duracin. En
un momento determinado, deja de crecer, reflejando el momento
o punto en que el negocio ya no puede funcionar. El costo del
tiempo fuera de servicio (que crece en el tiempo) tiene muchos
componentes (dependiendo de la industria y la compaa y
circunstancias especficas), entre stos: costo de recursos inactivos
(por ejemplo, en produccin), cada en las ventas (por ejemplo,
Costos
Figura 2.18Costos de interrupcin vs. costos de recuperacin
Operaciones
Descontinuadas
Total
Tiempo fuera de servicio
Estrategias de
Recuperacin
Alternativas
Tiempo
aso Ce syr stt ief ied ms1=on
ISACX.111..
rdenes), costos financieros (por ejemplo, no hay facturacin
ni recoleccin), demoras (por ejemplo, adquisicin) y costos
indirectos (por ejemplo, prdida de participacin de mercado,
imagen y buen nombre).
El otro factor es el costo de las medidas correctivas alternativas
(la activacin del BCP), que disminuye con el objetivo elegido
para el tiempo de recuperacin. El costo de recuperacin tambin
tiene muchos componentes (la mayora de los cuales son rgidos-
inelsticos). Esto incluye el costo de preparacin y prueba peridica
del BCP, el costo de instalaciones de almacenamiento fuera del sitio,
el costo de cobertura de seguro, el costo anual de configuracin de
sitios alternativos, etc. Las estrategias de recuperacin alternativas
pueden representarse mediante puntos, utilizando coordenadas como
intervalo de tiempo y costo.
Al identificar estos costos, laf igur a2.18 muestra tambin la
suma de las curvas de costos como total de costos (interrupcin
y recuperacin), en cuyo caso una organizacin desea encontrar
el punto en el cual se puede minimizar el costo total. Para esto,
se evalan las estrategias de desarrollo alternativas, en cuyo
caso, con algunas estrategias discretas, se puede dibujar la curva
descendente y cada punto en la curva representara una posible
estrategia. La curva como un todo representa todas las estrategias
posibles. Cada estrategia posible tiene un costo fijo, es decir, no
cambia en el tiempo. Note que el costo fijo de cada estrategia
posible puede diferir; en general, mientras ms corta sea la
recuperacin objetivo, ms alto ser el costo fijo. La organizacin
paga el costo de implementacin, aun cuando no ocurran
accidentes. Si existe un accidente, los costos variables aumentarn
significativamente (por ejemplo, su contrato de "warm site"
puede contemplar una cuota anual plana ms una cuota diaria por
ocupacin real) debido a la necesidad de personal adicional, horas
extra, transporte y otros problemas logsticos (por ejemplo, per
diem, nuevas lneas de comunicacin).
Si la estrategia de continuidad del negocio busca un tiempo de
recuperacin ms largo, ser menos costosa que una estrategia de
tiempo ms reducido, pero puede ser ms susceptible a que los
costos de tiempo fuera de servicio salgan de control.
Uno de los resultados importantes del BIA, aparte del RTO y
RPO, es que proporciona una manera de agrupar sistemas de
informacin de acuerdo a su tiempo de recuperacin. Esto suele
servir como gua en la seleccin de soluciones tecnolgicas (es
decir, controles) que soportan la continuidad del negocio y la
recuperacin en caso de desastre de TI.
En resumen, es necesario minimizar la suma de todos los
costostiempo fuera de servicio y recuperacin. El primer
grupo (costos de tiempo fuera de servicio) aumenta en el tiempo,
mientras que el segundo (costos de recuperacin) disminuye en
el tiempo; la suma es generalmente una curva en U. En la parte
inferior de la curva en U, se puede encontrar el costo ms bajo.
Nota: El candidato a CISA no se someter a prueba de
clculos de costos.
Clasificacin de operaciones y anlisis de criticidad
Qu es la clasificacin de riesgo del sistema? Involucra una
determinacin de riesgo basada en el impacto derivado del
perodo de tiempo de recuperacin crtico, as como tambin
la posibilidad de que ocurra una interrupcin adversa. Muchas
organizaciones utilizarn un riesgo de ocurrencia para determinar
un costo razonable de preparacin. Por ejemplo, pueden
determinar que existe un riesgo de 0,1 por ciento (o 1 en 1 000)
de que en los prximos cinco aos la organizacin sufrir una
seria interrupcin. Si el impacto evaluado de una interrupcin es
US $10 millones, el costo razonable mximo de estar preparado
puede ser de US $10 millones x 0,1 por ciento = US $10 000
durante cinco aos. Este mtodo se llama Expectativa de prdidas
anuales (ALE). En este proceso de anlisis basado en el riesgo,
la priorizacin de sistemas crticos puede ocurrir al desarrollar
estrategias de recuperacin. El procedimiento de clasificacin de
riesgo se debera realizar en coordinacin con el procesamiento
de SI y el personal de usuario final.
Un sistema caracterstico de calificacin de riesgos puede
contener las clasificaciones que aparecen en la figura 2.19.
Clasif icacin
Figura 2.19--Clasificacin de sistemas
Descr ipcin
Cr t ica No se pueden realizar estas funciones a menos
que se reemplacen por capacidades idnticas.
No se pueden reemplazar las aplicaciones crticas
con mtodos manuales. La tolerancia a las
interrupciones es muy baja; por lo tanto, el costo
de interrupcin es muy alto.
Vit al Estas funciones se pueden realizar manualmente,
pero slo por un breve perodo de tiempo. Existe
una mayor tolerancia a la interrupcin que con los
sistemas crticos y, por consiguiente, los costos de
interrupcin resultan un tanto ms bajos, siempre
que las funciones se restauren dentro de cierto lapso
de tiempo (por lo general cinco das o menos).
Sensit ivas Estas funciones se pueden realizar manualmente,
a un costo aceptable y por un perodo de tiempo
prolongado. Aunque se puede realizar manualmente,
generalmente es un proceso difcil y se requiere
personal adicional para ejecutarlo.
No sensit ivas Estas funciones se pueden interrumpir por un
perodo de tiempo prolongado, a un costo bajo o nulo
para la compaa y requieren poco o ningn esfuerzo
de actualizacin cuando se restauran.
ISACA. Tod oslosd er echosr eser vad os.
e ~ Capitulo 2- Gobierno y Gestin de TI Seccin Dos: Contenido
rdenes), costos financieros (por ejemplo, no hay facturacin
ni recoleccin), demoras (por ejemplo, adquisicin) y costos
indirectos (por ejemplo, prdida de participacin de mercado,
imagen y buen nombre).
Figura 2.18--Costos de interrupcin vs. costos de recuperacin
Costos
Operaciones
Dei\as
Estrategias de
Recuperacin
Alternativas
Tiempo
El otro factor es el costo de las medidas correctivas alternativas
(la activacin del BCP), que disminuye con el objetivo elegido
para el tiempo de recuperacin. El costo de recuperacin tambin
tiene muchos componentes (la mayora de los cuales son rgidos-
inelsticos). Esto incluye el costo de preparacin y prueba peridica
del BCP, el costo de instalaciones de almacenamiento fuera del sitio,
el costo de cobertura de seguro, el costo anual de configuracin de
sitios alternativos, etc. Las estrategias de recuperacin alternativas
pueden representarse mediante puntos, utilizando coordenadas como
intervalo de tiempo y costo.
Al identificar estos costos, la figura 2.18 muestra tambin la
suma de las curvas de costos como total de costos (interrupcin
y recuperacin), en cuyo caso una organizacin desea encontrar
el punto en el cual se puede minimizar el costo total. Para esto,
se evalan las estrategias de desarrollo alternativas, en cuyo
caso, con algunas estrategias discretas, se puede dibujar la curva
descendente y cada punto en la curva representara una posible
estrategia. La curva como un todo representa todas las estrategias
posibles. Cada estrategia posible tiene un costo fijo, es decir, no
cambia en el tiempo. Note que el costo fijo de cada estrategia
posible puede diferir; en general, mientras ms corta sea la
recuperacin objetivo, ms alto ser el costo fijo. La organizacin
paga el costo de implementacin, aun cuando no ocurran
accidentes. Si existe un accidente, los costos variables aumentarn
significativamente (por ejemplo, su contrato de "warm si te"
puede contemplar una cuota anual plana ms una cuota diaria por
ocupacin real) debido a la necesidad de personal adicional, horas
extra, transporte y otros problemas logsticos (por ejemplo, per
diem, nuevas lneas de comunicacin).
Si la estrategia de continuidad del negocio busca un tiempo de
recuperacin ms largo, ser menos costosa que una estrategia de
tiempo ms reducido, pero puede ser ms susceptible a que los
costos de tiempo fuera de servicio salgan de control.
Uno de los resultados importantes del BIA, aparte del RTO y
RPO, es que proporciona una manera de agrupar sistemas de
informacin de acuerdo a su tiempo de recuperacin. Esto suele
servir como gua en la seleccin de soluciones tecnolgicas (es
decir, controles) que soportan la continuidad del negocio y la
recuperacin en caso de desastre de TI.
En resumen, es necesario minimizar la suma de todos los
costostiempo fuera de servicio y recuperacin. El primer
grupo (costos de tiempo fuera de servicio) aumenta en el tiempo,
mientras que el segundo (costos de recuperacin) disminuye en
el tiempo; la suma es generalmente una curva en U. En la parte
inferior de la curva en U, se puede encontrar el costo ms bajo.
Nota: El candidato a CISA no se someter a prueba de
clculos de costos.
Clasificacin de operaciones y anlisis de criticidad
Qu es la clasificacin de riesgo del sistema? Involucra una
determinacin de riesgo basada en el impacto derivado del
perodo de tiempo de recuperacin crtico, as como tambin
la posibilidad de que ocurra una interrupcin adversa. Muchas
organizaciones utilizarn un riesgo de ocurrencia para determinar
un costo razonable de preparacin. Por ejemplo, pueden
determinar que existe un riesgo de O, 1 por ciento (o 1 en 1 000)
de que en los prximos cinco aos la organizacin sufrir una
seria interrupcin. Si el impacto evaluado de una interrupcin es
US $1 O millones, el costo razonable mximo de estar preparado
puede ser de US $1 O millones x O, 1 por ciento= US $1 O 000
durante cinco aos. Este mtodo se llama Expectativa de prdidas
anuales (ALE). En este proceso de anlisis basado en el riesgo,
la priorizacin de sistemas crticos puede ocurrir al desarrollar
estrategias de recuperacin. El procedimiento de clasificacin de
riesgo se debera realizar en coordinacin con el procesamiento
de SI y el personal de usuario final.
Un sistema caracterstico de calificacin de riesgos puede
contener las clasificaciones que aparecen en la figura 2.19.
Figura 2.19--Ciasificacin de sistemas
Clasificacin Descripcin
Critica No se pueden realizar estas funciones a menos
que se reemplacen por capacidades idnticas.
No se pueden reemplazar las aplicaciones crticas
con mtodos manuales. La tolerancia a las
interrupciones es muy baja; por lo tanto, el costo
de interrupcin es muy alto.
Vital Estas funciones se pueden realizar manualmente,
pero slo por un breve perodo de tiempo. Existe
una mayor tolerancia a la interrupcin que con los
sistemas crticos y, por consiguiente, los costos de
interrupcin resultan un tanto ms bajos, siempre
que las funciones se restauren dentro de cierto lapso
de tiempo (por lo general cinco das o menos).
Sensitivas Estas funciones se pueden realizar manualmente,
a un costo aceptable y por un perodo de tiempo
prolongado. Aunque se puede realizar manualmente,
generalmente es un proceso difcil y se requiere
personal adicional para ejecutarlo.
No sensitivas Estas funciones se pueden interrumpir por un
perodo de tiempo prolongado, a un costo bajo o nulo
para la compaa y requieren poco o ningn esfuerzo
de actualizacin cuando se restauran.
135
CISA ley rsr e msIttrn
ISAMCondlcat
La prxima fase en la gestin de la continuidad es identificar
las diversas estrategias de recuperacin y alternativas posibles
para recuperarse cuando ocurre una interrupcin y/o desastre.
La seleccin de una estrategia apropiada, basada en el BIA y el
anlisis de criticidad, es el siguiente paso para desarrollar los planes
de continuidad del negocio (BCP) y planes de recuperacin en caso
de desastre (DRP). Las dos mtricas que ayudan a determinar las
estrategias de recuperacin son el RPO y el RTO.
Las estrategias de recuperacin se describen detalladamente en el
captulo 4.
2.13.7 DESARROLLO DE PLANES DE CONTINUIDAD
DEL NEG OCIO
Tomando en cuenta las entradas que se reciben del BIA, los
anlisis de criticidad y la estrategia de recuperacin seleccionada
por la gerencia, se deberan desarrollar o revisar los BCP y DRP
detallados. Se deberan tratar todos los problemas concernientes
al alcance de la continuidad del negocio relacionados con
la interrupcin de los procesos de negocios, incluyendo la
recuperacin despus de un desastre. Los diferentes factores
que se deben considerar cuando se desarrolla/revisa el plan son
los siguientes:
Capacidad para actuar antes de que ocurran desastres, que cubra
el manejo de la respuesta a incidentes con el fin de resolver
correctamente todos los incidentes relevantes que afecten los
procesos de negocios
Procedimientos de evacuacin
Procedimientos para la declaracin de un desastre
(procedimientos de escalamiento)
Circunstancias bajo las cuales se debe declarar un desastre.
Todas las interrupciones no representan desastres, pero un
mnimo incidente si no se maneja a tiempo o de una manera
adecuada, podra conducir a un desastre. Por ejemplo, el ataque
de un virus que no se reconoce y se ha mantenido por algn
tiempo puede destruir toda la instalacin de TI.
La identificacin clara de las responsabilidades en el plan
La identificacin clara de las personas responsables para cada
funcin en el plan
La identificacin clara de la informacin sobre el contrato
La explicacin paso a paso del proceso de recuperacin
La identificacin clara de los diferentes recursos que se
requieren para la operacin de recuperacin y continuidad
de la organizacin
El plan debe estar documentado y escrito en un lenguaje sencillo
y fcil de entender.
Es comn identificar los equipos de personal que son responsables
de tareas especficas en caso de desastre. Se deben formar equipos
importantes. Sus responsabilidades se explican ms adelante. Se
deben mantener copias del plan fuera del sitio. El plan se debe
estructurar de modo tal que sus partes puedan ser fcilmente
manejadas por diferentes equipos.
2.13.8 OTROS PROBLEMAS EN EL DESARROLLO DE
LOS PLANES
El personal que deber reaccionar a la interrupcin o desastre
es aquel responsable por los recursos ms crticos. Por
consiguiente, la participacin de la gestin de usuario es vital
para el xito en la ejecucin del BCP. La participacin de la
gestin de usuario es esencial para la identificacin de sistemas
crticos, sus correspondientes tiempos de recuperacin y la
especificacin de los recursos necesarios. Las tres principales
divisiones que requieren participacin en la formulacin del
BCP son los servicios de apoyo (quienes detectan las primeras
seales de incidentes o desastres), las operaciones comerciales
(quienes pudieran verse afectadas a raz del incidente) y el
apoyo en el procesamiento de la informacin (quin correr la
recuperacin).
Debido a que el propsito subyacente del BCP es la recuperacin
y el restablecimiento de las operaciones comerciales, es esencial
considerar a toda la organizacin, no solamente los servicios de
procesamiento IS, en el desarrollo del plan. Cuando no exista un
plan BCP uniforme en toda la organizacin, debera ampliarse el
plan para el procesamiento IS a fin de incluir la planificacin para
todas las divisiones y unidades que dependen de las funciones de
procesamiento de los sistemas de informacin.
En la formulacin del plan, deberan asimismo incluirse los
siguientes aspectos:
Lista del personal, con informacin de contacto, necesaria para
mantener las funciones crticas del negocio a corto, mediano y
largo plazo.
Configuracin de las instalaciones del edificio, escritorios,
sillas, telfonos, etc., que se requieren para mantener las
funciones crticas del negocio a corto, mediano y largo plazo.
Los recursos requeridos para reanudar/continuar las operaciones
(no necesariamente recursos de TI y ni siquiera de tecnologa,
como por ejemplo los materiales con el membrete de la compaa).
2.13.9 ELEMENTOS DE UN PLAN DE CONTINUIDAD DEL
NEG OCIO
Dependiendo del tamao o los requerimientos de una
organizacin, un BCP puede constar de uno o ms documentos.
Esto debe incluir:
Plan de continuidad de las operaciones
DRP
Plan de restablecimiento del negocio
Tambin puede incluir:
Continuidad del plan de apoyo/Plan de contingencias TI
Plan de comunicaciones de crisis
Plan de respuesta a incidentes
Plan de transporte
Plan de emergencia del ocupante
Plan de evacuacin y reubicacin de emergencia
El propsito y alcance de los componentes de un BCP, tal como lo
sugiere NIST se indican en la Figura 2.20.
ISACA. Todoslosde r e chosr e se r vados.
Seccin Dos: Contenido Captulo 2 - Gobierno y Gestin de TI esa Certilled lnformation
M Systems Auditor
Ani$ACA"Ctrtilbli011
La prxima fase en la gestin de la continuidad es identificar
las diversas estrategias de recuperacin y alternativas posibles
para recuperarse cuando ocurre una interrupcin y/o desastre.
La seleccin de una estrategia apropiada, basada en el BIA y el
anlisis de criticidad, es el siguiente paso para desarrollar los planes
de continuidad del negocio (BCP) y planes de recuperacin en caso
de desastre (DRP). Las dos mtricas que ayudan a determinar las
estrategias de recuperacin son el RPO y el RTO.
Las estrategias de recuperacin se describen detalladamente en el
captulo 4.
2.13.7 DESARROLLO DE PLANES DE CONTINUIDAD
DEL NEGOCIO
Tomando en cuenta las entradas que se reciben del BIA, los
anlisis de criticidad y la estrategia de recuperacin seleccionada
por la gerencia, se deberan desarrollar o revisar los BCP y DRP
detallados. Se deberan tratar todos los problemas concernientes
al alcance de la continuidad del negocio relacionados con
la interrupcin de los procesos de negocios, incluyendo la
recuperacin despus de un desastre. Los diferentes factores
que se deben considerar cuando se desarrolla/revisa el plan son
los siguientes:
Capacidad para actuar antes de que ocurran desastres, que cubra
el manejo de la respuesta a incidentes con el fin de resolver
correctamente todos los incidentes relevantes que afecten los
procesos de negocios
Procedimientos de evacuacin
Procedimientos para la declaracin de un desastre
(procedimientos de escalamiento)
Circunstancias bajo las cuales se debe declarar un desastre.
Todas las interrupciones no representan desastres, pero un
mnimo incidente si no se maneja a tiempo o de una manera
adecuada, podra conducir a un desastre. Por ejemplo, el ataque
de un virus que no se reconoce y se ha mantenido por algn
tiempo puede destruir toda la instalacin de TI.
La identificacin clara de las responsabilidades en el plan
La identificacin clara de las personas responsables para cada
funcin en el plan
La identificacin clara de la informacin sobre el contrato
La explicacin paso a paso del proceso de recuperacin
La identificacin clara de los diferentes recursos que se
requieren para la operacin de recuperacin y continuidad
de la organizacin
El plan debe estar documentado y escrito en un lenguaje sencillo
y fcil de entender.
Es comn identificar los equipos de personal que son responsables
de tareas especficas en caso de desastre. Se deben formar equipos
importantes. Sus responsabilidades se explican ms adelante. Se
deben mantener copias del plan fuera del sitio. El plan se debe
estructurar de modo tal que sus partes puedan ser fcilmente
manejadas por diferentes equipos.
136
2.13.8 OTROS PROBLEMAS EN EL DESARROLLO DE
LOS PLANES
El personal que deber reaccionar a la interrupcin o desastre
es aquel responsable por los recursos ms crticos. Por
consiguiente, la participacin de la gestin de usuario es vital
para el xito en la ejecucin del BCP. La participacin de la
gestin de usuario es esencial para la identificacin de sistemas
crticos, sus correspondientes tiempos de recuperacin y la
especificacin de los recursos necesarios. Las tres principales
divisiones que requieren participacin en la formulacin del
BCP son los servicios de apoyo (quienes detectan las primeras
seales de incidentes o desastres), las operaciones comerciales
(quienes pudieran verse afectadas a raz del incidente) y el
apoyo en el procesamiento de la informacin (quin correr la
recuperacin).
Debido a que el propsito subyacente del BCP es la recuperacin
y el restablecimiento de las operaciones comerciales, es esencial
considerar a toda la organizacin, no solamente los servicios de
procesamiento IS, en el desarrollo del plan. Cuando no exista un
plan BCP uniforme en toda la organizacin, debera ampliarse el
plan para el procesamiento IS a fin de incluir la planificacin para
todas las divisiones y unidades que dependen de las funciones de
procesamiento de los sistemas de informacin.
En la formulacin del plan, deberan asimismo incluirse los
siguientes aspectos:
Lista del personal, con informacin de contacto, necesaria para
mantener las funciones crticas del negocio a corto, mediano y
largo plazo.
Configuracin de las instalaciones del edificio, escritorios,
sillas, telfonos, etc., que se requieren para mantener las
funciones crticas del negocio a corto, mediano y largo plazo.
Los recursos requeridos para reanudar/continuar las operaciones
(no necesariamente recursos de TI y ni siquiera de tecnologa,
como por ejemplo los materiales con el membrete de la compaa).
2.13.9 ELEMENTOS DE UN PLAN DE CONTINUIDAD DEL
NEGOCIO
Dependiendo del tamao o los requerimientos de una
organizacin, un BCP puede constar de uno o ms documentos.
Esto debe incluir:
Plan de continuidad de las operaciones
DRP
Plan de restablecimiento del negocio
Tambin puede incluir:
Continuidad del plan de apoyo/Plan de contingencias TI
Plan de comunicaciones de crisis
Plan de transporte
Plan de emergencia del ocupante
Plan de evacuacin y reubicacin de emergencia
El propsito y alcance de los componentes de un BCP, tal como lo
sugiere NIST se indican en la Figura 2.20.
JSACA. Todos los derechos reservados.
Certifled Information
CISA Systems Auditor
An Cadillo.
Figura
Plan
2.20Propsito del alcance de los componentes del p an de continuidad del negocio
Propsito Alcance
Planes de continuidad del
negocio
Brindar los procedimientos para sostener las operaciones
esenciales del negocio mientras se recuperan de un
trastorno significativo.
Aborda los procesos comerciales; TI basada solamente en
su respaldo a los procesos comerciales.
Plan de recuperacin (o
restablecimiento) del negocio
(BRP)
Brindar los procedimientos para recuperar las
operaciones comerciales inmediatamente despus de una
situacin de desastre.
Trata los procesos comerciales; TI no enfocada; TI basada
solamente en el respaldo a los procesos comerciales.
Plan de continuidad de
operaciones (COOP)
Brindar los procedimientos y las capacidades para
sostener las funciones esenciales y estratgicas de una
organizacin como sitio alterno durante un lapso de hasta
30 das.
Aborda el subconjunto de las misiones de una
organizacin que se caracterizan por ser las ms crticas;
usualmente escritas al nivel de la sede; TI no enfocada.
Continuidad del plan
de respaldo o plan de
contingencia TI
Brindar los procedimientos y capacidades para recuperar
una aplicacin mayor o un sistema general de respaldo.
Igual que el plan de contingencia TI; acomete las
irregularidades en el sistema TI; no se enfoca en el
proceso comercial.
Plan de comunicaciones
crticas
Brinda los procedimientos para distribuir informes de
situacin al personal y al pblico.
Trata las comunicaciones con el personal y con el pblico;
TI no enfocada.
cibemticos
Proporciona estrategias para detectar, responder y limitar
las consecuencias de incidentes cibemticos dolosos.
Se centra en respuestas de seguridad de informacin a
los incidentes que afectan los sistemas o redes.
Plan de recuperacin en caso
de desastre
Brindar procedimientos detallados para facilitar la
recuperacin de capacidades en un sitio alterno.
A menudo TI enfocada; se limita a los grandes trastornos
con efectos a largo plazo.
Plan de emergencia del
ocupante (OEP).
Brinda procedimientos coordinados para minimizar las
prdidas de vida o lesiones y proteger contra los daos a
la propiedad privada en respuesta a una amenaza fsica.
Se enfoca en el personal y la propiedad de la instalacin
en particular; no est basado en el proceso comercial ni
en una funcionalidad del sistema TI.
Para la fase de planificacin, implantacin y evaluacin del BCP,
debera acordarse lo siguiente:
Las polticas que regirn todos los esfuerzos de continuidad
y recuperacin
Metas/requerimientos/productos para cada fase
Instalaciones alternas para realizar las tareas y operaciones
Recursos de informacin crtica que se van a implementar
(p.ej. datos y sistemas)
Personas responsables de llevarlas a cabo
Recursos (incluso humanos) disponibles para ayudar en
su implementacin
Programa de actividades con prioridades establecidas
Muchos BCP son creados como procedimientos que albergan
los sistemas de recuperacin de la informacin (es decir:
almacenamiento de datos, servidores, etc.), estaciones de
trabajo de usuario, otros equipos determinados (lectores de
tarjetas, scanners de cdigos de barras, impresoras, etc.) y la
red (canales, equipo). Las copias del plan deberan mantenerse
fuera del establecimiento: en la instalacin de recuperacin, en la
instalacin de almacenamiento de medios y posiblemente en las
casas del personal clave en la toma las decisiones. Cada vez con
mayor frecuencia, una organizacin coloca la versin electrnica
del plan en un sitio web duplicado.
Personal clave para la toma de decisiones
El plan debera contener una lista telefnica o "rbol de llamadas", es
decir, un directorio de notificacin, del personal IS clave en la toma
de decisiones y del personal de usuario final, que se requieran para
emprender y llevar a cabo los esfuerzos de recuperacin. Usualmente
se trata de un directorio telefnico de personas que deberan ser
notificadas en el caso de un incidente, desastre o catstrofe. El punto
de atencin en la preparacin de la lista es que en caso de un desastre
de envergadura, incendio o explosin en horas laborables que dae
seriamente las oficinas de la organizacin, muchos lderes de equipo
pudieran no estar disponibles.
Este directorio debe contener la siguiente informacin:
Lista de contactos por orden de prioridad (es decir, A quin
debera llamarse primero?)
Nmeros telefnicos y direcciones principales y para
emergencias por cada persona crtica de contacto. Usualmente
sern los lderes clave de equipo quienes se encarguen de
comunicarse con los integrantes de sus equipos.
Nmeros telefnicos y direcciones de representantes de
proveedores de equipo y software.
Nmeros telefnicos de contactos dentro de compaas que se
hayan designado para proporcionar servicios, equipo o insumos.
Nmeros telefnicos de personas de contacto en los sitios de
recuperacin, incluso representantes en el hot site o servicios
para volver a enrutar comunicaciones de red predefinidas.
Nmeros telefnicos de personas de contacto en sitios de
almacenamiento de medios fuera del sitio y de las personas
de contacto dentro de la compaa que estn autorizadas para
recuperar medios desde la locacin fuera del sitio.
Nmeros telefnicos de agentes de seguros.
Nmero telefnico de los contactos en los servicios
suministrados por personal contratado.
Nmero telefnico y contactos de organismos legales,
reglamentarios o gubernamentales, de ser necesario.
Un procedimiento para determinar a cuntas personas se ubic
mientras se utilizaba la cadena de llamadas (call tree)
Respaldo de los suministros requeridos
El plan debe tener provisiones para todos los insumos que
se necesiten para continuar con las actividades de negocio
e
. Certified lntormatloo Captulo 2 - Gobierno y Gestin de TI
M Systems Auditor
MISACA"c.tlllcatlon
Figura 2.2o-Propsito del alcance de los componentes del plan de continuidad del negocio
Plan Propsito Alcance
Planes de continuidad del Brindar los procedimientos para sostener las operaciones Aborda los procesos comerciales; TI basada solamente en
negocio esenciales del negocio mientras se recuperan de un su respaldo a los procesos comerciales.
trastorno significativo.
Plan de recuperacin (o Brindar los procedimientos para recuperar las Trata los procesos comerciales; TI no enfocada; TI basada
restablecimiento) del negocio operaciones comerciales inmediatamente despus de una solamente en el respaldo a los procesos comerciales.
(BRP) situacin de desastre.
Plan de continuidad de Brindar los procedimientos y las capacidades para Aborda el subconjunto de las misiones de una
operaciones (COOP) sostener las funciones esenciales y estratgicas de una organizacin que se caracterizan por ser las ms crticas;
organizacin como sitio alterno durante un lapso de hasta usualmente escritas al nivel de la sede; TI no enfocada.
30 das.
Continuidad del plan Brindar los procedimientos y capacidades para recuperar Igual que el plan de contingencia TI; acomete las
de respaldo o plan de una aplicacin mayor o un sistema general de respaldo. irregularidades en el sistema TI; no se enfoca en el
contingencia TI proceso comercial.
Plan de comunicaciones Brinda los procedimientos para distribuir informes de Trata las comunicaciones con el personal y con el pblico;
crticas situacin al personal y al pblico. TI no enfocada.
Plan de respuesta a incidentes Proporciona estrategias para detectar, responder y limitar Se centra en respuestas de seguridad de informacin a
cibernticos las consecuencias de incidentes cibernticos dolosos. los incidentes que afectan los sistemas o redes.
Plan de recuperacin en caso Brindar procedimientos detallados para facilitar la A menudo TI enfocada; se limita a los grandes trastornos
de desastre recuperacin de capacidades en un sitio alterno. con efectos a largo plazo.
Plan de emergencia del Brinda procedimientos coordinados para minimizar las Se enfoca en el personal y la propiedad de la instalacin
ocupante (OEP). prdidas de vida o lesiones y proteger contra los daos a en particular; no est basado en el proceso comercial ni
la propiedad privada en respuesta a una amenaza fsica. en una funcionalidad del sistema TI.
Para la fase de planificacin, implantacin y evaluacin del BCP,
debera acordarse lo siguiente:
Las polticas que regirn todos los esfuerzos de continuidad
y recuperacin
Metas/requerimientos/productos para cada fase
Instalaciones alternas para realizar las tareas y operaciones
Recursos de informacin crtica que se van a implementar
(p.ej. datos y sistemas)
Personas responsables de llevarlas a cabo
Recursos (incluso humanos) disponibles para ayudar en
su implementacin
Programa de actividades con prioridades establecidas
Muchos BCP son creados como procedimientos que albergan
los sistemas de recuperacin de la informacin (es decir:
almacenamiento de datos, servidores, etc.), estaciones de
trabajo de usuario, otros equipos determinados (lectores de
tarjetas, scanners de cdigos de barras, impresoras, etc.) y la
red (canales, equipo). Las copias del plan deberan mantenerse
fuera del establecimiento: en la instalacin de recuperacin, en la
instalacin de almacenamiento de medios y posiblemente en las
casas del personal clave en la toma las decisiones. Cada vez con
mayor frecuencia, una organizacin coloca la versin electrnica
del plan en un sitio web duplicado.
Personal clave para la toma de decisiones
El plan debera contener una lista telefnica o "rbol de llamadas", es
decir, un directorio de notificacin, del personal IS clave en la toma
de decisiones y del personal de usuario fmal, que se requieran para
emprender y llevar a cabo los esfuerzos de recuperacin. Usualmente
se trata de un directorio telefnico de personas que deberan ser
notificadas en el caso de un incidente, desastre o catstrofe. El punto
de atencin en la preparacin de la lista es que en caso de un desastre
de envergadura, incendio o explosin en horas laborables que dae
seriamente las oficinas de la organizacin, muchos lderes de equipo
pudieran no estar disponibles.
Este directorio debe contener la siguiente informacin:
Lista de contactos por orden de prioridad (es decir, A quin
debera llamarse primero?)
Nmeros telefnicos y direcciones principales y para
emergencias por cada persona crtica de contacto. Usualmente
sern los lderes clave de equipo quienes se encarguen de
comunicarse con los integrantes de sus equipos.
Nmeros telefnicos y direcciones de representantes de
proveedores de equipo y software.
Nmeros telefnicos de contactos dentro de compaas que se
hayan designado para proporcionar servicios, equipo o insumos.
Nmeros telefnicos de personas de contacto en los sitios de
recuperacin, incluso representantes en el hot site o servicios
para volver a enrutar comunicaciones de red predefinidas.
Nmeros telefnicos de personas de contacto en sitios de
almacenamiento de medios fuera del sitio y de las personas
de contacto dentro de la compaa que estn autorizadas para
recuperar medios desde la locacin fuera del sitio.
Nmeros telefnicos de agentes de seguros.
Nmero telefnico de los contactos en los servicios
suministrados por personal contratado.
Nmero telefnico y contactos de organismos legales,
reglamentarios o gubernamentales, de ser necesario.
Un procedimiento para determinar a cuntas personas se ubic
mientras se utilizaba la cadena de llamadas (call tree)
Respaldo de los suministros requeridos
El plan debe tener provisiones para todos los insumos que
se necesiten para continuar con las actividades de negocio
137
CISA
Certtfied Information
Syst ems Auditor'
I S A C P C e n l I k e l l o n
normales durante las actividades de recuperacin. Esto incluye
procedimientos detallados impresos y actualizados que pueda
seguir fcilmente tanto el personal interno como externo
que no est familiarizado con las operaciones normales y de
recuperacin. Asimismo, se debe garantizar que la ubicacin fuera
del sitio cuente con un abastecimiento de formatos especiales,
tales como cheques, facturas y pedidos.
Si la funcin de entrada de datos depende de ciertos dispositivos
de hardware o de programas de software, tales programas y equipo
deberan proporcionarse en el hot site. Lo mismo aplicara al equipo
criptogrfico, incluidas las teclas electrnicas (tokens RSA, teclas
USB, etc.).
Seguro
El plan de recuperacin debe contener informacin clave
sobre el seguro de la organizacin. La pliza de seguro para el
procesamiento de SI es por lo general una pliza contra mltiples
daos diseada para brindar varios tipos de cobertura de TI. Debe
elaborarse modularmente, para que se pueda adaptar al ambiente
de TI particular del asegurado.
Nota: Los pormenores sobre las plizas de seguro no se
incluyen en el examen de CISA porque difieren de un pas a
otro. La prueba abarca lo que debera incluirse en las plizas
y acuerdos con terceros, pero no deberan examinar los tipos
especficos de cobertura.
Los tipos especficos disponibles de cobertura son:
Equipo e instalaciones ISOfrece cobertura contra daos
fisicos al IPF y equipo propio. (Debera obtenerse un seguro
para el equipo rentado cuando el arrendatario sea responsable
por la cobertura contra riesgos.) Se advierte al auditor de SI
que debera revisar estas plizas, ya que muchas obligan a los
proveedores de seguros a reemplazar equipos que no pueden
restaurarse solamente con "de igual clase y calidad", no
necesariamente con nuevo equipo por el mismo proveedor
del equipo daado.
Reconstruccin de medios (software)Cubre contra daos
a los medios informticos que sean de la propiedad del
asegurado y por los cuales el asegurado podra ser responsable.
El seguro est disponible para desastres en las instalaciones,
fuera de las instalaciones o en trnsito y cubre el costo de
reproduccin real del bien. Algunas consideraciones para
determinar el monto de la cobertura necesaria son los costos
de programacin para reproducir los medios daados, gastos
por respaldo y reemplazo fisico de dispositivos de medios,
tales como cintas, cartuchos y discos.
Gastos adicionalesDiseada para cubrir los costos
adicionales por continuar las operaciones despus del dao o
destruccin en IPF. El monto del seguro por gastos adicionales
necesario se basa en la disponibilidad y el costo de los equipos y
operaciones de respaldo. Los gastos adicionales tambin pueden
cubrir la prdida de ganancias netas ocasionadas por daos
en medios informticos. Dispone el reembolso por prdidas
pecuniarias causadas por la suspensin de las operaciones
debido a la prdida fsica de equipos o medios. Un ejemplo
de una situacin que requiere este tipo de cobertura es si las
instalaciones para el procesamiento de informacin estaban
en el sexto piso y se quemaron los cinco primeros pisos.
En este caso, las operaciones se interrumpiran aun cuando
las instalaciones de procesamiento de informacin (IPF) no
se hubieran afectado.
Interrupcin del negocio Cubre el lucro cesante debido
al trastorno de la actividad de la empresa causada por el mal
funcionamiento de la organizacin IS.
Documentos y registros de valorCubre el valor real en
efectivo de documentos y registros (no definidos como medios)
en las instalaciones del asegurado contra divulgacin no
autorizada, prdida o dao fisico directo.
Errores y omisionesBrinda proteccin contra
responsabilidad legal en caso de que un experto incurra en un
acto, error u omisin que resulte en una prdida financiera para
el cliente. Este seguro se dise originalmente para agencias de
servicios, pero ahora est disponible con muchas aseguradoras
para protegerse contra acciones de analistas de sistemas,
diseadores de software, programadores, consultores y otro
personal de SI.
Cobertura de fidelidadPor lo general se trata de una fianza
bancaria general, un seguro por exceso de fidelidad o fianzas
generales comerciales. Cubre contra prdida ocasionada por
actos deshonestos o fraudulentos por parte de empleados.
Este tipo de cobertura es comn en instituciones financieras,
que operan sus propias instalaciones de procesamiento de
informacin (IPF).
Transporte de mediosProporciona cobertura contra
posible prdida o dao de medios en trnsito a equipos de
procesamiento de informacin (IPFs) que estn fuera de las
instalaciones. La redaccin de la cobertura de trnsito en la
pliza suele especificar que todos los documentos tienen que
ser filmados o copiados por otros medios. Cuando la pliza
no requiere especficamente que los datos se filmen antes de
su transportacin y el trabajo no se filma, la gerencia debe
obtener del servicio de mensajera de la aseguradora una carta
que describa en forma especfica la posicin del servicio de
mensajera de la compaa aseguradora y la cobertura en caso de
destruccin de los datos.
Es importante recordar varios puntos clave sobre el seguro.
La mayora de los seguros cubren nicamente las prdidas
financieras con base en el nivel histrico y no en el nivel actual
de rendimiento. Tampoco, el seguro indemniza por prdida de
imagen o fondo de comercio.
2.13.10 PRUEBAS DEL PLAN
Muchas pruebas de continuidad del negocio no alcanzan a ser
una prueba a toda escala de todas las porciones operativas de la
organizacin, si efectivamente se prueban en su totalidad. Esto
no descarta hacer pruebas totales o parciales, porque uno de los
propsitos de la prueba al plan de continuidad del negocio es
determinar qu tan bien funciona el plan o qu partes del plan
requieren mejoras.
Las pruebas deben programarse durante un tiempo que minimice
las interrupciones de operaciones normales. Los fines de semana
son, por lo general, un buen momento para realizar las pruebas.
Es importante que los miembros clave del equipo de recuperacin
participen en el proceso de la prueba y le dediquen el tiempo
necesario para poner todo su empeo en ello. La prueba debe
incluir todos los componentes crticos y simular las condiciones
Seccin Dos: Contenido Captulo 2 - Gobierno y Gestin de TI 9sa Certified lntormation
M Systems Audotor
MISACA"c.rtllltatlaoo
normales durante las actividades de recuperacin. Esto incluye
procedimientos detallados impresos y actualizados que pueda
seguir fcilmente tanto el personal interno como externo
que no est familiarizado con las operaciones normales y de
recuperacin. Asimismo, se debe garantizar que la ubicacin fuera
del sitio cuente con un abastecimiento de formatos especiales,
tales como cheques, facturas y pedidos.
Si la funcin de entrada de datos depende de ciertos dispositivos
de hardware o de programas de software, tales programas y equipo
deberan proporcionarse en el hot si te. Lo mismo aplicara al equipo
criptogrfico, incluidas las teclas electrnicas (tokens RSA, teclas
USB, etc.).
Seguro
El plan de recuperacin debe contener informacin clave
sobre el seguro de la organizacin. La pliza de seguro para el
procesamiento de SI es por lo general una pliza contra mltiples
daos diseada para brindar varios tipos de cobertura de TI. Debe
elaborarse modularmente, para que se pueda adaptar al ambiente
de TI particular del asegurado.
Nota: Los pormenores sobre las plizas de seguro no se
incluyen en el examen de CISA porque difieren de un pas a
otro. La prueba abarca lo que debera incluirse en las plizas
y acuerdos con terceros, pero no deberan examinar los tipos
especficos de cobertura.
Los tipos especficos disponibles de cobertura son:
Equipo e instalaciones IS-Ofrece cobertura contra daos
fisicos al IPF y equipo propio. (Debera obtenerse un seguro
para el equipo rentado cuando el arrendatario sea responsable
por la cobertura contra riesgos.) Se advierte al auditor de SI
que debera revisar estas plizas, ya que muchas obligan a los
proveedores de seguros a reemplazar equipos que no pueden
restaurarse solamente con "de igual clase y calidad", no
necesariamente con nuevo equipo por el mismo proveedor
del equipo daado.
Reconstruccin de medios (software}-Cubre contra daos
a los medios informticos que sean de la propiedad del
asegurado y por los cuales el asegurado podra ser responsable.
El seguro est disponible para desastres en las instalaciones,
fuera de las instalaciones o en trnsito y cubre el costo de
reproduccin real del bien. Algunas consideraciones para
determinar el monto de la cobertura necesaria son los costos
de programacin para reproducir los medios daados, gastos
por respaldo y reemplazo fisico de dispositivos de medios,
tales como cintas, cartuchos y discos.
Gastos adicionales-Diseada para cubrir los costos
adicionales por continuar las operaciones despus del dao o
destruccin en IPF. El monto del seguro por gastos adicionales
necesario se basa en la disponibilidad y el costo de los equipos y
operaciones de respaldo. Los gastos adicionales tambin pueden
cubrir la prdida de ganancias netas ocasionadas por daos
en medios informticos. Dispone el reembolso por prdidas
pecuniarias causadas por la suspensin de las operaciones
debido a la prdida fisica de equipos o medios. Un ejemplo
de una situacin que requiere este tipo de cobertura es si las
instalaciones para el procesamiento de informacin estaban
en el sexto piso y se quemaron los cinco primeros pisos.
138
En este caso, las operaciones se interrumpiran aun cuando
las instalaciones de procesamiento de informacin (IPF) no
se hubieran afectado.
Interrupcin del negocio-Cubre el lucro cesante debido
al trastorno de la actividad de la empresa causada por el mal
funcionamiento de la organizacin IS.
Documentos y registros de valor- Cubre el valor real en
efectivo de documentos y registros (no definidos como medios)
en las instalaciones del asegurado contra divulgacin no
autorizada, prdida o dao fisico directo.
Errores y omisiones-Brinda proteccin contra
responsabilidad legal en caso de que un experto incurra en un
acto, error u omisin que resulte en una prdida financiera para
el cliente. Este seguro se dise originalmente para agencias de
servicios, pero ahora est disponible con muchas aseguradoras
para protegerse contra acciones de analistas de sistemas,
diseadores de software, programadores, consultores y otro
personal de SI.
Cobertura de fidelidad- Por lo general se trata de una fianza
bancaria general, un seguro por exceso de fidelidad o fianzas
generales comerciales. Cubre contra prdida ocasionada por
actos deshonestos o fraudulentos por parte de empleados.
Este tipo de cobertura es comn en instituciones financieras,
que operan sus propias instalaciones de procesamiento de
informacin (IPF).
Transporte de medios-Proporciona cobertura contra
posible prdida o dao de medios en trnsito a equipos de
procesamiento de informacin (IPFs) que estn fuera de las
instalaciones. La redaccin de la cobertura de trnsito en la
pliza suele especificar que todos los documentos tienen que
ser filmados o copiados por otros medios. Cuando la pliza
no requiere especficamente que los datos se filmen antes de
su transportacin y el trabajo no se filma, la gerencia debe
obtener del servicio de mensajera de la aseguradora una carta
que describa en forma especfica la posicin del servicio de
mensajera de la compaa aseguradora y la cobertura en caso de
destruccin de los datos.
Es importante recordar varios puntos clave sobre el seguro.
La mayora de los seguros cubren nicamente las prdidas
financieras con base en el nivel histrico y no en el nivel actual
de rendimiento. Tampoco, el seguro indemniza por prdida de
imagen o fondo de comercio.
2.13.10 PRUEBAS DEL PLAN
Muchas pruebas de continuidad del negocio no alcanzan a ser
una prueba a toda escala de todas las porciones operativas de la
organizacin, si efectivamente se prueban en su totalidad. Esto
no descarta hacer pruebas totales o parciales, porque uno de los
propsitos de la prueba al plan de continuidad del negocio es
determinar qu tan bien funciona el plan o qu partes del plan
requieren mejoras.
Las pruebas deben programarse durante un tiempo que minimice
las interrupciones de operaciones normales. Los fines de semana
son, por lo general, un buen momento para realizar las pruebas.
Es importante que los miembros clave del equipo de recuperacin
participen en el proceso de la prueba y le dediquen el tiempo
necesario para poner todo su empeo en ello. La prueba debe
incluir todos los componentes crticos y simular las condiciones
CISA litsd =ra i l


isAcrcernitatico
reales de procesamiento durante los momentos de mayor
actividad, aun si se lleva a cabo fuera de las horas pico.
Especificaciones
En la prueba debera hacerse nfasis en el cumplimiento de
las siguientes tareas:
Verificar la integridad y precisin del BCP.
Evaluar el desempeo del personal involucrado en el ejercicio.
Informar sobre la capacitacin y concienciacin de los empleados
que no formen parte de un equipo de continuidad del negocio.
Evaluar la coordinacin entre los miembros del equipo y los
contratistas y proveedores externos.
Medir la habilidad y la capacidad del sitio alterno para realizar
procesamientos recomendados.
Evaluar la capacidad de recuperacin de registros vitales.
Evaluar el estado y la cantidad de equipos e insumos que
se han reubicado al sitio de recuperacin.
Medir el desempeo general de las actividades de procesamiento
de sistemas de informacin y operativos para mantener la
entidad de negocio.
Nota: Esto forma parte importante de la responsabilidad
del auditor evaluar los resultados y el valor del BCP y las
pruebas DRP.
Ejecucin de la prueba
Para realizar las pruebas, se debe llevar a cabo cada una de las
siguientes fases de prueba:
Prueba preliminarEl conjunto de acciones necesarias
destinadas a establecer la etapa para la prueba real. Esta fase
incluye desde colocar mesas en el rea de recuperacin de
operaciones hasta transportar e instalar equipo telefnico de
respaldo. Estas actividades estn fuera del mbito de aquellas
que ocurriran en el caso de una emergencia real, en la cual por
lo general no hay una advertencia del evento y, por tanto, ningn
tiempo para tomar acciones preparatorias.
Pruebasta es la accin real de la prueba del plan de
continuidad del negocio. Se ejecutan las actividades operativas
reales para probar los objetivos especficos del plan. Se deben
hacer capturas de datos, llamadas telefnicas, procesamiento
de sistemas de informacin, manejo de pedidos y movimiento
de personal, equipo y proveedores. Los evaluadores deben
revisar a los miembros del personal mientras realizan las
tareas designadas. sta es la prueba real de preparacin para
responder a una emergencia.
Prueba posteriorLa depuracin de las actividades de grupo.
Esta fase comprende asignaciones como regresar todos los
recursos a su lugar apropiado, desconectar los equipos, regresar
al personal a sus ubicaciones normales y borrar todos los datos
de la compaa de los sistemas de terceros. La depuracin
posterior a la prueba tambin incluye evaluar formalmente
el plan e implementar las mejoras indicadas.
Adems, se pueden realizar los siguientes tipos de pruebas:
Prueba de evaluacin con lpiz y papelVerificacin fsica
del plan, que involucra a los principales actores en la ejecucin
del plan, quienes disciernen sobre qu podra pasar en un tipo
en particular de trastorno del servicio. Podran dar un repaso al
plan entero o slo a una parte de l. La prueba en papel suele
anteceder a las pruebas de preparacin.
Prueba de preparacinUsualmente es una versin localizada
de una prueba completa, donde se invierten recursos reales en la
simulacin de avera de un sistema. Estas pruebas se aplican a
diferentes aspectos del plan y pueden ser una forma rentable de
obtener gradualmente evidencia sobre qu tan bueno es el plan.
Tambin brindan los medios para mejorar el plan en incrementos.
Pruebas operativas completasEstn a un paso de una
interrupcin real en el servicio. Una organizacin necesita haber
realizado una prueba en papel y a nivel local antes de intentar
parar las operaciones por completo. A los efectos de las pruebas
BCP, ste es el desastre.
Documentacin de los resultados
Durante cada fase de la prueba, se debe mantener documentacin
detallada de las observaciones, problemas y soluciones. Cada equipo
debera tener un formulario en forma de diario, para anotar los
pasos especficos y la informacin, que puede emplearse a modo de
documentacin. Esta documentacin sirve como una informacin
histrica importante que puede facilitar la recuperacin real durante
un desastre real. Adems, la compaa aseguradora o las autoridades
locales pudieran pedirlo. Tambin la documentacin ayuda a realizar
un anlisis detallado tanto de las fortalezas como de las debilidades
del plan.
Anlisis de resultados
Es importante contar con una manera de medir el xito del plan y
de la prueba frente a los objetivos establecidos. Por consiguiente, los
resultados debern calibrarse cuantitativamente en contraposicin a
una evaluacin basada solamente en la observacin.
Las mediciones especficas varan dependiendo de la prueba y
de la organizacin; sin embargo, las siguientes medidas generales
suelen aplicar:
TiempoEl tiempo transcurrido para llevar a cabo las tareas
establecidas, la entrega de equipos, la conformacin del personal
y la llegada al sitio establecido previamente.
CantidadLa cantidad de trabajo realizado por el personal
administrativo en el sitio alterno y el volumen de operaciones
de procesamiento de los sistemas de informacin.
ConteoEl nmero de registros vitales que se transportaron con
xito al sitio alterno en comparacin con el nmero requerido,
as como el nmero de insumos y equipos solicitados en
comparacin con los que se recibieron en realidad. Asimismo, el
nmero de sistemas crticos que se recuperaron con xito puede
medirse con el nmero de transacciones procesadas.
ExactitudLa exactitud de la captura de datos en el sitio
de recuperacin en comparacin con la precisin normal
(como un porcentaje). De igual forma, la exactitud de los
ciclos de procesamiento real se puede determinar comparando
los resultados de salida con aquellos del mismo periodo
procesados en condiciones normales.
Mantenimiento del plan
Deberan revisarse y actualizarse los planes y estrategias para la
continuidad del negocio con base en un cronograma que refleje
el reconocimiento continuo de los requerimientos cambiantes o
de manera extraordinaria (revisiones no programadas), cuando
se produzca un cambio importante que afecte los planes y
estrategias. Los siguientes factores, y otros, pueden impactar en
los requerimientos para la continuidad del negocio y la necesidad
de actualizar el plan:
ISACA. Tod os los d erechos reserva d os.
e
. Certified lntormatioo Captulo 2 - Gobierno y Gestin de TI
Systems Auditor
AniSAC.II"c.tlllcltlall
reales de procesamiento durante los momentos de mayor
actividad, aun si se lleva a cabo fuera de las horas pico.
Especificaciones
En la prueba debera hacerse nfasis en el cumplimiento de
las siguientes tareas:
Verificar la integridad y precisin del BCP.
Evaluar el desempeo del personal involucrado en el ejercicio.
Informar sobre la capacitacin y concienciacin de los empleados
que no formen parte de un equipo de continuidad del negocio.
Evaluar la coordinacin entre los miembros del equipo y los
contratistas y proveedores externos.
Medir la habilidad y la capacidad del sitio alterno para realizar
procesamientos recomendados.
Evaluar la capacidad de recuperacin de registros vitales.
Evaluar el estado y la cantidad de equipos e insumos que
se han reubicado al sitio de recuperacin.
Medir el desempeo general de las actividades de procesamiento
de sistemas de informacin y operativos para mantener la
entidad de negocio.
Nota: Esto forma parte importante de la responsabilidad
del auditor -evaluar los resultados y el valor del BCP y las
pruebas DRP.
Ejecucin de la prueba
Para realizar las pruebas, se debe llevar a cabo cada una de las
siguientes fases de prueba:
Prueba preliminar-El conjunto de acciones necesarias
destinadas a establecer la etapa para la prueba real. Esta fase
incluye desde colocar mesas en el rea de recuperacin de
operaciones hasta transportar e instalar equipo telefnico de
respaldo. Estas actividades estn fuera del mbito de aquellas
que ocurriran en el caso de una emergencia real, en la cual por
lo general no hay una advertencia del evento y, por tanto, ningn
tiempo para tomar acciones preparatorias.
Prueba- sta es la accin real de la prueba del plan de
continuidad del negocio. Se ejecutan las actividades operativas
reales para probar los objetivos especficos del plan. Se deben
hacer capturas de datos, llamadas telefnicas, procesamiento
de sistemas de informacin, manejo de pedidos y movimiento
de personal, equipo y proveedores. Los evaluadores deben
revisar a los miembros del personal mientras realizan las
tareas designadas. sta es la prueba real de preparacin para
responder a una emergencia.
Prueba posterior-La depuracin de las actividades de grupo.
Esta fase comprende asignaciones como regresar todos los
recursos a su lugar apropiado, desconectar los equipos, regresar
al personal a sus ubicaciones normales y borrar todos los datos
de la compaa de los sistemas de terceros. La depuracin
posterior a la prueba tambin incluye evaluar formalmente
el plan e implementar las mejoras indicadas.
Adems, se pueden realizar los siguientes tipos de pruebas:
Prueba de evaluacin con lpiz y papel-Verificacin fisica
del plan, que involucra a los principales actores en la ejecucin
del plan, quienes disciernen sobre qu podra pasar en un tipo
en particular de trastorno del servicio. Podran dar un repaso al
plan entero o slo a una parte de l. La prueba en papel suele
anteceder a las pruebas de preparacin.
Prueba de preparacin-Usualmente es una versin localizada
de una prueba completa, donde se invierten recursos reales en la
simulacin de avera de un sistema. Estas pruebas se aplican a
diferentes aspectos del plan y pueden ser una forma rentable de
obtener gradualmente evidencia sobre qu tan bueno es el plan.
Tambin brindan los medios para mejorar el plan en incrementos.
Pruebas operativas completas-Estn a un paso de una
interrupcin real en el servicio. Una organizacin necesita haber
realizado una prueba en papel y a nivel local antes de intentar
parar las operaciones por completo. A los efectos de las pruebas
BCP, ste es el desastre.
Documentacin de los resultados
Durante cada fase de la prueba, se debe mantener documentacin
detallada de las observaciones, problemas y soluciones. Cada equipo
debera tener un formulario en forma de diario, para anotar los
pasos especficos y la informacin, que puede emplearse a modo de
documentacin. Esta documentacin sirve como una informacin
histrica importante que puede faci litar la recuperacin real durante
un desastre real. Adems, la compaa aseguradora o las autoridades
locales pudieran pedirlo. Tambin la documentacin ayuda a realizar
un anlisis detallado tanto de las fortalezas como de las debilidades
del plan.
Anlisis de resultados
Es importante contar con una manera de medir el xito del plan y
de la prueba frente a los objetivos establecidos. Por consiguiente, los
resultados debern calibrarse cuantitativamente en contraposicin a
una evaluacin basada solamente en la observacin.
Las mediciones especficas varan dependiendo de la prueba y
de la organizacin; sin embargo, las siguientes medidas generales
suelen aplicar:
Tiempo-El tiempo transcurrido para llevar a cabo las tareas
establecidas, la entrega de equipos, la conformacin del personal
y la llegada al sitio establecido previamente.
Cantidad-La cantidad de trabajo realizado por el personal
administrativo en el sitio alterno y el volumen de operaciones
de procesamiento de los sistemas de informacin.
Conteo--El nmero de registros vitales que se transportaron con
xito al sitio alterno en comparacin con el nmero requerido,
as como el nmero de insumos y equipos solicitados en
comparacin con los que se recibieron en realidad. Asimismo, el
nmero de sistemas crticos que se recuperaron con xito puede
medirse con el nmero de transacciones procesadas.
Exactitud-La exactitud de la captura de datos en el sitio
de recuperacin en comparacin con la precisin normal
(como un porcentaje). De igual forma, la exactitud de los
ciclos de procesamiento real se puede determinar comparando
los resultados de salida con aquellos del mismo periodo
procesados en condiciones normales.
Mantenimiento del plan
Deberan revisarse y actualizarse los planes y estrategias para la
continuidad del negocio con base en un cronograma que refleje
el reconocimiento continuo de los requerimientos cambiantes o
de manera extraordinaria (revisiones no programadas), cuando
se produzca un cambio importante que afecte los planes y
estrategias. Los siguientes factores, y otros, pueden impactar en
los requerimientos para la continuidad del negocio y la necesidad
de actualizar el plan:
139
Certffled
CISA Systems
Inform
Audito
ation
r'
An mur cernestion
Una estrategia que resulte apropiada en un momento
determinado pudiera no ser adecuada a medida que cambian las
necesidades de la organizacin (procesos comerciales, nuevos
departamentos, cambios en el personal clave.)
Se podran desarrollar o adquirir nuevas aplicaciones/recursos.
Los cambios en la estrategia comercial pueden alterar la
significacin de las aplicaciones crticas o catalogar de crticas
las aplicaciones adicionales
Cambios en el ambiente de software o hardware podra hacer
que las provisiones actuales sean obsoletas o inapropiadas
Nuevos acontecimientos o un cambio en la probabilidad de los
mismos pueden generar trastornos
Un paso importante en el mantenimiento de un BCP consiste
en actualizarlo y probarlo cada vez que se produzcan cambios
relevantes dentro de la organizacin. Tambin sera deseable
incluir el BCP como parte del proceso del ciclo de vida de
desarrollo de sistemas (SDLC).
La responsabilidad por el mantenimiento del BCP a menudo recae
en el coordinador del BCP. El plan especfico de mantenimiento
comprende las siguientes responsabilidades:
Desarrollar un programa para la revisin y el mantenimiento
peridico del plan e informar al personal sobre sus roles y
las fechas lmite para recibir modificaciones y comentarios.
Pedir revisiones no programadas cuando se produzcan cambios
significativos.
Verificar las revisiones y los comentarios y actualizar el plan
en el transcurso de X das (por ejemplo: 30 das, dos semanas)
de la fecha de revisin.
Organizar y coordinar pruebas programadas y no programadas
del BCP a fin de evaluar su suficiencia.
Participar en las pruebas programadas del plan, las cuales
deberan realizarse al menos una vez al ao en determinadas
fechas. Para las pruebas programadas y no programadas, el
coordinador escribir las evaluaciones e integrar los cambios
a fin de resolver los resultados de pruebas fallidas en el BCP
en el transcurso de X das (por ejemplo: 30 das, dos semanas).
Desarrollar un calendario para capacitar al personal de
recuperacin en los procedimientos de emergencia y
recuperacin conforme a lo establecido en el BCP. Las fechas de
la capacitacin deberan fijarse en el transcurso de 30 das de la
revisin de cada plan y de la prueba programada para el plan.
Mantener registros de las actividades de mantenimiento del
BCP, como pruebas, capacitacin y revisiones.
Actualizar peridicamente, al menos trimestralmente (se
recomiendan lapsos ms cortos), el directorio de notificacin de
todos los cambios en el personal, incluidos nmeros de telfono,
atribuciones o rango dentro de la empresa
Una herramienta de software para administrar los planes de
continuidad y recuperacin pudiera servir para rastrear y hacerle
seguimiento a las labores de mantenimiento.
Mejores prcticas en la gestin de continuidad
dei negocio
La necesidad de repasar y mejorar de manera continua y
peridicamente el programa de continuidad del negocio es
determinante para el desarrollo de una estrategia exitosa
y contundente de recuperacin en una organizacin,
independientemente de que la organizacin se encuentre
en la etapa inicial de desarrollo de un BCP. En un esfuerzo
por mejorar las capacidades del BCM (y cumplir con las
directrices reglamentarios), algunas organizaciones han
comenzado a adoptar las mejores prcticas para entidades tanto
independientes como especficas de la industria y agencias
reglamentarias. Algunas de estas entidades o prcticas/reglamen
tos/estndares son:
Instituto de Continuidad del Negocio (BCI)Brinda las
mejores prcticas para la gestin de la continuidad del negocio
Instituto Internacional de Recuperacin en Caso de Desastre
(Disaster Recovery Institute International, DRII)Proporciona
prcticas especiales para profesionales de la continuidad del
negocio
Agencia Nacional de Estados Unidos de Proteccin contra
Incendios (NFPA)
Asociacin Federal de Estados Unidos para el Manejo de
Emergencias (FEMA) Ofrece una gua para el comercio
y la industria en el manejo de las emergencias
COBIT
US National Institute of Standards and Technology
US Federal Financial Institution Examination Council (FFIEC)
Junta de Reserva Federal de Estados Unidos (FRB)
HIPAA
US Federal Energy Regulatory Commission (FERC)
Nota: El candidato a cisa no ser evaluado sobre prcticas/
estndares especficos
2.13.11 RESUMEN DE CONTINUIDAD DEL NEGOCIO Y
RECUPERACIN EN CASO DE DESASTRE
Con miras a garantizar un servicio continuo, debera redactarse un
BCP para minimizar el impacto de los trastornos. Este plan debera
basarse en el plan TI de largo alcance y debera respaldar y alinearse
con la estrategia general de continuidad del negocio. Por lo tanto, el
proceso de desarrollar y mantener un DRP o BCP apropiado debera
consistir en:
Realizar una evaluacin de riesgosIdentificar y priorizar
los sistemas y otros recursos que se requieren para soportar
los procesos de negocio crticos en caso de que ocurra una
interrupcin. Identificar y priorizar amenazas y vulnerabilidades.
Elaborar un anlisis del impacto del negocio sobre el efecto
que tiene la prdida de procesos de negocio crticos y sus
componentes de soporte.
Elegir controles apropiados y medidas de recuperacin de
componentes de TI para soportar los procesos de negocio crticos.
Desarrollar el plan detallado para recuperar las instalaciones
IS (DRP).
Desarrollar un plan detallado para las funciones de negocio que
sean crticas para continuar operando a un nivel aceptable (plan
de continuidad del negocio, BCP).
Probar los planes.
Actualizar los planes a medida que cambia el negocio y se
desarrollan sistemas.
1SACA. Todos los derechos reservados.
Seccin Dos: Contenido Captulo 2 - Gobierno y Gestin de TI elsa eertified lntormation
M Systems Auditor
An iSACII" Cinll ltatlool
Una estrategia que resulte apropiada en un momento
determinado pudiera no ser adecuada a medida que cambian las
necesidades de la organizacin (procesos comerciales, nuevos
departamentos, cambios en el personal clave.)
Se podran desarrollar o adquirir nuevas aplicaciones/recursos.
Los cambios en la estrategia comercial pueden alterar la
significacin de las aplicaciones crticas o catalogar de crticas
las aplicaciones adicionales
Cambios en el ambiente de software o hardware podra hacer
que las provisiones actuales sean obsoletas o inapropiadas
Nuevos acontecimientos o un cambio en la probabilidad de los
mismos pueden generar trastornos
Un paso importante en el mantenimiento de un BCP consiste
en actualizarlo y probarlo cada vez que se produzcan cambios
relevantes dentro de la organizacin. Tambin sera deseable
incluir el BCP como parte del proceso del ciclo de vida de
desarrollo de sistemas (SDLC).
La responsabilidad por el mantenimiento del BCP a menudo recae
en el coordinador del BCP. El plan especfico de mantenimiento
comprende las siguientes responsabilidades:
Desarrollar un programa para la revisin y el mantenimiento
peridico del plan e informar al personal sobre sus roles y
las fechas lmite para recibir modificaciones y comentarios.
Pedir revisiones no programadas cuando se produzcan cambios
significativos.
Verificar las revisiones y los comentarios y actualizar el plan
en el transcurso de X das (por ejemplo: 30 das, dos semanas)
de la fecha de revisin.
Organizar y coordinar pruebas programadas y no programadas
del BCP a fin de evaluar su suficiencia.
Participar en las pruebas programadas del plan, las cuales
deberan realizarse al menos una vez al ao en determinadas
fechas. Para las pruebas programadas y no programadas, el
coordinador escribir las evaluaciones e integrar los cambios
a fin de resolver los resultados de pruebas fallidas en el BCP
en el transcurso de X das (por ejemplo: 30 das, dos semanas).
Desarrollar un calendario para capacitar al personal de
recuperacin en los procedimientos de emergencia y
recuperacin conforme a lo establecido en el BCP. Las fechas de
la capacitacin deberan fijarse en el transcurso de 30 das de la
revisin de cada plan y de la prueba programada para el plan.
Mantener registros de las actividades de mantenimiento del
BCP, como pruebas, capacitacin y revisiones.
Actualizar peridicamente, al menos trimestralmente (se
recomiendan lapsos ms cortos), el directorio de notificacin de
todos los cambios en el personal, incluidos nmeros de telfono,
atribuciones o rango dentro de la empresa
Una herramienta de software para administrar los planes de
continuidad y recuperacin pudiera servir para rastrear y hacerle
seguimiento a las labores de mantenimiento.
Mejores prcticas en la gestin de continuidad
del negocio
La necesidad de repasar y mejorar de manera continua y
peridicamente el programa de continuidad del negocio es
determinante para el desarrollo de una estrategia exitosa
140
y contundente de recuperacin en una organizacin,
independientemente de que la organizacin se encuentre
en la etapa inicial de desarrollo de un BCP. En un esfuerzo
por mejorar las capacidades del BCM (y cumplir con las
directrices reglamentarios), algunas organizaciones han
comenzado a adoptar las mejores prcticas para entidades tanto
independientes como especficas de la industria y agencias
reglamentarias. Algunas de estas entidades o prcticas/reglamen
tos/estndares son:
Instituto de Continuidad del Negocio (BCI)-Brinda las
mejores prcticas para la gestin de la continuidad del negocio
Instituto Internacional de Recuperacin en Caso de Desastre
(Disaster Recovery Institute International, DRII)-Proporciona
prcticas especiales para profesionales de la continuidad del
negocio
Agencia Nacional de Estados Unidos de Proteccin contra
Incendios (NFPA)
Asociacin Federal de Estados Unidos para el Manejo de
Emergencias (FEMA)-Ofrece una gua para el comercio
y la industria en el manejo de las emergencias
COBIT
US National Institute of Standards and Technology
US Federal Financia! Institution Examination Council (FFIEC)
Junta de Reserva Federal de Estados Unidos (FRB)
HIPAA
US Federal Energy Regulatory Commission (FERC)
Nota: El candidato a cisa no ser evaluado sobre prcticas/
estndares especficos
2.13.11 RESUMEN DE CONTINUIDAD DEL NEGOCIO Y
RECUPERACIN EN CASO DE DESASTRE
Con miras a garantizar un servicio continuo, deberla redactarse un
BCP para minimizar el impacto de los trastornos. Este plan deberla
basarse en el plan TI de largo alcance y deberla respaldar y alinearse
con la estrategia general de continuidad del negocio. Por lo tanto, el
proceso de desarrollar y mantener un DRP o BCP apropiado deberla
consistir en:
Realizar una evaluacin de riesgos-Identificar y priorizar
los sistemas y otros recursos que se requieren para soportar
los procesos de negocio criticas en caso de que ocurra una
interrupcin. Identificar y priorizar amenazas y vulnerabilidades.
Elaborar un anlisis del impacto del negocio sobre el efecto
que tiene la prdida de procesos de negocio criticas y sus
componentes de soporte.
Elegir controles apropiados y medidas de recuperacin de
componentes de TI para soportar los procesos de negocio criticas.
Desarrollar el plan detallado para recuperar las instalaciones
IS (DRP).
Desarrollar un plan detallado para las funciones de negocio que
sean criticas para continuar operando a un nivel aceptable (plan
de continuidad del negocio, BCP).
Probar los planes.
Actualizar los planes a medida que cambia el negocio y se
desarrollan sistemas.

Catedra 1auditoria

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Catedra 1auditoria

Încărcat de

Drepturi de autor:

Formate disponibile

TEMARIO CATEDRA I

Seccin Dos: Contenido

Seccin Dos: Contenido

S-ar putea să vă placă și