Cyber Recovery-testen: Welke variabelen moet je afwegen?

Cyber Recovery-testen: Welke variabelen moet je afwegen?

Wist je dat meer dan 50% van de organisaties er bij een cyberaanval niet in slaagt om hun IT-systemen binnen de gestelde tijd te herstellen? De vraag is dan: hoe zorg je ervoor dat jouw organisatie niet in deze statistiek terechtkomt? Een goede cyber recovery-strategie valt of staat bij de kwaliteit van je tests. Maar wat moet je precies testen en hoe diep moet je gaan? In deze blog geen pasklare antwoorden, want elk bedrijf is uniek. Wel geven we handvatten: variabelen die je helpen bepalen hoe jouw organisatie kan aantonen dat ze klaar is voor het moment suprême.

Waarom testen voor cyberaanvallen meer omvat dan disaster recovery

Bij een disaster recovery-test focus je vaak op één lokaal probleem, bijvoorbeeld het herstellen van data na een hardwarefout in een datacenter. Maar wat als je organisatie wordt getroffen door een ransomware-aanval die je hele IT-landschap lamlegt?

In zo’n scenario gaat het niet alleen om dataherstel. Je moet applicaties opnieuw opstarten, interfaces herstellen en een volledig functionerende IT-infrastructuur weer opbouwen. Dit vraagt om een veel bredere, holistische aanpak: cyber recovery.

Hoewel cyber recovery verder gaat dan de traditionele focus van disaster recovery, is het niet vanzelfsprekend dat de huidige disaster recovery-tests volledig aansluiten bij wat een cyberaanval vereist. De kernvraag blijft: zijn al die losse testen samen voldoende om een geïntegreerde aanpak te waarborgen? Of is er meer nodig om voorbereid te zijn op een grootschalige cybercrisis?

In die context zijn er drie belangrijke variabelen om rekening mee te houden bij een cyber recovery test.

1. Mate van simulatie versus daadwerkelijk herstel

Wil je vooral de theorie doornemen of echt oefenen hoe je systemen zou herstellen in een crisis? Met een tabletop-oefening kunnen rollen en verantwoordelijkheden helder worden, maar geeft minder zekerheid over de daadwerkelijke werking van je systemen. Een parallelle test, waarin je systemen in een niet-productieomgeving herstelt, biedt meer realisme maar vraagt ook meer middelen en planning. De vraag is dan of je voldoende middelen hebt (o.a. geschikte testomgevingen) en of het noodzakelijk is om het herstel volledig te testen. Als het goed is worden er al disaster recovery testen uitgevoerd. Omdat cyber recovery een complexere vorm daarvan is, kun je overwegen om bepaalde elementen uit disaster recovery niet opnieuw te testen. Ook kun je aannames maken over herstelbaarheid, gebaseerd op eerder succes in een disaster recovery-scenario.

Concrete overwegingen: als je alleen tabletop-oefeningen uitvoert, weet je zeker dat de processen op papier kloppen, maar hoe weet je of jouw team ook onder druk kan presteren als systemen daadwerkelijk offline zijn? Aan de andere kant, het volledig simuleren van een black-out situatie, inclusief herstel van onderliggende IT-platforms, kan maanden aan voorbereiding en resources vereisen.

2. Mate van integratie

Test je alleen individuele systemen, of neem je ook interfaces en integraties mee? Vaak vereisen effectieve hersteloperaties dat applicaties en de onderliggende infrastructuur naadloos samenwerken. Hoe complexer de integratie tussen systemen, hoe belangrijker het is om deze samenwerking te testen. Je wilt voorkomen dat een goed werkend herstelproces vastloopt door gebrekkige communicatie tussen systemen. Deze communicatie moet je zien in het licht van:

1. “Verticale integratie”: Herstel van software op onderliggende platforms
   Hierbij kun je je afvragen of je de software wil hersteltesten een hersteld platform of dat je uitgaat van een bestaand, operationeel platform. In een volledige black-out is het mogelijk dat je eerst de platforms moet herstellen voordat je software kunt installeren. Daarentegen kan het ook zijn dat slechts een deel van de infrastructuur hersteld hoeft te worden, omdat sommige platformen operationeel blijven. De vraag is dus in welke mate, wederom in het licht van het al uitvoeren van disaster recovery testen en/of andere testen, je alles volledig wilt herstellen tijdens een hersteltest.
2. “Horizontale integratie”: Testen van communicatie tussen systemen (interfaces)
   Hierbij kun je je afvragen of en, zo ja, welke interfaces je in een hersteltest wilt herstellen. Met name de complexiteit rondom het testen van interface kan daarbij een remmende factor zijn en daarmee een rol spelen. Vragen die helpen bij het bepalen van de complexiteit zijn:
   • Betreffen het interfaces in hetzelfde netwerkdomein?
   • Betreffen het interfaces met externe partijen? En zo ja, hebben die externe partijen dan ook testomgevingen beschikbaar waarmee geconnecteerd kan worden? In welke mate kun je stubs toevoegen?
   • Is er een omgeving waarin we deze interfaces kunnen hersteltesten?

3. Testfrequentie en scope

Hoe vaak en hoe uitgebreid je test, hangt af van de veranderlijkheid van je omgeving en je risicoprofiel. In een dynamische IT-omgeving, waar regelmatig nieuwe systemen of updates worden toegevoegd, kan een hogere testfrequentie noodzakelijk zijn. Je kunt hierbij ook variëren in scope – een keer alleen de kritieke systemen testen en een andere keer een bredere oefening doen – of in diepgang van de testen.

Kortom: het bepalen van de juiste diepgang, vorm en reikwijdte van je hersteltesten is niet zo eenvoudig. Het algemene advies is dan ook om vooral aan de slag te gaan en iteratief te ondervinden wat acceptabel is, rekening houdend met onderstaande.

Drie essentiële stappen in elke Cyber Recovery-test

Naast bovenstaande variabelen zijn er enkele stappen die iedere test zou moeten bevatten om waardevol te zijn:

1. Betrokkenheid van de juiste stakeholders en heldere rolverdeling: Voor een effectieve test is het belangrijk dat alle relevante partijen meedoen. Van eindgebruikers die hun data moeten kunnen herstellen tot applicatiebeheerders die ervoor zorgen dat applicaties functioneren en IT-beheerders die verantwoordelijk zijn voor de infrastructuur. Duidelijke rolverdelingen en een gedeeld begrip van risico’s helpen om een samenhangende test te realiseren.
2. Evaluatie en vastleggen van verbeteracties: De waarde van je test hangt af van wat je ermee doet. Plan na elke test een grondige evaluatie in om te bepalen wat goed werkte en waar het beter kan. Leg de verbeterpunten vast en zorg dat deze bij de volgende test worden meegenomen. Dit continue leerproces is cruciaal voor een up-to-date en effectieve recovery-strategie.
3. Communicatie tijdens een incident simuleren: Heldere communicatie is essentieel tijdens een crisis. Het testen van communicatie – welke informatie wanneer en met wie wordt gedeeld – kan chaos en vertraging voorkomen. Denk aan wie op de hoogte moet zijn van de status en wie beslissingen moet nemen. Dit aspect wordt in tests vaak over het hoofd gezien, terwijl het in de praktijk een grote rol speelt in de effectiviteit van je respons. Dit zou je overigens ook enigszins losstaand van het herstellen van je IT kunnen testen.

Ga vooral aan de slag met oefenen, maak het geen theoretisch (eindeloos) verhaal

Er is geen one-size-fits-all aanpak voor cyber recovery testen. Maar één ding is zeker: niet testen is geen optie. Betrek je IT-beheerders, stel kritische vragen en durf keuzes te maken die passen bij je risicobereidheid. Zo maak je van je tests geen formaliteit, maar een cruciale stap richting echte cyber resilience. De vraag is: hoe zeker ben jij dat je voorbereid bent?

Bij ARC People begrijpen we dat effectieve cyber recovery meer vraagt dan alleen theorie. Onze experts helpen je met het opzetten van praktijkgerichte hersteltests die aansluiten bij jouw specifieke risico’s en IT-omgeving. Samen zorgen we ervoor dat jouw organisatie niet alleen voldoet aan de eisen, maar ook echt voorbereid is op het onverwachte. Met onze ervaring en hands-on aanpak maken we cyber resilience haalbaar én meetbaar. Durf jij de eerste stap te zetten? Neem contact op met Toine van den Hurk voor een oriënterend gesprek.