Llegamos a ustedes gracias a:



Reportajes y análisis

7 cosas que su plan de DR de TI debería abarcar

[29/08/2017] Huracanes. Tornados. Terremotos. Incendios. Inundaciones. Ataques terroristas. Ataques cibernéticos. Sabe que cualquiera de estos podría ocurrirle a su negocio en cualquier momento. Y probablemente tiene establecido un plan de recuperación en caso de desastre (DR, por sus siglas en inglés) para proteger la información de su empresa, a sus empleados y al negocio.

¿Pero qué tan minucioso es su plan DR? ¿Cuándo fue la última vez que se actualizó y se evaluó? ¿Ha tomado en cuenta nuevas tecnologías y servicios que pueden facilitar la recuperación en caso de desastre? A continuación, encontrará siete cosas que su plan de recuperación en caso de desastre de TI debería incluir.

1. Un análisis de todas las amenazas potenciales y posibles reacciones frente a éstas

Su plan DR debería tomar en cuenta el espectro completo de "interruptores potenciales de su negocio, aconseja Phil Goodwin, director de investigación de la firma IDC, dedicada a investigar sobre la protección, disponibilidad y recuperación de datos.

Debería describir un plan de recuperación para cada posible contexto. Por ejemplo, Goodwin señala "¿Si experimenta un ataque cibernético que deshabilita los servidores en D.C., cuenta con un plan de transición para ese contexto?

Por supuesto, no todos los contextos tienen la misma probabilidad de ocurrir. Así que, trate lo mejor que pueda de anticipar qué interruptores son los más probables. Lamentablemente, los ataques cibernéticos se están volviendo "un contexto más probable en estos días, resalta Goodwin. Es por esto que podría querer otorgar mayor prioridad a los ataques cibernéticos en relación con algunos interruptores naturales en su planeamiento, explica.

2. Un análisis del impacto al negocio (BIA)

Para determinar efectivamente las prioridades de su DR, haga que cada uno de los principales sistemas de información atraviese por un "análisis de impacto al negocio (BIA, por sus siglas en inglés), recomienda Mark Testoni, presidente y CEO de SAP National Security Services, Inc..

Un BIA "identifica y evalúa los efectos potenciales (financieros, vida/seguridad, regulatorios, legal/contractual, reputación y más) de los eventos naturales y humanos en las operaciones del negocio, de acuerdo con Gartner.

"Completar un BIA para sistemas principales de la TI permitirá la identificación de prioridades y dependencias del sistema, resalta Testoni. "Esto facilita la priorización de los sistemas y contribuye al desarrollo de estrategias de recuperación y prioridades para minimizar pérdidas. El BIA examina tres objetivos de seguridad: Confidencialidad, integridad, y disponibilidad.

Testoni añade que un BIA ayuda a establecer prioridades para su recuperación en caso de desastre, continuidad del negocio, y/o continuidad de los planes de operación. "Un enfoque estándar para desarrollar un plan exhaustivo de recuperación frente a desastres es desarrollar primero la política y después conducir el BIA, afirma. Después de crear una priorización con el BIA, las estrategias de contingencia son desarrolladas y formalizadas en un plan de contingencia.

Puede encontrar plantillas de BIA y cuestionarios en línea accediendo a Ready.gov y al National Institute of Standards and Technology,entre otras fuentes.

3. Personas

Un error común que muchas organizaciones cometen en sus planes de DR es "centrarse demasiado en la tecnología y no lo suficiente en las personas y procesos, señala Goodwin. "La TI es una facilitadora. Nunca olvide que no solo está recuperando servidores y datos. Él recomienda pensar sobre cómo construir un plan de DR en el contexto de toda su organización. "¿Qué comportamientos necesitará de su comunidad de usuarios? ¿Qué necesitan ellos para continuar con sus labores después de un desastre?

Asimismo, identifique por nombre a las personas más imprescindibles que deban responder frente a una crisis, indica John Iannarelli, consultor de seguridad, orador y exmiembro de la División Cibernética del FBI. Asegúrese de contar con sus correos electrónicos y sus números telefónicos. Aclare quién será convocado a trabajar durante una crisis. Sepa a quién llamará para pedir ayuda, como a las fuerzas policiales, y si le es posible, establezca una relación con las autoridades antes de que el desastre lo golpee. También decida por adelantado quien será el encargado de hablar -en representación de su compañía- con las víctimas, clientes y empleados en caso de un desastre. "Sepa qué planea decir, cuánto planea revelar y de qué manera confortará a quienes puedan estar nerviosos respecto a continuar haciendo negocios con su compañía, añade.

4. Actualizaciones

Otro gran error cometido por las organizaciones es no actualizar sus planes de recuperación en caso de desastre después de realizar cambios en sus sistemas internos, como lo son las actualizaciones importantes de software, resalta Mark Jaggers, director de Gartner dedicado a la investigación enfocada en la infraestructura de TI. Su plan no está completo a no ser que tome en cuenta todas las tecnologías, sistemas y aplicaciones que se están usando actualmente.

Además, puede que existan nuevas tecnologías o productos que se hayan incorporado desde que elaboró su plan de DR. Los planes de DR se basan en suposiciones sobre los procesos y herramientas disponibles en el momento en el que se finalizan los planes. "Pero esas suposiciones pueden cambiar significativamente a medida que la evolución de la tecnología es más rápida que nunca, y la innovación surge de lugares poco probables, resalta Milind Kulkarni, vicepresidente de administración de productos para la compañía de resiliencia de red, Veriflow.

"Los avances en la ciencia de computación, algoritmos predictivos y la disponibilidad de una inmensa capacidad de cómputo a un nivel de precio razonable permiten el surgimiento de nuevos enfoques y soluciones que garantizan la resistencia, tiempo de actividad, disponibilidad y recuperación frente a desastres de los sistemas de TI, añade Kulkarni.

Por ejemplo, con servicios como AWS Snowball, las organizaciones pueden transferir petabytes de información del negocio a un appliance dedicado y seguro en el sitio. Una vez que la transferencia acaba, envía el appliance al centro de AWS de su preferencia, donde sus datos son transferidos hacia el interior de la nube. AWS Snowball, y otros como éste, dan a las organizaciones nuevas maneras innovadoras y asequibles de asegurar la redundancia de los datos, afirma Kulkarni -lo cual es el cimiento de cualquier plan de DR.

5. Prioridades

"Identifique lo que es más importante, recomienda Lannarelli. "No vale la pena salvar, ni es necesario proteger, absolutamente todo en su negocio. Su información propietaria, por supuesto, sí debe protegerse. Pero cualquier información que está destinada a lanzarse públicamente no es tan importante. Piense en esto como si su casa se estuviese incendiando. ¿Qué es lo que se llevaría con usted mientras escapa?

6. Simulacros regulares

"Simplemente contar con un plan de DR no es suficiente, advierte Kulkarni. "El plan necesita ser puesto a prueba con regularidad y las personas tienen que practicar los procedimientos de la misma forma en que una escuela prepara a sus alumnos para un incendio y lleva a cabo simulacros regularmente. Si no se practica con regularidad, el plan es inefectivo.

7. Una consideración sobre el DRaaS

La práctica cada vez más común de mudar las operaciones de datos a la nube ha contribuido al surgimiento de la recuperación en caso de desastre como servicio (DRaaS, por sus siglas en inglés). Estos servicios a demanda ofrecidos por proveedores como iland e IBM han hecho que la recuperación en caso de desastre sea más sencilla y económica, lo que a su vez permite que más organizaciones estén mejor preparadas para los desastres, afirma Goodwin.

Cuando esté considerando un DRaaS, pregunte al proveedor cómo pondrá a prueba y validará la recuperación de su información y flujos de trabajo, aconseja Goodwin, puesto que algunas pruebas son más amplias que otras.

No espere

El error más grande cometido por la mayoría de compañías es esperar hasta después de un ataque cibernético o desastre para decidir qué acción tomará después, señala Iannarelli. "En mis más de 20 años con el FBI, nunca he visto que despidan a alguien de una compañía a causa de una fuga de datos. Pero he visto a muchas personas ser despedidas por fallar a la hora de responder apropiadamente a una fuga.