Hur länge bör du behålla filversioner efter en ransomware-attack?

Behåll dagliga filversioner i minst 30 till 90 dagar som ett praktiskt startintervall efter en ransomware-attack, men behandla inte detta som en universell raderingsdeadline. Lagringen bör sträcka sig bortom det tidigaste rimliga kompromissdatumet, bevara utvalda veckovisa eller månatliga rena punkter och hålla incidentbevis separat tills återställning, utredning, försäkring, juridik och efterlevnadsarbete är slutförda.

Ett praktiskt startintervall är 30 till 90 dagar

Många backupdesigner använder 30 till 90 dagar av daglig oföränderlig historik för operativ ransomware-återställning. En översikt över oföränderliga backuper noterar att 30 till 90 dagar är ett vanligt dagligt lagringsintervall för ransomware-skydd. Behandla detta som en utgångspunkt, inte en garanti för att den äldsta behållna versionen är ren.

Den nedre gränsen är bara rimlig när infektionen upptäcks snabbt, äldre kopior är isolerade och en ren återställning redan har bevisats.

Starta klockan innan lösenordsmeddelandet dök upp

Den synliga krypteringsevenemanget kan inträffa dagar eller veckor efter den initiala åtkomsten. En backupstrategi för ransomware bör ta hänsyn till den tid som förflyter mellan initial kompromiss och det synliga ransomware-evenemanget. Om den tidigaste misstänkta inloggningen, skriptet, användningen av referenser eller filändringen skedde 45 dagar före krypteringen, kan ett 30-dagars versionsfönster sakna en ren punkt.

Använd det tidigaste rimliga kompromissdatumet från loggar, slutpunktvarningar, identitetsposter och incidentresponsfynd. Lägg sedan till en säkerhetsmarginal för ofullständiga bevis. Lagringsfönstret bör täcka det datumet, inte bara det datum då användare först såg krypterade filer.

Använd lagerbaserad lagring istället för ett enda rullande fönster

Ett platt rullande fönster kan radera varje äldre ren punkt enligt samma schema. Tierad lagring behåller täta senaste versioner samtidigt som färre långsiktiga kontrollpunkter bevaras.

En aktuell analys av lagringstider visar varför utvalda veckovisa och månatliga återställningspunkter kan förlänga återställningen bortom ett komprometterat kort rullande fönster. De exakta nivåerna bör följa ditt datavärde, lagringsbudget och upptäcktsförmåga.

Bevara kopior från incidentperioden utanför normal rotation

Låt inte normal rensning ta bort versioner, loggar, backup-kataloger, lösenordsmeddelanden, påverkade filprover och konfigurationsregister som behövs för att förstå händelsen. Skapa ett incidenthåll eller exportera dessa artefakter till en skyddad plats med dokumenterad åtkomst.

Bevis från incidenter och operativ backup-lagring löser olika problem. Backup-historiken ger återställningsalternativ; incidenthåll stöder omfattningsanalys, försäkring, juridisk granskning och lärdomar. Samordna radering med ansvariga för dessa skyldigheter. Denna artikel är operativ vägledning, inte juridisk rådgivning.

Behåll längre för långsamt föränderliga och sällan öppnade filer

Ransomware kan ändra en fil långt innan någon märker det om filen sällan öppnas. Arkiv, skatteregister, designresurser, projektmästare, familjefoton och historiska dokument behöver ofta längre versionshistorik än aktiva arbetsmappar.

Hitta den senaste rena versionen innan du raderar äldre

Den nyaste versionen före kryptering är inte automatiskt säker. Cyberåterställning kräver att man identifierar en punkt som är fri från tecken på kompromiss och kan köras utan att angriparen återansluts. Ett återställningsflöde bör anta att den senaste rena backupen är okänd tills återställningspunkterna skannats och verifierats.

Verifiera kandidatversioner på en isolerad plats. Kontrollera filläsbarhet, hashvärden där det är meningsfullt, applikationskonsistens, tecken på skadlig kod, användarbehörigheter och förmågan att öppna representativa gamla filer. Behåll äldre versioner tills minst en ren punkt har klarat dessa tester.

Återställningstestning sätter den verkliga behållningströskeln

En behållningspolicy är bara användbar om versionerna kan återställas. Riktlinjer för återställningsplanering rekommenderar schemalagda återställningstester för att bevisa att filåterställning faktiskt är möjlig.

Testa minst tre punkter: en nyligen version, en nära den misstänkta kompromissgränsen och en äldre veckovis eller månatlig ankare. Om endast den nyaste punkten testas vet du inte om de långsiktiga versionerna som behövs för ransomware-återställning är kompletta, dekrypterbara och korrekt indexerade.

Se till att äldre versioner överlever angreppsvägen

Lång behållning på en skrivbar delning ger inte långsiktigt skydd om samma komprometterade konto kan radera den. Äldre versioner bör separeras genom behörigheter, lagringskonto, administrativ domän, nätverksväg eller offline-rotation. Oföränderlighet förhindrar tidig radering under en konfigurerad period, medan offline-kopior tar bort den aktiva angreppsvägen.

ZimaSpace-guiden för skydd av backupkontrollplaner och oföränderliga återställningskopior förklarar varför behållningsinställningar, arkiv, autentiseringsuppgifter och backupkonsoler måste skyddas tillsammans.

Kontrollera om lagringen kan upprätthålla behållningsplanen

Uppskatta kapaciteten utifrån den dagliga ändringshastigheten, inte bara storleken på de aktiva filerna. En enkel planeringsmodell är:

Nödvändig versionskapacitet ≈ grundkopian + behållna dagliga ändringar + veckovisa/månatliga ankare + temporärt utrymme för återställning och verifiering.

Mät faktisk tillväxt i arkivet under flera veckor. Inkludera komprimering, deduplicering, databasomsättning, behållning av raderade filer, oföränderliga låsperioder och det arbetsutrymme som behövs för sammanslagningar eller återställningstester. Om kapaciteten är för liten, minska versionsfrekvensen för mappar med lågt värde innan hela fönstret för rena punkter förkortas.

Förkorta behållning endast efter att specifika villkor är uppfyllda

Du kan överväga att minska tät daglig historik efter att alla följande är sanna:

• Det tidigaste rimliga kompromissdatumet har fastställts med rimlig säkerhet.
• Minst en ren återställningspunkt har validerats i isolering.
• Incidentbevis har bevarats utanför normal säkerhetskopieringsrotation.
• Kritiska system och filer har återställts och verifierats av sina ägare.
• Säkerhets-, juridiska, försäkrings- och efterlevnadsintressenter har godkänt normal radering.
• Veckovisa och månatliga ankare täcker fortfarande fördröjd upptäckt och säsongsdata.

Om någon förutsättning inte är löst, bevara de äldre punkterna. Lagringstryck är inte en säker anledning att radera de enda versionerna som kan föregå attacken.

Agera snabbt när versioner lagras av en molnsynkroniseringstjänst

Molnfilshistorik och papperskorgsfönster kan vara kortare än din säkerhetskopieringspolicy, och ransomwareförändringar kan synkroniseras till molnet. Återställningsråd varnar för att äldre filversioner och raderade objekt kan försvinna när en tjänstebegränsning löper ut.

Från en ren enhet, pausa synkronisering där det är lämpligt, bevara kontot, exportera kritiska versioner och dokumentera den tidigaste tillgängliga rena punkten. Anta inte att molnleverantören behåller obegränsad historik.

Vanliga frågor

När kan du radera versioner som kan innehålla krypterade filer?

Radera dem endast efter att incidentens omfattning är förstådd, rena versioner har återställts och testats, bevis har bevarats och eventuella juridiska eller försäkringsrelaterade spärrar har hävts. Isolera misstänkta versioner istället för att blanda tillbaka dem i produktionen.

Är fler versioner alltid säkrare?

Nej. Fler versioner hjälper bara när de är kompletta, skyddade från radering, indexerade, avkrypterbara och regelbundet testade. Hundratals versioner som kontrolleras av samma komprometterade konto kan fortfarande misslyckas samtidigt.

Bör snapshots och oberoende säkerhetskopior använda samma behållningstid?

Vanligtvis inte. Lokala snapshots är användbara för tät kortsiktig återställning, medan oberoende eller oföränderliga säkerhetskopior bör täcka längre ransomware- och katastroffönster. Använd olika behållningstider så att ett lagringsfel eller ett kontoövertagande inte raderar alla återställningspunkter.