Contener un ciberataque no significa que el negocio esté preparado para volver a operar. Y recuperar los procesos críticos y sistemas tampoco garantiza que los servicios financieros puedan restablecerse de manera segura.

Son las 8:30 de la mañana de un lunes. Después de casi 36 horas de trabajo ininterrumpido, el equipo de ciberseguridad de una institución financiera comunica una noticia esperada: el incidente ha sido contenido. Los sistemas comprometidos fueron aislados, las credenciales afectadas se bloquearon y los especialistas no encuentran nuevas evidencias de actividad maliciosa.

El equipo de infraestructura confirma que los servidores críticos están disponibles. Las aplicaciones principales responden y los respaldos utilizados para la recuperación superaron las verificaciones técnicas iniciales. En la sala de crisis comienza a sentirse cierto alivio, sin embargo, cuando el responsable de Operaciones pregunta a qué hora podrán reanudarse las transacciones, nadie tiene una respuesta definitiva.

La plataforma web y canal digital están disponibles, pero todavía existen dudas sobre la integridad de determinados registros. Algunas operaciones quedaron pendientes durante la interrupción, con la típica respuesta «Host no responde«. Otras necesitan conciliación y varios sistemas externos aún no han sido reconectados. El banco ha recuperado procesos pero el servicio sigue caído.

El Banco aún no ha recuperado la capacidad de operar con seguridad y confianza.

Esta situación plantea uno de los desafíos más complejos de la resiliencia operativa: comprender que la recuperación tecnológica y la recuperación del negocio no son necesariamente el mismo proceso.

La falsa tranquilidad de declarar que el incidente terminó

Durante un ciberataque, las prioridades iniciales suelen estar claras; identificar la amenaza, contener su propagación, proteger los activos comprometidos y evitar que el atacante continúe causando daños.

Son actividades fundamentales, sin embargo, sin una contención adecuada, cualquier intento de recuperación podría resultar prematuro, sin embargo, cuando los especialistas confirman que la amenaza está contenida, la organización puede interpretar ese resultado como el comienzo inmediato del retorno a la normalidad.

Y no siempre es así porque la contención demuestra que se han adoptado medidas para detener o limitar la actividad maliciosa identificada, pero no demuestra automáticamente que todos los sistemas sean confiables, que la información conserve su integridad y que los procesos críticos puedan reanudarse sin generar nuevas consecuencias.

Incluso después de contener el incidente, puede ser necesario continuar investigando posibles mecanismos de persistencia, accesos comprometidos o alteraciones que todavía no han sido identificadas, por eso, la decisión de volver a operar requiere algo más que confirmar que los servidores están encendidos y las bases de datos estes disponibles. Se requiere determinar si la organización puede procesar operaciones financieras sin introducir potenciales eventos de riesgos adicionales.

Recuperar un sistema no es recuperar un servicio

Imaginemos que una institución financiera consigue restablecer su plataforma de pagos después de un ataque de ransomware, desde el punto de vista tecnológico, la recuperación parece exitosa.

• La aplicación responde.

• La base de datos está disponible.

• Las conexiones principales funcionan.

Sin embargo, durante la interrupción quedaron miles de operaciones pendientes, algunas transacciones fueron iniciadas antes de la caída del servicio, pero no existe confirmación de que hayan sido completadas. Otras requieren verificar si fueron procesadas por sistemas externos y también existen diferencias entre registros internos y confirmaciones de terceros.

Si la institución reactiva inmediatamente el procesamiento de nuevas operaciones, podría generar operaciones duplicadas, inconsistencias contables o afectaciones a los clientes. El sistema funciona, pero el servicio todavía no está preparado para operar normalmente.

Aquí aparece una distinción importante: La recuperación tecnológica restablece componentes. La recuperación operativa restablece la capacidad de prestar servicios críticos de manera confiable. Ambas deben coordinarse, pero no pueden considerarse equivalentes.

El problema de recuperar información que no sabemos si es confiable

Uno de los escenarios más delicados después de un ciberataque es la incertidumbre sobre la integridad de los datos. Una organización puede disponer de respaldos técnicamente recuperables y, aun así, necesitar determinar si contienen información correcta y libre de alteraciones maliciosas.

Por ejemplo, si un atacante obtuvo acceso a determinados sistemas antes de ejecutar el ransomware, podría haber modificado registros, configuraciones o mecanismos de autenticación. En esas condiciones, restaurar una copia sin verificar su confiabilidad puede reintroducir vulnerabilidades o inconsistencias.

La pregunta no debería limitarse a: ¿Podemos recuperar la base de datos?

También necesitamos responder:

¿Desde qué momento podemos confiar en su integridad?

¿Qué operaciones fueron realizadas después de ese punto?

¿Cómo identificaremos las diferencias?

¿Qué información deberá reconstruirse?

¿Quién autorizará el uso de los datos recuperados?

Estas preguntas pueden ser particularmente complejas en procesos financieros que requieren exactitud transaccional, conciliaciones y trazabilidad.

Un respaldo disponible es una condición importante para la recuperación, pero no constituye, por sí solo, una garantía de integridad ni de retorno seguro a la operación.

El RTO se cumplió, pero los clientes siguen esperando

En continuidad del negocio, el Objetivo de Tiempo de Recuperación (RTO) establece el tiempo previsto para recuperar una actividad, sistema o recurso, según el alcance definido. Es un parámetro fundamental para planificar capacidades de recuperación. Sin embargo, su interpretación puede generar dificultades cuando la organización no distingue claramente entre la recuperación de componentes tecnológicos y la reanudación efectiva del servicio de negocio.

Supongamos que el RTO tecnológico de una plataforma es de cuatro horas. El equipo de infraestructura consigue restaurarla dentro de ese plazo. Desde su perspectiva, el objetivo se ha cumplido.

Pero Operaciones necesita otras seis horas para validar registros, conciliar transacciones pendientes y confirmar que los servicios pueden reanudarse.

Durante ese periodo, los clientes continúan afectados. ¿Podemos afirmar que el servicio crítico fue recuperado en cuatro horas?

La respuesta dependerá del alcance y de los criterios definidos para el objetivo de recuperación.

Si el RTO corresponde exclusivamente al componente tecnológico, su cumplimiento no demuestra que el servicio de negocio haya sido restablecido, por eso, es importante establecer criterios diferenciados de recuperación tecnológica, reanudación operativa y estabilización del servicio, manteniendo coherencia con las tolerancias de interrupción aprobadas.

La organización necesita saber no solamente cuándo vuelve a funcionar una aplicación, también cuándo puede volver a prestar el servicio crítico en condiciones aceptables.

La recuperación puede crear una segunda crisis

Existe una presión comprensible por restablecer las operaciones después de una interrupción importante:

• Los clientes necesitan acceder a sus fondos,
• Las operaciones comerciales se acumulan,
• Los canales de atención reciben reclamaciones,
• La Alta Dirección necesita recuperar la normalidad.

Pero una reanudación precipitada puede agravar las consecuencias del incidente. Imaginemos que una plataforma de transferencias se reactiva antes de completar la conciliación de operaciones pendientes. Algunas transacciones podrían ejecutarse nuevamente, otras podrían quedar registradas con estados inconsistentes.

El equipo de Operaciones tendría que corregir manualmente diferencias mientras el sistema continúa procesando nuevas solicitudes. La institución podría pasar de una crisis de indisponibilidad a una crisis de integridad operativa. Por eso, la recuperación debe considerar criterios de autorización y validación. No se trata de retrasar innecesariamente el retorno al servicio. Se trata de evitar que la urgencia por recuperar disponibilidad comprometa la confiabilidad de las operaciones.

La decisión de volver a operar no debería ser exclusivamente tecnológica

En muchos incidentes, el equipo de Tecnología tiene una participación decisiva en la recuperación, pero determinar si un servicio financiero puede reanudarse requiere una decisión más amplia.

• Ciberseguridad debe aportar evidencia sobre la contención y las condiciones de seguridad.

• Tecnología debe confirmar la disponibilidad y estabilidad de los componentes.

• Operaciones debe validar la integridad de los procesos y la capacidad para gestionar transacciones pendientes.

• Los responsables del negocio deben determinar si el servicio puede prestarse dentro de condiciones aceptables.

• Riesgos y Cumplimiento deben evaluar las exposiciones residuales, las excepciones y las obligaciones que requieren ser aplicadas.

• La Alta Dirección o la instancia facultada debe asumir las decisiones correspondientes cuando existan impactos o riesgos materiales.

La autorización de retorno a la normalidad debería basarse en criterios previamente establecidos, no solamente en la presión por restablecer el servicio.

La recuperación necesita pruebas que no representen una potencial crisis

Muchas instituciones realizan pruebas de recuperación tecnológica y obtienen resultados satisfactorios.; restauran servidores, verifican aplicaciones y comprueban la disponibilidad de respaldos.

Pero un escenario de ciberataque puede exigir capacidades adicionales.

¿Qué ocurre si los respaldos más recientes no son confiables?

¿Qué sucede si debemos reconstruir credenciales e identidades privilegiadas?

¿Cómo recuperaremos operaciones ejecutadas parcialmente?

¿Qué haremos si un proveedor externo todavía no autoriza la reconexión?

¿Cómo validaremos la integridad de los datos?

¿Podemos operar temporalmente con capacidad reducida?

¿Quién determina que el servicio está suficientemente estabilizado?

Estas situaciones deberían incorporarse, según su relevancia, a los ejercicios de continuidad y recuperación cibernética. Una prueba que demuestra que una aplicación puede encenderse o una base de datos esta disponible, no necesariamente demuestra que el negocio puede recuperarse después de un ataque severo. Capacidad operativa no es levantar solamente un proceso o aplicación.

Los indicadores que necesitamos revisar

La gestión de la recuperación suele concentrarse en tiempos de restauración, disponibilidad de respaldos y cumplimiento de pruebas. Estos indicadores continúan siendo importantes, sin embargo, para evaluar la recuperación integral de servicios críticos convendría complementarlos con otros.

Por ejemplo,

• el tiempo necesario para validar la integridad de los datos recuperados,
• la cantidad de operaciones pendientes de conciliación,
• el tiempo requerido para restablecer las dependencias externas
• la capacidad transaccional disponible durante la recuperación.

Estos indicadores permiten identificar brechas que podrían permanecer ocultas si solamente observamos la disponibilidad de infraestructura como único requisito para reanudar los servicios financieros.

La pregunta que debería llegar al Comité de Riesgos

Cuando una institución informa que sus respaldos funcionan y que los tiempos de recuperación tecnológica cumplen los objetivos establecidos, es razonable interpretar que dispone de capacidades importantes.

Pero convendría profundizar, si mañana sufriéramos un ciberataque severo, ¿cuánto tiempo necesitaríamos para volver a procesar operaciones financieras con información confiable? ¿Mi RTO tecnológico obtenido bajo un escenario de interrupción parcial, sería suficiente para recuperar ante un escenario severo de interrupción, tipo bajo un ataque de ransomware?

La respuesta exige comprender las dependencias entre ciberseguridad, tecnología, operaciones, datos y terceros. También requiere identificar qué condiciones deben cumplirse antes de autorizar el retorno al servicio.

El objetivo no es garantizar que nunca ocurrirá una interrupción. Es demostrar que la organización puede recuperar sus servicios críticos minimizando el impacto del evento, sin introducir consecuencias adicionales que agraven la crisis.

Reflexión final

Un ciberataque no termina necesariamente cuando desaparece la actividad maliciosa. Desde la perspectiva del negocio, sus consecuencias pueden continuar durante horas o días. Puede ser un RTO de hasta 15 días si el ataque compromete no solo información, sino llegase a comprometer infraestructura.

Los sistemas pueden estar disponibles mientras las operaciones siguen suspendidas.

Los respaldos pueden funcionar mientras persisten dudas sobre la integridad de la información.

La infraestructura puede recuperarse mientras los clientes todavía no pueden utilizar los servicios.

Por eso, una estrategia de ciberresiliencia no debería limitarse a prevenir ataques, contener amenazas y restaurar tecnología, también debe garantizar que la organización cuenta con capacidades para reconstruir la confianza operativa, validar información, gestionar operaciones pendientes y reanudar servicios críticos de manera segura.

La próxima vez que un equipo informe que el incidente ha sido contenido y los sistemas están recuperados, convendría formular una última pregunta: ¿Estamos realmente preparados para volver a operar o solamente hemos conseguido que la tecnología vuelva a funcionar? ¿Nuestras capacidades operativas se han restablecido?

Porque en una institución financiera, recuperar los sistemas es indispensable, pero recuperar la capacidad de operar con seguridad, integridad y confianza es lo que verdaderamente permite superar la crisis.

ALGERisk Corporation
Generando cultura de riesgos