Waarom ransomware back-ups tot doelwit maakt, niet tot vangnet
Jarenlang was de back-up de uitzondering die ransomware overleefbaar maakte: productie versleutelen, herstellen vanaf de back-up, en verder gaan. Aanvallers hebben dat inmiddels ingehaald. In Veeam's Ransomware Trends-onderzoek van 2025 onder 1.300 organisaties die waren getroffen, werd bij 89% de back-uprepository doelbewust aangevallen als onderdeel van de aanval — niet als bijzaak, maar als volwaardig doel binnen de kill chain. Het vangnet vernietigen of corrumperen vóórdat productie wordt versleuteld, is inmiddels standaardprocedure, omdat het slachtoffer zo elke onderhandelingspositie kwijtraakt nog voordat het losgeldbriefje binnenkomt.
Dat is terug te zien in de herstelcijfers. Uit het State of Ransomware 2025-rapport van Sophos blijkt dat slechts 54% van de organisaties back-ups gebruikte om data te herstellen na een aanval — het laagste percentage in de zes jaar dat het onderzoek loopt. Van de organisaties die uiteindelijk meer betaalden dan de oorspronkelijke eis van de aanvaller, gaf 38% mislukte of disfunctionerende back-ups op als reden dat ze geen beter alternatief hadden. Een back-up die op papier bestaat, is niet hetzelfde als een back-up die onder druk daadwerkelijk schoon herstelt.
Die kloof — tussen "we hebben back-ups" en "we hebben ransomware-bestendige back-ups" — komt neer op drie pijlers: immutability, isolatie en geteste recovery. Dit zijn geen losstaande maatregelen die je naar believen kunt combineren. Ontbreekt er één, dan compenseren de andere twee dat niet; een immutable back-up die een aanvaller niet kan bereiken, heeft alleen waarde als hij ook daadwerkelijk herstelt, en een goed geteste restoreprocedure is waardeloos als de back-up waarop die leunt al was verwijderd voordat de oefening ooit begon.
De drie pijlers in detail
1. Immutability: back-ups waar een aanvaller niet bij kan
Immutability betekent dat een back-up binnen de bewaartermijn niet kan worden gewijzigd of verwijderd — niet door een verkeerd geconfigureerd retentiescript, niet door een gecompromitteerd beheerdersaccount, en niet door de aanvaller die al domain admin-credentials heeft weten te bemachtigen. In de praktijk wordt dit afgedwongen via object lock op cloud- of objectopslag, Write Once Read Many (WORM)-hardware, of een gehardende Linux-repository met retentievergrendeling die op opslagniveau wordt afgedwongen, onafhankelijk van de eigen toegangscontroles van de back-upapplicatie.
Dat onderscheid is essentieel, omdat moderne ransomware-operators actief op zoek gaan naar back-uprepository's die bereikbaar zijn met productiecredentials, en die als eerste verwijderen of versleutelen, nog vóór ze de primaire data aanraken. Als hetzelfde beheerdersaccount dat je back-upsoftware beheert ook de restorepoints van vorige maand kan verwijderen, is immutability niet écht ingericht — het is een instelling die een aanvaller met voldoende rechten binnen enkele minuten kan uitschakelen.
De ransomware-richtlijnen van CISA zijn op dit punt expliciet: houd offline, versleutelde, immutable back-ups aan, verifieer ze regelmatig, en behandel ze als laatste verdedigingslinie in plaats van als het eerste obstakel dat een aanvaller moet omzeilen.
2. Isolatie: een gescheiden identity plane, en een kopie die aanvallers helemaal niet kunnen bereiken
Immutability beschermt een back-up tegen wijziging. Isolatie zorgt ervoor dat een back-up in de eerste plaats niet bereikbaar is. De twee zijn complementair, niet inwisselbaar, en organisaties die er maar één van implementeren, ontdekken het gat daartussen doorgaans tijdens een echt incident, niet tijdens een ontwerpreview.
Isolatie bestaat uit twee onderdelen. Het eerste is een gescheiden identity plane — back-upinfrastructuur zou niet hetzelfde Active Directory-domein, dezelfde beheerderscredentials, of hetzelfde platte netwerksegment als productie moeten vertrouwen. Een gecompromitteerde domain controller zou niet automatisch tot een gecompromitteerde back-upomgeving moeten leiden; is dat wel zo, dan hoefde de aanvaller maar één ding te compromitteren, niet twee. Het tweede is een echte offline of air-gapped kopie — minimaal één kopie van kritieke data zonder enig permanent netwerkpad vanuit productie, of dat nu wordt bereikt via offline tape-rotatie, een losgekoppeld replicatiedoel dat alleen kort online komt om data te ontvangen, of een cloudlaag zonder permanente credentials die ergens gecachet staan en bereikbaar zijn vanuit de productieomgeving.
Uit onderzoek van Veeam blijkt dat organisaties die deze gelaagde, geïsoleerde vorm van weerbaarheid prioriteit geven, tot zeven keer sneller herstellen van ransomware-aanvallen dan organisaties die dat niet doen, met bovendien aanzienlijk minder dataverlies. Isolatie maakt dat verschil mogelijk: het is het verschil tussen een aanvaller die daadwerkelijk extra werk moet verzetten om je recovery point te bereiken, en een aanvaller die daar al een open sessie op heeft omdat die dezelfde identity plane deelt met de systemen die hij zojuist heeft gecompromitteerd.
3. Geteste recovery: bewijzen dat herstel werkt vóórdat je het nodig hebt
De minst glamoureuze van de drie pijlers is ook degene die organisaties het vaakst overslaan — en dat is terug te zien in de resultaten. In een branche-onderzoek uit 2025 gaf 62% van de organisaties aan geen regelmatige backup-and-restore-tests uit te voeren, en zei 37% niet binnen de vereiste recovery time objective (RTO) te kunnen herstellen, specifiek omdat back-ups ontbraken of simpelweg nooit waren gevalideerd. Vertrouwen en werkelijkheid lopen hier sterk uiteen: meer dan 60% van de organisaties denkt binnen enkele uren te kunnen herstellen van downtime, maar slechts ongeveer een derde haalt dat daadwerkelijk wanneer het wordt getest.
Ongeteste restores falen op manieren die onzichtbaar blijven tot precies het moment waarop het ertoe doet: kapotte back-upketens, ontbrekende afhankelijkheden voor application consistency, service-account-credentials die maanden eerder al waren verlopen, of runbooks geschreven voor een infrastructuurtopologie die niet meer bestaat. Validatie overslaan brengt bovendien een scherper risico met zich mee dan gewone downtime — naar schatting loopt 63% van de organisaties het risico een infectie opnieuw te introduceren tijdens het herstel, omdat ze onder tijdsdruk integriteits- en malwarescans overslaan en zo effectief dezelfde payload terugzetten die de uitval oorspronkelijk veroorzaakte.
Een écht geteste recovery-aanpak betekent geplande, volledige restore-oefeningen naar een geïsoleerde recoveryomgeving — niet alleen meldingen dat de "backup job is geslaagd" — en gevalideerd tegen de RTO's die het bedrijf daadwerkelijk nodig heeft, niet tegen cijfers die alleen geruststellend ogen in een slidedeck.
Hoe het eruitziet wanneer de drie pijlers standhouden
De cijfers van Sophos uit 2025 bieden een nuttig tegenvoorbeeld voor de koppen boven de statistieken: van de organisaties waarbij een aanvaller wél data had versleuteld, kon 97% die data alsnog herstellen. Het verschil tussen die groep en de kleine minderheid die dat niet kon, is bijna altijd terug te voeren op één van de drie pijlers die in de praktijk zwakker bleek dan op papier — een retentievergrendeling die door de verkeerde rol kon worden overschreven, een "gescheiden" back-upnetwerk dat toch nog hetzelfde domein vertrouwde, of een restore die nog nooit end-to-end was geoefend.
De prijs van het verkeerd doen
De drie pijlers zijn geen abstracte best-practices-checklist — ze vertalen zich rechtstreeks naar hoeveel een ransomware-incident kost en hoe lang het duurt. De gemiddelde kosten om te herstellen van een ransomware-aanval, exclusief eventueel betaald losgeld, bedragen ruwweg $1.53 million. Slechts 53% van de slachtoffers was binnen een week volledig hersteld; de rest zat langer dan zeven dagen in een of andere vorm van verstoring, waarbij downtime, productiviteitsverlies en incident-response-inspanningen dagelijks opliepen.
Back-upvolwassenheid is een van de weinige variabelen in die vergelijking die een organisatie volledig zelf in de hand heeft. Of de openingszet van een aanvaller tegen je back-uprepository slaagt of faalt, wordt volledig bepaald door beslissingen die maanden eerder zijn genomen — niet tijdens het incident zelf. Tegen de tijd dat een threat actor domain admin-credentials heeft en op zoek is naar je back-upplatform, zijn immutability, isolatie en geteste recovery ofwel al ingericht, ofwel niet; er is geen gelegenheid meer om ze onder druk alsnog te regelen.
Veelgemaakte fouten die alle drie de pijlers stilletjes ondermijnen
In post-incident reviews duiken telkens dezelfde patronen op:
- Snapshots verwarren met back-ups. Een VMware-snapshot is een point-in-time delta die op dezelfde datastore staat als de VM die hij beschermt — geen onafhankelijke kopie. Hij groeit onbegrensd, drukt op de performance, en verdwijnt zodra de datastore dat doet. Snapshots zijn een gemaksfunctie voor kortstondige rollback, geen recoverystrategie.
- "Immutable" behandelen als vinkje in plaats van geverifieerde eigenschap. Object lock en retentiebeleid moeten getest worden tegen precies de beheerdersrol die het back-upplatform beheert, niet alleen worden gedocumenteerd in een configuratiehandleiding.
- Een tweede kopie binnen hetzelfde identity domain "geïsoleerd" noemen. Als dezelfde credentials die in productie zijn gecompromitteerd zich ook kunnen authenticeren bij de back-uprepository, biedt geografische of platformscheiding geen echte isolatie.
- Succes afmeten aan het voltooien van de back-up, niet aan restore-verificatie. Een groen vinkje bij de job van gisteravond vertelt je dat er ergens data is weggeschreven. Het vertelt je niet dat die data ook terug te halen, application-consistent en vrij van de malware is die de restore in de eerste plaats nodig maakte.
Hier komt BackupSec in beeld
Bij BackupSec helpen we enterprise-teams hun back-upomgevingen precies tegen deze drie pijlers te laten opereren — niet door hun back-upplatform te vervangen, maar door back-upbeveiliging observeerbaar, adviseerbaar en aantoonbaar te maken.
Onze aanpak combineert drie lagen:
- ZeroMON levert continue observability over de volledige back-upomgeving — Veeam-ready monitoring met real-time job tracking, geautomatiseerde security checks, forensische audit trails voor configuration drift, en compliance-rapportages met één klik. Dit is de laag die van "immutability is geconfigureerd" geen aanname meer maakt, maar bewijs.
- ZeroTAM biedt dedicated expert advisory voor back-uparchitectuur, isolatieontwerp en ransomware-recoveryplanning — de menselijke laag die de meeste enterprises nodig hebben om te interpreteren wat hun back-upomgeving daadwerkelijk vertelt, en om isolatie te ontwerpen die standhoudt bij een écht incident.
- ZeroPEN pentest je back-upinfrastructuur zoals een echte aanvaller dat zou doen — gericht op management planes, toegangscontroles en immutability-instellingen — en voert vervolgens echte restore-scenario's uit om te valideren dat je schoon, volledig en binnen je gestelde RTO kunt herstellen, niet alleen dat een backup job succes rapporteerde.
BackupSec wordt on-premise uitgerold, maakt verbinding met je back-upapplicaties via read-only API-toegang, en verplaatst nooit back-updata buiten je omgeving.
Praat met BackupSec over uw backupbeveiligingspositie →
Benieuwd of jouw eigen back-ups stand zouden houden? Score je omgeving met de gratis Backup Security Assessment.