Ransomware en herstel: drie actiepunten voor een goede voorbereiding

Organisaties die zonder voorbereiding ransomware-aanvallen meemaken zijn gemiddeld pas na 24 dagen hersteld.

Dat blijkt uit onderzoek van Coveware en Sophos. Voor middelgrote bedrijven, met minder IT-budget, duurt dit vaak nog langer.

In dit blog lees je hoe je de hersteltijd na een aanval aanzienlijk kunt verkorten en schade kunt beperken door een goede voorbereiding.

Waarom herstel na een aanval veel langer duurt dan verwacht

Een ransomware-incident is niet één moment. Het is een reeks weken waarin techniek, mensen en bedrijfsprocessen tegelijk onder druk staan.

De techniek is nog het meest rechttoe rechtaan: bestanden zijn versleuteld, applicaties liggen plat, backups moeten worden teruggezet. De vertraging zit elders. Wie beslist waar we beginnen met herstel? Kan marketing eerst, of is het ERP leidend? Welke backup is schoon en welke is al versleuteld? Kunnen we op vrijdag live gaan of moeten we wachten tot maandag omdat de fabrieksbeheerder er dan weer is?

Die gesprekken kosten in de eerste week meer tijd dan het daadwerkelijke herstel. En dat is precies waar die 24 dagen vandaan komen.

Drie veelgemaakte fouten bij ransomware-herstel

1. Backups die niet geïsoleerd zijn.
   Je backup staat op hetzelfde netwerk als je productieomgeving. Dezelfde Active Directory-accounts hebben rechten. Aanvallers doen hun huiswerk en komen er vanzelf bij. Zonder immutability of air-gap is je backup vanaf het begin al mee versleuteld, alleen merk je dat pas op dag 3.
2. Een DR-plan dat nooit is getest.
   Het Distaster Recovery document bestaat. Het staat in SharePoint. Als je het opent, begint het met ‘Versie 3, 2022’ en bevat het namen van collega’s die inmiddels weg zijn. Het plan bestaat, maar het werkt niet (meer).
3. Geen duidelijk eigenaarschap.
   In rustige tijden zijn de rollen helder op papier. In de chaos van een incident blijkt dat niemand zich écht eigenaar voelt van het herstelproces. IT wijst naar operations, operations naar IT, iedereen wacht op de directie. Voor je het weet vliegen de werkdagen voorbij.

Deze drie fouten hebben niets met techniek te maken. Ze hebben alles met voorbereiding te maken en daar kun je deze maand nog mee aan de slag.

DRaaS als vangnet: wat is het?

Disaster Recovery as a Service (DRaaS) betekent dat een externe partij continu een werkende kopie van je kritieke systemen draait, klaar om het over te nemen als jouw omgeving uitvalt. Geen backup, maar een stand-in.

Voor organisaties zonder eigen uitwijklocatie is dat vaak de enige haalbare manier om binnen uren operationeel te zijn in plaats van dagen. De kosten zijn reëel. De rekensom wordt namelijk pas helder als je bekijkt wat één week ongeplande downtime werkelijk kost aan omzet, overuren, contractuele boetes en klantvertrouwen.

Het is geen wondermiddel en ook niet voor elke organisatie de juiste keuze. Maar DRaaS is wel de enige oplossing die je met een gerust hart kunt testen, omdat de provider er zelf belang bij heeft dat het werkt.

Structurele restore-tests

Of je nu DRaaS afneemt of je eigen backup infrastructuur hebt: testen maakt het verschil.

Doe dit niet slechts één keer per jaar. Minimaal eens per kwartaal en op volledige systemen, niet alleen op losse bestanden. Elke test leert je iets concreets. De database herstelt bijvoorbeeld niet in de volgorde die je dacht. Het netwerksegment waar de herstelde server in terechtkomt bestaat niet meer. De enige collega die weet hoe de database-verbindingen weer open moeten is met vakantie…

Wat niet gemeten wordt, verbetert ook niet. Dus meet je je restore-tijd. Elk kwartaal, voor dezelfde kritieke systemen. Dan wordt je RTO (Recovery Time Objective) een getal dat je kunt onderbouwen in plaats van hopen.