Planes de Continuidad. 10 aspectos clave

Ya sea que hablemos de la continuidad de los procesos de negocio en general o de la continuidad de los servicios de TI en particular (equivalentes a los planes de contingencia de TI), hay una serie de aspectos clave a la hora de abordar estos proyectos que es necesario tener en cuenta para garantizar su éxito:

Mapa de procesos y/o catálogo de servicios de TI

Conseguir disponer de un mapa de procesos de negocio y/o un catálogo de servicios de TI suficientemente detallado.

Participación de la Dirección

Conseguir la participación y/o involucración de la Dirección en el proyecto. En caso de abordar un Plan de Continuidad de Negocio la participación debe quedar plasmada en el compromiso de involucrarse de forma continua y participativa en la ejecución del proyecto. Dicha participación es clave, por no decir absolutamente imprescindible. Un Plan de continuidad de Negocio es un proyecto estratégico para la organización.

Análisis de Impacto en el Negocio (BIA)

Conseguir que la Dirección y los interlocutores se ubiquen dentro del alcance de este tipo de proyectos y tengan claro la diferencia entre una incidencia y un desastre. Para ello es muy importante explicar el concepto de análisis de impacto en el negocio  (BIA). El BIA introduce en el análisis la variable temporal que permite evaluar, precisamente, cuando un incidente puede llegar a convertirse en un desastre si no se soluciona a tiempo.

Valoración tangible vs intangible

Poder valorar de forma tangible – económicamente - el impacto asociado a la no disponibilidad de un proceso crítico de negocio (PCN) o de un servicio de TI (PCTI).

Análisis de Riegos

Disponer de un análisis de riesgos creado con criterios homogéneos a lo largo de toda la organización. Esto puede ser complicado cuando la organización decide abordar este tipo de proyectos de forma interna y no dispone o designa a un responsable del proyecto que marque las pautas.

Plan de Tratamiento de Riesgos

Establecer el Plan de Tratamiento de Riesgos como un entregable básico del proyecto. En realidad no nos gustaría llegar a tener que activar nuestro Plan.

Estrategias de Recuperación

Conseguir que quede clara la diferencia entre lo que son las medidas de reducción, eliminación del riesgo (o del impacto asociado) con respecto a lo que son las estrategias de recuperación a implementar para conseguir cumplir con los requisitos de continuidad del negocio (RTOs).

Riesgo vs Coste

Valorar económicamente, con el nivel de detalle necesario, las medidas de reducción del riesgo y estrategias de recuperación planteadas. Los análisis de riesgo vs coste y RTO vs coste permitirán a la Dirección decidir en base a criterios de negocio. La experiencia demuestra que casi siempre, para algunos procesos de negocio o servicios de TI, la primera valoración de los RTO es demasiado restrictiva. Suele ser necesario un segundo análisis.

Escenarios de Indisponibilidad

Agrupar los riesgos residuales inaceptables para la organización en una serie de escenarios de indisponibilidad que se puedan tratar a posteriori con planes operativos de recuperación específicos para cada escenario (planes de recuperación ante desastres).

Oficina de Continuidad

La definición e implementación de una Oficina de Continuidad constituida por una estructura de roles y responsabilidades que velen en la organización por la continuidad y sean asumidas por personal capacitado (definiendo la estructura y seleccionando a las personas adecuadas para ejercer cada rol). Roles que pueden ser internos, externos o una mezcla de ambos.

De la Continuidad Tecnológica a la Continuidad de Negocio

Es indudable que en los últimos años ha crecido la preocupación en las organizaciones por garantizar la continuidad de las operaciones críticas del negocio.   Esta tendencia  puede ser debida a diversos factores, como las numerosas normas o estándares que abordan esta problemática (ISO 27000, la BS 25999 o la ISO 22301…),  los marcos metodológicos que aúnan buenas prácticas en la materia (COBIT, ITIL®…), organizaciones sin ánimo de lucro que tratan y fomentan la temática (ISACA, Business Continuity Institute…) o los numerosos antecedentes de eventos no deseados  que han provocado impactos muy importantes  en organizaciones muy conocidas. Todos recordareis el incidente del WindSord, el ataque sufrido por la plataforma PlayStationNetwork de Sony, el atentado a las Torres Gemelas, la reciente caída del servicio WhatsApp…

El problema que se encuentran muchas organizaciones que quieren proteger sus operaciones críticas es, dentro de la complejidad que tiene cada negocio, cómo comenzar a aplicar buenas prácticas en materia de continuidad de negocio.  Lo recomendable en una situación de este tipo es comerse el elefante en pequeños trozos que permitan ir expandiendo el foco. Y justo en este momento nos acordamos de las tecnologías de la información y comunicaciones (en adelante TIC).  Hay que tener en cuenta que gran parte de la operativa de las compañías está soportada por TICs y que  la tendencia tecnológica al alza en la que vive el mundo actual ha hecho que haya aumentado la dependencia que el negocio tiene de ellas.

Nuestra experiencia nos dice que el departamento de TI es un excelente punto de partida para, partiendo de un plan de contingencia de TI (identificar procesos críticos, sistemas TI clave, tiempos de recuperación mínimos, puntos de recuperación objetivos, existencia de procesos manuales alternativos, definición de estrategias de recuperación, establecimiento de Roles y Responsabilidades y del Plan de Recuperación frente a Desastres…) extender el concepto de continuidad hacia los niveles superiores de la organización, dando un paso clave de madurez en una compañía… “de la continuidad tecnológica a la continuidad de negocio”.

Para dar este paso es muy importante que el CIO asuma tanto el liderazgo como  el reto de transmitir a la Alta Dirección que “su” hoja de ruta simplifica las cosas, porque ya hay una estructura de roles y responsabilidades (Cultura de Comités, Equipos de Recuperación, Responsable de Continuidad…), ya se habla de riesgos, de cómo mitigarlos, de procesos críticos, de estrategias de recuperación, de planes de recuperación asociados…. y que si la organización aprovecha esa inercia obtenida a partir del plan de contingencia será más fácil impulsar y elevar el concepto de “continuidad”. En ese momento el CIO trasladará la “pelota” al techo de la Alta Dirección, que comenzará a pensar en términos de continuidad, identificando necesidades y fomentando la toma de decisiones.  Si se consigue captar el interés de la Alta Dirección  se percibirá la necesidad. A veces esto se consigue de manera curiosa, recuerdo una reunión en la que los miembros del Comité de Dirección no entendían la diferencia entre una incidencia normal y otra que diera lugar a la activación del plan de continuidad. El conocimiento que el CIO había obtenido le permitió  explicarles que necesitaban el Análisis de Impacto en el Negocio (BIA) porque introducía un elemento fundamental, la variable temporal. Esta variable era lo que convertía una incidencia de un tipo en una de otro.
  

Esta hoja de ruta es la que aconsejamos seguir en clientes de muy diversos sectores y con problemáticas de muy diversos tipos. En próximas entradas explicaré cómo mantener el sistema de Gestión de Continuidad de Negocio a través de la implantación de una Oficina de Continuidad. 

Gestión del Riesgo

La seguridad de la información es el conjunto de medidas preventivas y reactivas de las organizaciones y de los sistemas tecnológicos que permiten resguardar y proteger la entidad buscando mantener la confidencialidad, la disponibilidad e integridad de la misma.

Para ello existen una serie de estándares, protocolos, métodos, reglas, herramientas y leyes concebidas para minimizar los posibles riesgos a la infraestructura o a la información.

Una de las técnicas para evaluar en una entidad su nivel de Seguridad es realizar un análisis de Riesgos. El estudio puede incluir la visión de negocio, si se realiza el estudio después de la realización del Análisis de Impacto sobre el Negocio BIA (Business Impact Analysis).

La realización del análisis de riesgos proporciona a las organizaciones una visión de la situación en cuanto al nivel de protección de los sistemas de información. Por este motivo, se constituye como uno de los pilares fundamentales a la hora de conocer de manera de detallada la infraestructura y el funcionamiento interno.

Con el análisis de riesgo sobre los sistemas de la organización se conseguirán los siguientes objetivos:

• Identificar y valorar los procesos más críticos de negocio, con el propósito de identificar el nivel de protección adecuado.
• Determinar i evaluar las amenazas existentes, determinando su grado de efectividad para hacer frente a los riesgos existentes.
• Calcular el nivel de riesgo, existente, de forma que la organización conozca con detalle la probabilidad de materialización de cada una de las amenazas y el impacto que estas pueden ocasionar.

Para efectuar un análisis de riesgos con garantías, entre otras, se puede seleccionar la metodología MAGERIT, elaborada por el ‘Consejo Superior de Administración Electrónica’.

MAGERIT es el acrónimo de ‘Metodología de Análisis y Gestión del Riesgo de los Sistemas de Información’, y nace para minimizar los riesgo asociados al uso de los sistemas informáticos y telemáticos, garantizando su autenticidad, confidencialidad, integridad y disponibilidad de dichos sistemas y generando así la confianza en el usuario de los mismos.

A nivel conceptual, MAGERIT se basa en la evaluación y relación lógica de los siguientes conceptos:

Tal y como muestra el esquema, todo el análisis gira entorno de los conceptos:

• Activo: elemento que tiene un valor para la organización
• Amenaza: acontecimiento que supone un impacto negativo sobre el activo y
• Salvaguarda: medida implantada para proteger el propio activo

Los objetivos principales son:

1. Determinar los activos relevantes para la organización, su interrelación y su valor, en el sentido de qué perjuicio supondría su degradación.
2. Determinar a qué amenazas están expuestos dichos 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 expectación de materialización de la amenaza).

Llegando finalmente a un concepto MEDIBLE que es el riesgo al que la entidad queda expuesta, es decir a una vulnerabilidad provocada por una amenazada.

Conviene aclarar la existencia de dos variables de riesgo diferenciadas. La primera de ellas se acostumbra a nombrar RIESGO POTENCIAL, es decir el riesgo al que estaría expuesta la organización sino existiera ningún tipo de salvaguarda implantada. Todo y ser un valor de riesgo ‘ficticio’ es un valor muy práctico en el momento de implementar nuevas salvaguardas en la entidad, ya que permite simular la evolución del nivel de riesgo a medida que se introducen nuevas medidas de seguridad. En cambio, el RIESGO RESIDUAL se ha de considerar como el nivel de riesgo actual, y por tanto la base sobre la cual se estructuraran los planes de continuidad de los servicios prestados.

Existen herramientas, como el software EAR/PILAR, diseñadas para gestionar de manera eficiente los riesgos según la metodología expuesta.   

Con esta información, juntamente con los requisitos de las normativas aplicables, la organización/entidad podrá seleccionar y priorizar aquellas medidas técnicas que permitan mejorar de manera eficiente el nivel de seguridad de sus sistemas de información. 

Plan de Contingencia. ¿Cómo?. ¿Cuándo?

Algunos de vosotros nos habéis preguntado respecto de los criterios de activación del Plan de Contingencia. Para ello recurriremos a la guía 800-34 del NIST: Contingency Planning Guide for Information Technology Systems.

Para fijar conceptos, empecemos estableciendo en qué consiste realmente el plan. Estamos hablando, básicamente, de restaurar la interrupción de los servicios de TI:

1. Recuperando las operaciones de TI en una ubicación alternativa.
2. Recuperando las operaciones de TI con equipamiento alternativo.
3. Realizando alguno de los procesos de negocio soportados por dichos servicios mediante medios manuales.

Una vez tenemos el plan montado y probado, éste debe ser activado sólo cuando la evaluación de daños indica que uno o más de los criterios de activación se cumplen. Estos criterios son únicos para cada organización, deben ser claros y pueden basarse en:

1. La seguridad del personal y/o la magnitud de los daños sobre las instalaciones.
2. La extensión de la avería según criterios físicos, operacionales o financieros.
3. La criticidad del sistema afectado.
4. La previsión de la duración de la interrupción en base a los RTOs establecidos en el BIA. Este punto está relacionado con el anterior.

Por ejemplo, podemos establecer que nuestro plan se activará:

1. Cuando el tiempo de recuperación previsto de cualquiera de los servicios excede el tiempo máximo establecido.
2. Cuando transcurrido el 50% del tiempo máximo para la recuperación de un servicio, no haya sido posible identificar su causa.

Plan de Contingencia y catálogo de servicios de TI

Últimamente se han escrito en este blog diferentes puntos clave a tener en cuenta durante la realización de un Plan de Contingencia. El Plan de Contingencia tal como sabemos, trata de planificar la restauración de los servicios de TI ante una situación de desastre.

Como explicamos en su día, la primera fase del plan, el Análisis de Impacto (BIA), consiste en:

1. Identificar los procesos más críticos del negocio y los servicios de TI que los soportan.


2. Determinar el impacto si uno o varios de estos servicios de TI se ven afectados total o parcialmente.


3. Definir los requerimientos de recuperación establecidos por el negocio - tiempo máximo de interrupción o RTO y máxima pérdida de datos permitida o RPO.

En el momento de realizar el BIA, los requerimientos de recuperación del negocio se recogen a través de entrevistas con los responsables de las diferentes áreas o departamentos de la organización: RR.HH, compras, marketing, logística, producción, etc. El objetivo de dichas entrevistas es averiguar qué servicios de TI usa cada área o departamento.

Sin embargo, en este punto debemos preguntarnos si sabemos cuáles son los servicios de TI que ofrecemos. No se puede empezar la casa por el tejado, por lo que tanto el negocio como el Departamento de TI deben conocer cuáles son los servicios de TI que se ofrecen y soportan desde TI y en qué consisten.

El problema radica en que si no tenemos esta información:

1. Es complejo traducir lo que percibe el negocio con respecto a lo que ofrece TI.


2. Es fácil que el entrevistado no hable de todos los servicios de TI que utiliza. Disponer de un listado de servicios de TI ayuda a no dejarse nada en el tintero durante la realización de las entrevistas.

Por tanto, se hace necesario disponer de este catálogo de servicios de TI lo más fiel a la realidad posible.

Nuestra recomendación es incluir dentro del proyecto de Plan de Contingencia una revisión de los servicios de TI para poder conocer qué elementos los soportan (infraestructura, aplicaciones, etc.) y tener la habilidad de identificarlos durante las entrevistas. El uso de este catálogo reducirá el riesgo de repetir entrevistas y agilizará el proyecto con la seguridad de ser exhaustivos durante el proceso.

Como ya sabréis o habréis podido deducir de lo explicado hasta ahora, el catálogo de servicios es la herramienta que permite a los departamentos de TI categorizar de una manera ordenada cuales son los servicios de TI que se están provisionando y soportando. El catálogo de servicios de TI permite al departamento de TI describir:

1. Qué está proporcionando TI al negocio: cómo está ayudando a soportar los procesos de negocio de la organización.


2. Cómo lo está proporcionando: infraestructura, aplicaciones, personas, procesos de TI, niveles de disponibilidad y seguridad, garantías de continuidad, costes, etc.

Con esta entrada completamos el trimestre dedicado a los Planes de Contingencia. Si alguno de vosotros tiene alguna pregunta, necesita más información del tema o quiere aclarar algún concepto, por favor no dudéis en escribir vuestros comentarios o poneros en contacto con nosotros.

El próximo trimestre, hablaremos de las auditorías técnicas de seguridad o hacking éticos.

Plan de Contingencia. Aspectos a tener en cuenta

Informe de situación del CPD

Dentro del análisis de riesgos es imprescindible evaluar el conjunto de sistemas que forman parte del CPD y conocer exactamente las condiciones en que se encuentran. Para ello es conveniente realizar un estudio detallado de las condiciones que cumplen, con el objetivo de definir un conjunto de medidas correctoras, dirigidas a mejorar la seguridad física de la sala y optimizar la disponibilidad de los servicios de TI.

Como valor añadido, este análisis nos permitirá establecer recomendaciones con el objetivo de perseguir la máxima eficiencia energética de cada uno de los sistemas y así reducir el consumo energético del conjunto del CPD y, en consecuencia, los costes asociados.

De esta forma y una vez implementadas las recomendaciones resultantes, la organización habrá minimizado los riesgos que pueden afectar al CPD, aportando estabilidad y seguridad a todos los procesos de negocio.

El análisis ha de contemplar los siguientes aspectos:

• Sistema de cerramiento de la sala.
• Sistema eléctrico.
• Sistema de alimentación interrumpida.
• Sistema de climatización.
• Sistema de protección contra incendios.
• Sistema de monitorización de alarmas.
• El estado general de la sala, en cuanto a distribución, orden, limpieza, y nivel de respeto intrínseco de las condiciones de seguridad, control de accesos así como otros criterios técnicos específicos vitales en este tipo de entornos.

Manuales técnicos y “checklists funcionales”

Para que la recuperación de los servicios en el entorno de contingencia y su posterior restitución a la situación original sea un éxito, es imprescindible:

Definir cómo “levantaremos” la infraestructura que soporta los servicios de TI – equipos, bases de datos, comunicaciones, etc.- en los diferentes entornos.

Definir cómo comprobaremos que los procesos de negocio asociados a dichos servicios funcionan correctamente. Hemos de comprobar si podemos seguir haciendo pedidos, facturando, vendiendo, etc…

Para realizar el primer punto debemos definir todos aquellos manuales técnicos asociados. Manuales cuya ejecución se comprobará durante las pruebas y cuya responsabilidad de realización recae sobre el personal de TI.

Para realizar el segundo punto debemos definir todos aquellos “checklists funcionales” asociados a los procesos de negocio soportados por los servicios de TI. La responsabilidad de su realización recae sobre las diferentes unidades de negocio.

Proceso de gestión de la continuidad y disponibilidad de los servicios de TI

Una vez realizado el plan de contingencia, si queremos que sea algo vivo y útil, es fundamental establecer las bases para una gestión eficaz y eficiente, que proporcione continuidad en el tiempo al resto de trabajos realizados durante la creación del plan. Para ello, será necesario definir el proceso de gestión de la continuidad y disponibilidad de los servicios de TI.

La definición de este proceso implica, a su vez, la definición de los siguientes elementos:

• Objetivos de cada proceso.
• Actividades de cada proceso y roles y responsabilidades asociados a cada una de ellas de manera que quede claro quién hace qué dentro del proceso.
• Relaciones con el resto de procesos, principalmente gestión de incidencias, problemas, configuración y cambios.
• Las entradas del proceso definirán qué es lo que este proceso requiere de los demás.
• Las salidas del proceso definirán qué información se debe entregar al resto de procesos.
• Métricas e indicadores que describan cómo se debe medir el proceso.

Este proceso nos permitirá:

• Determinar claramente las responsabilidades dentro del ciclo de diseño, transición y operación de los servicios de TI.
• Que los servicios de TI se diseñen para alcanzar los requerimientos de disponibilidad y continuidad del negocio.
• Que se establezcan las bases para la mejora continua de los servicios de TI.
• Que se facilite la justificación del coste de las inversiones asociado a la disponibilidad y continuidad de los servicios.
• Adoptar una mentalidad proactiva.

¿Cómo hacer un Plan de Contingencia?

A medida que las organizaciones dependen más y más de la tecnología, que se ha convertido en un componente clave de la mayor parte de los procesos de negocio, la disponibilidad de los servicios de TI es imprescindible para su supervivencia. Esta disponibilidad se consigue mediante la definición e implementación de un Plan de Contingencia cuyo objetivo consiste en garantizar que se puede recuperar la infraestructura de TI que soporta dichos servicios dentro de los plazos y con el nivel de servicio acordado y necesario para el negocio.

Beneficios

1. Reducción de aquellos riesgos que, en caso de materializarse las amenazas que les originan, pueden representar pérdidas ingentes de capital, bien por facturación fallida, por reposición de los daños causados, por pérdida de oportunidad de negocio, por reclamación de clientes, por sanciones legales, etc.
2. Ahorro de tiempo y dinero al afrontar y corregir situaciones nefastas antes de que ocurran y nos obliguen a resolverlas con prisas y a cualquier precio.
3. Mejora de la imagen y revalorización de la confianza en la empresa de los accionistas, inversores, empleados, proveedores y clientes al mostrarles que se toman medidas diarias para garantizar la continuidad del negocio.

Retorno de la Inversión

La metodología para desarrollar el plan tiene como objetivo principal ayudar a la organización a garantizar que se implementan las medidas y estrategias de recuperación que el negocio realmente necesita y puede permitirse.

Es fundamental, por tanto, entender que significa para el negocio la no disponibilidad de sus sistemas y realizar las acciones y planes necesarios para evitar que ocurra. La clave para lograr esta comprensión es la calificación (la validación con el negocio) de lo que significa realmente el tiempo de inactividad y, a continuación, la cuantificación (medición) de las consecuencias para el negocio. Se trata, por tanto, de estimar el coste de mejorar la infraestructura de TI actual frente a las pérdidas por no disponibilidad.

Metodología

Básicamente, un proyecto de Plan de Contingencia consiste en:

1. Análisis de impacto en el negocio. Consiste en identificar los procesos más críticos del negocio, los servicios de TI que los soportan, determinar el impacto si uno o varios de estos servicios de TI se ven afectados total o parcialmente y definir los requerimientos de recuperación establecidos por el negocio – tiempo máximo de interrupción y máxima pérdida de datos permitida -.
2. Análisis de riesgos. Consiste en estimar el riesgo potencial al que están sometidos los sistemas de TI, evaluando el impacto asociado a la materialización de una amenaza, y definir aquellas recomendaciones o controles preventivos que permitan reducir o eliminar dicho riesgo.
3. Definición de las estrategias de recuperación. Consiste en establecer los escenarios de recuperación en función de las amenazas determinadas en el análisis de riesgos y los requerimientos de negocio definidos en el análisis de impacto. En esta fase se define el escenario tecnológico óptimo para soportar los procesos de negocio, atendiendo a las disponibilidades del servicio.
4. Desarrollo e implementación del Plan de Contingencia. Una vez definida la estrategia de recuperación, el plan debe definir y establecer aquellos procedimientos, manuales técnicos y checklists funcionales que permitan restaurar los servicios de TI (sistemas, operaciones y datos) después de una emergencia o afectación total o parcial de estos servicios. La implementación del plan consiste en la ejecución de las recomendaciones establecidas en el análisis de riesgos y el escenario tecnológico definido.
5. Prueba y mantenimiento del plan. Las pruebas del plan son esenciales para identificar las deficiencias de planificación y preparación del personal. Además, el plan debe ser un documento vivo que se actualiza periódicamente para mantenerse al día con los cambios en los sistemas de TI.

Aspectos importantes a tener en cuenta:

1. Es aconsejable, en algunos casos imprescindible, utilizar una herramienta para realizar el análisis de riesgos. En el mercado existen diversas herramientas y cada una de ellas tiene sus ventajas e incovenientes: PILAR, Meycor, Proteus, Ecija (PCN, SGSI), etc.
2. Es necesario definir los procesos de continuidad y disponibilidad de TI que permitan mantener actualizado el plan frente a los cambios continuos de la infraestructura y servicios de TI, considerando de forma especial su integración con el proceso de gestión de cambios.
3. Un punto delicado es la definición de los criterios de activación del plan. El plan debería activarse cuando la evaluación de los daños indique que se han cumplido uno o más de estos criterios.
4. Las estrategias de recuperación nos definen el escenario tecnológico que cumple con los criterios de continuidad del negocio. El desarrollo del plan de contingencia asociado puede verse aplazado hasta la implementación de dicho escenario. Esto puede conllevar una inversión económica considerable que deberá pasar, entre otras cosas, por un proceso de aprobación que se puede dilatar en el tiempo. Entre tanto, es aconsejable definir un plan provisional basado en "best effort" - intentar solucionarlo lo antes posible - que prevea qué hacer en caso de activación del plan.

Gestión de riesgos en los planes de continuidad

Proceso de gestión de riesgos de seguridad de la información ISO/IEC 27005

Mucha gente trata de determinar cuáles son los factores clave que determinan el éxito o fracaso de los planes de continuidad del negocio. Existe unanimidad en que entre ellos se encuentra la correcta gestión de riesgos.

Sin embargo, es sorprendente descubrir cómo se trata de una de las fases en la que en la mayoría de los planes, menos esfuerzo se dedica. Los motivos pueden ser varios: requiere la realización de un estudio detallado y la participación de personal especializado, es necesaria la participación activa de la dirección, etc.

¿Por qué es necesario dedicar tanto esfuerzo en esta fase? La respuesta es la de siempre: se deben tratar infinidad de posibles amenazas, con un número limitado de recursos. Y es aquí donde la gestión adecuada de riesgos juega un papel fundamental, determinando qué riesgos se deben tratar de forma prioritaria para reducir al mínimo la posibilidad de sufrir en el negocio las consecuencias de daños irreparables.

Si no se realiza una correcta gestión de los riesgos, es posible que se dediquen recursos a evitar la materialización de incidentes muy poco probables, y que en cambio no se identifiquen (y por tanto no se traten) algunos con probabilidad alta de materializarse.

Ante esta situación, se ha definido la norma ISO/IEC 27005 que trata de definir un framework para la gestión de riesgos. Cada uno de los subprocesos que lo forman, que siguen el modelo PDCA (Plan-Do-Check-Act), se encuentra ampliamente detallado en la propia norma, sirviendo como una guía de referencia para la gestión de riesgos.

A continuación se resumen estos procesos, indicando ejemplos y conceptos clave para su implementación:

• Establecer el contexto: Esta actividad establece el ámbito y el alcance de la gestión de riesgos. También se crean los criterios para evaluar, decidir el impacto, y aceptar los riesgos. Además, en este paso se debe crear la estructura organizativa que debe soportar la gestión de riesgos.

1. Es aconsejable comenzar con la gestión de riesgos enfocada en los activos que sean críticos para la organización, ya que sin tener experiencia, pretender abarcar dentro del alcance toda la organización puede ser excesivo.
2. En una reunión con la dirección, se deben establecer los criterios para los riesgos, de forma que cada uno de ellos se comprometa a respetar los resultados que se obtengan.
   

• Identificar los riesgos: este proceso identifica los activos a proteger, las amenazas existentes, los controles que se han aplicado, las vulnerabilidades actuales y las consecuencias de materializarse cada una de las amenazas.

1. Mediante la realización de entrevistas con la dirección y los empleados, se realiza un inventario de activos, imputándoles un valor, siguiendo los criterios establecidos por la fase anterior.
2. Resulta práctico analizar las descripción de amenazas comunes que aparece en la misma norma, así como "brainstorming" del personal técnico.
   

• Estimación de riesgos: se describen varias metodologías para realizar una estimación del nivel de riesgo de que una amenaza se haga realidad (ya sea a nivel cuantitativo, cualitativo o una combinación de ambos).

1. Tal y como se recomienda en la norma, es conveniente comenzar por un análisis de riesgo cualitativo, y si se considera oportuno entrar en más detalle (cuantitativo) para ciertos riesgos específicos.
   

• Evaluación de riesgos: se realiza una priorización de los riesgos a tratar, dependiendo de los resultados obtenidos en los procesos anteriores. Así se establece el plan de acción.

1. Normalmente a cada riesgo se le asigna una puntuación, en función de su probabilidad y el impacto que supondría. Así se puede realizar una clasificación que servirá para establecer qué riesgos se deben tratar primero.

• Tratamiento de riesgos: se diseñan los controles a implantar para evitar o minimizar los riesgos.

1. Se deben tener en cuenta los "daños colaterales" de implantar las medidas, ya que a menudo al implantar un control se introducen nuevas vulnerabilidades en los sistemas colindantes.
   

• Comunicación de riesgos: este proceso asegura que se produzca el flujo de información necesario para que todo implicado esté al día de la evolución de la gestión de riesgos.

1. Es aconsejable la realización de reuniones periódicas entre los diferentes implicados de la gestión de riesgos.
   

• Monitorización y revisión: mantenerse al día de la evolución de las amenazas y de las medidas implantadas para reducir o evitar riesgos.
  

1. Cada vez que se implemente un control, se deben establecer indicadores que proporcionen a la organización información sobre su correcto funcionamiento para tratar los riesgos.
   
2. Como mínimo cada dos años, se recomienda realizar auditorías tecnologías para determinar el estado y la validez de los controles implantados.
   

Tal y como se puede comprobar, la norma ISO/IEC 27005 se trata de una guía de referencia bastante completa, muy aconsejable para los implicados en el diseño de los planes de continuidad. Sin embargo, como suele suceder, cada organización deberá "personalizar" estos procesos, de forma que se integren de un modo natural en la organización.

Solamente realizando una gestión de riesgos eficiente, se podrá asegurar que el plan de continuidad responde a la realidad de la organización, y únicamente enfocándolo como un modelo de mejora contínua se conseguirá mantenerlo al día.

La importancia del "testing"

Esta tarde de casualidad, he encontrado un ranking con los 10 mayores desastres causados por servicios TIC. Algunos ya los conocía y otros la verdad es que me han sorprendido.

El número 1 de la lista es impactante: en 1983 un fallo en el sistema de detección de misiles soviético detectó por error un ataque estadounidense y estuvo a punto de desencadenar la tercera guerra mundial.

Todas ellas, sin duda se produjeron porque los sistemas no habían sido debidamente probados. Se considera que en proyectos críticos (como sin duda lo era el soviético), el 80% de su presupuesto debe ser destinado la realización de pruebas (testing).

Esta máxima, en el caso de los planes de recuperación de desastres (PRD) no debería ser menospreciada. En este sentido, nos podemos plantear la siguiente pregunta: ante un desastre, ¿de qué depende el éxito del plan de recuperación? Mi opinión es que depende de lo bien que haya sido "testeado".

Desde mi punto de vista, realizar un diseño óptimo del plan, es importante, pero sin duda lo es más la simulación periódica del mismo, para poder corregir los posibles fallos de diseño e instruir adecuadamente a las personas implicadas. La única forma de obtener suficientes garantías de éxito ante un desastre, es incluir este plan dentro de un ciclo de mejora continua.

Yo creo que sin haber realizado estas pruebas, la correcta recuperación de los sistemas, quedará en gran medida, en manos del azar.

¿Cómo realizar un BIA?

BIA son las siglas de Análisis de Impacto en el Negocio, en inglés, Business Impact Analysis.

El BIA ayuda a integrar los servicios de TI en los procesos de negocio, cuantificando el impacto que una indisponibilidad de estos servicios tendría en los mismos y determinando, para cada servicio de TI, el tiempo de recuperación necesario para que dicho impacto no pase a ser inasumible por el negocio ya sea desde un punto de vista económico, de imagen, legal, etc.

El BIA se engloba, como una de sus primeras fases, en el Plan de Continuidad de los Servicios de TI que, a su vez, forma parte del Plan de Continuidad del Negocio.

Por tanto, la organización de TI debe conocer en cuanto tiempo puede recuperar sus servicios y en cuanto tiempo necesita el negocio que sean recuperados. Estas dos variables se conocen como RTA (Recovery Time Actual) o Tiempo de Recuperación Garantizado y RTO (Recovery Time Objective) o Tiempo de Recuperación Objetivo o Deseado.

Es necesario tener en cuenta una variable más: el RPO (Recovery Point Objective) o Punto de Recuperación Objetivo o Deseado. Este valor describe la cantidad aceptable de datos que se pueden perder, medido en tiempo. Este valor, que ha de proporcionar el negocio, está estrechamente ligado a la política de backup, archiving, replicación de datos, etc. que se esté realizando.

Una vez se obtengan dichos valores para cada servicio, será el momento de diseñar las estrategias de recuperación que permitan cubrir ese gap.

¿Cómo calculamos el RTA?

1. El primer paso, por tanto, es calcular, para cada servicio, su RTA. Para ello, es condición necesaria disponer de la lista de servicios de TI que soportan los procesos de negocio de la organización.

2. El segundo paso consiste en estudiar cómo la infraestructura de TI soporta el servicio. Es decir, qué cadena de activos de TI soportan el servicio de TI. Estos activos se pueden agrupar, básicamente, en los siguientes grupos: CPD, Infraestructura WAN, infraestructura LAN, servidores, software (sistemas operativos, aplicaciones estándares, aplicaciones de negocio) y datos.

3. Para cada uno de estos grupos de activos en general y activos incluidos en particular, estudiaremos las contingencias existentes. Básicamente el tipo de contingencia (redundancias, tolerancias, contratos de mantenimiento, equipos en spare, etc) y la dependencia de la contingencia (si depende de la organización o de un tercero).

4. Por último, con estos datos, calcularemos el Tiempo de Recuperación Garantizado (RTA). El RTA del servicio lo marcará el mayor RTA de la cadena de activos que lo soporta.

¿Cómo calculamos el RTO?

Para calcular el RTO, nos reunimos con los diferentes departamentos de la organización y les preguntamos dos cosas:

1. ¿Cómo utilizan la informática?. Con esta pregunta tratamos de averiguar qué servicios de TI utilizan y cómo los utilizan.

2. ¿Qué dependencia tienen de la informática? o más concretamente ¿Cuánto tiempo consideran que, para su operativa diaria, es admisible que un servicio de TI pueda no estar disponible?. Aquí es importante matizar al entrevistado que se trata de un escenario de desastre.

Con la información obtenida de las entrevistas y el visto bueno del Comité de Dirección de la organización, podremos establecer el RTO para cada servicio de TI.

Si, para un servicio de TI determinado, el RTO obtenido es inferior al RTA calculado, no se estará cumpliendo con los requisitos del negocio y, como ya se ha comentado, deberemos diseñar un escenario futuro que nos permita eliminar esa diferencia. Ese escenario futuro tendrá que tener en cuenta la tecnología, los procesos, las personas y los proveedores (ITIL v3).

Lo más importante es que el RTA lo proporcione la organización de TI y el RTO lo proporcione el negocio. Esta clarificación de espectativas mútuas es la mejor manera de integrar los servicios de TI en los procesos de negocio. Es un error que desde TI se piense que se sabe lo que necesita el negocio sin haber intentado averiguarlo mediante una aproximación minimamente estructurada como la que se ha expuesto.