Business Impact Analysis (BIA): El primer paso en la definición de la estrategia de la Continuidad de Negocio Corporativa (Primera Parte)

Afrontar el desafío de implementar un sistema de continuidad de negocio (ISO 22301:2012 – 3.5 Business Continuity Management System: BCMS) es una tarea que se puede hacer extraordinariamente compleja si no se ha definido previamente una estrategia que permita optimizar los recursos necesarios para su implementación.

Y dentro de este contexto, la ejecución de un BIA (ISO 22301:2012, 3.8 Business Impact Analysis) o Análisis de Impacto de Negocio suele ser la piedra angular que permitirá definir dicha estrategia. Debido a que las organizaciones no cuentan con recursos infinitos para invertir en personas, procesos o tecnología orientados a la Continuidad del Negocio, se hace necesario establecer una metodología que permita comparar los procesos de negocio en base a parámetros homogéneos y objetivos, a fin de establecer las prioridades a la hora de asignar estos recursos de manera eficiente.

¿Cuáles son los objetivos que persigue un BIA?

El principal objetivo de un BIA, tal como se indicó anteriormente, es priorizar los procesos de negocio desde el punto de vista de su relevancia en cuanto a la continuidad operativa. Sin embargo, el BIA tiene otros objetivos secundarios que son dignos de destacar, y que se muestran en la Figura 1.

• Identificar componentes críticos del proceso. El BIA debe buscar descubrir y documentar todos los componentes críticos que posea el proceso que esté siendo analizado. Esta actividad comprende cuatro aspectos fundamentales:
  • Personas: Corresponden a las personas que son claves dentro de la ejecución, seguimiento y control del proceso. Estas son conocidas como personal clave, ya que su ausencia podría gatillar un incidente de continuidad del negocio.
  • Tecnología: Corresponde a aquellos sistemas que son necesarios para la ejecución, seguimiento y control del proceso. Esto además puede ser complementado con el levantamiento de los componentes a nivel de TI, seguridad y comunicaciones que soportan dichos sistemas.
  • Instalaciones: Corresponde a aquellas ubicaciones físicas donde se realizan los procesos. En el caso que los procesos sean completamente virtuales, dichas instalaciones suelen corresponder a los Datacenters.
  • Proveedores: En aquellos casos donde los procesos sean completa o parcialmente externalizados, se deben determinar los proveedores involucrados en ellos.
• Identificar temporalidades del proceso. Debido a que la continuidad del negocio corresponde a una actividad ininterrumpida en el tiempo, el BIA debe determinar aquellos momentos clave donde el proceso se ve sobrecargado o en donde la continuidad del negocio cobre mayor relevancia. Por citar un ejemplo, en un proceso de matricula para una universidad existen dos meses en el año donde dicho proceso adquiere una mayor relevancia en cuanto a la continuidad operativa.
• Determinar procedimientos de operación alternativa existentes. En organizaciones donde se ha implementado previamente parcial o totalmente un BCMS, es probable que ya existan procedimientos de continuidad operativa. Incluyo en aquellas organizaciones donde este concepto aún no esté desarrollado, los dueños de proceso podrían eventualmente tener planes definidos. En este sentido, el BIA debe recopilar y documentar los mecanismos existentes, a fin de poder considerarlos a futuro.
• Determinar el RPO y el RTO del proceso. Finalmente, el BIA debe perseguir y definir dos conceptos claves en la implementación de una estrategia de continuidad del negocio: El RPO (ISO 22301:2012, 3.44 Recovery Point Objetive) y el RTO (ISO 22301:2012, 3.45 Recovery Time Objetive). El RTO o Tiempo de Recuperación Objetivo se refiere a la cantidad de tiempo máxima permitida para recuperar un proceso posterior a una disrupción (27031:2011, 3.6 Disruption).  El RPO o Punto de Recuperación Objetivo, por su parte, se refiere a un objetivo de recuperación de datos. Este es el punto en el cual la información o los datos utilizados por el proceso deben ser restaurados posterior a una disrupción. Ambos conceptos claves deben ser definidos durante la ejecución del BIA, y ambos se definen basándose en un proceso de análisis de impacto asociado a la disrupción.

Durante las próximas entregas de este artículo, se entregarán algunos aspectos claves para construir una plantilla que les permita establecer un proceso de análisis de impacto en el negocio para cualquier organización.

¡Nos vemos en una próxima oportunidad!

Read Full Post »

Fundamentos de un DRP (Disaster Recovery Plan)

Un plan de recuperación de desastres (conocido según la ISO 27031:2011 como ICT Disaster Recovery Plan o ICT DRP) es un plan claramente definido y documentado que permite recuperar las capacidades de tecnologías de información y comunicación (Information and Communication Technologies) cuando ocurre una disrupción. (ISO 27031:2011, 3.8 ICT DRP).

La ISO 27031 (Information Technology — Security techniques — Guidelines for information and Communication Technology readiness for business Continuity) define además una disrupción como un incidente, ya sea previsible (como por ejemplo un huracán) o no previsible (como por ejemplo un corte general de energía eléctrica, un terremoto o un ataque físico o lógico a la arquitectura de ICT) que pueda causar una interrupción al curso normal de las operaciones de una organización o empresa (27031:2011, 3.6 Disruption).

El desarrollo de un plan de recuperación de desastres es una de las actividades clave dentro de la gestión de la continuidad del negocio. La gestión de la continuidad del negocio, conocida por sus siglas en inglés BCM (Business Continuity Management) es un proceso de gestión holístico que identifica los potenciales impactos que amenacen la continuidad de las actividades de negocio de una compañía, entregando un marco de trabajo que permita construir resiliencia y capacidad de respuesta efectiva que proteja los intereses de una organización de las disrupciones.

Como tal, el plan de recuperación de desastres corresponderá a una serie de actividades que permitirán al negocio reaccionar de manera efectiva y eficiente ante la ocurrencia de un incidente. Estas actividades se pueden describir en las siguientes fases, cuya relación se ilustra en la figura 1.

• Detección. Corresponde a la fase inmediatamente posterior a la ocurrencia del incidente. En líneas generales, la detección del incidente debería realizarse de forma proactiva, (como parte del proceso de gestión de eventos y monitoreo) o reactiva (a través de un proceso de gestión de incidentes).
• Activación del plan. Una vez que el incidente está declarado, se debe realizar el proceso de activación del plan de recuperación de desastres, el cual implica el desarrollo de un proceso comunicacional entre el cliente y su proveedor de servicios que permita autorizar la aplicación del plan y la posterior formalización de dicha autorización hacia los equipos del proveedor que estarán a cargo de la resolución del incidente y la recuperación de las operaciones normales del cliente. Cabe destacar que la activación de un plan de recuperación de desastres debe ser realizada siempre por parte de este último.
• Recuperación. La fase de recuperación, posterior a la activación del plan, corresponde al desarrollo de dos procesos en paralelo, que son los siguientes:
  • Plan de operación alternativo. Corresponde a las actividades orientadas a restablecer las operaciones críticas del cliente en el menor tiempo posible. En algunos casos, este proceso de operación alternativo puede suponer la reposición parcial del servicio, priorizando las funciones primordiales del negocio por sobre otras componentes del servicio secundarias.
  • Resolución del incidente que ocasionó la disrupción. En paralelo a la aplicación del plan de operación alternativo, el proveedor deberá trabajar en la resolución del incidente que causó la condición de desastre. Esto implica la detección de la causa raíz del incidente y la gestión posterior para resolverlo. Esto podría implicar ajustes de configuración, reemplazo de equipos u otras actividades que permitan establecer las condiciones necesarias para volver a la operación normal.
• Retorno a operaciones normales. Una vez que los procesos de recuperación están completos y el servicio está en condiciones de volver a operar con normalidad, se debe gatillar el proceso de vuelta atrás del plan de operación alternativo. Dependiendo de la estrategia de recuperación definida en el plan, este proceso de vuelta atrás podría ser transparente para el cliente o podría tener impacto en la continuidad de sus servicios. En ese sentido, en la fase de retorno a operaciones normales se deben definir estrategias para autorizar, programar y ejecutar este proceso de manera de minimizar el impacto que dichas actividades puedan ocasionar en la continuidad de la prestación de los servicios involucrados.

Pronto nos vemos con otro artículo sobre Continuidad del Negocio o Seguridad de la Información!

Read Full Post »

De vuelta, 5 años después

Hola!

 

Estoy de vuelta en mi blog. 5 años después que han sido 5 años de experiencia en Seguridad, Continuidad y Servicio, y en los cuales logré la certificación CISSP.

Y es la misma la que me trae de vuelta a este blog.

Atentos!

Read Full Post »