Ransomware in het MKB: wat de eerste 24 uur bepalen voor je recovery

Een ransomware-melding komt altijd op het slechtste moment. Wat een MKB-bedrijf in de eerste 24 uur daarna doet (of juist nalaat) bepaalt grotendeels hoe lang de recovery duurt en hoeveel schade er uiteindelijk is.

Uur 1: isoleren, niet uitschakelen

De eerste reflex is vaak om getroffen systemen uit te zetten. Begrijpelijk, maar niet altijd verstandig: isoleren (netwerkverbinding verbreken) is meestal beter dan uitschakelen, omdat forensisch onderzoek achteraf kan helpen vaststellen hoe de aanvaller binnenkwam. Zonder dat inzicht loop je het risico dat je exact dezelfde weg terug weer openzet bij de recovery.

Uur 1-4: vaststellen wat getroffen is en wat niet

Niet elk systeem is per definitie besmet. Een snelle, gestructureerde inventarisatie van wat wél en wat niet is geraakt, voorkomt dat je onnodig meer restoret (en dus meer tijd verliest) dan nodig is. Dit is het moment waarop managed detection and response (MDR) het verschil maakt: met continue monitoring is vaak al bekend wélke systemen zijn geraakt, in plaats van dat je bij nul begint.

Uur 4-24: restore starten vanaf een schone backup, niet vanaf het getroffen systeem

Dit is de kern van waarom een geteste, gescheiden backup zo belangrijk is: een restore vanaf een backup die zelf ook besmet of versleuteld is, is zinloos. Bedrijven die hun backup en productieomgeving strikt gescheiden houden (en dit vooraf hebben getest), kunnen binnen uren weer operationeel zijn. Bedrijven die dat niet hebben gedaan, onderhandelen vaak dagen tot weken met een aanvaller, zonder garantie dat betalen ook daadwerkelijk tot recovery leidt. Dat lukt alleen als er een kopie is die de aanvaller niet kon bereiken, zoals een onveranderbare offsite backup. Zie ook: SharePoint terugzetten na ransomware.

Wat de meeste schade veroorzaakt, is niet de aanval zelf

Het is de tijd die verloren gaat aan uitzoeken wát er is gebeurd, óf er een bruikbare backup is, en wie waarvoor verantwoordelijk is. Dat is precies waarom voorbereiding (een getest disaster recovery-plan, gescheiden backups, en actieve monitoring) meer bepaalt over de uiteindelijke schade dan de aanval zelf.

Wat je vandaag kunt doen

Leg vast (of laat vastleggen) wie binnen je organisatie het eerste aanspreekpunt is bij een vermoeden van ransomware, en zorg dat backup en productieomgeving aantoonbaar gescheiden zijn. Als je dat niet zeker weet, is dat een signaal om het nu te laten toetsen, niet tijdens een incident.

BCP combineert endpoint detection (ESET), managed detection and response, en gescheiden, geteste backups, zodat de eerste 24 uur na een incident draaien om recovery, niet om uitzoeken. Lees ook hoe wij backup en disaster recovery inrichten. Staan je mail, Teams en SharePoint in Microsoft 365? Lees waarom Microsoft 365 backup een eigen backup vraagt.

Valt je organisatie onder de Cyberbeveiligingswet? Lees wat de wet vraagt van je backup en je meldplicht.