Plan de contingencia: Sancionarán a firmas de telefonía móvil que fallen en casos de emergencia [Argentina]

Las compañías deberán presentar un plan de contingencia para situaciones como el temporal de la semana pasada. El servicio no podrá estar interrumpido más de una hora

Crédito foto: Reuters

Hace tiempo que las redes móviles de todas las compañías funcionan muy mal en la Argentina. Los problemas de comunicación son una constante para los usuarios, debido a que la modernización del parque de celulares significa mayor tráfico de datos, algo que las redes actuales no soportan.

Las dificultades con las que se enfrentan los argentinos no son pocas: por momentos parece que enviar un mensaje por WhatsApp se vuelve una proeza, lo mismo que cargar una página web o las fotos de Facebook. La saturación en determinadas zonas de la Ciudad es tal que en horarios pico es imposible enviar siquiera un SMS. En ese escenario, hasta el mejor smartphone se convierte en un objeto inútil en la mano del usuario.

Con este contexto de trasfondo, frente a una catástrofe ambiental como el violento temporal de la semana pasada (que causó 51 muertes) era de esperarse que las redes de telefonía móvil fallarían, una vez más.

Pero ante situaciones de emergencia, como puede ser una tormenta que corta el servicio energético, la comunicación vía celular se torna en una herramienta “esencial para que la población pueda comunicar su situación, al mismo tiempo que las autoridades informen y alerten a los vecinos, brinden atención e identifiquen víctimas”, sostiene la resolución publicada hoy en el Boletín Oficial.

“Las redes móviles resultan fundamentales en la minimización de pérdidas de vidas humanas, daños en infraestructuras y pérdidas económicas, tanto por facilitar la preparación de la población para afrontar situaciones de emergencia y catástrofe, como para favorecer la disminución de sus efectos y la coordinación de operaciones y equipos de emergencia”, sostiene la Secretaría de Telecomunicaciones.

En consecuencia, “y considerando los hechos acaecidos por el fenómeno climático que azotó a la Capital Federal y a La Plata y sus consecuencias en los sistemas de comunicación verificados por la autoridad de aplicación”, el Gobierno decidió “adoptar medidas tendientes a evitar situaciones de falta total o parcial de servicios de comunicaciones, máxime teniendo en cuenta la importancia que las mismas adquieren en este tipo de situaciones para la asistencia de personas”.

Entre el paquete de medidas, se insta a los prestadores de comunicaciones móviles a “asegurar el funcionamiento del servicio, incluso en situaciones de emergencia o catástrofe, admitiéndose en este último supuesto una discontinuidad máxima de una hora para restituir la normalidad del servicio”.

A los fines de dar cumplimiento a lo dispuesto, se estableció como requisitos mínimos para las empresas: “Disponer en cada uno de los sitios que conforman su infraestructura de red sistemas de respaldo de energía con autonomía mínima de 24 horas; garantizar el acceso a su personal competente a las instalaciones las 24 horas durante el transcurso de la emergencia o catástrofe; disponer de equipamiento de recambio o redundante, a efectos de garantizar la continuidad del servicio; y contar con unidades móviles de contingencia que permitan la continuidad del servicio para aquellos sitios que no puedan ser restituidos”.

Los prestadores de telefonía celular –añade la resolución- tendrán un plazo de 45 días para presentar ante la Comisión Nacional de Comunicaciones un “plan de contingencia de alcance nacional” que incluya todos los requisitos nombrados.

Además, se aclara que ante una catástrofe ambiental u otro tipo de emergencia las compañías deberán “garantizar la accesibilidad al servicio para todos sus usuarios en las zonas afectadas, independientemente del estado de su cuenta, pudiendo perseguir el cobro de llamadas con cargo superada la situación de urgencia”.

Quienes incumplan con esas obligaciones “será considerado falta gravísima”, por lo que el Gobierno podrá ejecutar las “penalidades dispuestas en la legislación aplicable”.

Fuentye: INFOBAE

6 tips de IBM para preparar el Plan de Contigencias de una empresa

Tornados, inundaciones, sismos, huracanes y cenizas volcánicas son apenas algunos de los “regalos” que la naturaleza nos brinda con frecuencia y que pueden afectar gravemente la continuidad de las operaciones de cualquier compañía. IBM resumió en 6 consejos cuales son los puntos que hay que tener previstos antes de la eventual llegada de un desastre natural.

Las contingencias climáticas y los desastres naturales son cotidianos: terremotos, huracanes, cenizas volcánicas y muchas otras circunstancias imprevistas interfieren no sólo con la vida cotidiana de las personas sino también con la actividad laboral de cualquier compañía, grande o pequeña.

Por eso, todo responsable de tecnología, o directivo general de una empresa, tiene que tener preparado -y ensayado- un plan de acción previo a cualquier pronóstico problemático.

 

Los expertos de IBM generaron una lista de chequeo con seis tips para que cualquiera pueda verificar su grado de preparación ante de una contingencia.

1) Validar el Plan de Back-up.
Hay que verificar primero que tenemos un plan de respaldo de datos e información en marcha y luego considerar si el acceso a esa data es posible desde otro ubicación geográfica. Una posibilidad que está surgiendo en los últimos tiempos es recurrir a servicios en la nube para alojar los datos claves y permitir a cualquier organización responder a cualquier condición con una mínima interrupción en los procesos.

 

2) Considerar el impacto de un desastre en los empleados.
Hace ya tiempo que hay una coincidencia: el capital humano es el elemento principal de cualquier compañía y eso debe ser considerado en cualquier plan de contingencias. Pero con una salvedad: para cada integrante de la empresa su propio elemento central es la familia. Y por lo tanto la compañía debe considerar este dato en el caso de, por ejemplo, tener que mudarse a otra locación en forma temporaria. En ese caso es posible que también tenga que movilizaslos junto a su familia, con los correspondientes gastos y problemas asociados que deberán ser previamente considerados.

 

3) Las comunicaciones.
En segundo lugar, una vez considerado el punto del recurso humano, hay que desarrollar un sistema de comunicación entre personal de la empresa. Hay que tener pensado en forma previa como y con qué medios se comunicará la compañía con sus empleados, con sus clientes, con sus socios de negocios y proveedores tras un desastre natural.

 

4) El efecto dominó.
Tal como mostró el reciente accidente de la planta nuclear en Japón, un desastre regional puede terminar en otros eventos impensados. Así, un huracán no sólo provocará vientos y lluvias sino que también puede desatar una posterior inundación lo que, a su vez, puede agravar los cortes de energía de comunicaciones y causar cortes de rutas y complicaciones en la logística y el transporte.

 

5) Planear la duración de una catástrofe.
Al momento de pensar un plan de contingencias es necesario considerar el impacto que tendrá la duración de la interrupción de la vida cotidiana. Un huracán puede pasar en dos días, una inundación puede durar una semana, y la emisión de cenizas volcánicas varios meses. Cada uno de esos eventos tendrá un impacto en forma diferente en la operación de la compañía.

 

6) Pensamiento lateral.
Aunque los directivos de la empresa tengan a punto y actualizado un plan de contingencias es necesario considerar qué pasa con los proveedores de productos y servicios. Nuestra preparación podría no servir de nada si nos encontramos con que un proveedor crítico deja de operar durante semanas. Esos elementos también deben ser considerados en un plan de recuperación de desastre.

Fuente: www.itsitio.com

Visto en solis.com.ve

ISO22301: gestión de la continuidad de negocio, un complemento muy valioso de los SGSI

Se publica la nueva norma internacional ISO 22301, una norma que ayudará a las empresas y organizaciones a mantener su actividad en caso de un incidente de seguridad.

La ISO 22301 es una norma internacional enfocada a la Continuidad de Negocio (Business Continuity Management), en adelante BCM (de sus siglas en inglés). La BCM establece un conjunto de medidas y mecanismos con el objetivo de garantizar el mantenimiento de la actividad de una empresa u organización en caso de que suceda un incidente que pueda poner en peligro dicha actividad.

Durante los atentados de las Torres Gemelas en Nueva York en septiembre de 2001, algunas empresas llegaron a desaparecer completamente o se vieron tan afectadas que tardaron meses en volver a retomar su actividad normal, puesto que sus principales activos (información, infraestructura, personas, etc.) se encontraban en su mayoría en las torres, y por otro lado, algunas empresas carecían de medidas y mecanismos para hacer frente a una situación de aquella magnitud.

Lo cierto es que no es necesario que se de un caso tan trágico como aquel para poner en peligro la actividad de una organización. ¿Qué ocurriría si se estropea el ordenador que gestiona toda la contabilidad o la red de comunicaciones deja de funcionar? ¿Durante cuánto tiempo es posible mantener la actividad en caso de un incidente? ¿Es posible recuperarse? ¿En cuánto tiempo sería posible volver a la actividad normal? Estas y otras preguntas son las que trata de responder la BCM.

La nueva norma fue publicada el 16 de mayo de 2012 por el “International Organization of Standardization” (ISO). Esta norma reemplaza a la BS 25999, elaborada por el “Bristish Standards Institution”, una norma fue publicada en dos partes, una en 2006 (BS 25999-1:2006 Parte 1, se trata de un documento orientativo que proporciona las recomendaciones prácticas para las el BCM) y otra en 2007 (BS 25999-2:2007 Parte 2, Establece los requisitos para un Sistema de Gestión de la Continuidad del BCM.

La norma BS 25999 proporcionaba una metodología y un conjunto de principios en torno a la BCM, pero la ISO 22391 va más allá, y además de lo anterior, aporta información práctica y soluciones enfocadas a la BCM ayudando a cualquier organización a prepararse para en caso de un incidente garantizar su actividad, o reduciendo el posible impacto sobre su actividad.

Los BCM están muy relacionados con los SGSI, siglas de Sistemas de Gestión de Continuidad de la Informaciónz. Ambos conceptos hacen referencia a sistemas de gestión enfocados a seguridad, pero los SGSI tienen un ámbito más amplio, dentro del cual puede estar el BCM. En cualquier caso, tanto los SGSI como los BCM, o los DRP (Planes de Recuperación de Desastres) son todos elementos muy importantes que deberían de formar parte de cualquier empresa u organización, adecuándolos a su tamaño, actividad, etc.

La Gestión de la Continuidad de Negocio es una norma de carácter preventivo, aunque en este caso, no se trata de prevenir un incidente, sino de prevenir las posibles consecuencias de un incidente y proporcionar a las organizaciones la capacidad para recuperarse ante desastres y todo tipo de incidentes de seguridad.

Desde INTECO-CERT recomendamos contar tanto con medidas de carácter preventivo para evitar que se produzca un incidente, como aquellas medidas que en caso de incidente podrán mitigar las consecuencias. En definitiva, es importante conocer y aplicar la BCM.

INTECO

¿Qué es ISO 22301?

El nombre completo de esta norma es ISO 22301:2012 Seguridad de la sociedad – Sistemas de gestión de la continuidad del negocio – Requisitos. Esta norma fue redactada por los principales especialistas en el tema y proporciona el mejor marco de referencia para gestionar la continuidad del negocio en una organización.

Relación con BS 25999-2

La ISO 22301 ha reemplazado a la 25999-2. Estas dos normas son bastante similares, pero la ISO 22301 puede ser considerada como una actualización de la BS 25999-2. Para conocer las diferencias entre ambas, por favor, consulte la infografía ISO 22301 vs. BS 25999-2.

¿Cuáles son los beneficios de la continuidad del negocio?

Si se implementa correctamente, la gestión de la continuidad del negocio disminuirá la posibilidad de ocurrencia de un incidente disruptivo y, en caso de producirse, la organización estará preparada para responder en forma adecuada y, de esa forma, reducir drásticamente el daño potencial de ese incidente.

¿Quién puede implementar esta norma?
Cualquier organización, grande o pequeña, con o sin fines de lucro, privada o pública. La norma está concebida de tal forma que es aplicable a cualquier tamaño o tipo de organización.

¿Cómo encaja la continuidad del negocio en la gestión general?
La continuidad del negocio es parte de la gestión general del riesgo en una compañía y tiene áreas superpuestas con la gestión de seguridad y tecnología de la información.




Más...

Fuente: iso27001standard.com

Continuidad del negocio TI: Cuatro tendencias críticas

La continuidad del negocio TI recibe ayuda -y también desafíos- de cuatro megatendencias tecnológicas: lo social, lo móvil, la virtualización y la nube.

En TI las fallas no son una opción. Por ello no es de sorprender que las organizaciones tengan como alta prioridad el desarrollo e implementación de planes confiables de continuidad del negocio para asegurar que los servicios TI se encuentren siempre disponibles para los usuarios internos y los clientes externos.

Pero los recientes desarrollos y tendencias tecnológicas, especialmente la virtualización de los servidores y desktops, la computación en la nube, el surgimiento de los dispositivos móviles en la fuerza laboral y las redes sociales, están teniendo impacto sobre la forma en que las empresas manejan el planeamiento y la evaluación de la continuidad del negocio TI. Gran parte del impacto es para mejor, dicen los expertos, pero estas tendencias pueden también crear nuevos desafíos para los ejecutivos de TI, seguridad de la información y gestión del riesgo.

A continuación una mirada a la forma en que estas megatendencias tecnológicas están afectando específicamente a la continuidad del negocio TI.

VirtualizaciónLa virtualización está haciendo más sencillo el planeamiento de la continuidad del negocio para los ejecutivos de TI y sus organizaciones, y esto se debe a que está ayudando a reducir el número de activos de TI, señala George Müller, vicepresidente de Planeamiento de Ventas, Cadena de Abastecimiento y TI de Imperial Sugar, empresa de Sugar Land, Texas, uno de los procesadores y comercializadores más grandes de Estados Unidos de azúcar refinada.

“Aquellos de nosotros que han estado en el mundo de TI por unos años, hemos sido testigos de la transición desde los grandes y viejos mainframes hasta los servidores cliente, las aplicaciones web y la computación en la nube”, sostiene Müller. “Durante ese tiempo, la proliferación de PC y servidores ha sido salvaje”.

Con tantos dispositivos que mantener, particularmente los servidores físicos en los centros de datos, asegurar el uptime de los sistemas se ha convertido en un gran desafío, sostiene el ejecutivo. “Con la virtualización, ahora estamos en capacidad de reducir esa huella [de servidores], lo cual significa que cuando planeamos la continuidad del negocio tenemos ahora menos dispositivos de los cuales preocuparnos”.

Más...

Fuente: www.cioperu.pe

Link relacionado: 
- 4 critical trends in IT business continuity

42% disaster recovery strategies dead or dormant

UK businesses are still ill-prepared to deal with downtime and unexpected disruption to operations, says ControlCircle, a leading UK managed services provider.

A recent survey of 100 CIOs/COOs/IT heads identified that whilst 90% had a strategy in place, only 46% had reviewed and tested their business continuity procedures in the last twelve months. 42% had either no strategy in place or were unsure when it was last tested. Over 50% of strategies were more than two years old.

In addition, more than 50% of those surveyed said it would take several hours for systems to be restored in the event of a disaster or fault. Over one third of those surveyed admitted it would take in excess of 24 hours to resume normal business operations.

“As shocking as these results are, they are consistent with our anecdotal conversations and insight into many organisations today”, said ControlCircle CEO Carmen Carey. “Most organisations see disaster recovery as a considerable expense to the business when in reality, it’s the cost of downtime that is immeasurable. Imagine how much damage you can do to your brand with three days of downtime?

Companies should be reviewing minutes versus hours as part of their strategy, especially now so much of today’s business is based online.”

ControlCircle partners with NetApp, the storage and data management solutions company, to put mission-critical failover systems in place at major UK corporations.

“Having a Disaster Recovery Service is essential for customers who are building a comprehensive cloud environment. In today’s environment, businesses demand 24/7 connectivity and companies require systems that ensure continued operational flexibility if the worse should happen,” said Pete Rawden, Partner Sales Director, UK & Ireland at NetApp. “Customers need assurance of efficient and flexible IT, so business users can work without restrictions. This is why we welcome ControlCircle bringing new services to customers in this space, based on NetApp technology.”

For further information on the survey, please contact Phillippa Chinery at ControlCircle, Phillippa.Chinery@ControlCircle.com. The survey was conducted by ControlCircle’s inside sales team, over October 2011. It asked CIOs, COOs and heads of IT departments a series of questions relating to disaster recovery strategy, including details of implementation, review and activate times.

www.controlcircle.com

Contingencia TIC vs Continuidad de negocio (INTECO)

Si bien es cierto que se van viendo avances significativos en la comprensión del, a veces, confuso mundo de la Continuidad de Negocio, todavía en ocasiones nos encontramos con que no se distinguen del todo algunos conceptos básicos. Es el caso de los Planes de Contingencia en relación con los Planes de Continuidad de Negocio (PCN).

Aquí podemos entrar en discusiones del tipo: “un Plan de Contingencia no es exactamente lo mismo que un Plan de Continuidad de Negocio” o “en realidad es un Plan de Continuidad de Negocio pero sólo para Sistemas”.

La forma más acertada de abordar el asunto, y en nuestra opinión la única que garantiza una comprensión definitiva del mismo, es considerar al Plan de Continuidad de Negocio como un Plan de Planes. Efectivamente, un buen Plan de Continuidad contendrá a su vez un cierto número de planes diferentes, como puede ser el Plan Evacuación, el Plan de Emergencia, el Plan de Gestión de Incidentes y, cómo no, un buen Plan de Contingencia de Sistemas.

En aras de una mayor claridad, podemos decir que un Plan de Contingencia de las Tecnologías de la Información y las Comunicaciones (TIC) consiste en una estrategia planificada en fases, constituida por un conjunto de recursos de respaldo, una organización de emergencia y unos procedimientos de actuación, encaminados a conseguir una restauración ordenada, progresiva y ágil de los sistemas de información que soportan la información y los procesos de negocio considerados críticos en el PCN de la compañía.

Por su parte, el Plan de Continuidad de Negocio puede ser definido como un conjunto formado por planes de actuación, planes de emergencia, planes financieros, planes de comunicación y planes de contingencias destinados a mitigar el impacto provocado por la concreción de determinados riesgos sobre la información y los procesos de negocio de una compañía.

A grandes rasgos, tres son los elementos característicos de un Plan de Continuidad de Negocio:

• - Garantiza la continuidad de los procesos ante desastres y eventualidades.

• - Es un elemento estratégico global, que se sustancia de n planes de contingencia de áreas de negocio y n planes de contingencia de las infraestructuras en las que se soporta el negocio, entre ellas los sistemas de información y las comunicaciones.

• - Tiene como objetivo dar respuesta a las situaciones que no han podido ser evitadas por las medidas de seguridad implantadas por la organización.

Por tanto, no debemos tener dudas al afirmar que el Plan de Contingencia es uno de los elementos más relevantes de un Plan de Continuidad de Negocio, y que si tenemos en cuenta la dependencia casi absoluta que las organizaciones y empresas de cualquier tipo tienen de los Sistemas de Información y de las Comunicaciones, nos daremos cuenta rápidamente de que a día de hoy es difícil dar Continuidad sin tener Contingencia de las TIC. Y decimos “difícil” y no “imposible”, pues en ocasiones podremos buscar alternativas “manuales” para aquellas actividades que en condiciones normales realizamos apoyándonos en las TIC.

En el ámbito de las normativas internacionales existentes en la actualidad, vemos también esta diferenciación entre Continuidad y Contingencia. Así, ahora mismo contamos con un estándar británico como es BS 25.999, cuya parte 2 nos permite certificar todo un Sistema de Gestión de Continuidad de Negocio, y estamos a punto de que la futura norma ISO basada en el estándar británico vea la luz. Será la esperada ISO 22.301 cuyo título en español todavía es difícil de traducir, pero que en inglés es Societal security - Preparedness and continuity management systems – Requirements.

En el campo de la contingencia de las TIC, el pasado mes de Abril se publicó el estándar internacional ISO 27.031 con el título Information technology - Security techniques - Guidelines for information and communication technology readiness for business continuity, es decir, una guía de buenas prácticas sobre la disponibilidad de las TIC para la Continuidad de Negocio.
Como vemos, Contingencia TIC y Continuidad de Negocio son elementos muy vinculados y que casi siempre irán de la mano, pero resulta conveniente no perder de vista el dicho popular de “juntos, pero no revueltos…”.

INTECO - 30/09/2011, por Manuel Díaz Sampedro



Encuesta 2011 sobre Preparación ante Desastres en las PyMEs

La Encuesta 2011 de Symantec sobre Preparación ante Desastres en las PyMEs evaluó las actitudes y prácticas de pequeñas y medianas empresas y de sus clientes sobre su preparación frente a desastres. Los resultados muestran que, a pesar de que las PyMEs están en riesgo, no ven la preparación ante desastres como una prioridad a menos que sufran un incidente o pérdida de información, por lo que es importante que tomen acción antes de que sea tarde



Hallazgos clave:El estudio se realizó a nivel global e incluyó a más de 1,840 encuestados de 23 países entre los que se encuentran Argentina, Brasil, Chile, Colombia, Costa Rica y México. En América Latina, estos son algunos de los principales hallazgos:

• Las PyMEs todavía no toman seriamente la preparación para desastres. 54 por ciento no cuenta con un plan y 14 por ciento no tiene intenciones de crear uno.
• Sin embargo, las PyMEs están en riesgo. 68 por ciento reside en regiones susceptibles a desastres y casi la mitad (47 por ciento ) sólo respalda el 60 por ciento de sus datos.
• Las PyMEs no actúan sino hasta que es demasiado tarde. Casi la mitad (46 por ciento ) de las PyMEs en la región implementaron un plan por una interrupción o pérdida de datos.
• No estar preparado puede tener un gran impacto negativo. Una interrupción en las operaciones cuesta a las PyMEs un promedio de 12,250 dólares por día si sus computadoras dejan de funcionar. 40 por ciento de los clientes cambiaron de proveedores PyMEs debido a sistemas de cómputo poco confiables

Recomendaciones de Symantec: 

• No esperar hasta que sea muy tarde: Es importante que las PyMEs no esperen hasta que ocurra un desastre para pensar en qué deberían haber hecho para proteger su información.
• Implementar una protección completa de la información: Para reducir el riesgo de perder información critica del negocio, las PyMEs deben implementar soluciones de seguridad adecuadas y copias de respaldo de los archivos importantes, tales como la información financiera y registros de los clientes.
• Involucrar a los empleados: Los empleados de las PyMEs juegan un rol clave en ayudar a prevenir los períodos de inactividad, y deberían ser instruidos en las mejores prácticas de seguridad informática y en qué hacer si la información accidentalmente se borra o no puede encontrarse en sus archivos con facilidad.
• Hacer pruebas con frecuencia: El peor momento para enterarse que los archivos críticos no habían sido resguardados en una copia de seguridad es después de que un desastre ocurre.
• Revisar su plan: Si realizar pruebas con frecuencia no es posible a causa de los recursos y la banda ancha, las PyMEs deberían al menos revisar su plan de preparación ante desastres por lo menos cada tres meses.

Descarga:

• Descargar reporte complete con hallazgos globales (en inglés)
• Ver boletín de prensa con hallazgos globales y regionales (en español)
• Infografía - ¿Están las PyMEs Preparadas para Enfrentar un Desastre?

Link relacionado:
- Estudio 2010 sobre Recuperación ante Desastres (Symantec)

El fallo de la nube de Amazon, un fiasco y un aviso a navegantes

Como ayer se preguntaba uno de los afectados, los lectores de Silicon News también se cuestionan la actuación de Amazon tras la caída el pasado domingo del servicio de cloud para empresas de la compañía.

Un rayo impactó en una estación transformadora, provocando un incendio y dejando el centro de datos de Amazon sin alimentación eléctrica. Casi mil páginas que utilizan la nube de Amazon en Europa se vieron de repente apagadas. Y así hasta hoy, que empiezan a recuperar prácticamente la totalidad el servicio.

La gran pregunta es ¿cómo pudo pasar algo así? La nube parecía muy fiable, especialmente la que cuenta con grandes nombres y planes alternativos detrás. Si falla la corriente, ¿no debería haber una alternativa a esa corriente caída para no dejar a oscuras los clientes? Los lectores de Silicon News se lo preguntan.

El 41% de los votantes de nuestra encuesta consideran que la caída es un aviso a todos aquellos que confían demasiado en las nubes de terceros y añaden que “lo vergonzoso es que Amazon no tenga un plan B”.

Para el 38%, el suceso es además “un aviso a navegantes”. Quizás las empresas han confiado demasiado en las nubes ajenas.

Únicamente el 21% de los votantes considera que no existe un problema de confianza en las nubes ajenas. El 11% recuerda que “la nube es el futuro” y un 10% asegura que un problema como el que acaba de vivir Amazon lo podría tener cualquiera.

Fuente: siliconnews.es

Índice global 2011 de recuperación de desastres, de Acronis

 

Porcentaje que utiliza TI basada en el Cloud

El Índice de recuperación de desastres de Acronis muestra cómo distintos países del mundo tienen diferentes niveles de confianza en la DR según su cultura, adopción de nueva tecnología, fe en sus procedimientos de copia de seguridad y margen de confianza de sus cuadros ejecutivos.

Así, se identificaron seis hallazgos clave:

1: La confianza en la DR empieza desde arriba; los líderes del Índice son los que cuentan con más apoyo de sus cuadros directivos.

2: La falta de inversión en herramientas y recursos reduce la confianza.

3: Los líderes del Índice son los más organizados y los que sufren menos en caso de inactividad.

4: Los que más adoptaron servidores virtuales están en cabeza del Índice; también son los que hacen copias de seguridad de sus servidores virtuales con más frecuencia.

5: El uso del Cloud casi se doblará durante 2011, pero siguen las preocupaciones.

6: Todas las empresas tienen dificultades con la copia de seguridad y DR en un entorno híbrido.

En definitiva, el éxito de cualquier solución de copia de seguridad y DR de una empresa se basa en la disponibilidad de sus sistemas y datos y en el impacto que los períodos de inactividad tienen en términos de pérdida de ingresos y de clientes, independientemente de los datos del entorno y los sistemas que en que se guarden. Para la mayoría de empresas de tamaño pequeño y mediano, el éxito de un servicio se basa en su capacidad de proporcionar facilidad de uso, unos costes asequibles y flexibilidad, así como su capacidad de implementar medidas lo bastante deprisa para tener un impacto positivo casi inmediato. Tanto los servicios en el Cloud como la virtualización, si se administran de la manera correcta, desde una única solución centralizada y fácil de usar, pueden ofrecer a las empresas la protección definitiva de copia de seguridad y recuperación de desastres, asegurando que la continuidad de la actividad empresarial sea más fácil de gestionar.

Download

 

Estudio 2010 sobre Recuperación ante Desastres (Symantec)

En su sexto año, el Estudio 2010 sobre Recuperación ante Desastres es auspiciado por Symantec para destacar las tendencias empresariales relacionadas con la planificación y la preparación de la recuperación ante desastres a nivel mundial.

Se encuestaron a más de 1,700 administradores de TI de grandes organizaciones de 18 países incluidos Estados Unidos, Canadá, Argentina, Brasil, Chile, Colombia y México.

Principales aspectos del Estudio:

El estudio destaca que en América Latina solo se realiza una copia de seguridad periódica de un tercio – 32 por ciento – de los datos en sistemas virtuales y que sólo uno de cada cuatro encuestados utiliza tecnologías de replicación y tolerancia a fallos para proteger los entornos virtuales.

Herramientas inadecuadas, seguridad y control. El empleo de múltiples herramientas para gestionar y proteger aplicaciones y datos en entornos virtuales causa grandes dificultades a los administradores de los centros de datos. .

Las limitaciones de recursos y de almacenamiento obstaculizan las copias de seguridad. En América Latina, los encuestados afirman que solo el 51 por ciento de las copias de seguridad se lleva a cabo sólo de forma semanal o incluso con una frecuencia menor, en vez de hacerlo diariamente (esto es menor al promedio global de 82 por ciento).

Espacio de tiempo entre inactividad de los equipos y la recuperación de la información. El estudio mostró que el tiempo necesario para recuperarse tras un período de inactividad es el doble de lo que los encuestados perciben.

Principales motivos de inactividad de los equipos. Cuando se les preguntó a los participantes en América Latina y otras regiones por las causas que hicieron que sus organizaciones sufrieran de inactividad en sus equipos a lo largo de los últimos cinco años, los encuestados informaron que se produjeron, principalmente, por la actualización de los sistemas, por cortes y fallos de suministro eléctrico y por ciberataques.

Recomendaciones y Mejores Prácticas:

Asegúrese de que los datos y las aplicaciones de sistemas críticos se traten de la misma forma en los diversos entornos (virtuales, físicos y en la nube) en lo que se refiere a la valoración y a la planificación de recuperación ante desastres.

Utilice herramientas integradas para gestionar entornos virtuales, físicos y en la nube para ahorrar tiempo, costos de formación y para mejorar la automatización de los procesos.

Adopte métodos de copias de seguridad y deduplicación de bajo impacto para garantizar que se realizan las copias de seguridad de forma eficiente y que se replican los datos fuera de las instalaciones de sistemas críticos.

Priorice las actividades y las herramientas de planificación que automatizan y realizan procesos que minimizan la inactividad de los equipos durante las actualizaciones de los sistemas.

Implemente soluciones para detectar problemas, reducir el tiempo de inactividad y recuperar información con más rapidez para cumplir mejor con las expectativas.

Las organizaciones deberán de implementar tecnologías y procesos básicos que protejan en caso de un corte de energía, y no tomar atajos que puedan tener consecuencias desastrosas.

Descargar el Estudio 2010 sobre Recuperación ante Desastres (PDF en inglés)

Results and Analysis from the 2010 Disaster Recovery Survey - Webcast

Checklist para implementación de la norma BS 25999-2 Continuidad del negocio

¿Su gerencia le ha asignado la tarea de implementar la continuidad del negocio pero usted no sabe muy bien cómo hacerlo? Aunque no se trata de una tarea sencilla, puede utilizar la metodología de la norma BS 25999-2 para facilitar las cosas. 

Los siguientes son los pasos principales que necesita seguir para implementar esta norma:

1. Obtener el apoyo de la dirección

Si bien no es un paso obligatorio de la norma BS 25999-2, sí se trata de un paso crucial al inicio: si la dirección no comprende los beneficios de la continuidad del negocio y no se compromete con el proyecto, lo más probable es que su proyecto fracase.

2. Tomarlo como un proyecto

La creación de su sistema de gestión de la continuidad del negocio (SGCN) le demandará bastante tiempo y recursos ya que debe definir claramente qué se necesita hacer, dentro de qué plazos y cuáles son las funciones en la implementación del proyecto. En otras palabras, debe aplicar métodos de gestión de proyectos.

3. Definir objetivos y alcance; redactar una Política de GCN

Debe definir qué es lo que usted desea lograr con el SGCN; es decir, cumplir, disminuir el nivel de riesgo, requisitos de sus clientes o socios, etc. También debe definir qué incluirá en su SGCN, si a toda la organización o solamente a una parte. Por ejemplo, puede decidir que incluirá sólo el centro de datos si usted suministra servicios de alojamiento a sus clientes. Todo esto tiene que estar documentado en la Política de GCN.

4. Definir las funciones y las responsabilidades para el SGCN

Como el SGCN se convertirá en una actividad permanente en su organización, es necesario asignar responsabilidades precisas, especialmente para el “promotor” del SGCN (alguien que sea responsable por el SGCN pero que no esté involucrado en las actividades diarias del mismo) y para el “coordinador de GCN”, “gerente de GCN” o similar (una o más personas con tareas activas relacionadas con el SGCN). Lo mejor es documentar estas funciones y responsabilidades en su Política de GCN.

5. Implementar procedimientos obligatorios

La norma BS 25999-2 requiere que se implementen los siguientes cuatro procedimientos obligatorios: control de documentos y registros, auditoría interna, medidas preventivas y correctivas. Estos procedimientos son, en realidad, la base de su sistema de gestión, igual que con las normas ISO 27001 o ISO 9001.

6. Realizar un análisis de impactos en el negocio y evaluación de riesgos

Mediante el análisis de impactos en el negocio usted debe identificar las actividades críticas, su período máximo tolerable de interrupción, sus dependencias (incluidas las dependencias con proveedores y socios externos) y debe establecer objetivos de tiempo de recuperación.

Al realizar la evaluación de riesgos encontrará realmente cuáles pueden ser las causas de interrupción de sus actividades críticas; pueden ser naturales pero también puede tratarse de actividades realizadas por personas (ya sea en forma maliciosa o accidental). También tendrá que llevar a cabo el tratamiento de riesgos, que implica que debe decidir cómo disminuir la posibilidad de que algo funcione mal. Desafortunadamente, la evaluación y el tratamiento de riesgos no están muy bien definidos en esta norma; por lo tanto, podría consultar la norma ISO 27001, que los describe mucho más detalladamente.

7. Determinar la estrategia de continuidad del negocio

Antes de continuar con la redacción de planes de continuidad del negocio, en realidad debe determinar qué recursos necesitará para retomar sus actividades críticas: qué empleados, ubicaciones, datos, hardware, software, proveedores, socios externos, etc.

La estrategia de continuidad del negocio no sólo debe determinar lo que usted necesita, sino también cómo hará para asegurar esos recursos.

8. Desarrollar planes de gestión de incidentes y planes de continuidad del negocio

El objetivo de los planes de gestión de incidentes es describir cómo se responderá directamente ante la ocurrencia de un incidente (por ej., incendio, terremoto, amenaza de bomba, corte de electricidad, etc.) para evitar que se agrande y para intentar disminuir sus efectos directos.

Por otro lado, el objetivo de los planes de continuidad del negocio es describir cómo se recuperarán las actividades críticas, cómo se harán funcionar conjuntamente todos los recursos que se han preparado. Esto quiere decir que es necesario detallar quién hará qué cosa, en qué plazo, utilizando qué datos y tecnología, para poner nuevamente a su organización en funcionamiento.

Todos esto planes tienen ser redactados detalladamente porque deben ser ejecutados aún en el caso que los principales empleados no se encuentren disponibles; por lo tanto, es necesario redactarlos de tal forma que otra persona pueda ejecutarlos.

9. Capacitación y concienciación

Necesita definir el nivel de competencias necesario para la ejecución de los planes de continuidad del negocio ante el caso de una interrupción y, luego, debe capacitar a todo el personal (tanto empleados como socios externos) para llegar a este nivel de competencias.

Sin embargo, esto no es suficiente. También debe explicarle a su personal por qué es necesaria la GCN. Aceptémoslo, sus planes de continuidad del negocio se utilizarán, con suerte, una única vez; por lo tanto, la mayoría de las personas lo consideran una pérdida de tiempo. Por eso, debe explicarles por qué debe existir esta planificación. (Consultar Cómo abordar a quienes no creen en la GCN)

10. Ensayo de GCN

Si piensa que ha redactado los planes de manera perfecta, probablemente se equivoque. Es casi imposible redactar un plan sin errores en el primer intento. Por eso resulta obligatorio ensayar parte del SGCN; debe verificar sus planes en una situación que, más o menos, se asemeje a una interrupción real. Solamente allí podrá determinar qué planificó correctamente y qué no.

11. Mantenimiento y revisión del SGCN

Otra forma de mantener actualizado su SGCN es definiendo intervalos en los que revisará sus planes de continuidad del negocio, pero también otras cuestiones (por ej., contratos con proveedores y socios externos, capacitación y concienciación, etc.). Existe toda clase de cambios en el entorno que amenazan con hacer obsoleta su documentación: es suficiente que un empleado abandone la empresa para tener un número telefónico inservible en un plan si esa persona cumplía una función en el SGCN.

S i se produjo un incidente real, también es obligatorio realizar revisiones después de ocurrido el mismo para ver cómo reaccionó la organización, si siguió los planes o no.

12. Auditoría interna

El objetivo de la auditoría interna es averiguar si hay algo que se está haciendo mal, de manera objetiva. El auditor debe ser una persona que pueda descubrir si algo se hace mal dentro de su SGCN para poder corregirlo. Si se realiza correctamente, la auditoría interna puede ser una de las mejores formas para mejorar su SGCN. (Leer Dilemas con los auditores internos de las normas ISO 27001 y BS 25999-2)

13. Revisión por parte de la dirección

Como se mencionó anteriormente, es muy importante que la dirección se involucre en el proyecto. La revisión por parte de la dirección está diseñada justamente para eso. La norma requiere que la dirección examine todos los hechos importantes sobre la GCN y que decida si ha cumplido su objetivo. Una vez que está hecha, la dirección debe decidir qué mejoras se deben implementar.

14. Medidas preventivas y correctivas

Lo mejor sería evitar que se produzcan errores (o, en términos de BS 25999-2, las “no conformidades”); para esto es que se utilizan las medidas preventivas, representan una forma sistemática de corregir las cosas antes de que generen problemas. Similares a las medidas preventivas, también hay medidas correctivas que solucionan los problemas que ya se han producido.

Ahora la pregunta es ¿por qué usaría usted la norma BS 25999-2? Aunque (todavía) no es una norma internacional, es la norma más reconocida a nivel mundial para la continuidad del negocio. Los pasos mencionados arriba están diseñados por los mejores especialistas en este tema. Por eso, si desea implementar las prácticas más aceptadas para continuidad del negocio, no busque más.

Aquí puede descargar el diagrama del proceso de implementación de la norma BS 25999-2 que muestra todos estos pasos junto con la documentación requerida (requiere inscripción).



 


Fuente blog.iso27001standard.com - 'By 'Dejan Kosutic on November 16, 2010

Guía práctica para PYMES: cómo implamentar un Plan de Continuidad de Negocio (INTECO - Deloitte)

Edición: Octubre 2010 (España)

INTECO y Deloitte presentan conjuntamente la guía, y la distribuyen en el seno del ENISE en los stands que ambas instituciones tienen en el Encuentro Internacional de la Seguridad de la Información (León, 26 a 28 de octubre de 2010). ¿Están las empresas preparadas para superar una contingencia grave? ¿Disponen las pymes españolas de planes donde se documente las acciones a adoptar en caso de, por ejemplo, caídas de luz, inundaciones, incendios o robos?

La competitividad creciente entre las organizaciones, las demandas exigentes del mercado, y un entorno regulatorio cada vez más estricto son factores que fuerzan a las empresas a demostrar su resistencia ante la incidencia de algún tipo de catástrofe.

Por ello, cada vez más se hace necesario por parte de las organizaciones el establecimiento de medidas técnicas, organizativas y procedimentales que garanticen la continuidad de las actividades o procesos de negocio en caso de tener que afrontar una situación de este tipo.

Esta guía establece un marco de actuación para las organizaciones que deseen abordar los principios y prácticas de continuidad de negocio de una forma integral: desde el momento inicial en el que se reconoce la necesidad de desarrollar un programa o estrategia de continuidad, hasta su mantenimiento y actualización constante.

Descarga (PDF - ES 80 Pag. )

Índice
1. ¿A quién va dirigida?
2. ¿Por qué es importante la continuidad?
3. ¿Cuál es la utilidad de esta guía?
4. ¿Por qué es necesario adoptar un plan de Continuidad de Negocio?
5. ¿Por dónde empezar?
6. Estructura de la guía
7. Fase I: Diseño del plan y establecimiento de la política de Continuidad de Negocio
8. Fase II: Conocimiento de los procesos de negocio de la organización y análisis de riesgos
9. Fase III: Medidas preventivas
10. Fase IV: Estrategias de recuperación
11. Fase V: Desarrollo e implantación del plan
12. Fase VI: Mantenimiento del plan
13. ¿Qué debo recordar?
14. Más información
15. Anexo I: Glosario

Curso: Gestión y tratamiento de incidentes de seguridad de la información (Material)

Gestión y tratamiento de incidentes de seguridad de la información

Organizado por Arcert

Links de Descarga Actualizados

Parte 1

Objetivos: Introducir en la gestión y el tratamiento de los incidentes de seguridad de la información y los procesos asociados.

Contenido:

• Definición de incidente
• Grupos de respuesta a incidentes
• Política y procedimientos de tratamiento incidentes
• Tratamiento de incidentes de seguridad
• Preparación y Detección
• Notificación y Priorización del incidente
• Manejo de información con terceras partes
• Análisis preliminar
• Recolección de evidencia
• Contención, respuesta y recupero
• Actividades posteriores al incidente
• Documentación de un incidente

El material puede descargarse Aquí

Parte 2:
Objetivos: Introducir en el uso de mecanismos y procedimientos adecuados para la detección de incidentes, análisis de logs, monitoreo de red y análisis preliminar relacionado con incidentes de seguridad de la información.

Contenido:

• Detección de Incidentes
• Monitoreo de Redes
  - Datos estadísticos
  - Datos de sesiones
  - Tráfico Completo
• Sistemas de detección de Intrusos
• Análisis de logs
• Correlación de eventos
• Volatibilidad de la evidencia

El material puede descargarse Aquí.

Parte 3
Objetivos: Introducir en el uso de mecanismos, herramientas y procedimientos adecuados para la recolección y el análisis de información relacionada con incidentes de seguridad informática.

Contenido:

• Formas de recolección, modificación de la evidencia y decisiones a tomar
• Recolección de información en vivo
• Duplicación y resguardo de medios de almacenamiento
• Análisis de imágenes de discos
  - Linux y Windows
  - Recuperación de datos
  - Líneas de tiempo
  - Identificación de archivos conocidos
  - Búsqueda de cadenas de texto
  - Revisión de logs
  - Análisis de correo electrónico (encabezados), sitios web visitados, etc.
• Análisis de RAM
  - Búsqueda de cadenas
  - Búsqueda de patrones
  - Herramientas
• Análisis online
  - Herramientas
  - Detección de procesos ocultos
  - Análisis de tráfico de red
  - Reporte de hallazgos

Material de la parte3:
Versión PDF - en 1 Transparencia x Hoja
Versión PDF - en 6 Transparencia x Hoja

10 Lecciones aprendidas en diferentes implementaciones de un Plan de Recuperación en caso de Desastres (DRP)

Como sucede en casi todos los temas, en la implementación y seguimiento de un plan de recuperación en caso de desastres (DRP) existen aspectos que los manuales no mencionan y que de no tomarse en cuenta, pueden provocar riesgosas fallas al momento de necesitar ponerlo en práctica.

¿Puede alguien presumir que ha llevado a la práctica un Plan de Recuperación en Caso de Desastres (DRP) sin contratiempos? Lo más probable es que no. La diferencia es que algunas empresas han tenido problemas menores y otras han sufrido fallas importantes que les han impedido, incluso, arrancar el plan en el momento necesario.
Involucrados en este tipo de fallas mayores hay muchos: instituciones bancarias, empresas manufactureras, retails, farmacéuticas, y no de importancia menor, en muchos casos se trata de los principales jugadores de estos sectores.
Por supuesto, casi ninguna empresa está dispuesta a exponer públicamente que falló en su DRP y menos a hablar de cuáles fueron en concreto los errores cometidos. Pero se sabe de casos como el de una gran compañía nacional de manufactura de bebidas que no documento punto a punto los procesos de su plan de contingencia y cuando se enfrentó a un siniestro, simplemente no lo pudo echar a andar.
En este caso en particular, el problema fue que los procesos estaban descritos en forma muy general, el DRP decía, por ejemplo, levantar el sistema X, pero no se documentó cómo hacer eso paso a paso. Así que en plena contingencia, el equipo de respuesta enfrentó serias dificultades para llevar el manual a la práctica.

Otro caso fue el de un conocido retail, que por falta de experiencia en su equipo interno tardó más de cinco años en implementar su DRP. Finalmente la empresa se dio cuenta que necesita asesoría externa, pero para entonces ya habían arriesgado bastante tiempo la operación del negocio.

La lista de ejemplos puede seguir, pero en resumen y como una forma de ofrecer una guía a los lectores de b:Secure respecto a lo que no dicen los manuales de DRP, he aquí lo que puede bautizarse como las lecciones aprendidas en diferentes implementaciones de un plan de contingencia.

1.- Cada quien debe poner su parte. Lo primero que se debe tener muy en cuenta en esto de desarrollar e implementar un DRP es sí se está en sincronía con la alta directiva respecto a este tema y si se van a cubrir de forma adecuada las necesidades del negocio.
“Primero se debe definir qué entienden los responsables de la estrategia de contingencia por DRP y qué entienden los directivos de la organización. Ese es el primero dolor de cabeza, porque, muchas veces, se tiene la equivocada idea de que esto es un problema exclusivo del área de informática”, comenta Méndez.
Pero para que informática sepa cuál pie pone primero para levantarse, continúa, la alta directiva debe ayudarle a definir qué sustenta a la empresa. “Si informática no sabe cual es el corazón del negocio, no sabrá qué levantar primero. Los directivos deben ayudarle a determinar cuál es la infraestructura y los procesos que requieren recuperarse primero y en qué tiempo, para minimizar las pérdidas. Informática lo que pone es el cómo se hace la recuperación.

2.- Hay que darle al plan “el mantenimiento adecuado”. Muchas organizaciones, asegura Alejandro Cerezo, de Integridata, se deciden a implementar un DRP por acatar la recomendación de los auditores (60%) o porque el corporativo se los pide (30%), pero pocas lo hacen por convicción propia (10%). “De manera que la mayoría se conforma con implementarlo y no lo actualiza, dicen ya cumplí, no le dan el mantenimiento necesario y luego vienen los fracasos”.
Ese mantenimiento del que habla Cerezo involucra, entre otras cosas, probar constantemente el DRP, para ver si algo falló en el desarrollo metodológico.
Puede ser que el personal no conozca bien la infraestructura del negocio, a la mejor la plataforma de recuperación no es la adecuada o los procedimientos técnicos no están bien desarrollados, y todo eso se mide en las pruebas posteriores a la implementación.
¿Cuántas pruebas deben hacerse y cada cuándo? Lo que recomienda el estándar BS25999 (que plantea el uso de sistemas de administración de la continuidad del negocio) es probar el DRP cada seis meses y luego proceder a las actualizaciones pertinentes, para asegurar su vigencia.
En la primera prueba, realizada después de la implementación, se logra alcanzar apenas entre 45 y 50% de efectividad en el plan. “Eso es un rango normal, no hay por qué preocuparse. La experiencia dicta que es hasta la cuarta o quinta evaluación cuando el DRP está ya listo, cuando la empresa puede salir airosa de una contingencia ”, asegura Cerezo.
Desafortunadamente, ni siquiera las empresas que implementan su DRP plenamente convencidos de su importancia le dan a éste el seguimiento adecuado. De hecho, muchas no pasan de la segunda prueba, así que de 10% que desarrolla un DRP por convicción, sólo 7% puede salir adelante de un evento catastrófico.
“De las empresas que estaban en las torres gemelas sólo 20 o 25% se recuperaro de ese evento, porque tenían un plan, pero no le dieron seguimiento, ni mantenimiento y nunca probaron con la frecuencia requerida, si no cada dos años y eso no es funcional”, enfatiza Cerezo.
Y agrega: “no se vale hacer la prueba dos años después, porque la gente ambia, la infraestructura cambia, los cambios en tecnología son muy rápidos y también en la operación del negocio, y si no le das mantenimiento al plan, ya no te puedes recuperar”, subraya el consultor.

3.- Contar con todo lo necesario para cubrirse bien las espaldas. El siguiente reto es la disponibilidad tecnológica y de elementos críticos: tener, por ejemplo, los suficientes respaldos para recuperar toda la información sensible.
“En el mundo de los respaldos hay una parte olvidada: no todos los usuarios tienen un plan para respaldar su información, por eso conviene elaborar una política en la cual se asiente que todo el personal debe almacenar en un servidor y no sólo en su computadora. Claro que para esto se requiere definir qué se respalda y cada cuándo”, puntualiza Méndez.
Además, cuando hablas de un proceso de recuperación, hay una parte importante que es la inversión en los equipos para el recovery. “A la dirección todo este gasto le parece excesivo, por ende se pronuncia por buscar esquemas baratos o asignan el presupuesto para implementar el plan, pero tres meses después lo retiran, eso provoca que el DRP se quede empantanado”, comenta Cerezo. Viene entonces la lección número…..

4.- Hay que saber vender el DRP. En la mayoría de las empresas no se consigue el presupuesto necesario para preparar la recuperación de un desastre, porque el personal de IT o los encargados de esto no saben cómo vender el plan a la dirección general.
La alternativa más adecuada para esto es hacer un análisis de impacto, es decir, hay que dejarle bien claro a la alta dirección, cuánto pierde la organización por estar fuera de servicio en las horas más críticas para el negocio. Por ejemplo, si la empresa es una comercializadora, habrá que definir cuando perdería por no poder llevar sus productos a ciertas regiones.
Pero en lugar de hacer esto, se empieza al revés, generalmente el área de sistemas pretende implementar el plan y conseguir los recursos necesarios sin justificar cuánto pierde la organización si no puede recuperarse de forma efectiva y en el tiempo justo de un incidente.

5.- Integrar un buen equipo de respuesta. Un plan de recuperación debe involucrar no sólo al responsable de la recuperación, si no a un grupo compuesto por: un equipo directivo (encargado de hacer la declaración formal de contingencia), otro de respuesta (enfocado a evaluar todo el evento y determinar en qué momento “sube” la decisión de declarar la contingencia), uno más con la función de “ejecutar” el plan en la parte técnica y un grupo de usuarios, cuya misión es operar las aplicaciones y darle continuidad al negocio.
Las lecciones específicas aprendidas en esta parte, durante ciertas implementaciones, indican, de acuerdo a los entrevistados, que a veces el DRP o las pruebas fallan, porque al responsable del plan lo saturan con otras cosas y no le permiten dedicarle a esto el tiempo suficiente.
En la mayoría de las empresas, reconoce Cerezo, ya existe un responsable de recuperación, encargado de coordinar toda la parte del recovery. Generalmente este personaje está integrado al área de sistemas. Pero muchas veces cumple otras funciones que le impiden concentrarse en el DRP.

6.- Tener todo documentado a detalle. Como se mencionó en el caso de la empresa de manufactura de bebidas, no tener bien documentados los procesos puede causar severos problemas.
Los procedimientos para lograr la recuperación después de un desastre deben escribirse a detalle e involucrar toda la parte técnica en cuanto a bases de datos, aplicaciones, sistemas operativos, pero también en lo relativo a procesos de identificación y declaración de contingencia, entre otros.

7.- Si no se actualiza el inventario de IT, el plan no sirve. El DRP necesita estar bien actualizado, esto implica: tener un inventario al día de todos los recursos de IT, porque a veces pasa que se cambia una PC o los sistemas operativos, pero no se hacen las actualizaciones pertinentes para saber con que infraestructura se cuenta y al menos los cambios en los equipos importantes para la operación del negocio, deben estar reflejados en el inventario. “Esa es la otra parte de la vida real que a veces resulta complicada”, admite Guadarrama.

8.- No se valen los ensayos de laboratorio. Claro que hacer las pruebas cada seis meses no es nada sencillo. “Hay que ver cómo se van a realizar, si se va a probar el plan de principio a fin y qué involucra hacerlo de esta forma”, comenta Manuel Méndez, oficial de seguridad de la información de una importante compañía de transporte.
Al respecto, Luis Guadarrama, consultor independiente y experto en el tema de DRP, asegura que las pruebas se vuelven un verdadero problema, porque requieren una buena cantidad de recursos, tanto monetarios como de tiempo y compromiso por parte del personal, sobre todo cuando se toma la acertada decisión de ejecutarlas tratando de acercarse lo más posible a la realidad.
Esa es precisamente otra de las lecciones aprendidas en la implementación del DRP, mientras más real sea el ambiente y la escena de prueba, mejor se ubicarán las posibles fallas del plan y los flancos descubiertos.
Sin embargo, lo cierto es que muchas empresas hacen pruebas de escritorio, hay ensayos de un DRP hechos en una sala de juntas. El equipo se reúne y actúa toda la prueba, alguien declara la contingencia y luego cada miembro del equipo va diciendo lo que le toca hacer, pero todo simulado en el escritorio. Eso no es una prueba real.
Evidentemente, tampoco se puede bajar el swicth, pero se deben encontrar un punto medio, entre la prueba de escritorio y esto. “No se puede tirar toda la infraestructura, pero si se debe prever la descompostura de un servidor crítico y dejarlo fuera o tirar funciones críticas”, recomienda Guadarrama.
Para convencer a la directiva de la necesidad de proceder así, habrá que plantear que en efecto la prueba puede tener cierto costo, pero esto se debe balancear contra el impacto de no estar preparados.

9.- La importancia del factor psicológico. Con todo y por muy real que sean las pruebas, existen factores imposibles de evaluar hasta que realmente sucede un incidente, “cuando se presenta un siniestro tienes encima a todos los usuarios; está, además, la presión de los ejecutivos; de la carencia de sistema y la necesidad de levantarlo lo más rápido posible para no afectar los procesos del negocio, todo eso involucra una respuesta psicológica por parte de los involucrados en la respuesta que es difícil de simular”, subraya Guadarrama.
Lo forma de responder a este hecho es extrapolar los resultados de la prueba e intentar deducir cómo se comportarían los principales involucrados.

10.- Se vale pedir ayuda. El caso del retail, mencionado al principio de este artículo, resulta bastante ilustrativo para dejar claro que a veces el equipo interno requiere la ayuda de algún especialista externo.
Pero no sólo eso, también es posible que se requiera el soporte de partners o socios de negocio para implementar y llevar a la práctica un DRP. Involucrarlos no sólo es valido si no acertado.

Fuente www.bsecure.com.mx