Continuidad de negocio: El exchange Cryptopia se declara en quiebra tras ser hackeado

Análisis de Riesgos insuficiente

Hace unos meses, allá por enero, los malos hackearon un Exchange en Nueva Zelanda llamado Cryptopia y se llevaron unos 16 millones de dólares. Sí, ya sé que habéis leído muchas noticias como esta e incluso ha salido en las noticias, pero igual que en otras ocasiones hemos hablado de cómo el Exchange tenía un seguro para asumir estas pérdidas, en esta ocasión no ha sido posible reponerse de la brecha de Seguridad y el exchange Cryptopia se ha declarado en quiebra… por lo que hoy toca hablar sobre Continuidad de Negocio.

Todas las empresas saben qué es la Continuidad de Negocio. Parece obvio, ¿no?, son las medidas que hay que tomar para asegurar que tu empresa es capaz de reponerse ante una interrupción de sus actividades. Esta interrupción se puede dar por muchas causas, no solo porque te hackeen como en el caso de Cryptopia… imaginad por ejemplo que hay una fuerte nevada y los empleados no pueden llegar a la empresa y por lo tanto no pueden ‘producir’ o desarrollar sus actividades con normalidad. O que haya habido un corte de luz debido a unas obras que se están realizando en la misma calle.

Aunque la Continuidad de Negocio suene a algo muy ‘IT’, de empresas modernas de informática o telecomunicaciones, en realidad llevamos mil años haciendo muchas cosas por la Continuidad de Negocio: desde la prueba de evacuación que nos exigen otras normas como la de Riesgos Laborales o las copias de seguridad de la información, líneas redundantes de luz o conexión a Internet, etc. Hace unos años acudí a una jornada sobre Continuidad de Negocio y una de las ponencias la daba un capitán de navío de la Armada Española, y explicaba que ellos llevan mil años haciendo ‘continuidad de negocio’ y, en caso de detectar una amenaza en un submarino (como una vía de agua), saben exactamente qué tienen que hacer para que el trasto no se vaya al fondo… y eso también es continuidad de ‘su’ negocio.

¿Qué es un Sistema de Gestión de la Continuidad de Negocio?

Se trata simplemente de plasmar todo esto en un plan de mejora continua, los famosos ciclos de Denimg o PDCA (plan-do-check-act) que ya conocemos de otras normas e ISOs. De esta forma, no solo vamos a documentar todo lo que hacemos para respaldar nuestro negocio, sino que lo vamos a probar y lo vamos a mejorar… por ejemplo, seguro que sabríais decir cuánto se tarda en recuperar un archivo con vuestro sistema de copias de seguridad actual… pero ¿cuánto se tarda en recuperar un servidor entero y tenerlo funcionando de nuevo en el caso de que falle el original? o si nuestra empresa de transportes que envía las naranjas que producimos a nuestros clientes falla… ¿tenemos alguna otra empresa en nuestros contactos que nos pueda enviar urgentemente estas naranjas antes de que nuestros clientes se enfaden? y más o menos ¿cuánto tardaría nuestros clientes en enfadarse si estas naranjas se retrasan un poco? seguramente si se retrasan unas horas no se den ni cuenta, si se retrasan un día podemos tener problemas… pero si se retrasan 3 días igual se buscan otro proveedor y perdemos el cliente, ¿verdad? pues esto es lo que llamamos un Sistema de Gestión de la Continuidad de Negocio.

No es tan tan sencillo, aunque tampoco es un proceso complicado. Primero debemos examinar nuestro negocio y detectar cuales son los procesos que realmente hacen que el negocio funcione. De poco nos sirve tener una sala repleta de servidores de última generación si nuestro principal cliente nos envía los pedidos por Fax y, si se estropea ese fax, perderíamos una gran parte de nuestra facturación. Parece claro que lo que hay que mantener por todos los medios es ese fax, verdad? pues esta información la obtendremos mediante un análisis de riesgos una vez identificados los procesos de negocio principales.

¿En qué ha fallado Cryptopia?

Podríamos identificar varias cosas que han fallado en Cryptopia y que le han llevado al cese de sus operaciones. No tenemos mucha más información al respecto, por lo que vamos a hacer un ejercicio de imaginación con la información que tenemos:

– Cryptopia tardó 2 semanas en detectar el ataque, pero durante esas 2 semanas hubo usuarios que perdieron sus criptoahorros: evidentemente algo falló en su gestión de incidentes (los usuarios seguro que protestaron enérgicamente) y en su gestión de la seguridad (el hecho anómalo debería haberse detectado antes de que los usuarios se dieran cuenta).

– Estuvieron casi 2 meses para resolver el fallo de seguridad: ¿Sabéis cuántos Exchanges hay en el mundo? los suficientes como para que si en un par de días no funciona tu Exchange favorito, te vayas a otro. 2 meses es totalmente inaceptable, yo sólo habría mantenido mi cuenta ahí de tener mucho dinero en criptomonedas… y evidentemente a los 2 meses cuando volvió a funcionar los hubiera sacado.

– No han sido capaces de asumir el coste de devolver el dinero robado a los usuarios: lo cual indica que su póliza de seguros no estaba correctamente configurada.

– No han sabido gestionar la crisis de forma adecuada: con una buena gestión de crisis, Cryptopia debía haberse vuelto a situar en el lugar que estuvo hace unos meses, o bien ofreciendo descuentos en las comisiones o innovando con algún servicio nuevo… no sé, pero algo que hiciera que nuevos usuarios se dieran de alta en la plataforma, con lo que habría sido más fácil reponerse económicamente.

Seguramente podríamos identificar algunos puntos más, como por ejemplo la normativa que afecta a los exchanges a nivel mundial y que les obliga a tener un alto porcentaje de sus cripto-activos respaldados con dinero real… y me da que Cryptopia no cumplió esta normativa del todo.

El resultado: la quiebra

Si la semana pasada hablábamos de cómo el exchange Binance había sido capaz de superar un hackeo y devolver el dinero a los usuarios con un fondo de respaldo propio, en este caso tenemos que hablar de justo lo contrario, Cryptopia no ha sido capaz de superar el palo y se ha declarado en quiebra. Esto no significa que los malos haya hecho que quebrase, en realidad lo han hecho ellos mismos no tomando las medidas necesarias para asegurar la relisiencia del negocio, es decir, la capacidad de recuperarse ante una interrupción importante del negocio.

¿Vosotros sabéis cuánto tiempo tardaríais en reinstalar el servidor de base de datos de vuestra empresa en el caso de que se estropee? ¿Y cuánto tiempo tardarían vuestros clientes en enfadarse si lo que se estropea es el portal en el que hacen los pedidos? ¿Cuánto dinero perderíamos durante ese rato? Todas estas preguntas básicas podríamos contestarlas si tuviéramos un Sistema de Gestión de la Continuidad de Negocio adecuado y actualizado… y por supuesto seríamos capaz de evaluar el riesgo de que un malote nos robe dinero de nuestro sistema y qué medidas tomar para detectar y detener el ataque.

Deja una respuesta

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.