Herstel na ransomware: hoe weet u of uw back-up nog betrouwbaar is?

Een ransomware-aanval kan de bedrijfsvoering in korte tijd volledig ontregelen. Bestanden worden versleuteld, applicaties vallen uit en medewerkers kunnen niet meer bij de gegevens die zij voor hun werk nodig hebben. In zo'n situatie lijkt de oplossing voor de hand te liggen: de getroffen systemen opnieuw opbouwen en de gegevens terugzetten vanuit een back-up.

Maar juist bij ransomware is herstel ingewikkelder dan bij een gewone technische storing. Een aanvaller kan al geruime tijd toegang hebben gehad tot de IT-omgeving voordat de aanval zichtbaar werd. In die periode kunnen accounts zijn misbruikt, beveiligingsinstellingen zijn gewijzigd en systemen zijn voorzien van middelen waarmee de aanvaller later opnieuw toegang kan krijgen. Ook back-ups kunnen gegevens of systeeminstellingen bevatten die inmiddels niet meer betrouwbaar zijn.

De belangrijkste vraag is daarom niet alleen hoe snel de organisatie weer kan werken, maar ook vanaf welk moment en onder welke voorwaarden herstel veilig mogelijk is.

Waarom ransomwareherstel anders is dan regulier herstel

Bij een defecte server of een beschadigde database is de oorzaak van de verstoring doorgaans technisch af te bakenen. Wanneer de onderliggende infrastructuur weer functioneert en een bruikbare back-up beschikbaar is, kan het herstel worden uitgevoerd en gecontroleerd.

Bij ransomware ligt dat anders. De zichtbare versleuteling is vaak slechts het laatste onderdeel van een langer incident. Aanvallers kunnen eerder al toegang hebben verkregen via een kwetsbaarheid, gestolen inloggegevens of een onvoldoende beveiligde externe verbinding. Vervolgens kunnen zij zich door het netwerk hebben verplaatst, aanvullende rechten hebben verkregen en voorbereidingen hebben getroffen om de impact van de aanval te vergroten.

Daardoor is niet vanzelfsprekend dat een back-up van vóór de versleuteling ook afkomstig is van vóór de compromittering. Een herstelpunt kan technisch volledig intact zijn, terwijl het besturingssysteem, de configuratie of de daarin opgenomen gegevens al zijn beïnvloed.

Wie zonder voldoende onderzoek systemen terugzet, loopt het risico dezelfde kwetsbaarheden of ongeautoriseerde toegang opnieuw te introduceren. Een organisatie kan dan na een geslaagde restore opnieuw slachtoffer worden, terwijl de indruk bestond dat het incident was opgelost.

Vier stappen naar verantwoord herstel

Herstel na ransomware vraagt om een samenhangende aanpak waarin incidentbeheersing, onderzoek en recovery op elkaar aansluiten. De onderstaande vier stappen maken duidelijk welke afwegingen nodig zijn voordat bedrijfskritische systemen opnieuw in gebruik worden genomen.

Deze stappen vormen geen strikt opeenvolgende werkzaamheden. Incidentbeheersing en onderzoek vinden vaak gelijktijdig plaats, terwijl het herstel van minder kritieke onderdelen mogelijk al wordt voorbereid. Nieuwe onderzoeksbevindingen kunnen bovendien aanleiding geven om een eerder gekozen herstelpunt opnieuw te beoordelen.

Het uitgangspunt blijft dat herstelsnelheid niet ten koste mag gaan van de betrouwbaarheid van de omgeving waarin de organisatie verder moet werken.

Eerst vaststellen wat daadwerkelijk is geraakt

Wanneer ransomware wordt ontdekt, gaat de aandacht begrijpelijkerwijs uit naar de systemen die niet meer functioneren. Toch is het minstens zo belangrijk om te onderzoeken welke onderdelen van de omgeving mogelijk zijn gecompromitteerd zonder dat zij zichtbare storingen vertonen.

Denk aan beheerdersaccounts, centrale identiteitsvoorzieningen, externe toegang, netwerkapparatuur en systemen waarmee software wordt verspreid of beheerd. Wanneer een aanvaller controle heeft gekregen over een van deze onderdelen, kan het herstellen van afzonderlijke servers onvoldoende zijn. De toegang die de aanval mogelijk maakte, kan immers nog steeds bestaan.

Ook de back-upomgeving verdient bijzondere aandacht. Aanvallers proberen regelmatig herstelmogelijkheden te verstoren door back-ups te verwijderen, opslag te versleutelen of de toegang tot beheersystemen over te nemen. Daarom moet worden vastgesteld of de beschikbare herstelgegevens onafhankelijk en voldoende beschermd zijn gebleven.

Het onderzoek hoeft niet altijd volledig te zijn afgerond voordat met herstelvoorbereidingen wordt begonnen. Wel moet voor de systemen die opnieuw in gebruik worden genomen voldoende duidelijk zijn welke risico's nog bestaan en welke maatregelen nodig zijn om herbesmetting te voorkomen.

Hoe bepaalt u welk herstelpunt betrouwbaar is?

Bij regulier herstel wordt vaak gekozen voor de meest recente bruikbare back-up. Daarmee blijft het gegevensverlies zo beperkt mogelijk. Na ransomware kan die keuze juist onverstandig zijn.

Stel dat de versleuteling op vrijdag wordt ontdekt, maar het onderzoek aanwijzingen oplevert dat een aanvaller al sinds de voorafgaande maandag toegang had tot de omgeving. De back-up van donderdag kan dan uitstekend herstelbaar zijn, maar mogelijk ook ongewenste wijzigingen bevatten. Een oudere back-up kan een veiliger uitgangspunt vormen, al betekent dat dat meer recente gegevens verloren gaan.

Er bestaat geen eenvoudige regel waarmee vooraf kan worden vastgesteld welke back-up veilig is. De keuze hangt af van onderzoeksbevindingen, de aard van de aanval, de inrichting van de back-ups en de mogelijkheden om gegevens en systemen afzonderlijk te controleren.

Vier aandachtspunten bij de beoordeling

Deze criteria moeten gezamenlijk worden beoordeeld. Een back-up die op één onderdeel betrouwbaar lijkt, is daarmee nog niet automatisch geschikt voor het volledig herstellen van de bedrijfsvoering.

De afweging tussen gegevensverlies en veilig herstel

Het selecteren van een ouder herstelpunt heeft een direct gevolg: transacties, documenten en andere wijzigingen van na dat moment zijn mogelijk niet meer beschikbaar. Voor organisaties die afhankelijk zijn van actuele gegevens kan dit aanzienlijke operationele en financiële gevolgen hebben.

Bijvoorbeeld wanneer een ERP-systeem wordt teruggezet naar een moment van enkele dagen eerder. In de tussentijd kunnen orders zijn verwerkt, goederen zijn ontvangen, productieopdrachten zijn uitgevoerd en facturen zijn aangemaakt. Als die gegevens ontbreken, ontstaat een verschil tussen de herstelde administratie en de feitelijke bedrijfsvoering.

Daarom is het niet altijd voldoende om één volledig systeem terug te zetten. Soms kunnen gegevens uit andere, aantoonbaar betrouwbare bronnen worden gereconstrueerd. Denk aan transactieregistraties, gegevens van externe systemen, documenten die elders beschikbaar zijn of handmatig vastgelegde werkzaamheden. Of dat verantwoord en technisch mogelijk is, moet per situatie worden beoordeeld.

Hier ontstaat een belangrijk spanningsveld tussen de gewenste herstelsnelheid, het maximaal acceptabele gegevensverlies en de zekerheid dat de organisatie niet opnieuw wordt getroffen. De eerder vastgestelde RPO- en RTO-doelstellingen blijven relevant, maar kunnen tijdens een ransomware-incident niet los worden gezien van de noodzakelijke veiligheidscontroles.

Een snelle terugkeer naar een onbetrouwbare omgeving is geen geslaagd herstel.

Herstellen in een omgeving die opnieuw te vertrouwen is

Wanneer een geschikt herstelpunt is vastgesteld, begint het daadwerkelijke herstel. Daarbij gaat het niet uitsluitend om het terugzetten van bestanden en servers. Ook de onderliggende infrastructuur, identiteiten, netwerkverbindingen en beveiligingsvoorzieningen moeten betrouwbaar zijn.

Afhankelijk van de aard en omvang van de compromittering kan het noodzakelijk zijn systemen volledig opnieuw op te bouwen in plaats van bestaande installaties te herstellen. Accounts en toegangsrechten moeten worden gecontroleerd, misbruikte inloggegevens moeten ongeldig worden gemaakt en kwetsbaarheden die aan het incident hebben bijgedragen moeten worden verholpen.

Ook de volgorde van herstel is belangrijk. Een bedrijfsapplicatie kan pas verantwoord functioneren wanneer de benodigde database, identiteitsvoorzieningen, netwerkverbindingen en andere afhankelijkheden beschikbaar en betrouwbaar zijn. Daarbij moet worden voorkomen dat herstelde systemen te vroeg opnieuw verbinding maken met nog niet onderzochte delen van het netwerk.

Het herstel kan daarom plaatsvinden in een afzonderlijke, gecontroleerde omgeving. Daar kunnen systemen en gegevens worden onderzocht en getest voordat zij opnieuw onderdeel worden van de reguliere bedrijfsvoering. Zo ontstaat ruimte om technische controles uit te voeren zonder direct het risico van verdere verspreiding te vergroten.

Wanneer kan de organisatie weer aan het werk?

Een systeem dat opnieuw opstart, is nog niet automatisch veilig of bedrijfsmatig bruikbaar. Na technisch herstel moet worden vastgesteld of de applicaties correct functioneren, de benodigde gegevens beschikbaar zijn en medewerkers hun werkzaamheden daadwerkelijk kunnen hervatten.

Bij ransomware komt daar een aanvullende beoordeling bij: zijn de oorzaken van het incident voldoende aangepakt en is er voldoende vertrouwen dat de herstelde omgeving niet opnieuw wordt gecompromitteerd? Dat vraagt onder meer om controle van beveiligingsinstellingen, toegangsrechten, logging en monitoring.

De beslissing om systemen weer beschikbaar te stellen is daarmee niet uitsluitend technisch. Ook de gevolgen voor de bedrijfsvoering moeten worden meegewogen. Soms kan een beperkt aantal processen eerder worden hervat, terwijl andere systemen nog nader onderzoek of aanvullende maatregelen nodig hebben.

Duidelijke verantwoordelijkheden zijn hierbij essentieel. De IT-beheerder, beveiligingsspecialisten, applicatieleveranciers en de organisatie zelf moeten weten wie het herstel uitvoert, wie de uitkomsten beoordeelt en wie besluit dat een bedrijfsproces weer verantwoord kan worden gestart.

Waarom voorbereiding het verschil maakt

Tijdens een ransomware-incident is de druk groot. Medewerkers kunnen niet werken, klanten wachten op dienstverlening en de financiële gevolgen nemen toe naarmate de verstoring langer duurt. Juist dan is het moeilijk om zorgvuldig afwegingen te maken wanneer de benodigde informatie en herstelvoorzieningen niet vooraf beschikbaar zijn.

Een goed recoveryplan beschrijft daarom meer dan de technische handelingen om een back-up terug te zetten. Het maakt duidelijk welke systemen bedrijfskritisch zijn, hoe zij van elkaar afhankelijk zijn, welke herstelvoorzieningen beschikbaar zijn en welke partijen bij het herstel betrokken moeten worden.

Voor ransomware is bovendien van belang dat back-ups voldoende beschermd en onafhankelijk toegankelijk zijn, dat herstel kan plaatsvinden zonder direct op mogelijk gecompromitteerde systemen te vertrouwen en dat er procedures bestaan om de betrouwbaarheid van herstelpunten te beoordelen.

Periodieke hersteltests helpen om vast te stellen of deze voorzieningen in de praktijk werken. Daarbij hoeft niet iedere test een volledig ransomware-incident na te bootsen. Gerichte tests van geïsoleerd herstel, toegangsbeheer, back-upintegriteit en applicatieafhankelijkheden kunnen al belangrijke tekortkomingen zichtbaar maken.

Herstelbaarheid vraagt om meer dan een back-up

Ransomware maakt duidelijk waarom back-up, beveiliging en IT-beheer niet los van elkaar kunnen worden georganiseerd. De kwaliteit van herstel wordt mede bepaald door keuzes die lang vóór een incident zijn gemaakt: de inrichting van toegangsrechten, de bescherming van back-ups, de segmentatie van het netwerk, de beschikbaarheid van logging en de manier waarop systemen worden beheerd.

Een organisatie die uitsluitend controleert of haar back-ups succesvol worden uitgevoerd, weet nog onvoldoende over haar daadwerkelijke herstelbaarheid. Daarvoor moet ook duidelijk zijn of een betrouwbaar herstelpunt kan worden vastgesteld, of systemen veilig opnieuw kunnen worden opgebouwd en of de bedrijfsvoering daarna verantwoord kan worden hervat.

Malenco benadert herstel daarom als onderdeel van samenhangend en beveiligingsgericht IT-beheer. Niet alleen de beschikbaarheid van gegevens staat centraal, maar ook de betrouwbaarheid van de omgeving, de onderlinge afhankelijkheden en de praktische uitvoerbaarheid van het herstel.

Het doel is niet simpelweg om na ransomware weer online te komen, maar om de organisatie op een gecontroleerde en betrouwbare manier verder te laten werken.