Al hilo de mis últimos trabajos en SOX, comentar que, como era de esperar, hay unos objetivos de control específicamente pensados para continuidad de los negocios y recuperación ante desastres (Business Continuity/Disaster Recovery, BC/DR)
Al contrario de lo que podría parecer, en SOX el BC/RC no es parte de la operativa crítica. Viene a ser más bien parte de la explotación de la tecnología. La operativa crítica se reserva a aquellos procesos realmente críticos que giran en torno a los procesos financieros, y que permitan realizar la revelación de infomación según requisitos: contabilidad, consolidación, finanzas, etc.
De todos modos, los procesos de BC/DR son muy importantes. No vamos ahora a entrar en lo importante que es la continuidad para que una organización cuyos procesos críticos reposan en las TI: ya sabemos que es algo obvio. Hay muchos factores para que un programa de BC/DR sea efectivo y tenga una relación coste-efectividad aceptable para la asunción de riesgos, su mitigación o su transferencia.
En este artículo he dado con seis aspectos críticos para que un programa de BC/DR sea algo verdadero, funcional y sobre todo, equilibrado.
- Understand business needs. Comprender los requisitos del negocio, y es que ya se sabe: la gestión de la seguridad tiene que ir forzosamente alineada con los requisitos del negocio.
- Know your enemies. Conozca a sus enemigos, conocer todos los posibles problemas que pueden hacer que un plan de BC/DR falle total o parcialmente es vital para diseñarlo con propiedad.
- Map your support system. Conocer la cadena de soporte es fundamental, para poder optimizarla. El BC/DR es un proceso que requiere secuenciación y ésta debe estar optimizada. Todos los engranajes deben estar perfectamente engrasados, o la cadena no funcionará.
- Get the message out, en alusión a la efectividad y la consistencia en la comunicación entre los integrantes de la organización.
- Fail your test, o las bondades de hacer pruebas, y aprender de los problemas y fallos que se produzcan. Los planes de BC/DR son como la musculatura: sólo se optimizan cuando se entrenan.
- Keep up with change, o a la necesidad imperativa y no negociable de que los cambios en la infraestructura cambien, cuando sea preciso, el programa de BC/DR. Estar al día es crucial.
Unos consejos muy sensatos, que seguramente muchos ya intuís, aplicáis o conocéis, pero que nunca está de mas recordar :)
La verdad, es que descrito, parece muy sencillo y fácil pero, en mi limitada experiencia, incluso aunque existan métricas y metolodogías al respecto, el proceso es costoso y complejo.
Sólo el primer paso, «comprender los requisitos de negocios» es ya suficientemente complejo de por sí. Quizá sea consecuencia de mi poca experiencia en el tema pero mi sensación general es que, en la mayoría de las empresas pequeñas e incluso algunas medianas, la recuperación y planificación ante desastres es un proceso largo y tedioso porque, la mayoría de las veces, ni siquiera se tienen bien claros las necesidades del negocio. En otros casos, cuando se tienen claros dichos requisitos, el tiempo necesario para planificar, documentar e implementar las medidas necesarias de contingencia son tan «elevadas» que alguien decide «improvisar» sobre la marcha.
La verdad, es que descrito, parece muy sencillo y fácil pero, en mi limitada experiencia, incluso aunque existan métricas y metolodogías al respecto, el proceso es costoso y complejo.
No sabes cuánta razón tienes :)
empresas pequeñas e incluso algunas medianas, la recuperación y planificación ante desastres es un proceso largo y tedioso porque, la mayoría de las veces, ni siquiera se tienen bien claros las necesidades del negocio
Es posible, si bien la causa principal es la escasa cultura de gestión de TI. El ordenador sigue siendo un cacharro que corre programas. Por ejemplo, un asesor fiscal, que valora y trata como oro su documentación para el fisco, muchas veces trata a su ordenador como algo secundario, no lo cuida, no lo actualiza, no se molesta en parchear, no pierde algo de tiempo analizando que es tan importante como los papeles que guarda en sus sagrados ficheros.
En las grandes empresas, el cirio suele estar ocasionado por una estructura jerárquica rígida, donde la cúpula superior no tiene un CIO o a alguien preocupado por saber qué pasa con la tecnología. Es típico ver cómo los departamentos de TI y seguridad nadan solos en la corriente, mientras que la cúpula se dedica sólo a los objetivos del negocio. Craso error.
Sea como fuere, no te falta razón. Seis pasos que se leen en seis minutos, pero que pueden tardar muchos meses en ser aplicados.
Saludos ;)
Respecto al tema, ya se está publicitando la aparición de la nueva norma BS 25999 que parece va a definir un poco mejor qué es esto de la gestión de la continuidad de negocio. Puedes ver más información en http://www.bsi-global.com/Xalter2/EntityDispatcher/Seminars/BCM/BCM.xalter
y si lo deseas, te hago llegar el último borrador de la norma.
La aparición de la BS 25999 viene motivada porque parece que para la Administración Pública Británica, garantizar la continuidad de negocio va a ser un requisito legal que cada vez tiene más sentido si caminamos hacia la e-Administración.
Imagino que tu por Basilea II también te verás muy afectado dado que la continuidad de negocio y el riesgo operacional están intimamente relacionados.
Javier,
Sobre continuidad recuerdo haber leído y referido después algo sobre ISO 27006. Si tienes el borrador de la 25999, pásamelo al correo ;) sergio [en] sahw [punto] com
El tema del riesgo operacional son palabras mayores, ya que lleva como bien dices de la mano la continuidad, por razones más que obvias, pero llevadas a su extremo. Hablamos de continuidad del 99,5% y superiores a lo largo del año, con tolerancias ante la ruptura de minutos e incluso segundos. No sólo exigidos por Basilea, sino además adoptados por cultura propia desde tiempos inmemoriales. Si hay infraestructuras donde ver un proceso de continuidad y sobre todo sus pruebas es un espectáctulo, esas son las entidades financieras :)
Lo dicho, pásame el borrador si tienes tiempo. Si has publicado en tu blog algo sobre 25999, házmelo saber.
Saludos y gracias ;)