Feeds:
Entradas
Comentarios

Determinando el RTO – La clave para priorizar los procesos de negocio

Sin lugar a duda, el objetivo principal que persigue un BIA es entregar una manera objetiva de priorizar los procesos de una organización de cara a la continuidad de negocio. Y dicha priorización quedará definida en gran medida por dos parámetros relevantes, los cuales son los siguientes:

  • RTO (Recovery Time Objective). Corresponde al máximo tiempo admitido para resumir una actividad, recuperar recursos, o proveer servicios luego de que ocurre un evento disruptivo. Este período de tiempo objetivo debe ser lo suficientemente corto para asegurar que el impacto negativo de dicha disrupción sea inadmisible. (ISO 27031:2011, 3.45 Recovery Time Objective, RTO).
  • RPO (Recovery Point Obective). Corresponde a un objetivo de recuperación de datos. Es el punto en el cual la información o datos utilizados por una actividad deben ser restaurados luego de que ocurre un incidente disruptivo. (ISO 27031:2011, 3.44 Recovery Point Objective, RPO).

Una de las actividades que son llevadas a cabo durante la ejecución de un BIA (Business Impact Analysis) es la determinación de el RTO del proceso analizado. Y esto se puede lograr en base a la determinación del impacto que una disrupción produce en el negocio a lo largo del tiempo.

En este sentido, la primera tarea a la hora de diseñar este proceso es definir los diversos tipos de impacto que una disrupción puede causar en el negocio. Este punto dependerá de la naturaleza que tiene el negocio: posiblemente los factores que más se pueden ver impactados en una empresa del rubro financiero (como un banco) serán muy distintos a los que puedan afectar a una empresa de la educación o el gobierno. A continuación, se indican algunos de los principales tipos de impacto que pueden ser utilizados en un BIA:

  • Montos involucrados. Uno de los principales impactos que produce una disrupción en un negocio es la pérdida monetaria. Y dicha pérdida puede ser de manera directa (costo asociado a la recuperación de la operación, en horas hombre, equipamientos y otros) o indirecta (dinero no percibido por la interrupción de las actividades del negocio). El mejor ejemplo para utilizar para describir este impacto es el típico escenario de sin sistema en las cajas de un supermercado: Si las cajas quedan sin sistema, se deberá invertir en un equipo de personas que recuperen los sistemas, pero además los clientes abandonarán el supermercado sin terminar sus compras hasta que el sistema vuelva, lo cual también se transforma en pérdida. Para determinar estas pérdidas indirectas, se puede recurrir a datos estadísticos que permitan proyectar el ingreso generado por el proceso, dependiendo de la hora y fecha en la cual dicha disrupción ocurra.
  • Efecto en la imagen. Otro impacto que puede ocasionarse debido a una disrupción es el daño en la imagen corporativa de la compañía, el cual puede traducirse en pérdida de clientes actuales o alejamiento de potenciales clientes de esta. En este sentido, el auge de las redes sociales y los medios de denuncia masivos hacen de que dicho factor pueda transformarse en relevante a la hora de determinar un RTO.
  • Impacto normativo. En las compañías que están sujetas a entes reguladores, el impacto de una disrupción a nivel normativo puede traducirse en observaciones, sanciones e incluso restricciones para la operación de la compañía que se ve afectada por una disrupción.
  • Impacto a nivel operacional. Como bien es sabido, rara vez un proceso de negocio será totalmente independiente del resto de los procesos de la compañía. En este sentido, un proceso de disrupción que afecte un proceso de negocio puede terminar afectando otros procesos a nivel corporativo.
  • Masividad. El impacto que una interrupción de un proceso de negocio produce puede medirse en base a la cantidad de transacciones que se ven interrumpidas o la cantidad de clientes que se puede ver afectados.

Una vez que se definen los factores que serán medidos para determinar el RTO, se debe crear una matriz que permita determinar el nivel de impacto en base a una escala. A continuación, se presenta un ejemplo de ello.

Factores de Impacto (Ejemplo)

Durante la ejecución del BIA, se medirá el impacto de cada uno de los factores de impacto a lo largo del tiempo. En este punto, se deben definir las escalas de RTO posible (Menor a 1 hora, entre 1 y 2 horas, entre 2 a 6 horas, etc.) y se debe determinar cual será el impacto de la disrupción en los diversos factores. Una vez que se determina que el impacto global es inadmisible, se define el RTO. La definición de qué será considerado inadmisible se puede realizar dentro del diseño del BIA (puede ser, por ejemplo, la primera banda donde exista al menos un impacto en nivel catastrófico).

Ejemplo de cálculo de RTO.

El RTO, en conjunto con el RPO, se transforman en dos factores claves que permitirán definir cuales son los procesos más críticos del negocio de cara a la continuidad operativa. Una vez que el análisis BIA se ha realizado a todos los procesos relevantes de la organización, se puede determinar en que casos es relevante generar planes de continuidad del negocio (BCP). Esto lo abordaremos en un próximo capítulo. ¡Hasta entonces!

Identificando los componentes críticos del proceso

Uno de los principales objetivos que debe perseguir un análisis de impacto de negocio (BIA) es la identificación de los componentes críticos que cada proceso tiene, de cara a la continuidad del negocio. Es por esto que la ficha BIA debe contener sí o sí un conjunto de secciones que permitan identificar, para cada proceso analizado, los siguientes componentes:

Aspectos críticos del proceso de cara a la continuidad del negocio.
  • Personal crítico del proceso. Dentro de este ítem se deben identificar aquellas personas que son clave en la ejecución del proceso, dentro de los que destacan los siguientes:
    • Responsable del proceso y su respectivo backup.
    • Administradores funcionales y técnicos de las aplicaciones clave utilizadas por el proceso y sus respectivos backups.
    • Número de personas dedicadas a tiempo completo para la ejecución del proceso.
    • Número de personas que están dedicadas a otros procesos y que podrían ejecutar el proceso en modalidad de backup.
    • Número mínimo de personas necesarias para ejecutar el proceso con normalidad.
    • Detalle del personal crítico del proceso, indicando sus nombres, datos de contacto y función específica dentro del proceso.
  • Aplicaciones clave del proceso. En este punto, es importante determinar, en la medida de lo posible, los siguientes aspectos:
    • Aplicaciones indispensables para la ejecución del proceso (aplicaciones que de estar ausentes el proceso no funciona con normalidad)
    • Aplicaciones alternativas para la ejecución del proceso, en caso de ausencia de aplicaciones críticas
    • Aplicaciones relacionadas con la ejecución del proceso (por ejemplo, correo electrónico)
  • Relación entre las aplicaciones críticas y los servidores. Este punto está relacionado con los conceptos de mapa aplicativo o CMDB. En la medida de lo posible, un BIA debería permitir identificar los servidores críticos para la ejecución de los procesos analizados. Este punto es uno de los más complejos a la hora de realizar esta actividad, debido a que la generación de un mapa aplicativo, sobre todo en empresas grandes, puede ser un proceso extremadamente complejo.
  • Registros vitales. En caso de que los procesos requieran como entrada para su ejecución ciertos registros (ya sea físicos o virtuales), estos deben ser debidamente identificados. Además, es ideal determinar su ubicación y las políticas de respaldos asociados a dichos registros.
  • Ubicaciones de ejecución de los procesos. Para el caso de aquellos procesos que se realicen de forma física, se debe determinar las ubicaciones donde dichos procesos deben ser realizados, y se debe determinar la ubicación alternativa donde dichos procesos puedan ser realizados.
  • Proveedores involucrados. Para el caso de aquellos procesos que sean ejecutados parcial o totalmente por proveedores, se deben identificar los siguientes aspectos:
    • Nombre de los proveedores involucrados y su función dentro del proceso
    • Gestor de contrato responsable de los proveedores
    • Proveedores de backup para el proceso, en caso de que existan

La recopilación de estos componentes permitirá comprender la estructura del proceso de cara a la continuidad de negocio e identificar los puntos de falla que permitirán alimentar el proceso del RIA.

En el próximo capítulo de esta serie, les compartiré algunos tips para determinar el RPO y el RTO de un proceso, dentro del análisis BIA.

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!

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.

DRP

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

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!

Sin lugar a dudas, es una de las herramientas tecnológicas más utilizadas por empleados en todo el mundo.  El correo electrónico nos tiene ocupados gran parte del día; nos pasamos una buena parte de nuestra jornada diaria recibiendo y enviando mensajes de correo a compañeros de trabajo, proveedores y clientes en todo el mundo.

Según un estudio recientemente publicado por Radicati Group, el uso del correo electrónico va en aumento explosivo. Este año existen cerca de 4.116 millones de cuentas de correo electrónico, de las cuales 974 millones son cuentas de empresas, y para el 2018 se espera llegar a los 5.000 millones de cuentas. Por otro lado, cerca de 190 billones de correos electrónicos se envían a diario, siendo más de la mitad de ellos de carácter empresarial.

Debido a su masivo uso, el correo electrónico frecuentemente ha sido blanco de ataques informáticos. Estos ataques han ido evolucionando con el pasar del tiempo; hemos pasado de la época del famoso virus «I love U» a variantes bastante más evolucionadas y dirigidas, como lo son el phishing y otras técnicas similares que están asociadas a los conceptos de Ingeniería Social que  Kevin Mitnick viralizó y que tan increíblemente explica en su libro «The Art of Deception».

De  hecho y dentro del mismo contexto, cabe destacar que los ataques informáticos más exitosos suelen ser aquellos que se aprovechan de las prácticas poco adecuadas que tenemos en el manejo de este tipo de herramientas, y de nuestra excesiva en el diario vivir. Por lo mismo, a continuación les entrego un conjunto de buenas prácticas a ser tomadas en cuenta en cuanto al uso del correo electrónico.

1) No crea todo lo que lee…

Usted va llegando a su casa y ve a un desconocido mirando insistentemente al interior de su hogar. ¿Qué piensa usted al respecto? Probablemente, le llamará la atención de inmediato, puesto que se encuentra ante una situación anormal. ¿Por qué no actuamos de igual manera con el uso de nuestras herramientas tecnológicas? El correo electrónico es una fuente de llegada de múltiples mensajes de todo tipo, y de todas partes. Sin embargo, ¿usted abre la puerta a todo desconocido que se acerque a tocarla? Con el correo electrónico deberíamos pensar de manera similar. Por dar un ejemplo sencillo, si trabajamos en una empresa local que no tiene contacto con proveedores ni partners en el extranjero, ¿qué tan razonable es recibir un correo en inglés?  Muchas veces abrimos correos sin preguntarnos su procedencia, incluso llegando a abrir correos que vienen en un idioma distinto al cual utilizamos a diario en nuestras labores. Este fenómeno generalmente se encuentra mitigado por los motores Antispam de nuestras compañías, pero en algunas ocasiones estas herramientas dejan pasar algunos correos de fuentes desconocidas.

Por otro lado, un tipo de ataque muy frecuente a través del correo electrónico es conocido como el «Hoax». ¿A quién no le ha llegado alguna vez un correo advirtiendo sobre una herencia millonaria en Europa, un niño secuestrado en Nigeria o una oferta irresistible de teletrabajo con sueldos y comisiones atractivas?  Definitivamente, no crea en todo lo que recibe.

2) Hipervínculos engañosos

Hoy por hoy el phishing se ha transformado en uno de los ataques más difundidos a nivel mundial. Corresponde a una técnica de ingeniería social – fraude basado en la confianza –  en donde suelen colocarnos en una situación compleja (una giro no autorizado de nuestra cuenta bancaria, el pago de una multa o la infección de nuestro equipo), para luego sugerirnos amablemente hacer clic en el vínculo que nos permitirá solucionar el problema de raíz. Y precisamente en este inocente vínculo está el engaño: Dicho vínculo no tiene nada de inocente y nos llevará a una página que es la réplica de la original, generalmente residente en un sitio extranjero y que al momento de ingresar nuestras credenciales nos arrojará un error y nos derivará al sitio real, no sin antes quedarse con una copia de nuestras credenciales.

En este sentido, lo más recomendable es nunca hacer clic en un hipervínculo que venga en un correo electrónico. En lo personal, cuando me llega un correo con hipervínculos suelo pararme sobre el mismo, dar clic secundario y seleccionar la opción «copiar hipervínculo» para luego pegarlo en un portapapeles y examinarlo detenidamente. Así puedo entender en donde el atacante mantiene residiendo su página falsa. Cuando el hipervínculo me llega de parte de un compañero de trabajo, suelo tomar el teléfono y preguntarle directamente si quiso enviarme un vínculo a alguna página. Una de las maneras más eficientes de salir de dudas cuando uno cree ser víctima de un ataque de ingeniería social es contactarse directamente con las fuentes.

3) Tenga cuidado con lo que envía

Muchas veces centramos nuestra atención solamente en el correo entrante, pero no tenemos el mismo nivel de atención con el correo que enviamos a diario. Debemos recordar que por lo general en nuestro día a día hacemos uso y manejamos información confidencial, y el correo electrónico suele ser una herramienta muy utilizada para enviar dicha información a otras personas.

En ese sentido, es muy recomendable validar a conciencia los destinatarios de un correo electrónico, sobre todo si en dicho correo vamos a adjuntar información de relevancia para nuestro trabajo.  Muchas veces al utilizar la opción «Responder a todos» terminamos enviando datos a quien no necesitaba acceder a ellos, y por otro lado, basta un pequeño error en el nombre o en el apellido (sobre todo en compañías con un alto número de empleados) para que nuestros archivos confidenciales vaya a dar a manos de quien no corresponde.

Como complemento a esta preocupación, una buena práctica es etiquetar nuestros correos salientes en base al nivel de confidencialidad de la información que vaya en ellos. En ese sentido, las soluciones de prevención de fuga de información (DLP o Data Loss Prevention) suelen implementar estas medidas de control de forma automática, protegiendo además nuestros adjunto de tal manera que aunque los hayamos enviado por error a otra persona esta no pueda visualizar la información contenida en el correo si no le corresponde hacerlo.

Estas sencillas prácticas nos ayudarán a utilizar de mejor manera esta popular herramienta tecnológica, evitando de pasada que pasemos un mal rato en el trabajo o que incluso lleguemos a comprometer información personal de relevancia. ¡Nos vemos en otra ocasión para compartirles más tips de seguridad!

Cómo ha pasado el tiempo. El otro día – el 2 de Septiembre, para ser más exacto – me llegó a mi correo una solicitud de aprobación de un comentario de este blog. Y recién ahí vine a darme cuenta que han pasado casi 3 años desde mi última publicación en este sitio. Y vaya que ha pasado agua bajo el puente. Tanta como puedan imaginarse. Y posiblemente más.

Y en estos casi 10 años que llevo metido en el mundo de la Seguridad de la Información he deambulado por los distintos ámbitos y escenarios que ofrece este fascinante mundo. Desde el mundo de la pedagogía, la investigación y desarrollo, las soluciones técnicas de seguridad y ahora último, el amplio mundo de la gestión; formando parte del mundo de los clientes y también del mundo de los proveedores.

Casi 3 años han pasado desde la última vez que escribí en este blog. Y hoy decidí volver a darme una vuelta por éste, que fue mi hogar virtual por tanto tiempo, para abrir el debate sobre una pregunta que me siempre me dado vueltas por la cabeza referente al mundo de la seguridad de la Información.

La Seguridad y el Negocio, ¿Son amigos o rivales?

Es sin duda una pregunta que difícilmente podremos resolver acá.

Recuerdo mi época de proveedor de servicios. Trabajaba en el área más desafiante de cualquier consultora de tecnología: el área de seguridad de la información. Vender una solución de seguridad era sin duda un gran desafío; lograr vender un proyecto o servicio de seguridad era mucho más complejo que vender una actualización de Exchange o de Directorio Activo. Nuestra facturación siempre estaba en la cuerda floja, y había que extremar recursos para poder vender una migración de la plataforma antivirus, o un análisis de las políticas de grupo de una compañía o de las prácticas de seguridad de servidores que tenían en el área de informática. Siempre me pregunté el por qué se hacía tan difícil implementar este tipo de soluciones.

Pasaron los años y ya conociendo la otra cara de la moneda – vale decir, el lado del cliente – es que logré entender un poco mejor en donde residía la dificultad de introducir mejoras de seguridad en el mercado. Y es que por regla casi general, la seguridad es vista como un enemigo natural del negocio. Y es algo de lo cual no necesariamente podemos culpar a las organizaciones, ni al sistema. Hasta cierto punto, la seguridad si es enemiga del negocio. Los controles de seguridad incorporan actividades que impactan en tiempo y complejidad a los procesos. Pasando por el simple ejemplo de un firewall, que al ser implementado necesariamente introduce un delay en el flujo de paquetes, un antivirus que revisa constantemente los archivos en búsqueda de secciones de código que coincidan con algunas de las firmas existentes en la base de datos del motor o un proceso formal de autorización de intercambio de información, que incorpora actividades de análisis de riesgo que pueden dilatar la entrega de los datos en uno o dos días. Mirado desde ese punto de vista, la seguridad suele entorpecer el negocio, lo cual tiende a generar un rechazo casi inmediato del usuario final que desea maximizar su producción y quedar más cerca de cumplir con las metas de su negocio, lo que generalmente está asociado a la obtención de un bono de desempeño.

Por otro lado, la seguridad tiene el gran inconveniente de estar asociada intrínsecamente al concepto de Riesgo. En otras palabras, las soluciones de seguridad de la información consisten por lo general en controles que nos protegen sobre situaciones que no sabemos con certeza si van a ocurrir. «Pero si no hemos tenido un incidente en años» es un argumento al que constantemente los especialistas de seguridad de la información se ven enfrentados al defender la incorporación de un nuevo control en un proceso que «hasta ahora no ha fallado nunca». La complejidad que tiene el cálculo del ROI (Retorno de inversión) de una solución de seguridad es otro factor a favor de la definición de la seguridad como un rival del negocio.

Sin embargo, la seguridad de la información no es necesariamente un rival del negocio. El establecer controles ciertamente puede hacer las cosas más lentas, pero puede por otro lado garantizar la continuidad de nuestro negocio, algo que si es ampliamente valorado por el mercado actual. O puede evitarnos la exposición a multas, sanciones o incluso la pérdida de nuestra imagen corporativa. El dicho de «no sabes lo que tienes hasta que lo pierdes» cobra gran sentido en este aspecto.

¿Cómo poder transformar la visión clásica de la seguridad como un enemigo del negocio en algo totalmente opuesto a ello?

¿Que opinan ustedes?

¡Bienvenidos de vuelta!

Cambios

 

En la vida existen distintos tipos de cambios. Algunos buenos, otros malos, otros inesperados y otros largamente deseados; sin embargo, aquellos cambios que realmente pueden transformar nuestras vidas se pierden, pues los dejamos ir debido al miedo que nos invoca la rutina, lo repetitivo, lo monótono, la comodidad en la que nos solemos encontrar cuando nos enfrentamos a ellos.

Todo cambio es una apuesta, en la que creemos que se puede ganar mucho pero a la vez se puede perder mucho también. Sin embargo, pocas veces visualizamos que en realidad todas aquellas cosas que podríamos perder en realidad no serán una pérdida, sino que más bien un sacrificio, una inversión, para llegar un poco más arriba del lugar donde estamos antes. Y en ese sentido, suelo siempre recordar una historia que leí en un libro cuando era 10 o 15 años más joven.

La historia hacía un paralelismo entre la vida y un edificio de departamentos. Nosotros partimos nuestra vida en el primer piso de este edificio, en el departamento más incómodo, frío y oscuro del lugar. Y a medida que ganamos experiencia, que vencemos en nuestras propias batallas personales, nos vamos moviendo de departamento en departamento en ese piso, a condiciones cada vez mejores, consiguiendo respeto y admiración de nuestros pares, hasta llegar al final del piso. Más cómodos no podemos estar; somos los más experimentados, los más sabios, los que viven en mejores condiciones del piso. Es ahí donde hemos llegado al fin de una etapa y es en ese momento donde cae una escalera desde el piso superior. Es la posibilidad de enfrentar un cambio, un cambio de nivel.

Y es ahí donde se plantea la gran paradoja del cambio. ¿Nos movemos? ¿Apostamos por un piso más arriba? Estamos cómodos donde estamos… Nos respetan, ¡nos admiran!. Somos los reyes del piso. ¿Y qué habrá arriba? ¿Valdrá la pena subir y enfrentar nuevos desafíos, o nos quedamos en nuestro marco de comodidad?

A través de los años, me ha tocado conocer visionarios y rutinarios. He visto gente que ha subido esa escala sin dudarlo, otros que lo han hecho con temor y muchísimos que han preferido la comodidad que las libertades que han obtenido con el tiempo. Mal que mal, el afrontar un cambio no es fácil. La ceguera y el temor a los cambios puede transformarse en un eterno castigo que mantiene a las personas atadas al piso de su edificio, viendo como algunos dan el salto, despidiéndose de ellos cada vez.

Hace algunos meses tuve la sensación de que había llegado al último departamento de mi piso. Y hace algunas semanas, la escala del piso superior bajó. Pensé en mis múltiples libertades y como las perdería. Pensé en utilizar corbata y entrar temprano todos los días. Pero también pesé rápidamente en el tremendo desafío y las posibilidades de crecer que afrontaría. Y decidí subir.

El día de mañana, a poco más de 7 años de haber obtenido mi título profesional, comienzo una nueva etapa. Lo que yo he llamado la fase de la especialización. Es un gran cambio sin duda, y no tengo otra cosa que muchas ganas de empezar a vivir dicho cambio.

Espero volver pronto a escribir en el blog, pero para comenzar a hablar de este nuevo gran mundo al cual comenzaré a enfrentarme: El mundo de la gestión de la seguridad.

 

Según la Wikipedia, Liderazgo está definido como "el proceso de influir en otros y apoyarlos para que trabajen con entusiasmo en el logro de objetivos comunes. Se entiende como la capacidad de tomar la iniciativa, gestionar, convocar, promover, incentivar, motivar y evaluar a un grupo o equipo".
 
Y bien, hace bastante rato que vengo reflexionando sobre lo que el liderazgo y su importancia en la vida laboral. Y es que ser líder es difícil, porque a mi juicio el liderazgo implica por sobre todas las cosas empatía con el equipo al cual el líder lidera (valga la redundancia).
 
Los líderes naturales suelen ser personas profundamente carismáticas, estudiosas de la gente y del ambiente, con un amplio sentido de la estrategia y con la capacidad de convencimiento necesaria para hacer que su equipo crea fehacientemente en su visión, independiente de que esta sea buena o mala. Porque a final de cuentas, han existido líderes tan potentes que han hecho creer a naciones enteras en cosas que hoy, 50 o 60 años después, encontramos simplemente aberrantes.
 
Si tuviese que hacer clasificaciones, creo que simplificaría todo a dos tipos de líderes. Por un lado existen los líderes motivadores, los que resaltan las virtudes de las personas que están en su equipo, buscando constantemente maneras de mejorar sus defectos o anularlos con las virtudes de otra persona. Los líderes motivadores siempre piden todo por favor, agradecen cuando se cumple el objetivo y no dudan en decir un ¡bien hecho! con mucho entusiasmo. El lider motivador logra, a través de un discurso cargado de energía, prender a la gente que lo rodea, entusiasmarse con el cumplimiento de los objetivos planteados y haciéndolos sentir parte importante de la tarea en total.
 
La labor de un líder motivador suele ser desgastante. Debe estar atento a los problemas de su equipo y tratar de resolverlos con prestancia, debe planificar que hacer para resolver las dificultades adicionales que se sucedan en el tiempo, y debe tener la sabiduría necesaria para salomónicamente poner fin a los problemas internos sin entrometerse demasiado.
 
Por otro lado, están los líderes desmotivadores. Utilizando el amedrentamiento y la amenaza como aliados, hablan golpeado, imponen reglas y castigos, hacen ver el objetivo final como algo que se debe cumplir "porque sí" y buscan la sumisión como método para mantener a su equipo de trabajo en acción. Rara vez destacan el buen trabajo de la gente y se limitan a decir "es tu trabajo".
 
¿Qué tipo de  líderes conocen ustedes?
Sin duda, las dantescas escenas que nos llegan a diario desde Concepción y sus alrededores nos muestran el otro lado del terremoto que hemos vivido en Chile el sábado recién pasado: El lado tecnológico del terremoto, del cual les hablo a continuación.
 
La continuidad de negocio tiene por objetivo tomar todas las precauciones necesarias para hacer funcionar a una compañía – del rubro que sea – y mantener sus servicios operativos, pase lo que pase. Y para poder mantener operativo un negocio, "pase lo que pase", es necesario ponerse en el peor de los escenarios. Y hoy por hoy, difícilmente podremos imaginar un escenario peor que el que hoy está viviendo nuestro país: un violento terremoto, seguido de un tsunami que es capaz de dejar cables, edificios, centros de datos y de comunicaciones en el suelo, en cosa de segundos.
 
Tecnológicamente hablando, este es quizá el desafío más grande que ha tenido nuestro país en su historia. Nos hemos dado cuenta lo frágil que es nuestra humanidad sin agua y sin luz. Si nos ponemos a enumerar las consecuencias tecnológicamente visibles, los miles de cajeros automáticos reseteados, la dificultad para fabricar pan y para distribuir agua en zonas elevadas (muchas veces esta distribución se realiza con bombas eléctricas) son los primeros que se vienen a la mente colectiva. Sin embargo, podemos mirar como este evento de gran magnitud gatillo la ejecución de los planes de recuperación de desastre en las principales compañías de servicios básicos en nuestro país, empezando rápidamente el proceso de normalización de los mismos en todo el territorio afectado.
 
Un plan de recuperación de desastre (DRP) es parte medular del plan de continuidad de negocio. Corresponde a un documento detallado de procedimientos, que prepara a la compañía para responder rápida y eficazmente ante cualquier incidente de seguridad que pueda afectar severamente la continuidad del negocio. A este incidente es al cual llamamos "desastre". Un plan de recuperación de desastre debe ser capaz de proveer instrucciones claras y precisas, coordinando las distintas fuerzas existentes en la compañía en la más amplia variedad de desastres: Terremotos, Tsunamis, Atentados, Incendios, Inundaciones, Cortes de energía e incluso fallas de hardware de cualquiera de los servidores críticos de la compañía deberán formar parte de este vital documento.
 
En líneas generales, la construcción de un plan de recuperación de desastres se inicia con un árduo proceso de levantamiento de los activos de la compañía. Los activos de información corresponden a la información misma, el software y hardware que lo soportan y los procesos con los cuales opera. Una vez realizado este levantamiento, es posible determinar a través de complejos estudios de tipo económico cuales activos son más valiosos para la organización y, por ende, cuales deben ser cubiertos con una mayor cantidad de recursos por parte de la misma. Este proceso, conocido como BIA (Bussiness Impact Analysis o análisis de impacto de negocio) permite optimizar el uso de recursos, y debe considerar los costos directos e indirectos que los diferentes incidentes de seguridad causan a los activos, además de la probabilidad de ocurrencia de los mismos. Tomando un ejemplo muy actual en nuestro país, un terremoto es un incidente altamente destructivo, con una probabilidad de ocurrencia media-baja, aunque bastante más probable que un tornado (algo – hasta ahora – casi imposible en nuestro país, gracias a la Cordillera de Los Andes).
 
Ahora, ¿cómo medir el impacto de los incidentes? Esta es una labor a veces titánica. Si ponemos por ejemplo, la página web de un banco como un activo de información, para poder calcular el impacto de un incidente en dicho activo debe considerar, entre otros costos:
 
a) Las horas hombre que cuesta volver el sitio a su funcionamiento normal
b) La inversión en software/hardware que esto pueda implicar
c) La cantidad de transacciones que no se realizaron (medible estadísticamente)
d) La cantidad de clientes potenciales que no se afiliaron al banco porque el sitio estaba abajo (también medible estadísticamente)
e) Las multas de los entes fiscalizadores por la falla
f) Los clientes que decidieron dejar de ser clientes del banco por la falla
g) Las posibles demandas recibidas por clientes
h) El daño a la imagen del banco
 
Como se puede ver, muchos de estos valores son bastante difíciles de inferir. Sin embargo este análisis es clave para priorizar las medidas a tomar sobre los activos de la organización.
 
Una vez categorizados e inventariados los activos, es necesario escribir los planes de continudad de negocio. Para ello, generalmente se define una etapa inicial de reconocimiento o evaluación de los daños debido a los incidentes existentes en cada uno de los escenarios definidos, para luego definir procedimientos estándar para la recuperación de cada uno de los componentes del activo en sí. Esto, entre otras cosas, debe considerar la recuperación de los datos, de los sistemas base que soportan el activo y de los componentes de comunicación, entre otros. Así, dependiendo del escenario definido se considerará la falla de uno o varios componentes anteriormente nombrados, lo que termina facilitando la redacción del plan en sí. Bajo este prisma, en la redacción de un DRP no habrá mucha diferencia entre un terremoto y un incendio del centro de datos, ya que en ambos casos los fallos provocados a los sistemas probablemente sean muy semejantes.
 
Dentro de la redacción de los DRP, también es muy importante determinar la manera en que los distintos activos se relacionan entre sí. Si esto no se considera, la ejecución del DRP puede añadir problemas nuevos que no estaban considerados y que de hecho podrían superar al problema original.
 
Finalmente, es clave poder probar los planes y actualizarlos de manera regular. Nuestro país en estos días ha vivido una prueba de fuego, y la mayoría de las compañías clave han logrado responder de manera bastante adecuada. A pocas horas del terremoto, muchos ya poseían los servicios básicos e incluso eran capaces de colocar en los distintos medios masivos de internet (Facebook, Twitter) sus primeras impresiones del terremoto. Es más, hace pocos minutos me comuniqué por MSN con un amigo que vive en Concepción, el epicentro de esta megacatástrofe, a poco menos de 96 horas de la misma, pese a que el terremoto arrasó con el sistema interconectado central de energía eléctrica y probablemente con gran parte del sistema telefónico. Aunque suene algo frívolo, la correcta definición de los DRP de estas compañías lograron dar una respuesta relativamente rápida; de no haber estado debidamente preparados para enfrentar este gran reto, probablemente hubiesen pasado semanas antes de que estos "milagros tecnológicos" salieran a la luz.
 
Este artículo está dedicado al pueblo chileno, y en particular a los amigos y conocidos de la zona sur de nuestro país. Fuerza Chile.