Per quanto tempo dovresti conservare le versioni dei file dopo un attacco ransomware?

Conserva le versioni giornaliere dei file per almeno 30-90 giorni come intervallo pratico di partenza dopo un attacco ransomware, ma non considerarlo una scadenza universale per l'eliminazione. La conservazione dovrebbe estendersi oltre la data di compromissione più plausibile e precoce, preservare punti puliti settimanali o mensili selezionati e mantenere le prove dell'incidente separatamente fino al completamento del recupero, dell'indagine, dell'assicurazione, delle questioni legali e di conformità.

Un intervallo pratico di partenza è da 30 a 90 giorni

Molti progetti di backup utilizzano da 30 a 90 giorni di cronologia giornaliera immutabile per il recupero operativo da ransomware. Una panoramica sui backup immutabili nota che 30-90 giorni è un intervallo comune di conservazione giornaliera per la protezione da ransomware. Consideralo come punto di partenza, non come garanzia che la versione più vecchia conservata sia pulita.

Il limite inferiore è ragionevole solo quando l'infezione viene rilevata rapidamente, le copie più vecchie sono isolate e un ripristino pulito è già stato dimostrato.

Inizia il conteggio prima che appaia la richiesta di riscatto

L'evento di crittografia visibile può verificarsi giorni o settimane dopo l'accesso iniziale. Una strategia di backup per ransomware dovrebbe tenere conto del tempo di permanenza tra la compromissione iniziale e l'evento ransomware visibile. Se il primo accesso sospetto, script, uso di credenziali o modifica di file è avvenuto 45 giorni prima della crittografia, una finestra di versioni di 30 giorni potrebbe non contenere alcun punto pulito.

Usa la data di compromissione più plausibile e precoce dai log, dagli avvisi degli endpoint, dai record di identità e dai risultati della risposta agli incidenti. Poi aggiungi un margine di sicurezza per le prove incomplete. La finestra di conservazione dovrebbe coprire quella data, non solo la data in cui gli utenti hanno visto per la prima volta i file crittografati.

Usa la conservazione a livelli invece di una singola finestra mobile

Una finestra mobile piatta può eliminare ogni punto pulito più vecchio con la stessa cadenza. La conservazione a livelli mantiene versioni recenti dense preservando meno checkpoint a lungo termine.

Un'analisi recente della conservazione mostra perché i punti di ripristino settimanali e mensili selezionati possono estendere il recupero oltre una finestra breve compromessa. I livelli esatti dovrebbero seguire il valore dei tuoi dati, il budget di archiviazione e la capacità di rilevamento.

Preserva copie dell'epoca dell'incidente fuori dalla rotazione normale

Non lasciare che la potatura normale elimini le versioni, i log, i cataloghi di backup, le note di riscatto, i campioni di file interessati e i record di configurazione necessari per comprendere l'evento. Crea una conservazione per incidente o esporta quegli artefatti in una posizione protetta con accesso documentato.

La conservazione delle prove di incidente e il backup operativo risolvono problemi diversi. La storia del backup fornisce opzioni di recupero; la conservazione per incidente supporta l'analisi dell'ambito, l'assicurazione, la revisione legale e le lezioni apprese. Coordina l'eliminazione con le persone responsabili di tali obblighi. Questo articolo è una guida operativa, non un consiglio legale.

Conserva più a lungo i file che cambiano lentamente e sono raramente aperti

Il ransomware può modificare un file molto prima che qualcuno se ne accorga se quel file viene aperto raramente. Archivi, documenti fiscali, risorse di design, progetti master, foto di famiglia e documenti storici spesso necessitano di una storia delle versioni più lunga rispetto alle cartelle di lavoro attive.

Trova l'ultima versione pulita prima di eliminare quelle più vecchie

La versione più recente prima della crittografia non è automaticamente sicura. Il recupero cyber richiede di identificare un punto privo di indicatori di compromissione e che possa funzionare senza ricollegare l’attaccante. Un flusso di lavoro di recupero dovrebbe presumere che l’ultimo backup pulito sia sconosciuto finché i punti di ripristino non sono scansionati e convalidati.

Valida le versioni candidate in un luogo isolato. Controlla la leggibilità dei file, gli hash dove significativi, la coerenza delle applicazioni, gli indicatori di malware, i permessi utente e la capacità di aprire file vecchi rappresentativi. Mantieni le versioni più vecchie finché almeno un punto pulito non ha superato questi test.

Il test di ripristino stabilisce la vera soglia di retention

Una politica di retention è utile solo se le versioni possono essere ripristinate. Le linee guida per la pianificazione del recupero raccomandano test di ripristino programmati per dimostrare che il recupero dei file è effettivamente possibile.

Testa almeno tre punti: una versione recente, una vicino al confine di compromissione sospetta e una vecchia ancora settimanale o mensile. Se testi solo il punto più recente, non sai se le versioni a lungo termine necessarie per il recupero da ransomware sono complete, decriptabili e indicizzate correttamente.

Assicurati che le versioni più vecchie sopravvivano al percorso di attacco

Una retention lunga su una condivisione scrivibile non garantisce protezione a lungo termine se lo stesso account compromesso può eliminarla. Le versioni più vecchie dovrebbero essere separate per permessi, account di storage, dominio amministrativo, percorso di rete o rotazione offline. L'immutabilità impedisce l'eliminazione anticipata durante un periodo configurato, mentre le copie offline rimuovono il percorso di attacco attivo.

La guida di ZimaSpace su protezione dei piani di controllo dei backup e delle copie di recupero immutabili spiega perché le impostazioni di retention, i repository, le credenziali e le console di backup devono essere protetti insieme.

Verifica se lo storage può sostenere il piano di retention

Stima la capacità dal tasso di modifica giornaliero, non solo dalla dimensione dei file attivi. Un modello di pianificazione semplice è:

Capacità versione richiesta ≈ copia di base + modifiche giornaliere mantenute + ancore settimanali/mensili + spazio temporaneo per ripristino e verifica.

Misura la crescita effettiva del repository per diverse settimane. Includi compressione, deduplicazione, turnover del database, conservazione dei file eliminati, periodi di blocco immutabili e lo spazio di lavoro necessario per fusioni o test di ripristino. Se la capacità è troppo piccola, riduci la frequenza delle versioni per le cartelle a basso valore prima di accorciare l'intera finestra dei punti puliti.

Accorcia la conservazione solo dopo che sono state soddisfatte condizioni specifiche

Puoi considerare di ridurre la cronologia giornaliera densa solo dopo che tutte le seguenti condizioni sono vere:

• La data più antica plausibile di compromissione è stata stabilita con ragionevole certezza.
• Almeno un punto di recupero pulito è stato convalidato in isolamento.
• Le prove dell'incidente sono state preservate al di fuori della rotazione normale dei backup.
• I sistemi e i file critici sono stati ripristinati e verificati dai loro proprietari.
• Gli stakeholder di sicurezza, legali, assicurativi e di conformità hanno autorizzato la cancellazione normale.
• Gli ancoraggi settimanali e mensili coprono ancora la scoperta ritardata e i dati stagionali.

Se una qualsiasi condizione non è risolta, conserva i punti più vecchi. La pressione di archiviazione non è una ragione sicura per eliminare le uniche versioni che potrebbero precedere l'attacco.

Agisci rapidamente quando le versioni sono archiviate da un servizio di sincronizzazione cloud

Le finestre di cronologia file e cestino nel cloud possono essere più brevi della tua politica di backup, e le modifiche da ransomware possono sincronizzarsi nel cloud. Le linee guida per il recupero avvertono che le versioni più vecchie dei file e gli elementi eliminati possono scomparire quando scade un limite di conservazione del servizio.

Da un dispositivo pulito, blocca la sincronizzazione dove appropriato, conserva l'account, esporta le versioni critiche e documenta il punto pulito più antico disponibile. Non dare per scontato che il provider cloud mantenga una cronologia illimitata.

Domande Frequenti

Quando si possono eliminare versioni che potrebbero contenere file criptati?

Eliminale solo dopo aver compreso l'entità dell'incidente, aver ripristinato e testato versioni pulite, preservato le prove e risolto eventuali vincoli legali o assicurativi. Isola le versioni sospette invece di reintegrarle in produzione.

Più versioni sono sempre più sicure?

No. Più versioni aiutano solo se sono complete, protette dalla cancellazione, indicizzate, decriptabili e testate regolarmente. Centinaia di versioni controllate dallo stesso account compromesso possono comunque fallire insieme.

Gli snapshot e i backup indipendenti dovrebbero usare lo stesso periodo di conservazione?

Di solito no. Gli snapshot locali sono utili per rollback densi a breve termine, mentre backup indipendenti o immutabili dovrebbero coprire finestre più lunghe contro ransomware e disastri. Usa diversi livelli di conservazione in modo che un guasto di archiviazione o una compromissione dell'account non cancellino ogni punto di recupero.