Gestion de Riesgos

I: Organización y gestión de los sistemas de información
Asociación Profesional del Cuerpo Superior
de Sistemas y Tecnologías de la Información
de la Administración del Estado
Temas Específicos para la preparación de la Oposición al Cuerpo

Superior de Sistemas y Tecnologías de la Información de la
Administración del Estado.
TEMAS ESPECÍFICOS I: Organización y gestión de los

sistemas de información
Tema 45. Seguridad de sistemas (1). Análisis y gestión de

riesgos. Herramientas
Editado por ASTIC en 2017 a partir de los temas numerados anteriormente como:
• Tema 32. La protección jurídica de los programas de ordenador

AUTOR: Eva María Ortiz Tovar y Mª Teresa Muñoz-Reja
Actualización 2013
• Tema 33. Auditoría Informática III: Desarrollo, adquisición,

implementación y mantenimiento de sistemas Evaluación de
procesos y gestión de riesgos
AUTOR: Vanessa González San Julián
Actualización 2016
045. Seguridad de sistemas (1). Análisis y gestión de riesgos. Herramientas. 1

Contenido
1 Protección de activos de información ................................................................................... 4
1.1 Introducción a la seguridad ........................................................................................... 7
1.2 Tipos de seguridad ........................................................................................................ 7
1.3 Análisis de riesgos y gestión del riesgo ......................................................................... 8
1.3.1 Análisis de Riesgos................................................................................................. 8
1.3.2 Gestión de Riesgos .............................................................................................. 11
1.4 Relación entre el ENS, MAGERIT y el análisis y gestión riesgos .................................. 12
2 Recuperación de desastres y continuidad del negocio. ...................................................... 13
2.1 Parámetros para definir la recuperación (RTO, RPO, …) ............................................. 14
2.2 Tipos de planes de continuidad de negocio ................................................................ 15
2.3 Alternativas para la Recuperación .............................................................................. 16
2.4 Planificación de la continuidad del negocio ................................................................ 18
2.4.1 Creación de la política de continuidad del negocio ............................................ 24
2.4.2 Análisis de Impacto en el Negocio (BIA) .............................................................. 24
2.4.3 Clasificación de activos, y análisis de criticidad .................................................. 24
2.4.4 Estrategia, desarrollo del Plan de continuidad ................................................... 25
2.4.5 Prueba e implementación del Plan ..................................................................... 35
2.4.6 Mantenimiento del Plan...................................................................................... 36
3. Evaluación de procesos y gestión de riesgos. ......................................................................... 37
3.1. Estrategias de gestión de riesgos. .................................................................................... 38
3.2. Establecimiento de proceso de gestión de riesgos. .................................................... 38
3.2.1 Identificación de activos...................................................................................... 38
3.2.2. Evaluación de amenazas y vulnerabilidades. ...................................................... 39
3.2.3. Evaluación del impacto. ...................................................................................... 39
3.2.4. Cálculo del riesgo. ............................................................................................... 39
3.2.5. Evaluación y respuesta al riesgo. ........................................................................ 39
3.3. Riesgo dentro del proceso de auditoría. ..................................................................... 40
3.4. Riesgos asociados con el desarrollo de software. ....................................................... 41
3.5. Marcos de referencia relacionados con análisis y gestión de riesgos. ....................... 41
3.5.1. ISO 31000. ........................................................................................................... 41
3.5.2. COSO.................................................................................................................... 44
3.5.3. Magerit. ............................................................................................................... 45
3.6. Análisis de riesgos en el ENS. ...................................................................................... 54

3.6.1. Categoría BASICA................................................................................................. 54

3.6.2 Categoría MEDIA. ................................................................................................ 55
3.6.3 Categoría ALTA. ................................................................................................... 56
4. Bibliografía .......................................................................................................................... 58

1 Protección de activos de información

Las organizaciones de todo tipo y tamaño trabajan con distintas clases de información que son
sensibles a amenazas de ataque, error, daños naturales, etc., así como a vulnerabilidades
propias de su uso. Proteger los distintos activos de información mediante sistemas de gestión
de la seguridad es esencial para que una organización pueda conseguir sus objetivos.
La gestión de la seguridad de la información pasa por la gestión del riesgo, que supone buscar
el equilibrio entre los riesgos a asumir y el coste que suponen sus medidas de control, tarea
que a menudo es harto complicada, dificultad a la que se suma el hecho de que ciertos riesgos
sean incontrolables. Es necesario, por tanto, llegar a un equilibrio entre inversión y riesgo
asumido voluntariamente ya que mitigar absolutamente todos los riesgos es inabordable,
tanto por cuestiones económicas como de índole operativa, y tampoco sería correcto asumir la
totalidad de los riesgos sin invertir en ninguna medida de control de los mismos. Aunque
existen muchas maneras de gestionar adecuadamente el riesgo, es aconsejable emplear
metodologías reconocidas, ya que estas emanan de una experiencia y un contraste que las
hace válidas a priori.
FIG. 1 PROCESO DE GESTIÓN DEL RIESGO (ISO 27005:2011)
Tras la gestión del riesgo aparecen los planes de continuidad del negocio, que podemos
definir como la capacidad estratégica y táctica, aprobada por la dirección de una organización,
para planificar la respuesta a incidentes e interrupciones del negocio con objeto de continuar
con las operaciones dentro de un nivel aceptable previamente definido.
En el ámbito informático, se entiende por incidente, cualquier evento que no es parte de la

operación normal de un servicio y el cual causa, o puede causar, una interrupción o reducción
en la calidad de éste. Algunos incidentes típicos son: servicio no disponible; corrupción de
Software; fallo hardware; detección de un virus; caída de un sistema; uso no autorizado de la

cuenta de un usuario; uso no autorizado de Privilegios de acceso al sistema; desfase de una o

más Páginas Web; ejecución de código malicioso que destruye datos. También son incidentes:
una inundación o un incendio en el CPD, la interrupción en el suministro de energía eléctrica,
un calentamiento excesivo que provoque que falle un sistema, un desastre natural. Por ello se
hace necesario gestionar estos incidentes con el objetivo de reestablecer las operaciones
normales tan rápido como sea posible con el menor impacto sobre el negocio y sobre el
usuario, de una manera eficaz en términos económicos.
Algunos incidentes se inician, con frecuencia, con un pequeño impacto, sino son gestionados
de manera apropiada pueden llegar a generar una interrupción prolongada y no tolerable del
servicio, que pueden poner en peligro la existencia de la organización.
Podemos definir desastres como las interrupciones que ocasionan que los recursos críticos de
información queden inoperantes por un periodo de tiempo. Los desastres requieren esfuerzos
de recuperación para restaurar el estado operativo, su origen puede ser:
• Desastres naturales
• Origen humano
• Indisponibilidad de servicios externos
Podemos clasificar los incidentes según la estimación de sus daños en:

• Incidente sin importancia: No causa daño perceptible o significativo (ej. caída breve
del SO, corte de energía momentáneo si existe UPS)
• Eventos menores: tienen importancia relativa, no presentan impacto material o
financiero
• Incidentes mayores: tienen impacto material negativo sobre los procesos de negocio,
afectando a otros sistemas, departamentos o clientes.
• Crisis: incidente mayor con impacto material serio sobre el funcionamiento continuo
del negocio u otros sistemas.
Entre las causas de indisponibilidad, las siguientes son las más comunes:
• Inundaciones (11 %)
• Incendios (10 %)
• Sabotajes (5 %)
• Actos Vandálicos (5 %)
• Fallos Hw / Sw (8 %)
• Cortes prolongados de suministro eléctrico (27 %)
FIG. 2 VULNERABILIDADES POR CAPAS

Las organizaciones necesitan definir planes de emergencia para evitar pérdidas de vidas
humanas, para favorecer su evacuación, basados en la valoración de los daños, estos planes
deben preparar un entorno de continuidad en condiciones precarias. Necesitan además un
plan de recuperación para conseguir la nueva puesta en marcha del negocio, hablamos para
ello de sitios fríos, templados o calientes (espejos) según veremos en apartados posteriores.
De acuerdo con la norma ISO17799 los diez dominios de control a contemplar en el Plan de
Continuidad son los siguientes:
Fig. 3 Los 10 dominios de control según ISO17799
La ISO1799 presenta además diez claves para asegurar la eficacia de los planes de continuidad:
1. Probar las copias de seguridad
2. Invertir en hardware / software de backup. Balance entre tiempo / coste.
3. Separación física de las copias periódicamente. Armarios ignífugos.
4. Aislamiento de equipos (sala de servidores). Refrigeración, armarios homologados
(rack), cableado estructurado.
5. Ubicación sala de servidores. No cañerías, no accesible con vehículos, no zona de
paso...
6. No descartar amenazas; priorizarlas por nivel de criticidad para la empresa (dirección),
por probabilidad e impacto.
7. Describir acciones para cada amenaza materializable.
8. Formación y concienciación: seminarios, circulares...
9. Ejecutar simulacros. “Tirar del cable”.
10. Escribir el protocolo (secuencia temporal) con datos concretos: nombres, teléfonos...
Es importante reseñar que Continuidad de Negocio no es lo mismo que Recuperación frente a

Desastres.
• Continuidad de Negocio son los procesos orientados a disminuir el riesgo en el
negocio evitándolos o mitigándolos; manteniendo un nivel mínimo de servicio que
soporte las funciones críticas.
• Recuperación ante desastres es la parte reactiva y es un subconjunto del BCP (Plan de
Continuidad del Negocio) constituido por los procedimientos seguidos por los
departamentos de TI (Tecnologías de Información y Telecomunicaciones) para
recuperar la capacidad de proceso.

1.1 Introducción a la seguridad

Se define como seguridad la capacidad de las redes o de los sistemas de información para
resistir, con un determinado nivel de confianza, los accidentes o acciones ilícitas o
malintencionadas que comprometan la disponibilidad, autenticidad, integridad y
confidencialidad de los datos almacenados o transmitidos y de los servicios que dichas redes y
sistemas ofrecen o hacen accesibles. El objetivo a proteger es la misión de la Organización,
teniendo en cuenta las diferentes dimensiones de la seguridad:
Disponibilidad: disposición de los servicios a ser usados cuando sea necesario. La carencia
de disponibilidad supone una interrupción del servicio. La disponibilidad afecta
directamente a la productividad de las organizaciones.
Integridad: mantenimiento de las características de completitud y corrección de los datos.
Contra la integridad, la información puede aparecer manipulada, corrupta o incompleta.
La integridad afecta directamente al correcto desempeño de las funciones de una
Organización.
Confidencialidad: que la información llegue solamente a las personas autorizadas. Contra la
confidencialidad o secreto pueden darse fugas y filtraciones de información, así como
accesos no autorizados. La confidencialidad es una propiedad de difícil recuperación,
pudiendo minar la confianza de los demás en la organización que no es diligente en el
mantenimiento del secreto, y pudiendo suponer el incumplimiento de leyes y
compromisos contractuales relativos a la custodia de los datos.
A estas dimensiones canónicas de la seguridad (identificadas por COBIT y las normas ISO
27000) se pueden añadir otras derivadas:
Autenticidad: propiedad o característica consistente en que una entidad es quien dice ser o
bien que garantiza la fuente de la que proceden los datos. Contra la autenticidad de la
información podemos tener manipulación del origen o el contenido de los datos. Contra
la autenticidad de los usuarios de los servicios de acceso, podemos tener suplantación
de identidad.
Trazabilidad: aseguramiento de que en todo momento se podrá determinar quién hizo qué
y en qué momento. La trazabilidad es esencial para analizar los incidentes, perseguir a
los atacantes y aprender de la experiencia. Se materializa en la integridad de los
registros de actividad.
1.2 Tipos de seguridad

La evolución es hacia una convergencia de Modelos; si empleamos una Visión Holística
debemos contemplar:
• Cumplimiento legal y estándares
• Políticas, normativas y procedimientos
• Red de comunicaciones
• Sistemas electrónicos de protección perimetral
• Tarjetas de identificación y acreditación
• Cerraduras y claves – jerarquización
• Control de identidad y presencia
• Logging de visitas y accesos autorizados

• Centro de control de alarmas e incidencias

• Protección y salvaguarda
Podemos realizar una clasificación de la seguridad en función de los medios empleados para su
consecución:
• Lógica. Protección de los datos en el mismo medio en el que se generan o se
transmiten, a través de claves, cifrado, firma digital, certificados digitales, sistemas de
ficheros encriptados…
• Física. Protección de los elementos tangibles:
o acceso a los equipos e instalaciones.
o catástrofes naturales (incendio, inundación, terremoto…)
o candados, tarjetas, pararrayos, detectores de humo, extintores, contenedores
de documentos a destruir, SAI, etc.
En ambos casos necesitamos normativas y políticas de seguridad en España tenemos entre
otras: LOPD (Ley 15/1999), LSSI (Ley 34/2002), Ley Firma Digital (59/2003), LAECSP (11/2007),
ENS (RD 3/2010)…
1.3 Análisis de riesgos y gestión del riesgo

La mayor dependencia de los medios informáticos, electrónicos y telemáticos de las
organizaciones supone grandes beneficios, pero también conlleva grandes riesgos que hay que
minimizar. Para ello es necesario realizar un análisis de riesgos con el objetivo de poder
gestionarlos. En este punto es importante definir qué es un riesgo y a que nos referimos con el
análisis y gestión de riesgos.
Riesgo: estimación del grado de exposición a que una amenaza se materialice sobre uno o
más activos causando daños o perjuicios a la organización.
El riesgo indica lo que le podría pasar a los activos si no se protegieran adecuadamente.
Es importante saber qué características son de interés en cada activo, así como saber en
qué medida estas características están en peligro, es decir, analizar el sistema.
Análisis de riesgos: proceso sistemático para estimar la magnitud de los riesgos a que está
expuesta una organización.
Gestión de riesgos: proceso destinado a modificar el riesgo.
Existen diversas formas de gestionar un riesgo: evitando las circunstancias que lo
provocan, reduciendo las posibilidades de que ocurra o incluso aceptando que pueda
ocurrir y previendo recursos para actuar en caso de que sea necesario.
1.3.1 Análisis de Riesgos

El análisis de riesgos permite determinar cómo es, cuánto vale y cómo de protegido se
encuentra el sistema. En coordinación con los objetivos, estrategia y política de la
organización, las actividades de tratamiento de los riesgos permiten elaborar un plan de
seguridad que, implantado y operado, satisfaga los objetivos propuestos con el nivel de riesgo
que acepta la Dirección. Al conjunto de estas actividades se le denomina Proceso de Gestión
de Riesgos.

Los sistemas de gestión de la seguridad de la información (SGSI), definidos en la norma ISO

27000, formalizan cuatro etapas cíclicas:
El análisis de riesgos es parte de las actividades de planificación, donde se toman decisiones

de tratamiento. Estas decisiones se materializan en la etapa de implantación, donde conviene
desplegar elementos que permitan la monitorización de las medidas desplegadas para poder
evaluar la efectividad de las mismas y actuar en consecuencia, dentro de un círculo de
excelencia o mejora continua.
El análisis de riesgos proporciona un modelo del sistema en términos de activos, amenazas y
salvaguardas, siguiendo un proceso sistemático:
1. determinar los activos relevantes para la Organización, su interrelación y su valor,
en el sentido de qué perjuicio (coste) supondría su degradación
2. determinar a qué amenazas están expuestos aquellos activos
3. determinar qué salvaguardas hay dispuestas y cuán eficaces son frente al riesgo
4. estimar el impacto, definido como el daño sobre el activo derivado de la
materialización de la amenaza
5. estimar el riesgo, definido como el impacto ponderado con la tasa de ocurrencia (o
expectativa de materialización) de la amenaza
F IG. 4 ELEMENTOS DEL ANÁLISIS DE RIESGOS
Siendo los elementos que deben gestionarse:

• Activos: componente o funcionalidad de un sistema de información susceptible de ser
atacado deliberada o accidentalmente con consecuencias para la organización.

Incluye: información, datos, servicios, aplicaciones, equipos, comunicaciones, recursos

administrativos, recursos físicos y recursos humanos.
• Amenazas: eventos que pueden originar un incidente produciendo daños materiales o
pérdidas inmateriales.
• Vulnerabilidades: posibilidad de ocurrencia, es decir, de materialización de una
amenaza sobre un activo.
• Salvaguardas o contramedidas: defensas desplegadas para que las amenazas no
causen tanto daño (mitigación del riesgo).
Con estos elementos se puede estimar el impacto, o lo que es lo mismo, la consecuencia de la

materialización de una amenaza sobre un activo. Además, los análisis de riesgos se enmarcan
en Planes de Contingencia, herramienta en la toma de decisiones que sirve para dar
continuidad a la actividad aprovechando la experiencia.
Los activos esenciales son la información y los servicios prestados; pero estos activos
dependen de otros como pueden ser los equipos, las comunicaciones, las instalaciones y las
frecuentemente olvidadas personas que trabajan con aquellos.
De tal forma que los activos vienen a formar árboles o grafos de dependencias donde la
seguridad de los activos que se encuentran más arriba en la estructura o ‘superiores’ depende
de los activos que se encuentran más abajo o ‘inferiores’. Estas estructuras reflejan de arriba
hacia abajo las dependencias, mientras que de abajo hacia arriba la propagación del daño caso
de materializarse las amenazas.
Del establecimiento de un buen árbol de relaciones entre activos depende en gran medida la
obtención de resultados significativos en el análisis de riesgos. Este árbol debe incluir todas las
relaciones significativas que permitan acumular el valor de los activos superiores sobre los
activos de nivel inferior a través de los cuales aquellos pueden ser atacados, pero al mismo
tiempo hay que incluir solamente aquellas relaciones que son significativas desde esta
perspectiva de acumulación de valor. De otro modo el estudio cobraría una complejidad
excesiva. Es un error común el interpretar la dependencia entre activos como una relación del
tipo “este activo depende de este otro para su funcionamiento”, aunque en algún caso ambas
interpretaciones puedan coincidir.
A la hora de hablar de riesgos es necesario hablar de costes; el objetivo, como hemos indicado,
es mantener un equilibrio entre lo que la organización está dispuesta a gastar y las pérdidas
económicas o de imagen que el daño en los activos puede ocasionar. Hay muchos factores a
considerar:
• coste de reposición: adquisición e instalación
• coste de mano de obra (especializada) invertida en recuperar (el valor) del activo
• lucro cesante: pérdida de ingresos
• capacidad de operar: confianza de los usuarios y proveedores que se traduce en una
pérdida de actividad o en peores condiciones económicas
• sanciones por incumplimiento de la ley u obligaciones contractuales
• daño a otros activos, propios o ajenos

• daño a personas
• daños medioambientales
En caso de materialización de un riesgo el Coste Total es igual a la suma del Coste de

Interrupción y el Coste de Recuperación: CT = CI + CR.
El Coste de Interrupción está relacionado con el tiempo de duración de la interrupción.

Intervienen en el mismo, factores de inactividad, lucro cesante, demora y otros factores
indirectos.
FIG. 5 EJEMPLO DE COSTE DE LA INTERRUPCIÓN DE LA ACTIVIDAD
El Coste de Recuperación es el asociado a la existencia de un plan de continuidad del negocio.

Para ello son necesarios recursos para su elaboración, implantación, realización de pruebas y
mantenimiento.
1.3.2 Gestión de Riesgos

Con objeto de Gestionar el Riesgo debemos establecer unos controles que nos faciliten esta
tarea. Los controles son objeto de diferentes clasificaciones en función de su frecuencia, de su
naturaleza, del momento en que actúan, etc.
CONTROL CARACTERÍSTICAS
Preventivos • Impedir problemas antes de que ocurran
• Visualizar entradas y operaciones
• Procurar predecir potenciales problemas antes de que ocurran
• Evitar errores, omisiones y actos maliciosos
Detectivos • Detectan cuándo se ha producido un error, una omisión o un acto
indebido e informan de ello
Correctivos • Minimizan el impacto de una amenaza
• Remedian problemas identificados mediante un control detectivo
• Identifican la causa de un problema
• Corrigen errores surgidos como consecuencia de un problema
• Modifican los sistemas de proceso para evitar futuras repeticiones
del mismo problema
FIG. 6 C LASIFICACIÓN DE LOS CONTROLES

1.4 Relación entre el ENS, MAGERIT y el análisis y gestión riesgos

Como se ha podido comprobar a lo largo del tema, el análisis y gestión de riesgos es de vital
importancia para garantizar la protección de los activos de cualquier organización. Dentro del
Esquema Nacional de Seguridad (ENS), la gestión de riesgos queda identificada como uno de
los principios básicos definidos en el artículo 4. Este principio se desarrolla en el artículo 6,
donde se detalla la gestión de la seguridad basada en el riesgo:
• “1. El análisis y gestión de riesgos será parte esencial del proceso de seguridad y
deberá mantenerse permanentemente actualizado.
• 2. La gestión de riesgos permitirá el mantenimiento de un entorno controlado,
minimizando lo riesgos hasta niveles aceptables. La reducción de estos niveles
se realizará mediante el despliegue de medidas de seguridad, que establecerá
un equilibrio entre la naturaleza de los datos y los tratamientos, los riesgos a
los que estén expuestos y las medidas de seguridad.”
La forma de acometer el análisis de riesgos, así como los aspectos a tener en cuenta varían en
función de la categorización del sistema objeto de estudio, quedando esto reflejado en el
punto 4.1.1 Análisis de riesgos dentro del Anexo II de Medidas de Seguridad.
Para los sistemas de categoría BÁSICA, bastará un análisis informal, realizado en lenguaje
natural. Es decir, una exposición textual que describa los siguientes aspectos:
a) Identifique los activos más valiosos del sistema.
b) Identifique las amenazas más probables
c) Identifique las salvaguardas que protegen de dichas amenazas
d) Identifique los principales riesgos residuales
Para los sistemas de categoría MEDIA se deberá realizar un análisis semi-formal, usando un
lenguaje específico, con un catálogo básico de amenazas y una semántica definida. Es decir,
una presentación con tablas que describa los siguientes aspectos:
a) Identifique y valore cualitativamente los activos más valiosos del sistema
b) Identifique y cuantifique las amenazas más probables
c) Identifique y valore las salvaguardas que protegen de dichas amenazas
d) Identifique y valore el riesgo residual
Para los sistemas de categoría ALTA se deberá realizar un análisis formal, usando un lenguaje
específico, con un fundamento matemático reconocido internacionalmente. El análisis deberá
cubrir los siguientes aspectos:
a) Identifique y valore cualitativamente los activos más valiosos del sistema
b) Identifique y cuantifique las amenazas posibles
c) Identifique las vulnerabilidades habilitantes de dichas amenazas
d) Identifique y valore las salvaguardas adecuadas
e) Identifique y valore el riesgo residual

Para el análisis y gestión de riesgos de conformidad con el Esquema Nacional de Seguridad se

puede emplear la metodología MAGERIT, un método formal para investigar los riesgos que
soportan los Sistemas de Información y para recomendar las medidas apropiadas que deberían
adoptarse para controlar estos riesgos. MAGERIT es, por tanto, un instrumento para facilitar la
implantación y aplicación del ENS, proporcionando los principios básicos y requisitos mínimos
para la protección adecuada de la información.
FIG. 7 ISO 31000 - MARCO DE TRABAJO PARA LA GESTIÓN DE RIESGOS
2 Recuperación de desastres y continuidad del negocio.

En sistemas de información, la estrategia más habitual de recuperación es aquella que implica
la activación de una réplica de la infraestructura en otro sitio alejado del emplazamiento
habitual, donde haya podido acontecer el desastre. Así hablamos de sitios calientes, templados,
fríos y sitios espejo calientes. Hay otra estrategia importante, que es la relativa a la pérdida del
personal, pero esa está vinculada a la gestión de recursos humanos, y no entraremos en ella.
Debemos identificar las estrategias adecuadas de recuperación y evaluarlas con criterios de

efectividad/coste. Elegiremos en función de este análisis la estrategia más adecuada
(recuperación off-line, recuperación on-line, replicación de datos, clustering, replicación
periódica…)
No todos los datos requieren el mismo tratamiento:
• 15% son datos de Misión Crítica: Datos asociados a los procesos críticos de la
organización. Deben ser retenidos por motivos legales.
• 20% son datos vitales: Son datos usados en procesos considerados normales y son de
importancia para la organización, aunque no sean requeridos de forma inmediata para
la continuidad del negocio.
• 25% Datos sensibles: Datos que son usados de forma normal, pero para los cuales
existe otra fuente alternativa y por tanto son fácilmente reconstruibles.
• 40% Datos No-Críticos: Datos que pueden ser reconstruidos fácilmente.

FIG. 8 C OSTE FRENTE A T IEMPO - E STRATEGIAS DE RECUPERACIÓN
2.1 Parámetros para definir la recuperación (RTO, RPO, …)
Repasamos a continuación los principales términos empleados para definir la recuperación:

- Tolerancia a desastre: es la brecha de tiempo en la cual el negocio puede aceptar
indisponibilidad de los servicios de Tecnologías de la Información (TI).
- Ventana de interrupción: es el tiempo que una organización puede esperar desde el punto
de fallo hasta la recuperación de los servicios críticos. Después de este tiempo, las pérdidas
progresivas causadas por la interrupción no son permisibles.
- Objetivo de entrega de servicio (Service Delivery Objective SDO): El nivel de servicios a
proveer durante el modo de proceso alterno hasta que se restaure la situación normal.
- Costes máximos tolerables: Tiempo máximo que la organización puede soportar procesar en
modo alterno. Después de este punto, pueden surgir diferentes problemas, en especial, si el
SDO alterno es inferior al SDO habitual.
- Objetivo de Punto de Recuperación (RPO- Recovery Point Objective): Se determina en base a
la pérdida aceptable de datos en caso de interrupción de las operaciones.
El RPO cuantifica la cantidad permitida de pérdida de datos en caso de interrupción. Existirán
"Catchup data" o "puesta al día de los datos" (transacciones existentes entre el RPO y la
interrupción, que deberán volver a realizarse tras la recuperación), y datos huérfanos, son
aquellos que se perderán tras recuperar las transacciones perdidas.
- Objetivo de Tiempo de Recuperación (RTO- Recovery Time Objective): Es el tiempo máximo
tolerable de interrupción. Indica el punto más próximo en el tiempo en que deben recuperarse
las operaciones tras la aparición del desastre. Cuanto más bajo sea el RTO más baja será la
tolerancia ante el desastre. A menor RTO, más bajo será el tiempo de recuperación requerido
(RTO/RPO) y más elevado será el costo de las estrategias de recuperación. Si el RPO está en
minutos, el mirroring o la duplicación de datos será la estrategia de recuperación más
aconsejable.
• Requerimientos de los procesos críticos de negocio

➢ Tiempo máximo de recuperación (RTO)
➢ Pérdida máxima de información (RPO)

FIG. 9 RTO/RPO - VERSUS TECNOLOGÍA DE RECUPERACIÓN
2.2 Tipos de planes de continuidad de negocio

Plan de Continuidad de Negocio (PCN) o Business Continuity Plan (BCP por sus siglas en inglés)
es un conjunto de directrices, criterios, normas de actuación y herramientas organizativas que,
ante la ocurrencia de una contingencia que provocase la interrupción de alguna o todas las
áreas de negocio de una organización, permiten la recuperación de la operatividad de las
mismas en el menor tiempo posible, de modo que las pérdidas ocasionadas sean mínimas. Las
características principales de un Plan de Continuidad de Negocio son las siguientes:
• Es un proceso de mejora continua de la gestión de riesgos de la organización.
• Está orientado a recuperar los procesos de negocio críticos.
• Es diseñado para integrarse con el resto de elementos de seguridad.
• Permite la automatización de tareas para evitar su planificación en momentos de
crisis.
Además del Plan de Continuidad de Negocio existen otros tipos de planes, a saber:
• Disaster Recovery Plan (DRP): Se trata de una estrategia planificada en fases cuyo
objetivo es recuperar todos los servicios relacionados con las tecnologías de la
información y las comunicaciones y los recursos que los conforman en el menor
tiempo posible, a partir de un evento que ocasiona una interrupción en su
funcionamiento.
• Bussiness Resumption Plan (BRP): Se trata de plan que organiza la reanudación de los
procesos de negocio de la organización que se hayan visto afectados por un fallo o
incidente.
• Plan de Continuidad de Operaciones (COOP): Su objetivo es conseguir la continuidad
en las funciones estratégicas de una organización desempeñadas en sus instalaciones
corporativas.
• Plan de Contingencia (CP): Su objetivo es conseguir la recuperación de los servicios y
recursos de TI después de un desastre que provoca una interrupción en su
funcionamiento.
• Plan de Respuesta de Emergencia: Salvaguarda de los empleados, el público, el medio
ambiente, así como del resto de activos de la organización ante una situación de

desastre.
2.3 Alternativas para la Recuperación

Existen diferentes alternativas de recuperación en función de los parámetros que la
Organización esté dispuesta a asumir (RTO/RPO).

TIPO CARACTERÍSTICAS
▪ Totalmente configurados
▪ Tiempo de recuperación pequeño. Listo para operar en varias horas.
▪ Equipos, red y SW deben ser compatibles con la instalación respaldada. Solo
necesitan personal, programas, archivos de datos y documentación.
▪ Costes elevados: Coste básico de suscripción, cuota mensual, cargos de prueba,
costes de activación y cargos por uso por hora o por día.
HOT SITES
▪ El contrato debe incluir: la cantidad de tiempo que se necesita, la frecuencia y el
tiempo especificado para pruebas.
▪ Destinado para: operaciones de emergencia durante un periodo limitado de tiempo
y no para uso prolongado (es un medio de lograr la continuidad de las operaciones
esenciales durante varias semanas después del desastre o emergencia). RTO aprox.
de minutos.
▪ Parcialmente configurados
▪ Instalación con cableado, electrónica de red, equipos básicos. Falta HW principal o
de menor capacidad. RTO de 2- 7 días.
WARM SITES
▪ La ubicación e instalación de la CPU y otras unidades no disponibles llevará varios
días o semanas.
▪ Menos costoso que un Hot Site.
▪ Instalación alternativa con cableado, falsos suelos, acondicionado y potencia
eléctrica. RTO + de 1 semana.
COLD SITES
▪ Listo para recibir los equipos, pero no ofrece ningún componente en el lugar antes
de necesitarse su uso. Su activación llevará varias semanas.
▪ Lugares de recuperación dedicados preparados para la interrupción, respalda las
aplicaciones críticas. La instalación es completa con replicación de datos y/o
balanceo de carga. El RTO es inmediato.
▪ Puede adoptar varios formatos: desde “Hot site” listo y en espera, hasta contrato
recíproco para uso de la instalación de otra empresa.
INSTALACIONES ▪ Principios de viabilidad:
REDUNDANTES o No sujeto a los mismos desastres naturales que el sitio principal.
o Compatibilidad de HW/SW entre Principal y Respaldo.
▪ Disponibilidad de recursos: Monitorización de las cargas de trabajo.
▪ Necesidad de acuerdos respecto a la prioridad de agregar aplicaciones hasta que se
hayan utilizado plenamente todos los recursos de recuperación
▪ Necesidad de pruebas periódicas.
▪ Remolque diseñado que puede ser transportado rápidamente a un lugar de
negocio.
SITIOS MÓVILES ▪ Alternativa útil en el caso de un desastre expandido.
▪ Alternativa eficiente en costes para duplicar las instalaciones de procesamiento de
información de una organización con múltiples oficinas.
▪ Mirrored: Centro duplicado del entorno primario tanto en lo referente al software
como a los datos.
ATENDIENDO A SU ▪ Standby: Centro en el cual existe total o parcialmente el software y la actualización
DISPONIBILIDAD de los datos se realiza cada cierto periodo de tiempo.
▪ Split Workload: La carga se reparte entre dos centros, aunque todo el entorno se
puede respaldar en uno.
▪ Los participantes acuerdan mutua provisión de tiempo de cómputo en caso de
ACUERDOS
emergencia.
RECÍPROCOS CON
▪ Ventajas: Bajo coste.
OTRAS
▪ Desventajas: Ausencia de obligatoriedad. Diferentes configuraciones. Cambios no
ORGANIZACIONES
notificados en configuraciones o cargas de trabajo.
FIG. 10 ALTERNATIVAS DE RECUPERACIÓN Y SUS CARACTERÍSTICAS

Estrategia Capacidad de Costes anuales Costes durante un

minimizar el tiempo de contingencia
interrupción
HOT SITE ALTO MEDIO BAJO
WARM SITE MEDIO MEDIO MUY ALTO
COLD SITE BAJO BAJO MUY ALTO
CENTRO IMAGEN MUY ALTO MUY ALTO BAJO
ACUERDO RECÍPROCO MEDIO BAJO ALTO
CONTRATO CON BAJO BAJO MUY ALTO
EMPRESA
ESPECIALIZADA
INSTALACIÓN MÓVIL MEDIO MEDIO MUY ALTO
FIG. 11 E STRATEGIAS DE RECUPERACIÓN
FIG. 12 DEFINICIÓN Y OBJETIVOS DE RECUPERACIÓN
2.4 Planificación de la continuidad del negocio

La gestión de la continuidad de negocio lleva implícita la realización de una serie de
actuaciones:
• Creación de una Política de Continuidad del Negocio.
• Análisis de Impacto sobre el Negocio.
• Clasificación de las operaciones y análisis de criticidad.
• Desarrollo del Plan de Continuidad del Negocio.
• Prueba e implementación del Plan.
• Mantenimiento.

FIG. 13 MODELO CÍCLICO DE LA G ESTIÓN DE LA CONTINUIDAD DEL N EGOCIO
FIG. 14 F ASES DE LA G ESTIÓN DE CONTINUIDAD DEL NEGOCIO
Instalación y configuración de infraestructura de contingencia: hardware, software y

comunicaciones.
• Evaluación Incidentes Desastre: Identificación de las causas y alcance de los daños
(Parcial/Total)
• Comité de Emergencia: Responsables de la activación del plan y de la toma de
decisiones
• Staff de emergencia: Personal involucrado en la recuperación (sistemas,
comunicaciones, etc.)
• Recursos necesarios: Localización HW, SW, dispositivos de comunicaciones, etc.
Contactos con soporte, proveedores, etc.

• Procedimientos de Recuperación de Sistemas/Servicios: Procedimientos específicos

de recuperación ante desastres y adicionales a la operación diaria
• Procedimientos de Recuperación de Comunicaciones: Procedimientos de
recuperación ante desastres
• Procedimientos de Recuperación de Áreas de Usuarios
• Pruebas y simulacros
• Validación del entorno de contingencia: validación de la infraestructura de
contingencia y de los procedimientos de recuperación (efectividad), así como el
aseguramiento del cumplimiento de los requerimientos recogidos en el BIA (procesos,
tiempo y datos).
• Metodología de mantenimiento del Plan
• Gestión On-site: sistemas, aplicaciones y comunicaciones.
• Gestión Remota: Accesos al entorno de contingencia y sistemas de gestión
Algunas soluciones tecnológicas:



Como vemos, el concepto de failover extendido a varias localizaciones se convierte en una

solución de recuperación automática ante desastres. Las mismas tareas realizadas en el CPD A

pueden ser realizadas en el CPD B de forma automatizada y viceversa. Algunas de las opciones
que nos proporciona la tecnología en su estado actual para llegar a este objetivo son las
siguientes (consultar bloque IV para profundizar en este tema):
• GSLB (Global Server Load Balancing): basados en DNS y también en BGP
• Routing dinámico
• Entradas DNS Múltiples
• Extensión de VLANs
2.4.1 Creación de la política de continuidad del negocio

Con la creación de una política de continuidad de negocio se busca asegurar que todas las
actividades de gestión de la continuidad del negocio se implementen de manera controlada y
consensuada, que estas actividades se adaptan a las características de la organización y
establecer un marco de trabajo sobre el que se asiente la gestión de la continuidad del
negocio. Para ello se indispensable contar con los siguientes elementos:
• Compromiso y apoyo de la dirección.
• Elaborar un caso de negocio para buscar apoyo.
• Vender la necesidad de un PCN.
• Generar concienciación.
• Aproximación Top-Down.
• Es necesario un amplio conocimiento del Negocio, se suelen emplear las siguientes
técnicas para obtenerlo:
– Cuestionarios
– Entrevistas
2.4.2 Análisis de Impacto en el Negocio (BIA)

El propósito fundamental del Análisis de Impacto sobre el negocio, conocido más comúnmente
como BIA, (Business Impact Análisis) es determinar y entender qué procesos son esenciales
para la continuidad de las operaciones y calcular su posible impacto. Este proceso es parte
fundamental dentro de la elaboración de un Plan de Continuidad del Negocio.
Los objetivos principales del BIA son:

• Entender los procesos críticos que soportan el servicio, la prioridad de cada uno de
estos servicios y los tiempos estimados de recuperación (RTO).
• Determinar los tiempos máximos tolerables de interrupción (MTD).
• Apoyar el proceso de determinar las estrategias adecuadas de recuperación.
Para ello se deben realizar las siguientes actuaciones:

• Identificar los activos críticos
• Identificar los eventos
• Identificar los tiempos críticos de recuperación
• Determinar los costes de recuperación
• Asignar prioridades a los sistemas
2.4.3 Clasificación de activos, y análisis de criticidad

Ya se ha comentado que lo activos son los recursos del sistema, o relacionados con éste,
necesarios para que la Organización funcione correctamente según los objetivos marcados por
la Dirección. Por su criticidad se pueden clasificar como:
• Crítico: No pueden ser reemplazados por métodos manuales. La tolerancia a la
interrupción es muy baja. El coste de la interrupción es muy alto.
• Vital: Pueden realizarse manualmente por un breve periodo de tiempo (5 días o
menos). Mayor tolerancia a la interrupción. Costes de la interrupción más bajos.
• Sensible: Se pueden realizar manualmente, a un coste tolerable y por un periodo
prolongado de tiempo; pero es un proceso difícil que requiere de personal adicional.
• No crítico: Pueden ser interrumpidas por un periodo prolongado de tiempo, a un coste
pequeño o nulo para la compañía.
FIG. 15 C LASIFICACIÓN DE ACTIVOS Y CRITICIDAD
2.4.4 Estrategia, desarrollo del Plan de continuidad

En la elaboración del Plan de Continuidad de Negocio es necesario determinar cuáles serán las
estrategias de recuperación que consisten en la combinación de medidas preventivas,
detectivas y correctivas. Que tratan de:
• Cuando sea posible, eliminar la amenaza completamente.
• Minimizar la probabilidad de ocurrencia.
• Minimizar el efecto (impacto).
Además:
• Identifican la mejor forma de recuperar un sistema en caso de interrupción.
• Proveen una orientación basada en qué procedimientos detallados de recuperación se
pueden desarrollar.
• Se desarrollan diferentes estrategias y se presentan a la dirección.
• La alta dirección selecciona la estrategia más apropiada y acepta el riesgo residual
inherente.

FIG. 16 E STRATEGIAS BC/DR
ESTRUCTURA Y DESARROLLO DEL PLAN
El Plan de Contingencia hay que considerarlo como un proceso evolutivo. Debe ser actualizado
en función de las necesidades que aparezcan como consecuencia de cambios en las
instalaciones, nuevas funcionalidades soportadas, etc. El Plan de Continuidad de Negocio
(PCN) contempla acciones precisas que van orientadas a recuperar las funciones críticas del
negocio. En este punto es necesario distinguir entre un plan de contingencias y un plan de
continuidad de negocio.
En un Plan de Contingencias se presume que hay una interrupción de los servicios durante un
tiempo, sobre el cual se declara la emergencia, y entran a operar una serie de procedimientos
que permiten que el servicio se restablezca en el menor tiempo posible. El enfoque del plan de
contingencia se basa en la minimización del impacto y del tiempo de parada y se concentra en
la recuperación de los sistemas causantes de la interrupción del servicio.
El Plan de Continuidad está orientado, como su nombre indica, a asegurar la continuidad de

los servicios ofrecidos a pesar de una catástrofe, como puede ser un terremoto, un incendio,
una inundación,... Un plan de continuidad tiene como objetivo tratar de alcanzar una
disponibilidad total para la infraestructura crítica, lo que implica que el sistema siempre estará
disponible.
Para ello, habrá una serie de medidas preventivas aplicadas como resultado de la Política de
Seguridad implantada, como pueden ser sistemas de alta disponibilidad, sistemas de detección
y reparación antivirus, sistemas automáticos de realización de copias de respaldo,... En caso de

sucesos en los que las medidas preventivas no son suficientes, se pone en marcha el Plan de
Continuidad.
Por PCN se entienden las acciones de alto nivel emprendidas con la aparición de un evento de
tipo catastrófico, y conducentes a preparar los medios humanos y técnicos con el fin de
recuperar las operaciones de la organización con el nivel de servicio acordado.
A modo de ejemplo, un PCN incluye el procedimiento de activación del equipo de dirección de

la recuperación y su colaboración con otras unidades de negocio involucradas. El equipo de
dirección con el apoyo técnico necesario dispondrá de un procedimiento que le sirva de ayuda
para tomar la decisión de si activa o no el PCN según el evento que se haya producido y
dependiendo de si se encuentra entre alguno de los escenarios contemplados en el Plan. En el
momento que se decida la activación del Plan se pondrán en marcha los procedimientos de
alto nivel que asignarán las tareas de recuperación de las infraestructuras necesarias en
respaldo a cada equipo de recuperación, ya sean tareas de tipo logístico o de tipo técnico de
infraestructuras.
Estos procedimientos organizativos de alto nivel invocarán finalmente a los esquemas de

restauración de los Servicios y a los procedimientos alternativos de procesado para aquéllos
que lo requieran.
Planes de Contingencia Operativa

Los PCOs tienen que ver con la recuperación tecnológica de los Servicios proporcionados por
Sistemas de Información y Redes de Comunicaciones.
Los procedimientos técnicos estarán ligados a las soluciones de respaldo definidas

anteriormente y contemplarán esquemáticamente los pasos necesarios para activar la
infraestructura tecnológica de respaldo. Estos esquemas invocarán finalmente a los manuales
técnicos de detalle con los pasos concretos para activar tecnológicamente el Servicio.
El Plan de Continuidad de Negocio es una función de toda la Organización. En el caso de un

desastre importante que impida que los servicios se sigan proporcionando desde el
emplazamiento habitual, la aplicación del plan debe permitir situar los sistemas en un
emplazamiento alternativo. De esta forma, cuando se pueda restablecer la actividad
informática, la actividad del negocio se podrá reanudar.
No obstante, es necesario asumir que, en caso de un desastre, puede que no sea posible
reanudar la actividad en las condiciones habituales de operación y deba pasarse por un
periodo de ‘operación-degradada’, antes de volver a la normalidad.
Como en el Plan de Contingencia, es fundamental la revisión periódica del Plan de Continuidad

de Negocio para mantener su operatividad y vigencia. Es por ello por lo que se requiere la
realización de pruebas periódicas para adecuarlo a las necesidades que aparezcan como
consecuencia de cambios en las instalaciones, nuevas funcionalidades soportadas, cambios en
la organización que lo pudieran afectar, etc.

La metodología seguida en la definición del Plan de Continuidad se ajusta a lo establecido en el

estándar ISO/IEC 27002 (anteriormente denominada ISO 17799) y consta de las siguientes
tareas:
• Inicio y gestión del proyecto: Debe determinar la necesidad del Plan de Continuidad
de Negocio (BCM) y su política, incluyendo el apoyo de la organización. Ha de
especificarse el alcance, el ámbito y condiciones. La asignación de recursos y la
organización del proyecto.
• Análisis de Impacto (BIA): Debe de identificar los impactos que generan las
interrupciones y los desastres que pueden afectar a la organización, así como las
técnicas que se pueden emplear para cuantificar y calificar dichos impactos. Determina
las funciones críticas, sus prioridades de recuperación e interdependencias de forma
que se pueda establecer el objetivo de tiempo de recuperación. Han de definirse para
cada servicio los parámetros de:
o RTO: Recovery Time Objective, o tiempo que se precisa un nivel mínimo de
servicio.
o RPO: Recovery Point Objective, o máxima cantidad de datos que se pueden
perder en caso de desastre.
• Análisis de Riesgos: Determina los eventos y las circunstancias externas que pueden
afectar negativamente a la organización y sus instalaciones. Esto se realiza en términos
de interrupción y de desastre, el daño que dichos eventos pueden causar, y los
controles necesarios para evitar o minimizar los efectos de las pérdidas potenciales. Se
puede realizar un análisis de coste-beneficio para justificar las inversiones en
controles que mitiguen el riesgo.
• Estrategia de continuidad de negocio: Selecciona las estrategias alternativas para la
recuperación de las tecnologías de la información dentro del objetivo de tiempo de
recuperación. Consiste en identificar y evaluar opciones de recuperación. De forma
paralela, su objetivo recae también en identificar y evaluar las opciones de reducción
de riesgos.
• Implantación: Desarrollo e implantación del Plan que proporcione la recuperación en
un umbral de tiempo marcado como objetivo. Podemos dividirlo en las siguientes
tareas:
o Identificar los componentes del proceso de planificación (metodología de
planificación, organización del Plan, necesidades de personal, etc).
o Controlar el proceso de planificación y producir el Plan.
o Implementar el Plan
• Gestión Operativa: Comprende las actividades recurrentes de mantenimiento,
formación y pruebas.

FIG. 17 FASES IMPLEMENTACIÓN BCM
Centro de Respaldo
Un centro de respaldo por sí sólo no basta para hacer frente a una contingencia grave. Es
necesario disponer de un Plan de Contingencias corporativo. Este plan contiene tres subplanes
que indican las medidas técnicas, humanas y organizativas necesarias en tres momentos clave:
• El plan de respaldo. Contempla las actuaciones necesarias antes de que se produzca
un incidente. Esencialmente, mantenimiento y prueba de las medidas preventivas.
• El plan de emergencia. Contempla las actuaciones necesarias durante un incidente.
• El plan de recuperación. Contempla las actuaciones necesarias después de un
incidente. Básicamente, indica cómo volver a la operación normal.
Diseño de un centro de respaldo

Un centro de respaldo se diseña bajo los mismos principios que cualquier CPD, pero bajo
algunas consideraciones más. En primer lugar, debe elegirse una localización totalmente
distinta a la del CPD principal con el objeto de que no se vean ambos afectados
simultáneamente por la misma contingencia. Es habitual situarlos entre 10 y 20 kilómetros del
CPD principal. La distancia está limitada por las necesidades de telecomunicaciones entre
ambos centros.

En segundo lugar, el equipamiento electrónico e informático del centro de respaldo debe ser
absolutamente compatible con el existente en el CPD principal. Esto no implica que el
equipamiento deba ser exactamente igual. Normalmente, no todos los procesos del CPD
principal son críticos. Por este motivo no es necesario duplicar todo el equipamiento. Por otra
parte, tampoco se requiere el mismo nivel de servicio en caso de emergencia. En
consecuencia, es posible utilizar hardware menos potente. La Sala técnica de un centro de
respaldo recibe estas denominaciones en función de su equipamiento:
• Sala blanca cuando el equipamiento es exactamente igual al existente en el CPD
principal.
• Sala de back-up cuando el equipamiento es similar pero no exactamente igual.
En tercer lugar, el equipamiento software debe ser idéntico al existente en el CPD principal.
Esto implica exactamente las mismas versiones y parches del software de base y de las
aplicaciones corporativas que estén en explotación en el CPD principal. De otra manera, no se
podría garantizar totalmente la continuidad de operación.
Por último, pero no menos importante, es necesario contar con una réplica de los mismos
datos con los que se trabaja en el CPD original. Este es el problema principal de los centros de
respaldo, que se detalla a continuación.
Sincronismo de datos
Existen dos políticas o aproximaciones a este problema:
• La copia síncrona de datos. Se asegura que todo dato escrito en el CPD principal
también se escribe en el centro de respaldo antes de continuar con cualquier otra
operación.
• La copia asíncrona de datos. No se asegura que todos los datos escritos en el CPD
principal se escriban inmediatamente en el centro de respaldo, por lo que puede
existir un desfase temporal entre unos y otros.
La copia asíncrona puede tener lugar off-line o fuera de línea. En este caso, el centro de
respaldo utiliza la última copia de seguridad existente del CPD principal. Esto lleva a la perdida
de los datos de operaciones de varias horas (como mínimo) hasta días (lo habitual). Esta
opción es viable para negocios no demasiado críticos, donde es más importante la continuidad
del negocio que la perdida de datos. Por ejemplo, en cadenas de supermercados o pequeños
negocios. No obstante, es inviable en negocios como la banca, donde es impensable la pérdida
de una sola transacción económica.
En los demás casos, la política de copia suele descansar sobre la infraestructura de

almacenamiento corporativo. Generalmente, se trata de redes SAN y cabinas de discos con
suficiente inteligencia como para implementar dichas políticas.
Tanto para la copia síncrona como asíncrona, es necesaria una extensión de la red de
almacenamiento entre ambos centros. Es decir, un enlace de telecomunicaciones entre el CPD
y el centro de respaldo. En caso de copia síncrona es imprescindible que dicho enlace goce de
baja latencia. Motivo por el que se suele emplear un enlace de fibra óptica, que limita la

distancia máxima a decenas de kilómetros. Existen dos tecnologías factibles para la copia de
datos en centros de respaldo: iSCSI y Fiber Channel
La copia síncrona es esencial en negocios como la banca, donde no es posible la pérdida de

ninguna transacción. La copia asíncrona es viable en la mayoría de los casos, ya que el desfase
temporal de la copia se limita a unos pocos minutos.
Resumimos los factores a considerar en el desarrollo del Plan:

• Estar preparado antes del desastre, cubriendo la gestión de respuestas a cualquier tipo
de incidentes.
• Procedimientos de evacuación.
• Procedimientos para declaración del desastre.
• Circunstancias bajo las cuales se debe declarar el desastre (no todas las interrupciones
son desastres).
• Identificación de responsables y responsabilidades en el Plan.
• Identificación de información de los contratos.
• Identificación de los procesos a recuperar.
• Identificación de los diversos recursos requeridos para la recuperación.
• Aplicación paso por paso de la etapa de recuperación.
Componentes de un BCN:
• Plan de Recuperación del Negocio (BRP)
• Plan de Continuidad de Operaciones (COOP)
• Plan de Soporte de la Continuidad / Plan de Contingencia de TI
• Plan de Comunicaciones de crisis
• Plan de Respuesta a incidentes
• Plan de Recuperación ante desastre (DRP)
• Plan de Emergencia de Ocupantes (OEP)
En la Introducción del Plan debemos reflejar:

• Objetivos
• Requerimientos previos
• Hipótesis (mapa de negocio, mapa de servicios, time frame, …)
• Instrucciones de uso
• Lista de ejemplares distribuidos
Organización de los equipos de emergencia

• Inventario de equipos
• Descripción de personal
• Directorio de contacto por equipos
• Localización de emergencia (CPD primario o de respaldo)
Plan de Acciones
• Estrategia global
• Estrategia por equipos de emergencia

Comunicaciones (CPD principal y respaldo)

• Inventario de líneas
• Mapas de la red
• Equipos de comunicaciones
• Software de comunicaciones
Anexos
• Anexo I : Directorio de Suministradores
• Anexo II : Directorio de Usuarios
Otros Documentos
• Estrategia por entorno de negocio
• Estrategia por equipo de emergencia
• Estrategia de vuelta a la normalidad
Organización de Responsabilidades (se puede utilizar la matriz RASCI):

• Equipo de acción ante emergencia: Es el primer equipo de respuesta. Responsable de
la evacuación ordenada del personal y de garantizar vidas humanas
• Equipo de evaluación de daños: Evalúa el grado de los daños una vez ocurrido el
desastre. Además, sus miembros deben tener capacidad de estimar el tiempo
requerido para las operaciones de recuperación en el lugar afectado.
• Equipo de administración de la emergencia: Responsable de coordinar las actividades
de los demás equipos y de la toma de decisiones clave. Determina la activación del
BCP.
• Equipo de almacenamiento en sede alternativa (offline): Responsable de obtener y
enviar los medios y los registros a las instalaciones de recuperación.
• Equipo de software: Responsable de restaurar el SW del sistema y sus actualizaciones.
• Equipo de software de aplicaciones: Se desplaza al lugar de recuperación del sistema
y restaura los paquetes y programas de aplicación de usuario.
• Equipo de seguridad: Monitoriza el sistema de seguridad y los enlaces de
comunicación, resolviendo cualquier conflicto.
• Equipo de operaciones de emergencia: Operadores de turno que administrarán las
operaciones del sistema durante todo el desastre y los proyectos de recuperación
• Equipo de recuperación de red: Responsable del redireccionamiento del tráfico de
datos y voz de la WAN. Restablece acceso al lugar de recuperación del sistema.
• Equipo de comunicaciones: Establece una red LAN en el lugar de recuperación.
• Equipo de transportes: Responsable de coordinar el transporte de los empleados de la
compañía al sitio de recuperación.
• Equipo de preparación de datos y registros: Actualiza la base de datos de aplicaciones
desde los terminales instalados en el sitio de recuperación.
• Equipo de soporte administrativo.
• Equipo de suministros: Apoya al equipo de HW, contactando con vendedores y
coordinando los suministros TI y de oficina.
• Equipo de reubicación: Coordina el traslado al sitio alternativo, o bien, a la ubicación

original restaurada.
• Equipo de coordinación: Coordina los esfuerzos de recuperación en caso de diversas
oficinas distribuidas geográficamente.
• Equipo de asuntos legales.
• Equipo de prueba de recuperación.
Según la norma BS25999-1 “Code of practice for business continuity management”, todos los
documentos deberían incluir los siguientes apartados comunes:
• Propósito y alcance
• Funciones y responsabilidades del personal
• Procedimiento o normas de activación
• Propietario y responsable del mantenimiento del plan
• Para los Planes de Gestión de Crisis en particular, la norma BS25999-1 establece que,
además de lo anterior, se debe incluir lo siguiente:
• Acciones o tareas
• Contacto con las personas
• Contacto con los medios
• Contacto con los principales implicados (gobiernos, accionistas, etc.)
• Centro de gestión de crisis
• Anexos (planos, listas de contactos internos y externos, etc.)
En cuanto a los Planes de Continuidad de Negocio, (PCNs) la norma BS25999-1 establece que,
además de los apartados comunes mencionados anteriormente, se debe incluir lo siguiente:
• Lista de tareas
• Requerimientos de recursos
• Información vital
• Personas responsables
• Formularios y Anexos
El último componente de una estrategia de BCM efectiva es un personal formado, entrenado y

concienciado. Pueden emplearse variedad de métodos para conseguirlo, como aplicaciones
Intranet, simulacros y sesiones de formación.
En Plan debe contener un directorio del personal clave que necesario para iniciar y llevar a
cabo los esfuerzos de recuperación.
– Jefes de equipo
– Proveedores Hardware/Software
– Suministradores
– Instalaciones alternativas
– Almacenamiento en el centro alternativo
– Compañías de seguros
– Empresas contratadas
– Agencias legales y gubernamentales.

FIG. 18 DESARROLLO DEL PLAN
Fases del Plan de Continuidad de Negocio

• Acciones en situación de emergencia
• Notificación
• Declaración de emergencia
• Recuperación de sistemas
• Recuperación de la red
• Recuperación de operaciones
• Operaciones de salvamento
• Procedimientos de reubicación
FIG. 19 PROCEDIMIENTO DE NOTIFICACIÓN DEL DESASTRE

FIG. 20 PROCEDIMIENTO DE ACTIVACIÓN DEL PCN
2.4.5 Prueba e implementación del Plan
Las fases que hay que llevar para probar correctamente:
Programación de la prueba: Durante un periodo que minimice las interrupciones a las

operaciones normales.
Personal: Es importante que los miembros clave del equipo de recuperación participen en el
proceso de prueba y se les conceda tiempo para tal actividad.
Objetivos de la prueba del Plan de Continuidad de Negocio

• Verificar que la documentación es completa y exacta
• Evaluar el rendimiento del personal involucrado en el ejercicio
• Evaluar la coordinación entre el equipo de contingencia y los proveedores
• Medir la capacidad de recuperación
• Evaluar el estado y cantidad de consumibles reubicados en la sede alternativa
• Medir el rendimiento general de las actividades para mantener la capacidad del
negocio
• Tipos
o En papel
o Preparación
o Operativa
• Fases de la prueba
o Preparación
o Prueba
o Análisis de resultados

• Métrica de resultados
o Tiempo
o Cantidad
o Calidad
o Exactitud
EQUIPO DE PRUEBAS:
• Director del Plan de Contingencias
• Coordinador del Plan de Contingencias
• Al menos el Responsable y un componente de los siguientes equipos o grupos:
o Operaciones
o Soporte Técnico
o Bases de Datos
o Logística
o Control de la Producción
o Sistemas
o Comunicaciones
o Aplicaciones (un componente por aplicación)
FIG. 21 TIPOS DE PRUEBAS
2.4.6 Mantenimiento del Plan

Es necesario mantener el Plan de Continuidad de Negocio debido a:
• Estrategias emergentes
• Nuevas aplicaciones
• Modificaciones en Estrategia de negocio
• Cambios de la infraestructura
Debe existir un Coordinador que realice las siguientes funciones:

• Elaboración de los procedimientos de mantenimiento
• Planificación anual del mantenimiento

• Elaboración de presupuestos para mantenimiento

• Elaboración periódica de versiones actualizadas del documento de Plan de
Contingencias
• Planificación de las pruebas a realizar
• Dirección de las pruebas del plan
• Confección y distribución (controlada con una lista cerrada de destinatarios) de
informes sobre pruebas (tiempos, cobertura, adecuación de procedimientos, …)
F IG. 22 H ERRAMIENTAS DE SOPORTE AL PCN
Herramientas de Soporte
• Son herramientas que facilitan la formalización, el mantenimiento y la gestión del Plan
de Contingencias.
• Carecen de aplicación en las fases iniciales del Plan (no cubren el trabajo de campo).
• Su utilización como herramientas de apoyo a la toma de decisiones no excluye la
necesidad de contar con Comités de decisión al más alto nivel durante la realización
del Plan.
• Actividades de mantenimiento
o Programa de revisiones periódicas
o Revisiones no programadas
o Actualización en 30 días
o Análisis de adecuación del plan
o Adiestramiento del personal
o Registro de actividades de mantenimiento
o Actualización cambios del personal
3. Evaluación de procesos y gestión de riesgos.

Se denomina Gestión de Riesgos al proceso que permite identificar las vulnerabilidades de

los activos empleados por una organización y las amenazas a las que se encuentran
expuestos, con el fin de establecer las protecciones oportunas para reducir el riesgo a un
nivel aceptable (riesgo residual).
3.1. Estrategias de gestión de riesgos.

De forma genérica, la estrategia que puede adoptar una organización cuando gestiona los
riesgos se clasifica en:
• Evitar: eliminando la causa se elimina el riesgo.
• Mitigar: reducir la probabilidad o impacto de riesgo estableciendo los controles

oportunos.
• Compartir/transferir: se comparte o transfiere el riesgo a través de la cobertura de

un seguro, acuerdo contractual u otros métodos.
• Aceptar: reconocimiento formal de la existencia del riesgo y de las posibles

consecuencias.
Sea cual sea la estrategia adoptada, es importante recordar que los costes de las
contramedidas que se establezcan no pueden nunca superar los asociados a la ejecución
efectiva de las posibles amenazas.
3.2. Establecimiento de proceso de gestión de riesgos.

En primer lugar hay que determinar el propósito que se persigue con el establecimiento de
este proceso, que puede ser desde reducir el coste de los seguros hasta hacer descender
el número de incidentes relacionados.
A continuación es necesario que se asignen responsabilidades dentro del plan de gestión

de riesgos al personal del departamento u organización.
Los pasos para establecer un programa de gestión de riesgos incluyen:
• Identificación de activos.
• Evaluación de amenazas y vulnerabilidades a los activos.
• Evaluación del impacto.
• Cálculo del riesgo.
• Evaluación y respuesta al riesgo.
3.2.1 Identificación de activos.

En este paso se identifican los recursos o activos de información que requieren protección
porque son vulnerables a amenazas. Dichos activos se pueden clasificar diferentes
categorías como:
• Información y datos.
• Hardware.
• Software.
• Documentos.

• Personal.
• No tangibles: imagen / reputación.
3.2.2. Evaluación de amenazas y vulnerabilidades.

El siguiente paso es evaluar las vulnerabilidades de un activo, así como las probabilidades
de que se materialice una amenaza asociada al mismo.
Algunos ejemplos de vulnerabilidades son:
• Falta de conocimiento o concienciación en los usuarios.
• Configuración de seguridad no adecuada.
Entre las posibles amenazas se encontrarían:
• Errores humanos o en la tecnología.
• Ataques intencionados.
3.2.3. Evaluación del impacto.

Se denomina impacto al resultado de la materialización de una amenaza que hace que
explote una vulnerabilidad. Se pueden ocasionar diferentes tipos de pérdidas:
• Financieras: en estos casos se producen únicamente pérdidas de dinero. Un

ejemplo sería el rescate que pagaría una empresa para evitar que un ransomware
provocara daños mayores en un servidor crítico de su organización.
• Materiales: los daños se producen sobre activos tangibles de la organización,

provocando un perjuicio mayor que si fuera únicamente un daño financiero. Un
ejemplo sería el daño provocado en un servidor crítico si no se pagara el rescate
solicitado ante un ransomware.
• No materiales o intangible: los daños ocasionados por este tipo de pérdidas son
difícilmente evaluables ya que afectan a la imagen o prestigio de una organización.
Siguiendo con el ejemplo de los dos apartados anteriores, imaginemos que el
servidor crítico contiene información personal sobre componentes de las fuerzas
de seguridad del estado. El daño ocasionado si esta información se viera publicada
en redes sociales por ejemplo tendría un coste incalculable.
3.2.4. Cálculo del riesgo.

A continuación se calcula el riesgo total para cada amenaza. Se puede aplicar la siguiente
fórmula para cada amenaza:
Probabilidad de ocurrencia * Magnitud de impacto.
3.2.5. Evaluación y respuesta al riesgo.

Una vez conocido evaluadas las amenazas y las vulnerabilidades y estimado el posible
nivel de riesgo, es necesario establecer controles (también denominados contramedidas o
salvaguardas) que permitan reducirlo a un nivel aceptable para la organización.
Se denomina riesgo residual al nivel remanente de riesgo una vez han sido aplicados los
controles seleccionados por la organización.
Existen diferentes clasificaciones para las salvaguardas:

• Preventivos / Detectivos / Correctivos.
Los controles preventivos se establecen para reducir el riesgo. Los detectivos para
identificar una amenaza en caso de que se materialice. Los correctivos tratan de eliminar o
al menos reducir los daños ocasionados por una amenaza una vez se ha materializado.
• Manuales /Automatizados.
En los controles manuales es necesaria la intervención humana para su puesta en marcha,

mientras que en los automatizado no.
• Formales / Ad hoc
Los controles formales se encuentran documentados en manuales de procedimientos y se

mantienen pruebas de su operación, mientras que los controles ad hoc son controles
aplicados de forma particular en una situación específica.
La gestión de riesgos dentro de las TI necesita operar en diferentes niveles:
• Operativo: en este caso la gestión de riesgos se centra en los sistemas TI e

infraestructura que los soporta.
• Proyecto: dentro de este nivel, la gestión de riesgos se concentra en uno o varios

proyectos en particular.
• Estratégico: en este caso, la gestión de riesgos está enfocada en la propia

estrategia del negocio.
Aunque la gestión de riesgos TI es responsabilidad de diferentes grupos y personas dentro

de una organización, es necesario que se produzca una acción conjunta y coordinada de
todos ellos puesto que una acción independiente por parte de una de las personas o
grupos podría perjudicar al conjunto de ellos.
También es necesario recordar que dentro del proceso de gestión de riesgos es necesario
tener en cuenta, como ya se ha comentado anteriormente, que el coste de las
contramedidas o salvaguardas a aplicar no puede ser mayor que el posible coste de la
materialización de las amenazas a las que están expuestos los activos que proteger, ya
que en este caso la relación coste-beneficio sería negativa para la organización.
3.3. Riesgo dentro del proceso de auditoría.

Se define como el riesgo de que la información obtenida durante una auditoría contenga
errores, y dichos errores no sean detectados.
El riesgo dentro del proceso de auditoría tiene diferentes facetas o componentes:
• Riesgo inherente: la organización es auditada sin tener en cuenta los controles

establecidos por la dirección.
• Riesgo de control: causado por un error material en la evaluación de los controles.
• Riesgo de detección: ocasionado por errores dentro de los procesos de detección

de evidencias o falsedad en declaraciones.
• Riesgo general de auditoría: producido por errores en los informes proporcionados

dentro del proceso de auditoría.

3.4. Riesgos asociados con el desarrollo de software.

Entre los riesgos potenciales que pueden ocurrir cuando se diseñan y desarrollan sistemas
SW se encuentran:
• Probabilidad de que el nuevo sistema no satisfaga las necesidades de negocio o

los requerimientos funcionales.
• Las actividades necesarias para la construcción del SI excedan el presupuesto

asignado inicialmente al proyecto.
• Asociado a los proveedores.
• Dentro de la propia organización, como por ejemplo falta de apoyo o priorización

necesaria.
• Con el entorno exterior. En ocasiones, un proyecto puede afectar a las condiciones

de los mercados o incluso a las condiciones gubernamentales o regulatorias.
• Tecnología seleccionada. La selección de una determinada tecnología siempre

lleva asociado un riesgo inherente. Un cambio en la relación coste-efectividad o
nivel de compatibilidad puede traer asociado efectos colaterales negativos.
En muchas ocasiones, estos riesgos están asociados a una falta de metodología de

desarrollo de SW o a la aplicación de una metodología no adecuada para el proyecto en
cuestión. Aunque la aplicación de una metodología de desarrollo SW no elimine por
completo los posibles riesgos asociados a un proyecto de desarrollo SW, es cierto que los
disminuye en gran medida.
Será misión del Auditor TI verificar que dentro de un proyecto se está aplicando la
metodología de desarrollo SW adecuada.
3.5. Marcos de referencia relacionados con análisis y gestión de riesgos.

Entre los marcos de referencia relacionados con el análisis y gestión de riesgos más
relevantes se encuentran:
• COBIT 5
• ISO 31000
• COSO
• Magerit v3
3.5.1. ISO 31000.

Se trata de un estándar internacional para la gestión de riesgos dentro de las
organizaciones, cuyo objetivo es proporcionar una serie de principios y directrices
genéricas que puedan ponerse en práctica de forma universal, en cualquier organización
independientemente de su naturaleza.
Está especialmente pensado para empresas con presencia internacional.
En la siguiente imagen, está reflejado el marco de trabajo ISO 31000 para la gestión de
riesgos:

FIGURA 23 MARCO DE TRABAJO ISO 31000 PARA LA GESTIÓN DE RIESGOS
El marco de referencia ISO 31000 constará de los siguientes pasos:
• Diseñar el modelo de gestión del riesgo (tiene que existir un apoyo por parte de
la dirección).
• Implementarlo.
• Realizar el seguimiento del sistema.
• Revisar el sistema y adaptarlo para su mantenimiento en el tiempo.
ISO 31000 se basa en los siguientes principios, que contribuyen a establecer una
estructura efectiva de gestión de riesgos dentro de la organización:
• Los procesos asociados a la gestión de riesgos deberían crear valor para la

organización.
• La gestión de riesgos debe estar integrada dentro de los procesos de la

organización.
• La gestión de riesgos debería ser un factor clave en la toma de decisiones a

cualquier nivel.
• Los procesos deberían señalar de forma explícita la incertidumbre.
• La gestión de riesgos debería ser sistemática, estructurada y adecuada.
• Las actividades deberían estar basadas en la mejor información disponible.
• El proceso general debe ser adaptado.

• Se debe considerar los factores humanos y culturales a cualquier nivel.
• La gestión de riesgos ha de ser transparente y completa.
• El proceso general debe ser dinámico, iterativo y flexible ante cambios.
• El proceso de gestión de riesgos debe facilitar la mejora continua en la

organización.
En la siguiente figura se muestran los procesos de gestión de riesgos dentro de la ISO

31000:
FIGURA 24 PROCESOS DE GESTIÓN DE RIESGOS DENTRO DE ISO 31000
En esta figura se representan los diferentes componentes del proceso de gestión de

riesgos recogido en la ISO 31000 y la relación existente entre los mismos:
• Establecimiento del contexto.
• Apreciación del riesgo (identificación, análisis y evaluación).
• Tratamiento del riesgo.
• Seguimiento y revisión.
• Registro del proceso de gestión del riesgo.

Existen dos normas complementarias a la ISO 31000:
• ISO Guía 73: contiene los términos asociados a la gestión de riesgos.
• ISO 31010: en esta guía figuran las técnicas relacionadas con la gestión de
riesgos.
3.5.2. COSO.
Se trata de un marco de referencia que proporciona directrices y orientaciones generales
relacionadas con la gestión del riesgo, control interno y disuasión del fraudo. Su objetivo es
mejorar el funcionamiento de la propia organización y reducir el alcance del fraude dentro
de la misma.
En la siguiente figura quedan reflejadas las 3 dimensiones de este marco de referencia:
FIGURA 25 MARCO DE REFERENCIA COSO
El modelo de control interno de COSO 2013 está compuesto por 5 componentes y 17

principios asociados a estos 5 componentes:
• Supervisión del sistema de control.
o Realizar evaluaciones continuas y/o independientes.
o Evaluar y comunicar las deficiencias.
• Sistemas de información y comunicación.

o Utilizar información pertinente
o Comunicación interna.
o Comunicación externa.
• Actividades de control.
o Seleccionar y desarrollar actividades de control.
o Seleccionar y desarrollar controles generales sobre tecnología.
o Implementación a través de políticas y procedimientos.
• Evaluación de riesgos.
o Especificar objetivos relevantes.
o Identificar y analizar los riesgos.
o Evaluar el riesgo de fraude.
o Identificar y analizar cambios significativos.
• Entorno de control.
o Demostrar compromiso con la integridad y los valores éticos.
o Ejercer la responsabilidad de supervisión.
o Establecer la estructura, autoridad, y responsabilidad.
o Demostrar compromiso con las competencias.
o Aplicar la rendición de cuentas.
3.5.3. Magerit.
Magerit es la metodología de análisis y gestión de riesgos promovida por el CSAE, en
previsión de un incremento del riesgo, que es necesario gestionar, y que surge como
consecuencia de un crecimiento exponencial del uso de los sistemas de información y
comunicaciones en la Administración Pública en particular y de la sociedad en general.
La versión actual de Magerit es la 3, y en lo sucesivo, se hará referencia a ella como

Magerit v3.
Diferencia entre los procesos de evaluación, certificación, acreditación y auditoría.

Relación con la gestión de riesgos.
El análisis de riesgos es una actividad obligatoria para poder llevar a cabo los procesos de
evaluación, certificación, auditoría y acreditación según se muestra en el siguiente
esquema:

FIGURA 26 CERTIFICACIÓN Y ACREDITACIÓN DE LOS SISTEMAS DE INFORMACIÓN
• Evaluación: permite medir el grado de confianza que merece o inspira un sistema

de información.
• Certificación: consiste en asegurar responsablemente y por escrito un

comportamiento. La evaluación puede llevar a una certificación o registro de la
seguridad de la información. Existen certificaciones de:
o Productos: es impersonal, se trata de comprobar que contiene

determinadas características técnicas.
o Sistemas: tiene que ver con el componente humano de las organizaciones

buscando el análisis de cómo se explotan los sistemas.
• Acreditación: proceso específico cuyo objetivo es legitimar al sistema para formar

parte de sistemas más amplios.
• Auditorías: dentro de las auditorías internas o externas es posible distinguir entre
o Auditorías requeridas por ley para operar en cierto sector (cumplimiento).

En el caso de la Administración pública existen 2 RD según los cuales es
necesario realizar auditorías:
▪ Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba

el Reglamento de desarrollo de la Ley Orgánica 15/1999, de 13 de
diciembre, de protección de datos de carácter personal.
▪ Real Decreto 3/2010, de 8 de enero, por el que se regula el

Esquema Nacional de Seguridad en el ámbito de la Administración
Electrónica. BOE de 29 de enero de 2010.
o Auditorías requeridas por la Dirección de la Organización.
o Auditorías requeridas por entidades colaboradoras que ven su nivel de

riesgo ligado al de nuestra organización.

Definiciones.
En este apartado se incluyen las definiciones fundamentales dentro de Magerit v3:
• Activos: Componente o funcionalidad de un sistema de información susceptible de

ser atacado deliberada o accidentalmente con consecuencias para la organización.
Se distinguen los siguientes tipos de activos:
o Activos esenciales: en un sistema de información hay dos cosas esenciales

que marcan los requisitos de seguridad para todos los demás componentes
del sistema.
▪ La información que se maneja.
▪ Los servicios que se prestan.
o Arquitectura del sistema: elementos que permiten estructurar el sistema,

definiendo su arquitectura interna y sus relaciones con el exterior.
o Datos / Información: activo abstracto que será almacenado en equipos o

soportes de información (normalmente agrupado como ficheros o bases de
datos) o será transferido de un lugar a otro por los medios de transmisión
de datos.
o Claves criptográficas: esenciales para garantizar el funcionamiento de los

mecanismos criptográficos.
o Servicios: Función que satisface una necesidad de los usuarios (del

servicio).
o Software- Aplicaciones informáticas: tareas que han sido automatizadas

para su desempeño por un equipo informático.
o Equipamiento informático (hardware): medios materiales, físicos,

destinados a soportar directa o indirectamente los servicios que presta la
organización.
o Redes de comunicaciones: medios de transporte que llevan datos de un

sitio a otro.
o Soporte de información: dispositivos físicos que permiten almacenar

información de forma permanente o, al menos, durante largos periodos de
tiempo.
o Equipamiento auxiliar: otros equipos que sirven de soporte a los sistemas

de información, sin estar directamente relacionados con datos.
o Instalaciones: lugares donde se hospedan los sistemas de información y

comunicaciones.
o Personal: personas relacionadas con los sistemas de información.
• Dimensiones de valoración: características o atributos que hacen valioso un

activo. Se consideran las siguientes dimensiones de valoración:
o Disponibilidad: propiedad o característica de los activos, consistente en que

las entidades o procesos autorizados tienen acceso a los mismos cuando

lo requieren.
o Integridad: propiedad o característica consistente en que el activo de

información no ha sido alterado de manera no autorizada.
o Confidencialidad: propiedad o característica consistente en que la

información ni se pone a disposición, ni se revela a individuos, entidades o
procesos no autorizados.
o Autenticidad: propiedad o característica consistente en que una entidad es quien dice

ser o bien que garantiza la fuente de la que proceden los datos.
o Trazabilidad: propiedad o característica consistente en que las actuaciones de una

entidad pueden ser imputadas exclusivamente a dicha entidad.
• Amenaza: causa potencial de un incidente que puede causar daños a un sistema

de información o a una organización. Se consideran los siguientes tipos de
amenaza:
o Desastres naturales.
o De origen industrial.
o Errores y fallos no intencionados.
o Ataques intencionados.
• Impacto: medida del daño sobre el activo derivado de la materialización de una

amenaza.
• Riesgo: medida del daño probable sobre un sistema.
• Salvaguardas: o contra medidas como aquellos procedimientos o mecanismos

tecnológicos que reducen el riesgo. Dentro de Magerit v3, se consideran los
siguientes tipos de salvaguardas:
o Protecciones generales u horizontales.
o Protecciones de los datos / información.
o Protección de las claves criptográficas.
o Protección de los servicios.
o Protección de las aplicaciones (software).
o Protección de los equipos (hardware).
o Protección de las comunicaciones.
o Protección en los puntos de interconexión con otros sistemas.
o Protección de los soportes de información.
o Protección de los elementos auxiliares.
o Protección de las instalaciones (seguridad física).
o Salvaguardas relativas al personal.
o Salvaguardas de tipo organizativo.

o Continuidad de operaciones.
o Externalización.
o Adquisición y desarrollo.
• Vulnerabilidades: toda debilidad que puede ser aprovechada por una amenaza, o
más detalladamente a las debilidades de los activos o de sus medidas de
protección que facilitan el éxito de una amenaza potencial.
Técnicas.
Dentro de Magerit v3 se emplean de forma habitual las siguientes técnicas:
1. Técnicas específicas para el análisis de riesgos:
a) Análisis mediante tablas.
b) Análisis algorítmico.
c) Arboles de ataque.
2. Técnicas generales:
1. Técnicas gráficas.
2. Sesiones de trabajo: entrevistas, reuniones y presentaciones.
3. Valoración Delphi.
Gestión de riesgos.
Dentro de la gestión del riesgo, se consideran de forma general las siguientes tareas:
FIGURA 27 GESTIÓN DE RIESGOS
• Análisis de riesgos: permite determinar qué tiene la organización y estimar lo que

podría pasar.
• Tratamiento de los riesgos: permite organizar las defensas hasta alcanzar a un

nivel residual de riesgo que la dirección pueda asumir.
En el caso concreto de Magerit v3, la gestión de riesgos incluye las siguientes tareas:
• MAR – Método de Análisis de Riesgos.

• PAR – Proyecto de Análisis de riesgos.
• PS – Plan de Seguridad.

FIGURA 28 GESTIÓN DE RIESGOS EN MAGERIT V 3
Método de Análisis de Riesgos (MAR).

El análisis de riesgos es una aproximación metódica para determinar el riesgo que sigue
unos pasos establecidos de forma previa. En la siguiente figura, se representan los
elementos dentro de un análisis de riesgos:
F IGURA 29 ELEMENTOS DEL ANÁLISIS DE RIESGOS
Dentro de Magerit v3, la tarea que contempla el proceso de Análisis de Riesgos se

denomina MAR (Método de Análisis de Riesgos). Esta tarea contempla las siguientes
actividades y subactividades:
• MAR.1 – Caracterización de los activos.

o MAR.11 – Identificación de los activos.
o MAR.12 – Dependencias entre activos.
o MAR.13 – Valoración de los activos.
• MAR.2 – Caracterización de las amenazas.
o MAR.21 – Identificación de las amenazas.
o MAR.22 – Valoración de las amenazas.
• MAR.3 – Caracterización de las salvaguardas.
o MAR.31 – Identificación de las salvaguardas pertinentes.
o MAR.32 – Valoración de las salvaguardas.
• MAR.4 – Estimación del estado de riesgo.
o MAR.41 – Estimación del impacto.
o MAR.42 – Estimación del riesgo.
Proyectos de análisis de riesgos (PAR).

La realización de un análisis de riesgos dentro de cualquier organización debe
considerarse como un proyecto con entidad propia, y, por tanto, se ha de establecer y
seguir una metodología para poder llevarlo a cabo,
Dentro de Magerit v3, la tarea que contempla la metodología para llevar a cabo proyecto
de análisis de riesgos se denomina PAR (Proyectos de análisis de riesgos), y contempla
las siguientes actividades:
• PAR.1 – Actividades preliminares.
• PAR.2 – Elaboración del análisis de riesgos.
• PAR.3 – Comunicación de resultados.
Plan de Seguridad (PS).

Esta tarea, contempla dentro de Métrica v3 cómo llevar a cabo planes de seguridad, que,
según el contexto, reciben diferentes nombres:
• plan de mejora de la seguridad
• plan director de seguridad
• plan estratégico de seguridad
• plan de adecuación (en concreto es el nombre que se usa en el ENS)
Las actividades contempladas dentro de esta tarea son:
• PS.1 – Identificación de proyectos de seguridad

• PS.2 – Plan de ejecución
• PS.3 – Ejecución
Herramientas EAR (Entorno de Análisis de riesgos).

Las herramientas EAR (Entorno de Análisis de Riesgos) soportan el análisis y la gestión de
riesgos de un sistema de información siguiendo la metodología Magerit v3 y está
desarrollada y financiada parcialmente por el CCN. Se actualizan periódicamente y existen
diversas variantes:
• PILAR: versión íntegra de la herramienta. Dispone de una biblioteca estándar de

propósito general y es capaz de realizar calificaciones de seguridad respecto de
normas ampliamente conocidas como:
◦ ISO/IEC 27002 (2005, 2013)- Código de buenas prácticas para la Gestión de la

Seguridad de la Información.
◦ ENS - Esquema Nacional de Seguridad.
La versión actual de esta herramienta es PILAR 5.4.8 (9.3.2016)
Guías STIC relacionadas:
• CCN-STIC-470G1 Manual de la Herramienta de Análisis de Riesgos PILAR

5.4
• CCN-STIC-470G2 Manual de PILAR 5.4. Análisis de impacto y continuidad

de operaciones
FIGURA 30 HERRAMIENTA PILAR
• PILAR Basic: versión sencilla para Pymes y Administración Local. Guía STIC

relacionada: CCN-STIC-472E Manual de usuario Pilar Basic 5.4.
FIGURA 31 PILAR BASIC
• μPILAR: versión de PILAR reducida, destinada a la realización de análisis de riesgos

muy rápidos. Guía STIC relacionada: CCN-STIC-473D Manual de usuario mPilar 5.4.
FIGURA 32 ΜPILAR
• RMAT (Risk Management Additional Tools) Personalización de herramientas. Se puede

realizar una personalización en varios aspectos:
o EVL - Perfiles de protección: Criterios de evaluación/acreditación específicos de

ciertos sectores o de puntos de vista específicos. Por ejemplo: leyes nacionales de
protección de datos personales.
o TSV - Perfiles de amenazas: Estableciendo la vulnerabilidad típica de los activos

frente a las amenazas en diferentes entornos de operación.
o KB - Protecciones adicionales: Detallando protecciones adicionales sobre ciertos

tipos de activos. Se puede llegar a dar instrucciones al administrador del activo.
FIGURA 33 RMAT
3.6. Análisis de riesgos en el ENS.

El análisis de riesgos [op.pl.1] está clasificado dentro del ENS como una medida en la
sección de planificación [op.pl] dentro del marco operacional [op].
Dependiendo de la categoría asignada al sistema, en referencia a las siguientes

dimensiones:
• Disponibilidad (D).
• Autenticidad (A).
• Integridad (I).
• Confidencialidad (C).
• Trazabilidad (T).
se realizará un tipo u otro de análisis de riesgos que se pasa a detallar a continuación.
3.6.1. Categoría BASICA.

En este caso, será suficiente realizar un análisis informal (realizado en lenguaje natural)
que describa los siguientes aspectos:

• Identifique los activos más valiosos del sistema.
• Identifique las amenazas más probables.
• Identifique las salvaguardas que protegen de dichas amenazas.
• Identifique los principales riesgos residuales.
En el caso de sistemas clasificados con categoría BÁSICA, de acuerdo con la guía de

seguridad CCN-STIC-808 “Verificación del cumplimiento de las medidas en el ENS”, los
controles de auditoría a aplicar son:
• Op.pl.1-CONT1: se deberá disponer de un documento aprobado por la Dirección

con una antigüedad no mayor de 1 año, que contenga un análisis de riesgos
realizado en lenguaje natural. Además, será necesario que exista un procedimiento
de revisión y aprobación regular (al menos anual) del análisis de riesgos.
• Op.pl.1-CONT2: en el documento mencionado en el control anterior, se identifican

los servicios y la información que maneja la organización en referencia a la ley
11/207, así como los elementos en los que se sustentan.
• Op.pl.1-CONT3: en el documento mencionado en el primer control se encuentran

identificadas las amenazas más probables.
• Op.pl.1-CONT4: en el documento mencionado en el primer control, se identifican

las salvaguardas de que se disponen para mitigar las amenazar identificadas.

las amenazas para las que no existen salvaguardas, o aquellas para las que el
grado de protección actual no es el suficiente.
3.6.2 Categoría MEDIA.

En el caso de que un sistema sea clasificado con categoría MEDIA, se deberá realizar un
análisis semi-formal usando un lenguaje específico, con un catálogo básico de amenazas y
una semántica definida que describa los siguientes aspectos:
• Identifique y valore cualitativamente los activos más valiosos del sistema.
• Identifique y cuantifique las amenazas más probables.
• Identifique y valore las salvaguardas que protegen de dichas amenazas.
• Identifique y valore el riesgo residual.
En el caso de sistemas clasificados con categoría MEDIA, de acuerdo con la guía de


realizado en un lenguaje específico y con una semántica definida. Además, será
necesario que exista un procedimiento de revisión y aprobación regular (al menos
anual) del análisis de riesgos.


11/207, así como los elementos en los que se sustentan. Los activos (servicios e
información) son valorados cualitativamente (siguiendo los criterios de bajo, medio
o alto).

identificadas las amenazas más probables, y estas son cuantificadas.

las salvaguardas de que se disponen para mitigar las amenazas identificadas y su
nivel de eficacia.
• Op.pl.1-CONT5: en el documento mencionado en el primer control, se identifica el

nivel de riesgo al que están expuestos los servicios (bajo, medio o alto), conforme
a una tabla de equivalencias que tiene en cuenta el valor de los activos, la
probabilidad de las amenazas y la eficacia de las salvaguardas.
3.6.3 Categoría ALTA.

En el caso de que un sistema sea clasificado con categoría ALTA, se deberá realizar un
análisis formal usando un lenguaje específico, con un fundamento matemático reconocido
internacionalmente, que cubra los siguientes aspectos:
• Identifique y valore cualitativamente los activos más valiosos del sistema.
• Identifique y cuantifique las amenazas posibles.
• Identifique las vulnerabilidades habilitantes de dichas amenazas.
• Identifique y valore las salvaguardas adecuadas.
• Identifique y valore el riesgo residual.
En el caso de sistemas clasificados con categoría ALTA, de acuerdo con la guía de


realizado en un lenguaje específico y con un fundamento metodológico reconocido
internacionalmente (ej. Magerit). Además, será necesario que exista un
procedimiento de revisión y aprobación regular (al menos anual) del análisis de
riesgos. Se utilizará una herramienta reconocida de análisis de riesgos (ej. PILAR).

11/207, así como los elementos en los que se sustentan. Los activos (servicios e
información) son valorados cualitativamente (siguiendo los criterios de bajo, medio
o alto).

identificadas las amenazas más probables para cada activo, su frecuencia y

degradación resultante.
• Op.pl.1-CONT4: en el documento mencionado en el primer control se identifican

las vulnerabilidades que habilitan las amenazas contempladas en el punto anterior.

las salvaguardas de que se disponen para mitigar las amenazas identificadas y su
nivel de eficacia, así como la posible necesidad de disponer de más salvaguardas.
• Op.pl.1-CONT6: en el documento mencionado en el primer control, se identifica el

nivel de riesgo al que están expuestos los servicios y la información (bajo, medio o
alto).

4. Bibliografía
1. BS 25999-1:2006 Gestión de la Continuidad de Negocio – Código de Prácticas
2. ISO 22301:2012 Seguridad de la sociedad – Sistemas de gestión de la continuidad del
negocio – Requisitos
3. ISO/IEC 17799:2005 Tecnología de la Información – Técnicas de Seguridad – Código
para la Práctica de la Gestión de la Seguridad de la Información
4. ISO/IEC 27001 Tecnología de la Información – Técnicas de Seguridad – Sistemas de
Gestión de Seguridad de la Información – Requisitos
5. MAGERIT versión 3
6. RD 3/2010 Esquema Nacional de Seguridad en el Ámbito de la Administración
Electrónica

Gestion de Riesgos

Cargado por

Copyright:

Formatos disponibles

Gestion de Riesgos

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Gestion de Riesgos

Cargado por

Copyright:

Formatos disponibles

I: Organización y gestión de los sistemas de información

Asociación Profesional del Cuerpo Superior

de Sistemas y Tecnologías de la Información

de la Administración del Estado

Temas Específicos para la preparación de la Oposición al Cuerpo

TEMAS ESPECÍFICOS I: Organización y gestión de los

Tema 45. Seguridad de sistemas (1). Análisis y gestión de

• Tema 32. La protección jurídica de los programas de ordenador

• Tema 33. Auditoría Informática III: Desarrollo, adquisición,

045. Seguridad de sistemas (1). Análisis y gestión de riesgos. Herramientas. 1

045. Seguridad de sistemas (1). Análisis y gestión de riesgos. Herramientas. 2

3.6.1. Categoría BASICA................................................................................................. 54

045. Seguridad de sistemas (1). Análisis y gestión de riesgos. Herramientas. 3

1 Protección de activos de información

FIG. 1 PROCESO DE GESTIÓN DEL RIESGO (ISO 27005:2011)

En el ámbito informático, se entiende por incidente, cualquier evento que no es parte de la

045. Seguridad de sistemas (1). Análisis y gestión de riesgos. Herramientas. 4

cuenta de un usuario; uso no autorizado de Privilegios de acceso al sistema; desfase de una o

Podemos clasificar los incidentes según la estimación de sus daños en:

FIG. 2 VULNERABILIDADES POR CAPAS

045. Seguridad de sistemas (1). Análisis y gestión de riesgos. Herramientas. 5

Fig. 3 Los 10 dominios de control según ISO17799

Es importante reseñar que Continuidad de Negocio no es lo mismo que Recuperación frente a

045. Seguridad de sistemas (1). Análisis y gestión de riesgos. Herramientas. 6

1.1 Introducción a la seguridad

1.2 Tipos de seguridad

045. Seguridad de sistemas (1). Análisis y gestión de riesgos. Herramientas. 7

• Centro de control de alarmas e incidencias

1.3 Análisis de riesgos y gestión del riesgo

1.3.1 Análisis de Riesgos

045. Seguridad de sistemas (1). Análisis y gestión de riesgos. Herramientas. 8

Los sistemas de gestión de la seguridad de la información (SGSI), definidos en la norma ISO

El análisis de riesgos es parte de las actividades de planificación, donde se toman decisiones

F IG. 4 ELEMENTOS DEL ANÁLISIS DE RIESGOS

Siendo los elementos que deben gestionarse:

045. Seguridad de sistemas (1). Análisis y gestión de riesgos. Herramientas. 9

Incluye: información, datos, servicios, aplicaciones, equipos, comunicaciones, recursos

Con estos elementos se puede estimar el impacto, o lo que es lo mismo, la consecuencia de la

045. Seguridad de sistemas (1). Análisis y gestión de riesgos. Herramientas. 10

En caso de materialización de un riesgo el Coste Total es igual a la suma del Coste de

El Coste de Interrupción está relacionado con el tiempo de duración de la interrupción.

FIG. 5 EJEMPLO DE COSTE DE LA INTERRUPCIÓN DE LA ACTIVIDAD

El Coste de Recuperación es el asociado a la existencia de un plan de continuidad del negocio.

1.3.2 Gestión de Riesgos

045. Seguridad de sistemas (1). Análisis y gestión de riesgos. Herramientas. 11

1.4 Relación entre el ENS, MAGERIT y el análisis y gestión riesgos

045. Seguridad de sistemas (1). Análisis y gestión de riesgos. Herramientas. 12

Para el análisis y gestión de riesgos de conformidad con el Esquema Nacional de Seguridad se

FIG. 7 ISO 31000 - MARCO DE TRABAJO PARA LA GESTIÓN DE RIESGOS

2 Recuperación de desastres y continuidad del negocio.

Debemos identificar las estrategias adecuadas de recuperación y evaluarlas con criterios de

045. Seguridad de sistemas (1). Análisis y gestión de riesgos. Herramientas. 13

FIG. 8 C OSTE FRENTE A T IEMPO - E STRATEGIAS DE RECUPERACIÓN

2.1 Parámetros para definir la recuperación (RTO, RPO, …)

Repasamos a continuación los principales términos empleados para definir la recuperación:

• Requerimientos de los procesos críticos de negocio

045. Seguridad de sistemas (1). Análisis y gestión de riesgos. Herramientas. 14

FIG. 9 RTO/RPO - VERSUS TECNOLOGÍA DE RECUPERACIÓN