Arquitectura de un SOC MDR · IV — Recuperación: cuando la contención no alcanza

La entrega anterior terminó con la respuesta conteniendo, erradicando y recuperando el servicio en el caso normal. Pero hay un caso donde ese ciclo no alcanza: cuando el daño ya está hecho. El ransomware ya cifró los servidores de producción. El wiper ya borró. Los Domain Controllers ya no son confiables. Ahí contener no devuelve nada y erradicar no reinicia el negocio —hacen falta las dos cosas, y hace falta algo más: un plan estructurado para restaurar sistemas, datos y operaciones a un estado aceptable. Ese plan es el DRP, y es la última pieza del plano.

Esta entrega cierra la serie documentando la recuperación ante desastres de ciberseguridad. Qué la activa, cómo se prioriza qué se restaura primero, la decisión que ningún equipo técnico puede tomar solo, y —el punto que la distingue de un plan de continuidad genérico— por qué corre en paralelo a la respuesta al incidente, no después. El alcance es deliberadamente acotado: desastres originados por ciberseguridad (ransomware, corrupción de datos, compromiso de identidad o de cloud), no incendios ni fallas de hardware, que viven en un plan de continuidad de negocio aparte.

El DRP no reemplaza a la respuesta: corre con ella#

El error conceptual más común es imaginar la recuperación como la fase que viene después de la respuesta: primero conteno, después restauro. En un desastre real no hay ese lujo secuencial. Si el ransomware cifró producción, el equipo contiene y erradica (IRP) mientras simultáneamente arranca la restauración de los servicios críticos (DRP). Los dos planes corren a la vez, con dueños distintos y en comunicación continua.

flowchart TB
    INC(["Incidente P1\ndaño a sistemas críticos"]) --> SPLIT{" "}
    SPLIT --> IRP
    SPLIT --> DRP

    subgraph IRP["IRP — dueño: SOC Manager"]
        direction TB
        I1["Contener\naislar, cortar C2"] --> I2["Erradicar\neliminar persistencia,\nrotar credenciales"] --> I3["Identificar vector\n(parche para el hardening)"]
    end

    subgraph DRP["DRP — dueño: Sponsor + SOC Manager"]
        direction TB
        D1["Verificar integridad\nde backups"] --> D2["Restaurar en\nentorno aislado + scan"] --> D3["Hardening\n(usa el vector del IRP)"] --> D4["Reconectar por Tiers\n+ monitoreo reforzado"]
    end

    IRP -.el vector alimenta el hardening.-> DRP
    IRP --> DONE(["Servicio restaurado\ny endurecido"])
    DRP --> DONE

La flecha que conecta los dos carriles es la que importa: el DRP necesita el resultado del IRP. No tiene sentido restaurar un sistema con la misma vulnerabilidad que permitió el ataque —volvería a caer en horas—, así que el paso de hardening de la recuperación consume el vector de entrada que la erradicación identificó. Restaurar sin ese dato es reconstruir la puerta por la que entró el atacante. Por eso la coordinación es explícita: el SOC Manager es dueño del IRP, el Sponsor del cliente es dueño del DRP, y trabajan en comunicación continua porque una decisión de uno cambia el trabajo del otro.

La mayoría de los incidentes se resuelven solo con el IRP. El DRP se activa pocas veces —pero cuando se necesita, se necesita con urgencia y sin margen para improvisar.

Qué lo activa, y quién#

El DRP no lo dispara una alerta: lo dispara una decisión. Se activa cuando se confirma un daño que la respuesta sola no puede revertir:

• Cifrado masivo por ransomware sobre sistemas Tier 1 o Tier 2.
• Destrucción o corrupción de datos que impide la operación normal.
• Indisponibilidad prolongada de servicios esenciales —a veces causada por la propia contención: se aisló un servidor crítico para frenar el ataque—.
• Compromiso de la infraestructura de identidad (Domain Controllers, IdP) que vuelve insegura toda la cadena de autenticación.
• Compromiso del management plane del cloud (cuentas de administración, recursos eliminados).
• Compromiso de la infraestructura de backup —el peor, porque ataca la capacidad misma de recuperarse—.

Los Tiers: qué se restaura primero#

No todo se restaura a la vez, y el orden no se improvisa en el momento del pánico: se define en el onboarding y se valida con el Sponsor. Los sistemas se clasifican en tres tiers, y cada tier lleva dos objetivos que gobiernan la recuperación —el RPO (Recovery Point Objective: cuántos datos se aceptan perder, medido en tiempo hacia atrás desde el último backup limpio) y el RTO (Recovery Time Objective: cuánto puede tardar la restauración)—.

Esta clasificación es el único elemento del servicio que es cien por ciento específico del cliente y que el MDR no define: el cliente dice qué es crítico para su negocio, el MDR lo documenta y lo usa para priorizar. Para un PSE/OIV hay una regla dura encima: los sistemas que soportan el servicio esencial son Tier 1 obligatoriamente, porque restaurar el servicio esencial es la primera prioridad no solo operativa sino legal.

Restaurar sin reinfectar#

La parte contraintuitiva de la recuperación es que restaurar rápido y restaurar bien están en tensión, y elegir la velocidad sobre el cuidado es cómo un desastre se convierte en dos. El procedimiento tiene un orden que no se saltea:

1. Verificar la integridad de los backups antes de tocar nada. Un atacante sofisticado compromete los backups semanas antes de lanzar el ransomware, precisamente para que la recuperación reinstale su persistencia. Verificar hashes, fechas, y montar el backup en un entorno aislado para inspeccionarlo.
2. Restaurar en un entorno aislado primero. Segmento de red separado, validar que el sistema restaurado está limpio —sin malware, sin persistencia, sin cuentas no autorizadas—, correr un scan de EDR sobre él.
3. Aplicar hardening antes de reconectar. Los parches del vector que identificó el IRP, antes de exponer el sistema a la red.
4. Seguir el orden de Tiers. Tier 1 completo y validado, después Tier 2, después Tier 3. Dentro de cada tier, el orden lo fija el Sponsor.
5. Validación por usuarios finales. Un sistema no está «restaurado» hasta que quien lo usa confirma que funciona y que los datos están íntegros.
6. Monitoreo reforzado mínimo 72 horas sobre lo reconectado: reglas más agresivas, revisión de logs, verificación de que no hay reinfección.

El primer paso, verificar antes de confiar, tiene una versión operativa mínima: comparar el hash del backup contra el registrado cuando se generó, antes de montarlo.

La decisión que ningún SOC toma solo#

Cuando el ransomware cifró y los backups no alcanzan, aparece la decisión más incómoda del incidente, y es una decisión de negocio, no técnica. Se reduce a tres caminos, y el rol del MDR es informar cada uno con datos, no elegir por el cliente:

flowchart TD
    R(["Ransomware con cifrado masivo"]) --> DEC1{"¿Backups limpios\ny RPO aceptable?"}
    DEC1 -->|sí| A["Opción A — Restaurar\n(recomendada)\nMDR asiste y monitorea"]
    DEC1 -->|no| DEC2{"¿Existe descifrador\npúblico?\n(nomoreransom.org)"}
    DEC2 -->|sí| DECR["Descifrar\nsin restaurar ni pagar"]
    DEC2 -->|no| DEC3{"Decisión del cliente\n(con asesor legal)"}
    DEC3 --> B["Opción B — Negociar\n(último recurso)\nMDR NO recomienda pagar"]
    DEC3 --> C["Opción C — Reconstruir\ndesde cero\nse acepta pérdida de datos"]
    A --> END(["Recuperación por Tiers"])
    DECR --> END
    B --> END
    C --> END

La Opción A (restaurar) es la recomendada siempre que los backups estén limpios y el RPO sea aceptable. Antes de descartarla conviene revisar si existe un descifrador público para la variante —a veces lo hay, y evita todo lo demás—. La Opción B (negociar) es el último recurso: el MDR no recomienda pagar —no hay garantía de recuperar, financia la próxima campaña, y puede tener implicancias legales— pero la decisión es del cliente, con asesor legal y potencialmente fuerzas del orden involucradas. La Opción C (reconstruir desde cero) acepta la pérdida de datos desde el último backup viable y levanta todo desde imágenes limpias. Ninguna de las tres es buena; la Opción A es simplemente la menos mala, y todo el trabajo de backup previo existe para que sea la que esté disponible.

Un plan que no se prueba no existe#

Todo lo anterior es teoría hasta que se ejecuta, y un plan de recuperación que nunca se probó es una hipótesis optimista sobre backups que quizás no restauran. Por eso el DRP se valida con dos ejercicios periódicos: una restauración real de al menos un sistema de cada tier —midiendo el RTO real y comparándolo con el objetivo—, y una simulación de mesa donde todos los involucrados recorren un escenario (ransomware cifró Tier 1) paso a paso sin ejecutar acciones, buscando los huecos de proceso y los roles que nadie tenía claros.

Las métricas que importan no son de vanidad: RTO real contra objetivo, RPO real contra objetivo, y tasa de éxito de restauración —¿el backup restauró al primer intento?—. Un backup que falla al restaurar no es un backup: es un archivo que da tranquilidad falsa. La única forma de saber que existe es restaurarlo antes de necesitarlo. Es el mismo principio que atravesó toda la serie, girado una vez más: un control sin verificación de que sigue vivo es un control muerto que se cree sano, y un backup sin restauración de prueba es exactamente eso.

Con esto cierra el plano. Cuatro entregas para cuatro problemas que un servicio de detección y respuesta gestionada resuelve en secuencia: adoptar un cliente sin heredar su caos (onboarding), decidir qué mirar sin ahogarse en todo (telemetría), convertir una alerta en acción dentro de un reloj que a veces es legal (respuesta), y volver a ponerse de pie cuando el daño ya ocurrió (recuperación). El hilo que los une no es técnico: es que cada capa asume que la anterior puede fallar, y construye el control que lo detecta. Un SOC no es un producto que se compra; es una serie de lazos que se cierran, y esta serie fue el plano de cómo se cierran.

El punto de entrada a la serie completa —con el orden de lectura y el mapa de las cuatro capas— está en la introducción.