¿Cuánto tiempo deberías conservar las versiones de archivos después de un ataque de ransomware?

Mantenga versiones diarias de archivos por al menos 30 a 90 días como un rango inicial práctico después de un ataque de ransomware, pero no lo trate como un plazo universal de eliminación. La retención debe extenderse más allá de la fecha de compromiso más temprana plausible, preservar puntos limpios semanales o mensuales seleccionados y mantener la evidencia del incidente por separado hasta que se complete la recuperación, investigación, seguros, asuntos legales y cumplimiento.

Un rango inicial práctico es de 30 a 90 días

Muchos diseños de respaldo usan de 30 a 90 días de historial diario inmutable para recuperación operativa de ransomware. Una visión general de respaldos inmutables señala que de 30 a 90 días es un rango común de retención diaria para protección contra ransomware. Considere esto como un punto de partida, no como una garantía de que la versión más antigua retenida esté limpia.

El extremo inferior solo es razonable cuando la infección se detecta rápidamente, las copias antiguas están aisladas y ya se ha demostrado una restauración limpia.

Comience el conteo antes de que apareciera la nota de rescate

El evento visible de cifrado puede ocurrir días o semanas después del acceso inicial. Una estrategia de respaldo contra ransomware debe tener en cuenta el tiempo de permanencia entre el compromiso inicial y el evento visible de ransomware. Si el inicio de sesión sospechoso más temprano, script, uso de credenciales o cambio de archivo ocurrió 45 días antes del cifrado, una ventana de versiones de 30 días puede no contener un punto limpio.

Utilice la fecha de compromiso más temprana plausible según los registros, alertas de puntos finales, registros de identidad y hallazgos de respuesta a incidentes. Luego agregue un margen de seguridad para evidencia incompleta. La ventana de retención debe cubrir esa fecha, no solo la fecha en que los usuarios vieron por primera vez los archivos cifrados.

Utilice la retención escalonada en lugar de una ventana móvil única

Una ventana móvil plana puede eliminar cada punto limpio más antiguo en el mismo horario. La retención escalonada mantiene versiones recientes densas mientras preserva menos puntos de control a largo plazo.

Un análisis reciente de retención muestra por qué los puntos de restauración semanales y mensuales seleccionados pueden extender la recuperación más allá de una ventana corta comprometida. Los niveles exactos deben seguir el valor de tus datos, presupuesto de almacenamiento y capacidad de detección.

Preserva copias de la era del incidente fuera de la rotación normal

No permitas que la poda normal elimine las versiones, registros, catálogos de copias de seguridad, notas de rescate, muestras de archivos afectados y registros de configuración necesarios para entender el evento. Crea una retención por incidente o exporta esos artefactos a una ubicación protegida con acceso documentado.

La retención de evidencia de incidentes y la retención de copias de seguridad operativas resuelven problemas diferentes. El historial de copias de seguridad proporciona opciones de recuperación; la retención por incidente apoya el análisis del alcance, seguros, revisión legal y lecciones aprendidas. Coordina la eliminación con las personas responsables de esas obligaciones. Este artículo es una guía operativa, no un consejo legal.

Conservar más tiempo para archivos que cambian lentamente y se abren raramente

El ransomware puede modificar un archivo mucho antes de que alguien lo note si ese archivo se abre raramente. Los archivos archivados, registros fiscales, activos de diseño, proyectos maestros, fotos familiares y documentos históricos a menudo necesitan un historial de versiones más largo que las carpetas de trabajo activas.

Encuentra la última versión limpia antes de eliminar las anteriores

La versión más reciente antes del cifrado no es automáticamente segura. La recuperación cibernética requiere identificar un punto libre de indicadores de compromiso y que pueda ejecutarse sin reconectar al atacante. Un flujo de trabajo de recuperación debe asumir que la última copia de seguridad limpia es desconocida hasta que los puntos de restauración sean escaneados y validados.

Valide las versiones candidatas en un lugar aislado. Verifique la legibilidad de los archivos, los hashes cuando sean significativos, la consistencia de la aplicación, indicadores de malware, permisos de usuario y la capacidad de abrir archivos antiguos representativos. Mantenga las versiones antiguas hasta que al menos un punto limpio haya pasado esas pruebas.

Las pruebas de restauración establecen el umbral real de retención

Una política de retención solo es útil si las versiones pueden restaurarse. La guía de planificación de recuperación recomienda pruebas de restauración programadas para demostrar que la recuperación de archivos es realmente posible.

Pruebe al menos tres puntos: una versión reciente, una cerca del límite de compromiso sospechado y una ancla semanal o mensual más antigua. Si solo se prueba el punto más nuevo, no se sabe si las versiones a largo plazo necesarias para la recuperación de ransomware están completas, descifrables e indexadas correctamente.

Asegúrese de que las versiones antiguas sobrevivan a la ruta de ataque

Una retención prolongada en un recurso compartido escribible no proporciona protección a largo plazo si la misma cuenta comprometida puede eliminarla. Las versiones antiguas deben separarse por permisos, cuenta de almacenamiento, dominio administrativo, ruta de red o rotación fuera de línea. La inmutabilidad previene la eliminación temprana durante un período configurado, mientras que las copias fuera de línea eliminan la ruta de ataque en vivo.

La guía de ZimaSpace para proteger los planos de control de respaldo y las copias de recuperación inmutables explica por qué la configuración de retención, los repositorios, las credenciales y las consolas de respaldo deben protegerse juntos.

Verifique si el almacenamiento puede sostener el plan de retención

Estime la capacidad a partir de la tasa de cambio diaria, no solo del tamaño de los archivos activos. Un modelo simple de planificación es:

La capacidad de versión requerida ≈ copia base + cambios diarios retenidos + anclas semanales/mensuales + espacio temporal para restauración y verificación.

Mida el crecimiento real del repositorio durante varias semanas. Incluya compresión, deduplicación, rotación de base de datos, retención de archivos eliminados, períodos de bloqueo inmutable y el espacio de trabajo necesario para fusiones o pruebas de restauración. Si la capacidad es demasiado pequeña, reduzca la frecuencia de versiones para carpetas de bajo valor antes de acortar toda la ventana de puntos limpios.

Acorte la Retención Solo Después de Cumplir Condiciones Específicas

Puede considerar reducir el historial diario denso después de que todas las siguientes condiciones sean verdaderas:

• Se ha establecido con confianza razonable la fecha más temprana plausible de compromiso.
• Al menos un punto de recuperación limpio ha sido validado en aislamiento.
• La evidencia del incidente ha sido preservada fuera de la rotación normal de copias de seguridad.
• Los sistemas y archivos críticos han sido restaurados y verificados por sus propietarios.
• Los responsables de seguridad, legales, de seguros y cumplimiento han autorizado la eliminación normal.
• Los anclajes semanales y mensuales aún cubren descubrimientos tardíos y datos estacionales.

Si alguna condición no está resuelta, preserve los puntos más antiguos. La presión de almacenamiento no es una razón segura para eliminar las únicas versiones que pueden ser anteriores al ataque.

Actúe Rápidamente Cuando las Versiones Son Almacenadas por un Servicio de Sincronización en la Nube

Las ventanas de historial de archivos y papelera de reciclaje en la nube pueden ser más cortas que su política de respaldo, y los cambios por ransomware pueden sincronizarse en la nube. La guía de recuperación advierte que las versiones antiguas de archivos y los elementos eliminados pueden desaparecer cuando expira un límite de retención del servicio.

Desde un dispositivo limpio, congele la sincronización donde sea apropiado, preserve la cuenta, exporte versiones críticas y documente el punto limpio disponible más temprano. No asuma que el proveedor en la nube mantiene un historial ilimitado.

Preguntas Frecuentes

¿Cuándo se pueden eliminar versiones que pueden contener archivos cifrados?

Elimínelas solo después de entender el alcance del incidente, restaurar y probar versiones limpias, preservar evidencia y despejar cualquier retención legal o de seguro. Aísle versiones sospechosas en lugar de mezclarlas de nuevo en producción.

¿Más versiones siempre son más seguras?

No. Más versiones solo ayudan cuando están completas, protegidas contra eliminación, indexadas, descifrables y probadas regularmente. Cientos de versiones controladas por la misma cuenta comprometida aún pueden fallar juntas.

¿Deben las instantáneas y las copias de seguridad independientes usar el mismo período de retención?

Normalmente no. Las instantáneas locales son útiles para retrocesos densos a corto plazo, mientras que las copias de seguridad independientes o inmutables deben cubrir ventanas más largas contra ransomware y desastres. Use diferentes niveles de retención para que una falla de almacenamiento o compromiso de cuenta no borre todos los puntos de recuperación.