Hoe lang moet je bestandsversies bewaren na een ransomware-aanval?

Bewaar dagelijkse bestandsversies minstens 30 tot 90 dagen als praktisch startpunt na een ransomware-aanval, maar beschouw dit niet als een universele verwijderingsdeadline. De retentie moet verder gaan dan de vroegst aannemelijke compromitteringsdatum, geselecteerde wekelijkse of maandelijkse schone punten behouden en incidentbewijzen apart bewaren totdat herstel, onderzoek, verzekering, juridische en nalevingswerkzaamheden zijn afgerond.

Een praktisch startbereik is 30 tot 90 dagen

Veel back-upontwerpen gebruiken 30 tot 90 dagen dagelijkse onveranderlijke geschiedenis voor operationeel ransomwareherstel. Een overzicht van onveranderlijke back-ups vermeldt dat 30 tot 90 dagen een gangbare dagelijkse retentieperiode is voor ransomwarebescherming. Beschouw dit als een startpunt, niet als een garantie dat de oudste bewaarde versie schoon is.

De ondergrens is alleen redelijk wanneer de infectie snel wordt gedetecteerd, oudere kopieën geïsoleerd zijn en een schoon herstel al is bewezen.

Begin de klok voordat de losgeldbrief verscheen

De zichtbare versleutelingsgebeurtenis kan dagen of weken na de eerste toegang plaatsvinden. Een ransomware-back-upstrategie moet rekening houden met de verblijftijd tussen de eerste compromittering en de zichtbare ransomware-gebeurtenis. Als de vroegste verdachte aanmelding, script, inloggegevensgebruik of bestandswijziging 45 dagen voor de versleuteling plaatsvond, kan een versievenster van 30 dagen geen schoon herstelpunt bevatten.

Gebruik de vroegst aannemelijke compromitteringsdatum uit logs, eindpuntwaarschuwingen, identiteitsgegevens en bevindingen van incidentrespons. Voeg vervolgens een veiligheidsmarge toe voor onvolledig bewijs. Het retentievenster moet die datum omvatten, niet alleen de datum waarop gebruikers voor het eerst versleutelde bestanden zagen.

Gebruik gelaagde retentie in plaats van één doorlopend venster

Een vlak rollend venster kan elk ouder schone punt volgens hetzelfde schema verwijderen. Gelaagde retentie behoudt dichte recente versies terwijl minder lange-termijn controlepunten worden bewaard.

Een recente retentieanalyse toont waarom geselecteerde wekelijkse en maandelijkse herstelpunten het herstel kunnen verlengen voorbij een gecompromitteerd kort rollend venster. De exacte lagen moeten volgen op uw datawaarde, opslagbudget en detectiemogelijkheden.

Bewaar kopieën uit de incidentperiode buiten de normale rotatie

Laat normale opschoning niet de versies, logs, back-upcatalogi, losgeldnotities, getroffen bestandsvoorbeelden en configuratieregisters verwijderen die nodig zijn om het incident te begrijpen. Maak een incident-hold aan of exporteer die artefacten naar een beveiligde locatie met gedocumenteerde toegang.

Bewijs van incidenten en operationele back-upretentie lossen verschillende problemen op. De back-upgeschiedenis biedt herstelopties; de incident-hold ondersteunt scope-analyse, verzekering, juridische beoordeling en geleerde lessen. Coördineer verwijdering met de verantwoordelijken voor die verplichtingen. Dit artikel is operationele richtlijn, geen juridisch advies.

Bewaar langer voor langzaam veranderende en zelden geopende bestanden

Ransomware kan een bestand wijzigen lang voordat iemand het merkt als dat bestand zelden wordt geopend. Archieven, belastingdocumenten, ontwerpassets, projectmasters, familiefoto’s en historische documenten hebben vaak een langere versiegeschiedenis nodig dan actieve werkmappen.

Vind de nieuwste schone versie voordat u oudere verwijdert

De nieuwste versie vóór encryptie is niet automatisch veilig. Cyberherstel vereist het identificeren van een punt dat vrij is van compromitteringsindicatoren en kan draaien zonder de aanvaller opnieuw te verbinden. Een herstelworkflow moet aannemen dat het laatste schone backup onbekend is totdat herstelpunten zijn gescand en gevalideerd.

Valideer kandidaatversies op een geïsoleerde locatie. Controleer leesbaarheid van bestanden, hashes waar relevant, applicatieconsistentie, malware-indicatoren, gebruikersrechten en de mogelijkheid om representatieve oude bestanden te openen. Bewaar oudere versies totdat minstens één schoon punt deze tests heeft doorstaan.

Hersteltesten bepalen de echte retentiedrempel

Een retentiebeleid is alleen nuttig als de versies hersteld kunnen worden. Richtlijnen voor herstelplanning raden geplande hersteltests aan om te bewijzen dat bestandsherstel daadwerkelijk mogelijk is.

Test minstens drie punten: een recente versie, een versie nabij de vermoedelijke compromitteringsgrens, en een ouder wekelijks of maandelijks anker. Als alleen het nieuwste punt wordt getest, weet je niet of de langetermijnversies die nodig zijn voor ransomwareherstel compleet, ontsleutelbaar en correct geïndexeerd zijn.

Zorg dat oudere versies het aanvalspad overleven

Lange retentie op een schrijfbare share biedt geen langdurige bescherming als hetzelfde gecompromitteerde account het kan verwijderen. Oudere versies moeten gescheiden worden door permissies, opslagaccount, administratief domein, netwerkpad of offline rotatie. Onveranderlijkheid voorkomt vroegtijdige verwijdering gedurende een geconfigureerde periode, terwijl offline kopieën het live-aanvalspad verwijderen.

De ZimaSpace-gids voor het beschermen van backup control planes en onveranderlijke herstelkopieën legt uit waarom retentie-instellingen, repositories, referenties en backup consoles samen beschermd moeten worden.

Controleer of de opslag het retentieplan kan volhouden

Schat de capaciteit op basis van het dagelijkse wijzigingspercentage, niet alleen de grootte van de actieve bestanden. Een eenvoudig planningsmodel is:

Vereiste versiecapaciteit ≈ basis kopie + behouden dagelijkse wijzigingen + wekelijkse/maandelijkse ankers + tijdelijke herstel- en verificatieruimte.

Meet de werkelijke groei van de opslagplaats gedurende enkele weken. Houd rekening met compressie, deduplicatie, databaseverversing, retentie van verwijderde bestanden, onveranderlijke vergrendelingsperioden en de werkruimte die nodig is voor samenvoegingen of hersteltests. Als de capaciteit te klein is, verminder dan de versiefrequentie voor mappen met lage waarde voordat je het hele schone-puntvenster verkort.

Verkort retentie alleen nadat aan specifieke voorwaarden is voldaan

Je kunt overwegen de dichte dagelijkse geschiedenis te verkorten nadat het volgende allemaal waar is:

• De vroegst aannemelijke datum van compromis is met redelijke zekerheid vastgesteld.
• Ten minste één schoon herstelpunt is geïsoleerd gevalideerd.
• Bewijs van het incident is buiten de normale back-uprotatie veiliggesteld.
• Kritieke systemen en bestanden zijn hersteld en geverifieerd door hun eigenaren.
• Beveiligings-, juridische-, verzekerings- en compliancebelanghebbenden hebben normale verwijdering goedgekeurd.
• Wekelijkse en maandelijkse ankerpunten dekken nog steeds vertraagde ontdekking en seizoensgebonden data.

Als een voorwaarde niet is opgelost, behoud dan de oudere punten. Opslagdruk is geen veilige reden om de enige versies te verwijderen die mogelijk ouder zijn dan de aanval.

Handel snel wanneer versies worden opgeslagen door een cloud-synchronisatiedienst

Cloud-bestandsgeschiedenis en prullenbakvensters kunnen korter zijn dan je back-upbeleid, en ransomwarewijzigingen kunnen in de cloud worden gesynchroniseerd. Herstelrichtlijnen waarschuwen dat oudere bestandsversies en verwijderde items kunnen verdwijnen wanneer een service-retentiegrens verloopt.

Bevries synchronisatie vanaf een schoon apparaat waar nodig, behoud het account, exporteer kritieke versies en documenteer het vroegst beschikbare schone punt. Ga er niet van uit dat de cloudprovider onbeperkte geschiedenis bewaart.

Veelgestelde vragen

Wanneer kun je versies verwijderen die mogelijk versleutelde bestanden bevatten?

Verwijder ze pas nadat de omvang van het incident is begrepen, schone versies zijn hersteld en getest, bewijs is veiliggesteld en eventuele juridische of verzekeringsbeperkingen zijn opgeheven. Isoleer verdachte versies in plaats van ze terug te mengen in de productieomgeving.

Zijn meer versies altijd veiliger?

Nee. Meer versies helpen alleen als ze compleet zijn, beschermd tegen verwijdering, geïndexeerd, ontsleuteld en regelmatig getest. Honderden versies die door hetzelfde gecompromitteerde account worden beheerd, kunnen nog steeds samen falen.

Moeten snapshots en onafhankelijke back-ups dezelfde retentieperiode gebruiken?

Meestal niet. Lokale snapshots zijn nuttig voor frequente korte-termijn terugdraaiingen, terwijl onafhankelijke of onveranderlijke back-ups langere ransomware- en rampenvensters moeten dekken. Gebruik verschillende retentieniveaus zodat één opslagfout of accountcompromis niet elk herstelpunt wist.