Recuperar y vigilar la reinfección

El CSF 2.0 lo pide de forma expresa: la integridad de las copias y de los demás recursos de restauración se verifica antes de usarlos (RC.RP-03), y la de los activos restaurados se verifica después (RC.RP-05). La razón es práctica: una copia con la integridad comprobada pero tomada después del primer acceso del atacante restaura también lo que él dejó.

Por eso la primera pregunta no es «¿cuál es la copia más reciente?», sino «¿cuál es la más reciente anterior a la primera actividad conocida del atacante, y está comprobada?».

Las copias de nc-fact01 están en una tabla, con su fecha y si se verificó su integridad. El caso tiene su propia línea de tiempo, con el primer indicio de actividad del atacante en un registro de identidad. La copia correcta cumple las dos condiciones a la vez; la última antes de esa fecha puede ser incremental o no estar verificada, y entonces no sirve.

Restaurar no es hacerlo todo a la vez. Un servicio que depende de otro no arranca antes que él, y entre varios que pueden empezar se prioriza por criticidad y por el tiempo máximo que la empresa tolera sin ellos. La tabla del caso trae las dependencias; el primero es el que no necesita a nadie y es crítico.

Tras la restauración, el SOC no vuelve a su rutina: vigila de forma reforzada, con la lista de indicadores del caso (direcciones, dominios, cuentas) y revisión frecuente de los aciertos. Eso sirve para dos cosas: ver si el atacante vuelve por la misma puerta y encontrar equipos que el alcance no incluía. Un acierto en un equipo que nunca estuvo en el caso significa que el alcance estaba incompleto, no que el equipo restaurado esté mal.

La vigilancia reforzada no es indefinida ni se levanta «cuando parece que todo está bien»: la política de la casa le pone una duración. Calcula la fecha de fin con el inicio y la duración que la política indica, contando los días corridos.