Un repaso rápido a la Continuidad de Negocio según la BS 25999 y la nueva UNE 71599. Pueden descargar el PDF desde http://www.s2grupo.es/jornadas_presentaciones.shtml
1. Continuidad de Negocio
UNE 71599 / BS 25999
Manuel Benet
Consultor de Seguridad. S2 Grupo
12 de Mayo, 2011
2. Prólogo
Prólogo
Existen varios caminos a la Continuidad de Negocio:
a. El directo.
b. El indirecto.
c. El doloroso.
2
3. Prólogo
a. El directo o “momento revelación”
“Hoy podría morir calcinado en este salón de actos.
¿Sobreviviría mi organización a tan trágica pérdida?“
I. No. Tienen (tenemos) un problema.
II. Sí. ¿A qué coste?
3
4. Prólogo
b. El indirecto o “momento
certificación ISO 27001”
4
5. Prólogo
c. El doloroso
Suele llegar demasiado tarde y quizá no haya
negocio que continuar.
Puede conllevar no sólo pérdidas económicas
sino también humanas.
5
8. “Eso no me puede pasar a mí”
1. Polonia
El 10 de abril de 2010 el avión Tupolev 154 en el que
viajaba el presidente de Polonia, Lech Kaczynski, se
estrelló en la ciudad rusa de Smolensk.
Además del presidente y su esposa fallecieron el
gobernador del Banco Central, el jefe de Estado Mayor, el
viceministro de Exteriores y decenas de diputados.
8
9. “Eso no me puede pasar a mí”
2. Edificio Windsor
9
12. “Quizá sí, pero es poco probable”
Ejemplos más “mundanos”
1. Manolo, su excavadora y las líneas de datos.
2. Los grupos electrógenos: a veces funcionan, a veces no.
3. Esa afición por colocar tuberías en los CPDs.
4. La diversión de abrir adjuntos ejecutables.
5. ¿La clave del fichero de claves? Sólo la sabía Pepe.
6. ¿Copias? ¿Qué copias?
7. Los AACC se van de vacaciones en agosto.
12
15. “De acuerdo, hagámoslo”
El camino fácil (que no el correcto)
Una vez planteada la necesidad/obligatoriedad
del proyecto, es habitual optar por un enfoque
“simplificado” que...
15
16. “De acuerdo, hagámoslo”
… se limita a las copias de seguridad y poco más.
… ignora la problemática asociada a las personas.
… ignora las necesidades del negocio.
… ignora las capacidades reales de TI.
… no es mantenido regularmente.
… no es probado en condiciones.
… no incluye los planes operativos correspondientes.
16
17. “De acuerdo, hagámoslo”
Ese planteamiento, menos exhaustivo y costoso,
puede ser parcialmente válido, pero debemos ser
conscientes de sus limitaciones y de que no es un
Sistema de Gestión de Continuidad de Negocio.
Lo que fácil viene, fácil se va
17
18. “De acuerdo, hagámoslo”
El camino correcto (que no el fácil)
1. Implica un proceso de a) desarrollo, b) implantación, c)
mantenimiento y d) posible certificación.
2. Requiere pruebas periódicas.
3. Necesita tiempo, recursos económicos y humanos.
4. Exige implicación de la Dirección.
5. Es un Sistema de Gestión.
6. Sigue un estándar probado: UNE 71599 / BS 25999.
18
20. UNE 71599 / BS 25999
La Continuidad de Negocio es un sistema de
Gestión que identifica las amenazas que
pueden poner en riesgo la continuidad de la
organización y proporciona los medios para
hacerles frente y proteger el negocio.
20
21. UNE 71599 / BS 25999
Seis pasos básicos
1. Colocar los cimientos.
2. Entender la Organización.
3. Determinar la Estrategia de Continuidad de Negocio.
4. Desarrollar e implantar la Continuidad de Negocio.
5. Probar, mantener, revisar y auditar.
6. Asentar la Continuidad de Negocio en la cultura de la
organización.
21
23. 1. Asegurar los cimientos
1. Colocar los cimientos
• Definición del alcance
• Asignar recursos.
• Implicar a la Dirección y a la organización.
• Asignar las responsabilidades.
23
24. 1. Asegurar los cimientos
Errores típicos
• El alcance no está claramente definido.
• Hay proyecto, pero no hay recursos.
• No hay implicación (“es un proyecto
de TI”).
• ¿Responsabilidades? ¿Qué
responsabilidades? (también conocido
como “TI se lo guisa, TI se lo come.”)
24
25. 2. Entender la organización
2. Entender la organización
• El Análisis de Impacto sobre el Negocio.
• El Análisis de Riesgos.
25
26. 2. Entender la organización
El Análisis de Impacto sobre el Negocio (AIN o BIA):
I. Procesos del negocio.
• Activos y personal implicado.
• Dependencias (proveedores, servicios
internos, etc.).
• Periodos críticos.
• Impactos.
• Tiempo máximo de interrupción tolerable.
• Niveles mínimos de calidad de servicio
aceptables tras la recuperación del proceso.
• Tiempo máximo para volver a la operación
normalizada.
26
27. 2. Entender la organización
El Análisis de Riesgos:
I. Amenazas.
II. Impactos.
III. Probabilidades.
IV. Riesgos inherentes y residuales.
V. Política de gestión de riesgos (aceptar /
mitigar / transferir / eliminar).
El resultado proporciona los riesgos no
aceptables para las necesidades del negocio y
los procesos más vulnerables a los riesgos
detectados.
27
28. 2. Entender la organización
Errores comunes
• Tener una visión demasiado “aérea”.
• Obtener tiempos no “razonables”.
• Omitir dependencias internas.
• Omitir personal crítico.
• Basarse únicamente en la visión de TI.
• No consensuar/contrastar los resultados
obtenidos con el resto de la organización.
28
29. 3. La estrategia
3. La estrategia
Para cada potencial incidente, deben
desarrollarse alternativas a adoptar en
cada uno de los aspectos controlables.
Recursos necesarios para cada alternativa
propuesta.
29
30. 3. La estrategia
Posibles alternativas y factores
• Personal. Necesidades de formación, externalización, gestión
del conocimiento…
• Ubicaciones físicas. Alquiler, compra, teletrabajo…
• Tecnología. Sedes alternativas, replicación, acceso remoto,
virtualización, copias de seguridad,…
• Información. Ubicación digital, papel, datos de carácter
personal, registros críticos,…
• Suministros. Proveedores críticos y tiempos de respuesta,
contratos de servicio, almacenes y proveedores alternativos…
• Terceras partes. Aspectos legales (p.ej. LOPD, presentación
de tributos), comunicación con clientes, partners,…
30
31. 3. La estrategia
Errores comunes
• Las estrategias no están en línea con el risk
appettite (o nivel de riesgo aceptable por la
organización).
• No tener en cuenta las actividades críticas.
• No tener en cuenta los periodos críticos.
• Proponer estrategias “a futuro” o irreales por
coste o ejecución. No ser realista.
• No tener el apoyo y visto bueno de Dirección.
31
32. 4. Desarrollo e implantación
4. Desarrollo e Implantación
Tomando como base la información del BIA, el AR y
las estrategias seleccionadas, determina:
• El plan de respuesta a incidentes (o Plan de Crisis).
• Planes de gestión de incidentes.
32
33. 4. Desarrollo e implantación
El plan de respuesta a incidentes:
• Gestiona el momento inicial de la incidencia.
• Garantiza una respuesta rápida al incidente.
• Simplifica la toma de decisiones.
• Identifica al personal responsable de la
gestión del incidente.
• Especifica las condiciones de disparo de los
planes específicos.
Si algo puede salir mal, saldrá mal, y lo hará en el
peor momento posible.
33
34. 4. Desarrollo e implantación
Los planes de gestión de incidentes:
• Documentos que permiten la recuperación
de las diferentes actividades afectadas por un
incidente.
• Identifican al personal responsable del plan.
• Contienen los recursos necesarios afectados
por el plan (personal, locales, tecnología,
información, suministros y terceras partes).
• Contienen los procedimientos de toma de
decisiones (quién, cómo, y a quién informar).
• Identifican procedimientos operativos
concretos.
34
35. 4. Desarrollo e implantación
Errores comunes
• La documentación está obsoleta.
• La documentación está ilocalizable.
• ¿Documentación? ¿Qué documentación?
• Las responsabilidades no están definidas.
• No se contemplan dependencias.
• El escalado de incidencias no está claramente
definido.
• No existen planes operativos.
35
36. 5. Pruebas
5. Pruebas
• Verificar que el sistema “no olvida nada”.
• Comprobar que TI puede soportar al negocio.
• Anticipar problemas concretos en situaciones
controladas.
• Mejorar la capacidad de la organización para
enfrentarse a situaciones de crisis.
• Propagar la cultura de la continuidad de negocio
entre los participantes.
• Generar confianza entre los participantes de las
pruebas.
36
37. 5. Pruebas
Errores comunes
• No se realizan pruebas.
• Las pruebas olvidan al usuario final u omiten
personal relevante.
• Las pruebas no son comunicadas a la
organización.
• Las pruebas no son realistas.
• El resultado de las pruebas se “maquilla”.
• El resultado de las pruebas no tiene
continuidad (¿planes de acción?).
37
38. 6. Cultura de la organización
6. Cultura de la organización
Como todo Sistema de Gestión, debe
desarrollarse un programa de concienciación que:
• Mejore la eficacia del sistema.
• Prepare al personal implicado.
• Difunda entre clientes y proveedores las
ventajas del sistema implantado.
• Mejore la receptividad de la organización hacia
las pruebas.
38
39. 6. Cultura de la organización
Algunas medidas
• Utilización de los medios internos: Intranet, e-
mail, circulares internas.
• Sesiones de formación entre el personal.
• Encuestas y grupos de trabajo.
• Incluir la Continuidad de Negocio en las
reuniones de los departamentos.
39
40. 6. Cultura de la organización
Errores comunes
• No desarrollar un programa de
concienciación.
• Incluir en el programa únicamente a
personal técnico.
• Tener un programa demasiado disperso
en el tiempo.
40
41. Conclusiones
Un Sistema de Gestión de la Continuidad de
Negocio es como una rueda de repuesto:
Se ve poco, no se usa, pero hay que revisarla
de vez en cuando. Ojalá no tengamos que
utilizarla nunca, pero…
…mejor que esté ahí, por si acaso.
41
42. Conclusiones
Principales problemas
• No tener el apoyo de Dirección.
• No dedicar recursos, tiempo y personal asignado.
• Olvidar las necesidades del negocio.
• No desarrollar o mantener la documentación.
• Obviar las pruebas y la comunicación a usuarios.
42
