Wat is back-upretentie?
Back-upretentie is het behouden van kopieën van kritieke data gedurende vastgestelde perioden, bepaald door regelgeving, wettelijke en cybersecurity-eisen. Het bepaalt hoe lang u herstelpunten bewaart, waar u deze opslaat en hoe u ze beschermt tegen aanvallen die uw productieomgeving kunnen compromitteren.
De risico’s zijn reëel. Tijdens het ransomware-incident bij MGM Resorts in 2023 meldde het bedrijf een impact van circa $100 miljoen op de aangepaste EBITDA in een SEC-aanvraag. Wanneer aanvallers uw back-ups bereiken of corrumperen, overstijgt de impact de IT-uitval en wordt het een financieel bedrijfsrisico op ondernemingsniveau.
Veel organisaties behandelen back-upretentie nog steeds als een opslaglogistiek probleem. Het verschil tussen organisaties die herstellen en organisaties die losgeld betalen, hangt af van hoe zij hun back-upretentiebeleid ontwerpen, implementeren en handhaven.
De CISA #StopRansomware Guide wijst back-upretentie aan als Cross-Sector Cybersecurity Performance Goal 2.R: onderhoud offline, versleutelde back-ups van kritieke data en test regelmatig hun beschikbaarheid en integriteit. Dit is een federale cybersecurity-baseline.
Ransomwaregroepen richten zich nu primair op back-upinfrastructuur. Uw back-upretentiebeleid is het plan dat bepaalt of die back-ups overleven.
.jpg)
Hoe back-upretentiebeleid zich verhoudt tot cybersecurity
Back-upretentiebeleid is een defensieve maatregel. Het NIST Cybersecurity Framework 2.0 legt dit vast onder Subcategorie PR.DS-11, waarbij vereist is dat back-ups worden aangemaakt, beschermd, onderhouden en getest. Daarmee valt back-upretentie binnen uw beschermende controle-architectuur, naast endpointbescherming, toegangsbeheer en netwerksegmentatie.
Het cybersecurity-belang wordt duidelijk wanneer u het gedrag van aanvallers onderzoekt. Volgens NIST SP 800-209 kunnen aanvallers het back-upproces zelf verstoren en geleidelijk toekomstige kopieën vergiftigen, zodat de enige beschikbare back-ups al zijn gecorrumpeerd. De retentieduur bepaalt direct of u een schoon herstelpunt behoudt dat voorafgaat aan de compromittering.
Tijdens het Colonial Pipeline ransomware-incident in 2021 beschreef het Amerikaanse ministerie van Justitie een losgeldbetaling van $4,4 miljoen in haar DOJ-publicatie. Back-upretentie stopt ransomware niet op zichzelf, maar bepaalt wel of u kunt herstellen en hervatten zonder te onderhandelen.
Uw back-upretentiebeleid bepaalt hoe ver u terug kunt herstellen, hoe snel u kunt herstellen en of aanvallers uw mogelijkheid om losgeld te weigeren kunnen elimineren.
Hoe back-upretentiebeleid werkt
Een back-upretentiebeleid regelt de levenscyclus van elke back-upkopie die uw organisatie maakt. Het specificeert aanmaakfrequentie, opslaglocaties, beschermingsmechanismen, retentieduur en verwijderingsprocedures voor elke dataklasse.
Het 3-2-1-1-0-framework
De industriestandaard is geëvolueerd van de 3-2-1-regel naar het 3-2-1-1-0-framework om in te spelen op huidige ransomwaretactieken.
Het framework vereist:
- 3 back-upkopieën naast productiedata
- 2 verschillende mediatypen ter bescherming tegen verschillende risicoklassen
- 1 kopie offsite opgeslagen voor geografische scheiding
- 1 onveranderlijke of fysiek gescheiden kopie, plus 0 fouten bij back-upverificatietests
Het afdwingen van al deze eisen verkleint de kans dat één compromittering alle herstelopties vernietigt.
Retentieniveaus en -duur
Uw back-upretentiebeleid moet retentieperioden definiëren op basis van dataclassificatie, regelgeving en hersteldoelstellingen. Volgens Gartner's Peer Community maken organisaties doorgaans onderscheid tussen back-upkopieën voor disaster recovery (30 tot 90 dagen) en gearchiveerde data voor compliance (geregeld door sectorspecifieke eisen).
Twee tijdsgebonden doelstellingen sturen elke retentiebeslissing:
- Recovery Point Objective (RPO): De maximaal acceptabele ouderdom van data voor herstel. Een RPO van vier uur betekent dat u niet meer dan vier uur aan data mag verliezen.
- Recovery Time Objective (RTO): De maximaal acceptabele uitvaltijd. Dit bepaalt hoe snel uw retentie-infrastructuur bruikbare herstelpunten moet leveren.
Samen bepalen RPO en RTO hoe vaak u back-ups maakt en hoe snel uw retentie-infrastructuur deze moet leveren tijdens een incident.
Onveranderlijkheid en toegangscontrole
Onveranderlijke back-ups gebruiken WORM (Write Once Read Many)-technologie om wijziging of verwijdering te voorkomen, zelfs door beheerders met volledige rechten. NIST SP 1800-25 stelt dat back-upsystemen de toegang moeten beperken tot één serviceaccount op bekende machines, met rolgebaseerde toegangscontrole, MFA en gescheiden authenticatiekaders van productie.
Deze mechanismen vormen de basis, maar de manier waarop u uw back-ups structureert bepaalt hoe effectief uw retentiebeleid elke dataklasse beschermt.
Back-uptypen en retentiestrategieën
Uw back-upretentiebeleid moet rekening houden met de verschillende back-upmethoden die uw organisatie gebruikt. Elk type creëert een andere herstelketen met verschillende opslag-, snelheid- en risicoprofielen.
- Volledige back-ups: Een volledige back-up kopieert alle geselecteerde data in één operatie. NIST SP 800-34 adviseert dat beleid de back-upfrequentie specificeert op basis van datakritiek en de snelheid waarmee nieuwe informatie wordt toegevoegd. Volledige back-ups herstellen het snelst omdat slechts één back-upset nodig is, maar ze verbruiken de meeste opslag en duren het langst om te voltooien.
- Incrementele back-ups: Een incrementele back-up legt alleen de data vast die sinds de laatste back-up van welk type dan ook is gewijzigd. Elke incrementele back-up is klein en snel, maar herstel vereist de laatste volledige back-up plus elke daaropvolgende incrementele back-up. Als een schakel in die keten is gecorrumpeerd, verliest u toegang tot alle volgende herstelpunten.
- Differentiële back-ups: Een differentiële back-up legt alle wijzigingen vast sinds de laatste volledige back-up, ongeacht hoeveel differentiëlen er zijn uitgevoerd. Differentiëlen worden elke dag groter, maar herstellen sneller dan incrementele back-ups omdat u slechts twee back-upsets nodig heeft: de laatste volledige en de meest recente differentiële.
- Combineren van methoden met GFS-rotatie: De meeste organisaties combineren deze methoden met een Grandfather-Father-Son (GFS)-rotatie: wekelijkse volledige back-ups die maandenlang worden bewaard, dagelijkse differentiëlen of incrementele back-ups die wekenlang worden bewaard, en maandelijkse of jaarlijkse archiefkopieën voor compliance. Uw retentieschema moet verschillende duur per niveau specificeren. Bijvoorbeeld: dagelijkse incrementele back-ups verlopen na 14 dagen, wekelijkse volledige back-ups na 90 dagen en maandelijkse archiefkopieën na één tot zeven jaar, afhankelijk van regelgeving.
Het gekozen back-uptype beïnvloedt ook uw RPO. Uurlijkse incrementele back-ups geven een strakkere RPO dan dagelijkse differentiëlen, maar creëren langere herstelketens die uw RTO verhogen. Koppel elke dataklasse aan de back-upmethode en retentieduur die deze doelstellingen in balans brengt.
Best practices voor back-upretentiebeleid
Een back-upretentiebeleid op papier is slechts zo sterk als de implementatie ervan. Elke best practice hieronder adresseert een specifiek faalmechanisme dat is waargenomen in echte incidenten, van back-upvergiftiging en identiteitscompromittering tot niet-geteste herstelprocedures en onvoldoende monitoring.
1. Handhaaf onveranderlijke back-upopslag voor minimaal 30 tot 90 dagen
Configureer onveranderlijke retentieperioden op basis van de gemiddelde dwell time van dreigingen binnen uw organisatie. De CISA LockBit-advies vereist dat alle back-updata versleuteld, onveranderlijk en de volledige datainfrastructuur van de organisatie dekken.
Een venster van 90 dagen houdt rekening met langzame, persistente compromitteringen die NIST SP 800-209 beschrijft als back-upvergiftiging, waarbij aanvallers kopieën geleidelijk corrumperen over weken voordat encryptie op productiesystemen wordt geactiveerd. Kortere vensters van 30 dagen beschermen tegen snel ontdekte aanvallen, maar dekken mogelijk geen langere dwell times.
2. Implementeer fysiek of logisch gescheiden opslag
Uw onveranderlijke back-ups verliezen hun waarde als aanvallers ze kunnen bereiken via dezelfde netwerkpaden als waarmee productie is gecompromitteerd. NIST NCCoE-richtlijnen benadrukken volledige isolatie via fysieke air-gapping (offline tape of verwijderbare media zonder netwerkverbinding) of logische air-gapping (online opslag met object-level retentiebeleid en sterke identiteitscheiding). In beide gevallen mogen aanvallers niet kunnen pivoteren van uw productie-identiteitsvlak naar uw back-upcontrolevlak.
3. Test herstel met nul foutentolerantie
De "0" in 3-2-1-1-0 betekent nul tolerantie voor niet-geteste herstelprocedures. NIST Cybersecurity Framework 2.0 vereist expliciet dat back-ups worden getest, waarmee dit wordt verheven van aanbevolen praktijk tot formele cybersecurity-uitkomstvereiste.
Bouw een testfrequentie die past bij uw risicoprofiel:
- Valideer maandelijks het herstel van kritieke systemen
- Voer elk kwartaal volledige hersteltests uit die ransomware-scenario’s simuleren
- Voer halfjaarlijks of jaarlijks volledige herstel-oefeningen uit voor ISO 27001-auditgereedheid
Elke test moet de werkelijke hersteltijd meten ten opzichte van uw RTO en de dataintegriteit verifiëren via checksums. Behandel elke mislukte test als een P1-incident en los deze op vóór de volgende cyclus.
4. Implementeer geïsoleerde herstelomgevingen
NIST NCCoE-richtlijnen adviseren geïsoleerde herstelomgevingen (IRE’s) met Immutable Data Vaults (IDV’s). Dit zijn veilige, geïsoleerde omgevingen waar u back-updata herstelt en analyseert zonder malware opnieuw te introduceren. Uw IRE vereist gescheiden authenticatiekaders, aparte netwerksegmenten en onafhankelijke beheerderspaden.
5. Versleutel back-ups en scheid sleutelbeheer
Pas AES-256 versleuteling toe in rust en TLS 1.3 tijdens transport volgens ISO 27001-richtlijnen. Sla encryptiesleutels gescheiden op van back-updata met aparte roltoewijzingen. Vereis MFA voor sleutelverwijderingsacties. Als een aanvaller zowel uw back-updata als encryptiesleutels via hetzelfde toegangspad compromitteert, biedt encryptie geen bescherming.
6. Integreer back-uptelemetrie met security operations
Uw back-upinfrastructuur genereert signalen die uw SOC moet monitoren. NIST SP 800-61 stelt dat back-upsystemen moeten integreren met incident response-mogelijkheden. Voer back-uptelemetrie in uw SIEM of XDR-platform in en let op:
- Plotselinge veranderingen in back-upgrootte of -duur
- Overgeslagen of mislukte back-uptaken
- Ongebruikelijke inlogpatronen op back-upinfrastructuur
- Onverwachte pogingen tot wijziging of verwijdering
Deze afwijkingen komen vaak aan het licht voordat ransomware encryptie activeert. Het Singularity Platform van SentinelOne kan deze telemetrie correleren met endpoint- en cloudsignalen, zodat uw analisten context krijgen over de volledige aanvalsketen.
7. Onderhoud golden images en infrastructure-as-code back-ups
De CISA #StopRansomware Guide adviseert organisaties om golden images van kritieke systemen te onderhouden en infrastructure-as-code (IaC) te gebruiken voor het uitrollen van cloudresources, waarbij sjabloonback-ups offline worden bewaard. Versiebeheer uw IaC-sjablonen en audit wijzigingen om volledige reconstructie van omgevingen mogelijk te maken.
8. Implementeer quorumgoedkeuring voor destructieve acties
Geen enkele beheerder mag alleen onveranderlijke back-ups kunnen verwijderen of wijzigen. Vereis quorumgoedkeuring (meerdere bevoegde personen) voor elke actie die back-upkopieën vermindert, retentieperioden verkort of onveranderlijkheid uitschakelt. Dit beschermt tegen zowel insider threats als gecompromitteerde bevoorrechte accounts.
Na implementatie van deze controles, koppel retentieperioden en testbewijzen aan uw compliancekaders.
Regelgevende compliance-eisen voor back-upretentie
Back-upretentieperioden zijn niet alleen beveiligingsbeslissingen. Het zijn complianceverplichtingen met audit- en juridische consequenties. De uitdaging is dat verschillende kaders verschillende eisen stellen, en veel organisaties onder meerdere kaders vallen. Wanneer regelgeving conflicteert, hanteer de langste toepasselijke back-upretentie-eis en documenteer de rechtvaardiging per dataklasse.
HIPAA
HIPAA specificeert geen retentieperioden voor back-updata, maar vereist procedures om exacte, opvraagbare kopieën van elektronische beschermde gezondheidsinformatie (ePHI) te maken en te behouden onder 45 CFR § 164.308(a)(7). De HHS HIPAA-serie vereist een minimale retentieperiode van zes jaar voor beveiligingsdocumentatie.
GDPR
EDPB-richtlijnen 4/2019 vereisen verwijdering van persoonsgegevens wanneer deze niet langer nodig zijn. GDPR beschouwt back-ups als verwerking onder EDPB-richtlijnen 9/2022, waardoor ze onder alle gegevensbeschermingseisen vallen. Documenteer uw zakelijke rechtvaardiging voor elke retentieperiode.
PCI-DSS
PCI-DSS Vereiste 10.7 vereist één jaar retentie van audittrails met drie maanden direct beschikbaar. Vereiste 3.1 vereist kwartaalverificatie dat opgeslagen data die de retentieperiode overschrijdt, veilig wordt verwijderd.
SOC 2
SOC 2 schrijft geen retentieperioden voor. Definieer uw eigen beleid, documenteer het, volg het consequent en toon effectieve controlewerking aan tijdens audits.
Framework | Back-updataretentie | Documentatieretentie | Testen vereist | Encryptie vereist |
HIPAA | Risicogebaseerd (niet gespecificeerd) | Minimaal 6 jaar | Ja | Adresbaar voorschrift |
GDPR | Doelbeperkt met gedocumenteerde rechtvaardiging | Volgens verantwoordingsprincipe | Ja (tijdig herstel) | Vereist onder Artikel 32 |
PCI-DSS | Op zakelijke rechtvaardiging, kwartaalverificatie | 1 jaar auditlogs (3 maanden online) | Impliciet | Verplicht voor kaarthouderdata |
SOC 2 | Door organisatie gedefinieerd en gedocumenteerd | Volgens organisatiebeleid | Ja (beschikbaarheidscriteria) | Vereist (beveiligingscriteria) |
Compliance-afstemming is noodzakelijk maar niet voldoende. U moet ook plannen voor faalmechanismen die back-upretentie in de praktijk ondermijnen.
Uitdagingen en beperkingen van back-upretentiebeleid
Zelfs goed ontworpen retentiebeleid ondervinden implementatiebarrières die pas tijdens echte incidenten aan het licht komen. De meest voorkomende fouten vertonen een patroon: organisaties bouwen het beleid correct, maar onderschatten hoe aanvallers, infrastructuurhiaten en operationele blinde vlekken de effectiviteit ervan in de loop van de tijd aantasten.
Ransomwaregroepen richten zich eerst op back-ups
Aanvallers zoeken naar back-upreferenties, misbruiken ongepatchte back-upoplossingen en corrumperen bewust herstelinfrastructuur voordat encryptie op productiesystemen wordt geactiveerd. Als uw back-upinfrastructuur dezelfde identiteitsbron gebruikt als productie, kan één gecompromitteerd domeinbeheerder-account uw volledige herstelcapaciteit elimineren.
De blinde vlek in identiteitsinfrastructuur
Als Active Directory, authenticatiesystemen en privileged access management niet binnen uw retentiescope vallen, ontstaat een herstelparadox: onveranderlijke databack-ups bestaan, maar u kunt er geen toegang tot herstellen. Uw back-upretentiebeleid moet identiteitsinfrastructuur als volwaardige back-updoelstelling opnemen.
Complianceconflicten tussen kaders
Het dataminimalisatieprincipe van GDPR kan conflicteren met langere retentie-eisen van HIPAA of PCI-DSS. Het beheren van deze conflicten vereist gedetailleerde, dataspecifieke retentieschema’s met gedocumenteerde juridische basis en voortdurende juridische toetsing.
Monitoringshiaten en stille fouten
Als niemand back-uplogs of waarschuwingen bekijkt, blijven fouten maandenlang onopgemerkt. Opslag raakt vol, back-uptaken worden overgeslagen zonder melding en organisaties ontdekken corruptie pas bij daadwerkelijke herstelpogingen. Integratie van back-uptelemetrie in uw security monitoring stack sluit deze zichtbaarheidsgaten.
Aanvalstiming in weekenden en vakanties
Aanvallers maken gebruik van verminderde monitoringvensters. Ransomwaregroepen plannen aanvallen bewust tijdens perioden met minimale IT-bezetting, waardoor de kans toeneemt dat back-upcompromittering onopgemerkt blijft. Autonome monitoring- en responsmogelijkheden adresseren deze kwetsbaarheid effectiever dan handmatige controle alleen.
Deze uitdagingen wijzen op een gemeenschappelijk probleem: back-upretentiebeleid vereist continue handhaving, niet alleen documentatie. Het dichten van die kloof vraagt om een securityplatform dat autonoom werkt en zichtbaarheid biedt over uw volledige herstelomgeving.
Verbeter back-upretentie met SentinelOne
Uw back-upretentiebeleid bepaalt de regels. Uw securityplatform bepaalt of die regels standhouden onder aanval. Het Singularity Platform van SentinelOne versterkt back-upretentie door ransomware te stoppen voordat het uw back-upinfrastructuur bereikt en door uw SOC de zichtbaarheid te geven om back-upgerichte activiteiten in realtime te detecteren.
Autonome ransomware rollback
SentinelOne gebruikt gedrags-AI om ransomware-activiteiten bij uitvoering te identificeren en te stoppen, waardoor de kans afneemt dat encryptie kritieke systemen, inclusief back-upservers, bereikt. Wanneer ransomware bestanden op Windows-eindpunten versleutelt, gebruikt de rollbackfunctie Volume Shadow Copy-snapshots om getroffen bestanden te herstellen naar hun toestand vóór de aanval.
Bescherming van back-upinfrastructuur
Singularity Cloud Workload Security breidt realtime bescherming uit naar de VM’s, servers, containers en Kubernetes-clusters die uw back-upinfrastructuur hosten. Het platform biedt runtime dreigingspreventie en autonome respons in publieke clouds, private clouds en on-premises datacenters, waarbij getroffen systemen worden geïsoleerd en teruggezet naar een bekende veilige staat zonder tussenkomst van een analist.
AWS Backup-integratie
SentinelOne integreert met AWS Backup om cloudherstelprocessen te stroomlijnen. Wanneer Singularity Cloud Workload Security een gecompromitteerde EC2-instantie detecteert, vraagt het herstelinformatie op bij AWS Backup en presenteert een herstelkoppeling direct vanuit de SentinelOne-console.
Purple AI voor back-upanomalieonderzoek
Purple AI stelt uw analisten in staat om verdachte back-uptoegangspatronen te onderzoeken via conversatiegerichte zoekopdrachten, waardoor de tijd die nodig is om herstelopties te valideren tijdens incident response wordt verkort. Early adopters melden dat Purple AI threat hunting en onderzoeken tot 80% sneller maakt.
Singularity™ AI SIEM
SentinelOne’s Singularity™ AI SIEM voor de autonome SOC is het snelste open platform in de branche voor al uw data en workflows. Het is gebouwd op onze data lake en biedt realtime AI-bescherming voor de gehele onderneming. U krijgt toegang tot onbeperkte schaalbaarheid en eindeloze dataretentie. Versnel uw workflows met Hyperautomation. Bescherm uw endpoints, clouds, netwerken, identiteiten, e-mails en meer. Stream uw data voor realtime detectie en realiseer bescherming op machinesnelheid met autonome AI. U krijgt ook meer zichtbaarheid voor onderzoeken en detecties met de enige uniforme console-ervaring in de branche. Bekijk de tour.
Vraag een demo aan bij SentinelOne om te zien hoe autonome back-upbescherming in uw omgeving past.
AI-gestuurde cyberbeveiliging
Verhoog uw beveiliging met realtime detectie, reactiesnelheid en volledig overzicht van uw gehele digitale omgeving.
Vraag een demo aanBelangrijkste punten
Back-upretentie is een cybersecuritymaatregel die bepaalt of uw organisatie herstelt van ransomware of betaalt. Implementeer het 3-2-1-1-0-framework met onveranderlijke, fysiek gescheiden kopieën. Test herstel elk kwartaal met nul foutentolerantie.
Stem back-upretentieschema’s af op HIPAA, GDPR, PCI-DSS en SOC 2. Integreer back-uptelemetrie in uw SOC. Het Singularity Platform van SentinelOne versterkt deze strategieën met autonome respons en realtime zichtbaarheid over uw herstelomgeving.
Veelgestelde vragen
Een back-upbewaarbeleid is een set regels die bepaalt hoe lang uw organisatie back-upkopieën van gegevens bewaart, waar deze kopieën worden opgeslagen en wanneer ze worden verwijderd. Het omvat aanmaakfrequentie, opslaglocaties, vereisten voor onveranderlijkheid en procedures voor verwijdering.
Bewaarbeleid wordt bepaald door cybersecurity-eisen, wettelijke verplichtingen zoals HIPAA en GDPR, en de hersteldoelstellingen van uw organisatie voor RPO en RTO.
Het 3-2-1-1-0-framework bouwt voort op de traditionele 3-2-1-regel met twee toevoegingen die zijn ontworpen voor veerkracht tegen ransomware. De extra "1" vereist een onveranderlijke of air-gapped kopie die aanvallers niet kunnen wijzigen, zelfs niet met gestolen beheerdersreferenties.
De "0" handhaaft nul tolerantie voor niet-geverifieerde herstelacties, zodat u geen corruptie ontdekt tijdens een actief incident. Dit verandert back-upbewaring van opslaghygiëne in een herstelmaatregel.
Ransomwaregroepen stelen referenties, vaak door geheugen te dumpen op beheerdersendpoints, en verplaatsen zich vervolgens naar back-upconsoles en -repositories. Ze misbruiken niet-gepatchte back-upsoftware, wijzigen taakschema's om dekkingsgaten te creëren en proberen bewaarinstellingen te verwijderen of te verkorten.
Sommige actoren vergiftigen ook back-ups in de loop van de tijd, zodat herstel persistentie opnieuw introduceert. Uw doel is toegangspaden te blokkeren, onveranderlijkheid af te dwingen en herstelacties regelmatig te verifiëren.
Back-upvergiftiging treedt op wanneer aanvallers back-ups geleidelijk corrumperen tijdens de verblijftijd, zodat elk recent herstelpunt de compromittering bevat. Wanneer versleuteling uiteindelijk wordt geactiveerd, herstelt u en introduceert u de aanvaller opnieuw.
Onveranderlijke bewaarvensters moeten langer zijn dan de typische verblijftijd in uw omgeving. Veel organisaties beginnen met 30 tot 90 dagen onveranderlijkheid en stemmen dit vervolgens af op basis van hun detectiesnelheid en algehele risicotolerantie.
Als aanvallers Active Directory of uw identiteitsprovider compromitteren, kunt u het vermogen verliezen om te authenticeren bij de systemen die uw back-ups bevatten. De gegevens bestaan, maar u kunt er niet veilig bij of de integriteit aantonen.
Zonder identiteitsback-ups moet u vaak het domein, serviceaccounts en vertrouwensrelaties opnieuw opbouwen voordat u productieapplicaties herstelt. Die vertraging kan een herstel van uren naar dagen verlengen.


