Hip of happening? | Cyberrecovery

Dat herstel op kleine schaal lukt, betekent nog niet dat je voorbereid bent op een grote verstoring. Peter onderscheidt operationeel herstel, disaster recovery en cyber recovery.

• Bij operationeel herstel zet je bijvoorbeeld een bestand of database terug.
• Bij disaster recovery moet je na een grote calamiteit systemen en dienstverlening herstellen.
• Cyber recovery voegt daar een belangrijke onzekerheid aan toe: welke systemen en gegevens kun je nog vertrouwen?

Bij a.s.r. werd het verschil in schaal zichtbaar na een storage-incident in 2019. Uitwijken bood geen oplossing, omdat het probleem diep in de storage zat. Back-ups moesten worden teruggezet, maar dat ging te langzaam voor de hoeveelheid die hersteld moest worden.

Elles benadrukt dat productie veel minder geraakt was en snel weer draaide. Ze vertelt: “Vooral de testomgevingen waren getroffen. Het herstel daarvan kostte ons maanden, waarbij de belangrijkste ketens voorrang kregen.”

Het incident leidde tot de inrichting van een nieuwe back-upomgeving. Bij de selectie keek a.s.r. naar de snelheid en compleetheid van herstel, voor zowel dagelijkse incidenten als grotere verstoringen. Ook de verbindingen naar die omgeving moesten over voldoende capaciteit beschikken. Snelle herstelsoftware helpt namelijk maar deels als de data onderweg niet snel genoeg kan worden verplaatst.

Bij een cyberaanval komt daar onderzoek bij, net zoals in het recente voorbeeld van Ahold Delhaize. Een aanvaller kan al langer aanwezig zijn voordat de aanval wordt ontdekt. De meest recente back-up kan daardoor ook sporen van de aanval bevatten. Peter: “Dit soort recente voorbeelden laten zien dat bij een cyberrecovery niet alleen belangrijk is dat je snel kunt herstellen, maar je ook zeker weet dat wat je herstelt veilig en schoon is.”

Dat vraagt om samenwerking met specialisten die onderzoeken wat er is gebeurd, welke malware is gebruikt en welke aanwijzingen er zijn voor besmetting. Op basis daarvan kun je beoordelen welke gegevens geschikt zijn voor herstel. Peter noemt onder meer onderzoek in een afgeschermde herstelomgeving (een zogenaamde cleanroom) en het zoeken naar dreigingen in back-updata.

Daarmee verschuift ook het gesprek over snelheid. Het terugzetten zelf is maar een deel van de totale hersteltijd. “Onderzoek, besluitvorming en de voorbereiding van een veilige omgeving kosten ook tijd”, zegt Peter. “Als je alleen rekent vanaf het moment dat iemand op de herstelknop drukt, onderschat je hoe lang de organisatie daadwerkelijk niet kan werken.”

Een herstelstrategie moet daarom beginnen bij je bedrijfsprocessen. Peter noemt dat je minimum viable company. Wat moet minimaal functioneren om de belangrijkste activiteiten weer uit te voeren? Dat bepaalt welke applicaties en data voorrang krijgt. Vervolgens moet je weten van welke onderliggende IT-diensten die afhankelijk zijn. Een applicatie terugzetten heeft weinig zin als medewerkers nog niet kunnen inloggen of kritieke verbindingen ontbreken.

Maak samen met de verantwoordelijken in je organisatie voor die processen duidelijk hoe lang uitval te verdragen is en hoeveel dataverlies acceptabel is. Daar horen twee begrippen bij:

• Recovery Time Objective (RTO): de beoogde tijd waarbinnen een systeem of dienst weer beschikbaar moet zijn.
• Recovery Point Objective (RPO): hoeveel dataverlies in tijd maximaal acceptabel voor je is, bijvoorbeeld de gegevens van het afgelopen uur.

Die afspraken helpen om eisen te stellen aan de hersteloplossing. Daarna moet een oefening aantonen of ze ook haalbaar zijn. Elles benadrukt dat je de voorbereidingstijd hierin moet meenemen. “Die verdwijnt niet doordat de software snel kan herstellen.”

Bij a.s.r. bleef de voorbereiding niet beperkt tot nieuwe techniek. In tabletop-sessies doorlopen medewerkers gezamenlijk een scenario en bespreken ze wat ze op dat moment zouden doen. Dat levert ongemakkelijke, nuttige vragen op:

• Je wilt een schone laptop gebruiken, maar hoe log je in?
• Waar staat het benodigde wachtwoord?
• Kun je daar nog bij als de server waarop het is opgeslagen ook onbruikbaar is?

In het gesprek komt zelfs fysieke toegang aan bod. Bij een eerdere verstoring bleek toegang tot het pand een probleem. Ook wifi werkte niet doordat die afhankelijk was van de getroffen storage. Zulke afhankelijkheden zie je gemakkelijk over het hoofd wanneer je alleen naar de back-upomgeving kijkt.

“En als je dat weer niet voorbereidt, dan sta je als het zover is, alleen maar te zoeken en te overleggen”, zegt Elles. Oefenen maakt zichtbaar welke informatie, middelen en toegangsrechten je vooraf beschikbaar moet hebben. Het dwingt je ook om aannames uit te spreken. Wat voor de ene collega vanzelfsprekend is, blijkt voor een ander nog helemaal niet geregeld.

De keuzes achter herstel raken de héle organisatie. Welke dienstverlening krijgt voorrang? Welke uitval is acceptabel? Hoeveel tijd en budget reserveer je om dat te testen? De IT-afdeling kan die vragen niet alleen beantwoorden.

Regelgeving onderstreept die verantwoordelijkheid:

• De Cyberbeveiligingswet (NIS2) noemt bedrijfscontinuïteit, back-upbeheer, disaster recovery en crisisbeheer als onderdelen van cyberrisicobeheersing.
• De richtlijn zegt ook dat bestuursorganen van organisaties die eronder vallen maatregelen goedkeuren en toezicht houden op de uitvoering.
• Voor financiële instellingen die onder DORA vallen, zijn ook gedocumenteerde back-up- en herstelprocedures en periodieke tests voorgeschreven.

Die aandacht helpt volgens Elles om het onderwerp op de agenda te krijgen. Maar een oefening levert pas écht verbetering op wanneer de bevindingen worden opgevolgd. Anders verdwijnt de aandacht voor ontbrekende wachtwoorden, onduidelijke rollen en trage herstelstappen weer onder de dagelijkse gang van zaken. Reserveer dus ook tijd voor de aanpassingen die uit een test komen.

Peter ziet verschillen tussen organisaties in hoever ze staan. “De financiële sector is volgens hem vaak verder, terwijl veel andere organisaties nu ontdekken wat ze nog moeten regelen.

De volgende stap hoeft niet direct een nieuwe oplossing te zijn. Begin met één kritisch bedrijfsproces en toets of je dat werkelijk kunt herstellen. Laat de applicatiebeheerder de uitkomst beoordelen, meet de benodigde tijd en doorloop ook de stappen vóór het terugzetten.

Peter adviseert om operationeel herstel regelmatig te testen, waar mogelijk geautomatiseerd, en een grotere disaster- of cyberrecovery-oefening minimaal jaarlijks te doen. Welke oefening je ook kiest, leg vast wat niet werkte en wie dat oplost. Zo ontstaat bewijs waarop je bij een volgend incident kunt terugvallen.

Stel jezelf als organisatie deze vraag: als je belangrijkste bedrijfsproces morgen stilvalt, weet je dan hoe je het veilig weer op gang krijgt, of ga je ervan uit dat je back-up voldoende is?