Blog Archives

1. Wat betekenen RTO, RPO en MTD?

Om het vraagstuk goed te benaderen, is het belangrijk eerst enkele traditionele BCM-termen te begrijpen:

• Recovery Time Objective (RTO): De maximale tijdsduur waarin na een verstoring herstel moet plaatsvinden voordat onacceptabele impact optreedt.
• Recovery Point Objective (RPO): De maximale hoeveelheid data (uitgedrukt in tijd) die verloren mag gaan zonder onacceptabele schade.
• Maximum Tolerable Downtime (MTD): De absolute maximale tijd dat een proces of dienst buiten werking mag zijn voordat ernstige schade optreedt. Het verschil met RTO is dat MTD een absolute grens weergeeft, terwijl RTO de doelstelling binnen de MTD is om herstel plaats te laten vinden.

Traditioneel worden deze parameters vastgesteld op procesniveau. Maar is dat de meest effectieve benadering?

2. Waarom RPO en RTO op applicatieniveau bepalen?

Hoewel de klassieke BCM-aanpak stelt dat RPO en RTO op procesniveau moeten worden vastgesteld, brengt dit enkele nadelen met zich mee:

1. Procesgerichte benadering leidt tot suboptimale invulling: Processen bestaan vaak uit meerdere applicaties en systemen met verschillende herstelmogelijkheden.
2. Hersteloplossingen worden ingericht op technisch niveau, niet op procesniveau: Disaster recovery-oplossingen, zoals back-up- en replicatietechnologie, richten zich op servers en applicaties, niet direct op processen. IT-teams werken met hersteltijden en dataverliesgrenzen per applicatie of andersoortige IT, maar in ieder geval niet per bedrijfsproces.
3. Efficiënter beheer en betere afstemming met IT-infrastructuur: Door RTO en RPO op applicatieniveau vast te stellen, sluit BCM beter aan op technische herstelstrategieën.

Praktisch voorbeeld: Stel dat een organisatie een RTO van 4 uur vaststelt voor het proces ‘facturatie’. Dit proces maakt echter gebruik van drie applicaties: een ERP-systeem, een database en een documentmanagementsysteem. Vanuit de procesbenadering stel je dat deze drie applicaties binnen 4 uur hersteld zouden moeten zijn. Een meer fit-for-purpose benadering zou zijn om, binnen de grenzen die de context van proces bepaald (waaronder MTD), per applicatie te bepalen wat zinvol is. Het kan dan gebeuren dat één applicatie binnen 2 uur hersteld is, terwijl een andere 6 uur nodig heeft. Dat hoeft niet erg te zijn, zolang die applicatie die 6 uur nodig heeft geen cruciale rol speelt in het proces. Mogelijk kan het facturatieproces prima op gang komen zonder die ene applicatie. Een voor het proces cruciale applicatie zal nu eenmaal sneller hersteld moeten zijn dan een applicatie die “nice-to-have” is binnen het proces. Voor zo’n “nice-to-have” applicatie zou zelfs kunnen gelden dat die later wordt hersteld dan de MTD van het proces.

3. RTO en RPO in de context van cyberdreigingen

De traditionele BCM-aanpak is grotendeels gebaseerd op fysieke verstoringen, zoals brand of stroomuitval. In die gevallen kunnen bedrijven uitgaan van voorspelbare herstelparameters. Maar bij cyberincidenten, zoals ransomware-aanvallen, gelden andere spelregels:

• Herstel kan dagen tot weken duren vanwege forensisch onderzoek en saneringsmaatregelen.
• Het risico bestaat dat herstelpunten (back-ups) zijn gecompromitteerd.
• IT-systemen kunnen opnieuw worden aangevallen tijdens het herstelproces.

Dit brengt ons bij het concept van Cyber RTO (CRTO) en eventueel Cyber RPO (CRPO), een meer realistische hersteltijd en herstelpunt specifiek voor cyberdreigingen.

Waar je bij de traditionele RTO in principe direct zou kunnen overschakelen naar een tweede datacenter, vrijwel zonder tijdsverlies, is dat bij een cyberaanval niet mogelijk. Er worden dan andere activiteiten verwacht; activiteiten waar rekening mee gehouden moet worden bij het bepalen van de CRTO:

• Tijd voor detectie en initiële containment.
• Tijd voor forensisch onderzoek en schoonmaakacties.
• Tijd voor gefaseerd herstel en validatie.

Voorbeeld: Een organisatie met een reguliere RTO van 6 uur voor hun CRM-systeem wordt getroffen door ransomware. Forensisch onderzoek en het veiligstellen van de omgeving nemen 48 uur in beslag. Een traditionele RTO is hier niet haalbaar, maar een CRTO van bijvoorbeeld een week kan wél een realistische inschatting geven. Waarom dit grote verschil tussen 6 uur en een week als onderzoek en veiligstellen 2 dagen kost? Omdat mogelijk niet alleen het CRM-systeem hersteld moet worden, maar ook (alle) onderliggende infrastructuur. Met dit laatste hoeft niet per definitie rekening te worden gehouden bij de traditionele RTO.

Naast de CRTO zou je ook een CRPO kunnen introduceren. Waarom? Waar je bij traditionele BCM rekening kunt houden met goed functionerende back-ups (en clusters), is dat bij cyberincidenten niet per definitie het geval: mogelijk moet je data in je back-ups opschonen wat tot dataverlies kan leiden en je dus een aangepast een enigszins herstelpunt moet hanteren.

Waarom is dit belangrijk?

• Bedrijven kunnen beter anticiperen op cyberdreigingen en realistische herstelstrategieën formuleren.
• CRTO en CRPO dwingt organisaties na te denken over aanvullende maatregelen, zoals gescheiden back-ups en out-of-band management.

4. Andere relevante, maar meer geavanceerde BCM-termen en hun rol in cyber recovery

Naast RTO, RPO en MTD zijn er andere BCM-termen die relevant zijn, maar ook voor verwarring kunnen zorgen. Hieronder noemen we er een aantal, maar het advies is om in beginsel te blijven bij RPO, RTO en MTD:

• Work Recovery Time (WRT): De tijd die nodig is ná technische recovery om operationeel te worden (bijv. testen, gebruikersinstructies). In het kader van cyberaanvallen zou deze gelijk kunnen zijn aan de reguliere WRT, maar aannemelijk is dat niet per se.  Afhankelijk van je herstelstrategie (herstellen of opnieuw opbouwen) kan WRT toenemen bij een cyberaanval. De grootste factor in toename zit hem echter in doorlooptijd van forensische testen, opschoning en validaties.

Overigens: Of WRT om de hoek komt kijken voor of na de RTO is niet iedereen het over eens. Het idee is vooral dat men weer aan echt aan het werk kan op het moment dat de WRT erop zit. Stel je de (C)RTO gelijk aan dat moment of aan het moment dat het systeem technisch hersteld is? Dat is vooral de overweging die (ook) gemaakt moet worden bij het bepalen van de (C)RTO.

• Service Delivery Objective (SDO): Het minimale niveau van dienstverlening dat na een incident in beginsel geleverd moet worden. Herstel hoeft niet per definitie in te houden dat alle capaciteit die je ter beschikking had ook direct weer geleverd wordt. Daarom is het verstandig een SDO af te stemmen. De tijd die benodigd is om tot de SDO te komen in herstel na een cyberincident kan echter drastisch langer zijn dan de hersteltijd bij een traditioneel incident.
  De vraag is dus: Bepaal je de (C)RTO op basis van wanneer de SDO wordt bereikt, stel je de (C)RTO op basis van de 100% performance (business as usual)? De theorie is hierover verdeeld. In feite maakt het ook niet veel uit welke keuze gemaakt wordt, zolang het maar duidelijk is welke keuze is gemaakt.

Door deze termen duidelijk te definiëren en toe te passen kan een organisatie effectiever inspelen op cyberdreigingen en realistische verwachtingen scheppen over herstel na een aanval.

Conclusie

BCM moet mee-evolueren met het dreigingslandschap. Het vaststellen van RTO en RPO op applicatieniveau binnen de context van je bedrijfsprocessen en diensten biedt een realistischer kader voor herstelstrategieën. Daarnaast is CRTO onmisbaar om een effectieve respons op cyberincidenten te waarborgen. Door deze begrippen correct toe te passen, kunnen organisaties beter voorbereid zijn op zowel traditionele als moderne dreigingen.

Wat maakt Cyber Recovery anders dan traditioneel back-upherstel?

Back-ups beschermen tegen hardwarestoringen, menselijke fouten en softwarefouten. Maar een cyberaanval kan hele netwerken besmetten en back-ups compromitteren. Alleen data terugzetten is dan niet genoeg; je moet zeker weten dat je geen geïnfecteerde systemen herstelt. Daarom draait cyber recovery om méér dan back-ups: het vereist isolatie, immutability en actieve (intelligente) inspectie:

1. Isolatie – Data die als laatste redmiddel dient, moet fysiek of logisch gescheiden zijn van de productieomgeving. Een aanvaller mag hier nooit bij kunnen, zelfs niet met beheerdersrechten in de productieomgeving.
2. Immutability – De data in de kluis mag niet gewijzigd of verwijderd kunnen worden. Zelfs een aanvaller met diepe systeemtoegang kan de kluisinhoud niet manipuleren.
3. (Intelligente) Inspectie – De opgeslagen data wordt continu of periodiek gescand op tekenen van malware, ransomware of andere Indicators of Compromise (IoC’s). Hierdoor voorkom je dat je een besmetting terugplaatst bij herstel.

Twee hoofdbenaderingen in Cyber Recovery

Cyber recovery-oplossingen zijn grofweg in te delen op basis van:

1. Functionele basis – Werkt de oplossing op basis van Endpoint Detection & Response (EDR) of op basis van back-uptechnologie?
2. Implementatiemodel – Wordt de oplossing aangeboden als een cloudgebaseerde oplossing of als een on-premise systeem?

Hieruit ontstaan vier categorieën, die we verder uitwerken:

1. EDR-gebaseerde Cyber Recovery oplossingen

Endpoint Detection & Response (EDR)-gebaseerde oplossingen richten zich op het detecteren, blokkeren en herstellen van cyberaanvallen door te focussen op endpoints en actieve dreigingen. Dit type oplossing is geschikt voor bedrijven die met name een snelle respons op bedreigingen willen en hun herstelprocessen willen automatiseren.

Geschikt voor organisaties die snelle detectie en herstel van werkplekken en servers belangrijk vinden.

2. Back-upgebaseerde Cyber Recovery oplossingen

Back-upgebaseerde oplossingen leggen de nadruk op het veiligstellen van cruciale data en systemen, zodat deze na een aanval volledig hersteld kunnen worden. Deze oplossingen gebruiken vaak isolatie, immutability en geavanceerde malwaredetectie om besmetting van back-ups te voorkomen.

Geschikt voor organisaties die een brede en diepgaande bescherming nodig hebben, inclusief servers, databases en complete IT-infrastructuren.

Bij back-upgebaseerde cyber recovery-oplossingen heb je, naast de keuze tussen on premise en cloud, twee opties:

1. Leverancier-specifiek – Deze oplossingen bouwen voort op een bestaande back-uptechnologie van dezelfde aanbieder en zijn volledig geïntegreerd. Hierdoor kunnen cyber recovery oplossingen bijvoorbeeld (vaak) ook versleutelde back-ups inspecteren op malware, ransomware of IoC’s in zijn algemeenheid.
2. Leverancier-onafhankelijk – Compatibel met meerdere back-upsystemen, wat handig is voor organisaties die verschillende technologieën combineren. Dit laatste is vanzelfsprekend enkel relevant op het moment dat je als organisatie al gebruik maakt van verschillende back-upoplossingen.

3. Cloudgebaseerde Cyber Recovery oplossingen

Cloud-native oplossingen bieden cyber recovery als een dienst, waarbij data, configuraties en applicaties veilig in de cloud worden opgeslagen en beheerd. Dit kan zowel voor back-ups als voor EDR-oplossingen gelden.

Geschikt voor organisaties die flexibiliteit en wereldwijde toegankelijkheid vereisen.

4. On-Premise Cyber Recovery oplossingen

Voor organisaties die volledige controle over hun cyber recovery-strategie willen behouden, blijven on-premise oplossingen een cruciale optie. Dit geldt zowel voor back-ups als voor EDR-oplossingen.

Geschikt voor organisaties die met strikte compliance-eisen en geen afhankelijkheid van IT-leveranciers willen.

De voor- en nadelen op een rijtje

De strategische keuze: hybride denken

De realiteit is dat de meeste organisaties niet voor óf alleen product-specifieke oplossingen, óf alleen een algemene oplossing kiezen. Vaak is er sprake van een hybride aanpak. Daarom is het aan te bevelen in je cyber recovery strategie per proces, applicatie en/of dataset na te gaan wat de waarde is voor je organisatie en welke cyber recovery oplossing daar het best bij past.

Conclusie

Er is geen universeel juiste keuze tussen product-specifieke en algemene cyber recovery oplossingen. De beste strategie hangt af van de aard van je IT-landschap, de samenstelling van je applicatieportfolio, de data die je verwerkt en je risicobereidheid. Wat wel zeker is: zonder duidelijke cyber recovery strategie, inclusief isolatie, immutability en (intelligente) inspectie, wordt het vrijwel onmogelijk om na een serieuze cyberaanval met zekerheid malwarevrij en veilig te herstellen.

Denk vooruit: Hoe ziet jouw ideale cyber recovery strategie eruit? Is jouw organisatie voorbereid op cyber recovery of vertrouw je nog te veel op traditionele back-ups? Het is tijd om je cyberweerbaarheid structureel te versterken.

Waarom is dit een dilemma?

Een cyberaanval brengt enorme druk met zich mee, vooral op management- en bestuursniveau. Operationele teams willen de systemen weer online krijgen, terwijl securityteams en externe forensische specialisten willen achterhalen hoe de aanval heeft plaatsgevonden en of de dreiging volledig is geëlimineerd.

Te snel herstel kan betekenen dat je een aanvaller per ongeluk laat ontsnappen of dat je niet goed begrijpt hoe de aanval heeft plaatsgevonden. Aan de andere kant kan een langdurig onderzoek de bedrijfsvoering ernstig verstoren en imagoschade vergroten.

De voor- en nadelen bij de keuzes

Voordelen van uitgebreid forensisch onderzoek:

• Inzicht in aanvalspad – Begrijpen hoe de aanvaller binnenkwam en zich lateraal bewoog binnen de organisatie.
• Detectie van achterdeurtjes – Voorkomen dat een aanvaller ongezien terugkeert.
• Verbetering van toekomstige verdediging – Kennis gebruiken om preventieve maatregelen te versterken.
• Juridische en compliance-verplichtingen – Voldoen aan regelgeving zoals de AVG, DORA of NIS2.

Nadelen van uitgebreid forensisch onderzoek:

• Verlengde downtime – Systemen blijven langer offline, wat operationele en financiële schade oplevert, waar klanten en partners ook last van (kunnen) hebben.
• Imagoschade – De organisatie komt negatief in het daglicht, omdat bekend wordt dat er een cyberaanval heeft plaatsgevonden.
• Kosten – Externe forensische specialisten en de impact van downtime kunnen flink in de papieren lopen.

Voordelen van snel herstel:

• Minimalisatie van operationele schade – Organisatie kan sneller weer functioneren.
• Beperkte klantimpact – Klanten ondervinden minder hinder van verstoringen.
• Beheerste kosten – Minder tijd en middelen nodig voor langdurige analyses.

Nadelen van snel herstel:

• Onvolledig onderzoek – Mogelijk missen van sporen of actieve dreigingen.
• Risico op herinfectie – Als de achterliggende oorzaak niet goed wordt begrepen, kan de aanvaller terugkomen.
• Mogelijke compliance-risico’s – Wettelijke rapportageverplichtingen kunnen worden bemoeilijkt zonder goed onderzoek.

Hoe dit geen groot dilemma hoeft te zijn

Het goede nieuws: met de juiste voorbereiding en strategie kunnen organisaties het conflict tussen onderzoek en herstel grotendeels oplossen. Een veelgebruikte oplossing is het maken van een forensische kopie van getroffen systemen voordat herstel plaatsvindt. Hierdoor kunnen analisten achteraf een diepgaand onderzoek uitvoeren zonder dat dit de hersteloperatie vertraagt.

Om te voorkomen dat herstel overhaast of juist te traag verloopt, moeten organisaties vooraf de juiste maatregelen nemen. Dit zijn de belangrijkste stappen:

1. Real-time logging en monitoring inrichten

Goed ingerichte logging en detectie zorgen ervoor dat je direct inzicht hebt in een aanval. Dit kan niet alleen de schade beperken, maar versnelt ook het forensisch onderzoek en herstel. Echter, omdat aanvallen snel kunnen worden uitgevoerd, vaak sneller dan de verdediging op gang komt – iets wat met hulp van AI verbeterd kan worden – wil er wel eens een aanval tussendoor glippen. Het hebben van de juiste (en betrouwbare) logging kan dan helpen het forensisch onderzoek te versnellen en tegelijkertijd zorgen voor een beter gefundeerd herstelplan.

2. De processtappen voor forensisch onderzoek vooraf gereed hebben

Hoe eerder je kunt starten met forensisch onderzoek, hoe eerder je kunt herstellen. De volgende factoren spelen daarbij een rol:

• Werk, nog voordat er sprake is van een (cyber)incident / tijdens de “business as usual,” samen met gekwalificeerde forensische experts en stel vooraf vast welke certificeringen en competenties nodig zijn om effectief onderzoek te kunnen doen. Een gekwalificeerde forensisch expert beschikt idealiter over certificeringen zoals GCFA (GIAC Certified Forensic Analyst) of CHFI (Computer Hacking Forensic Investigator). Een helder contract met SLA’s en duidelijke verwachtingen en een gemakkelijk (ook niet-digitaal) te raadplegen contactenboekje met daarin de gegevens van de forensisch expert kan ervoor zorgen dat de expert direct en efficiënt kan handelen bij een incident.
• Zorg voor vooraf gedefinieerde forensische procedures, zodat duidelijk is welke systemen, logs en metadata veiliggesteld moeten worden. Bepaal daarbij vooraf welke kritieke assets bij een aanval altijd moeten worden gekopieerd, zodat er geen tijd verloren gaat aan discussie.
• Gebruik geautomatiseerde tooling voor forensische kopieën en logging, zodat dit proces snel en gestandaardiseerd verloopt.

3. Scheiding tussen onderzoek en herstelacties

Terwijl forensische kopieën worden geanalyseerd, kunnen al bepaalde herstelstappen worden ingezet. Welke stappen parallel kunnen worden ingezet is echter situatieafhankelijk en (soms) al dan niet deels afhankelijk van de eerste resultaten vanuit het forensisch onderzoek. Als incidenten de cyclus “Analyse – Inperking (containment) – Opschoning (eradication) – Herstel” doorlopen, is het in de fase van (parallel) herstel wel handig om alvast wat richting te krijgen vanuit analyses. Frequente communicatie tussen forensisch onderzoekers en herstelteams is dan ook cruciaal.

Desalniettemin kan in voorkomende gevallen – al is dat soms ten overvloede – alvast gestart worden met de voorbereiding op herstel gedurende het onderzoek. Om goed te kunnen herstellen moet vaak niet simpelweg op een knop gedrukt worden. Er zijn verschillende handelingen noodzakelijk, al helemaal naar mate de cyberaanval grootschaliger is.

• Zijn herstelteams al (technisch) in staat met elkaar te communiceren?
• Kunnen herstelprocedures (technisch) al in gang worden gezet?

Indien het antwoord op een van deze vragen “nee” is, kan daar in ieder geval aan gewerkt worden.

In feite kan dus alles parallel aan het forensisch onderzoek worden voorbereid om – zodra het bestuur/management vindt dat er voldoende onderzoek is gedaan – direct aan de slag te gaan met herstel; te beginnen met opschoning (eradication), gevolgd door het daadwerkelijk herstel.

Let wel, uit het onderzoek kan blijken dat de inhoud van back-ups ook opgeschoond moet worden. Mede daarom is het niet verstandig klakkeloos back-ups te herstellen.

4. Oefenen met tabletop-exercises

Organisaties die vooraf crisisscenario’s oefenen, zijn beter voorbereid op de balans tussen onderzoek en herstel en wanneer de balans welke kant op wijst. Simulaties kunnen helpen om de juiste afwegingen voor te bereiden onder tijdsdruk.

5. Oefenen (back-up) restore testen

In deze blog staat tijdsdruk en het dilemma tussen langer onderzoek versus sneller herstel centraal. “Sneller herstellen” betekent echter niet dat direct na het besluit te kunnen gaan herstellen een IT-omgeving (of deel ervan) gelijk hersteld is. Ook herstel kost tijd. Daarom is het goed om als input voor de afwegingen die hierboven genoemd zijn (bij de tabletop-exercises) te weten hoe lang je daadwerkelijk doet over herstel. De enige manier om daar een serieuze inschatting van te maken, is door het herstel te oefenen. Daarbij geldt daarnaast dat hoe vaker iets geoefend is hoe sneller het proces gaat, technische beperkingen daargelaten.

6. Communicatie en stakeholdermanagement

Heldere communicatie met interne en externe stakeholders helpt de verwachtingen te managen en voorkomt paniekbeslissingen. Een cybercrisiscommunicatieplan voorkomt onnodige druk om systemen te snel online te brengen.

Conclusie

Het conflict tussen forensisch onderzoek en snel herstel is een klassieke uitdaging binnen incident response. Toch kan dit dilemma grotendeels worden weggenomen door vooraf goed na te denken over responsstrategieën. Door snel en efficiënt forensische kopieën te maken, parallelle herstelstappen te nemen, kunnen organisaties zowel snel herstellen als waardevolle inzichten uit het forensisch onderzoek behouden. Zoals vaak met (ogenschijnlijke) dilemma’s: het gaat om het vinden van de juiste balans.

Hoe gaat jouw organisatie om het vinden van die balans en hoe valt de balans uit: staat snelheid of zorgvuldigheid bij jullie voorop?

Vooruitplannen: structuur versus inflexibiliteit

Een gedetailleerd herstelplan heeft duidelijke voordelen. Het biedt structuur en houvast in een chaotische situatie. Iedereen weet wat ze moeten doen, in welke volgorde, en welke stappen prioriteit hebben. Maar te veel structuur kan ook een valkuil zijn. Wat als je plan uitgaat van een bepaald type aanval dat nét anders blijkt te zijn? Wat als de vooraf bedachte volgorde niet past bij de situatie, en niemand de autoriteit heeft om af te wijken?

Een voorbeeld: stel, dat jouw plan voorschrijft om eerst kritieke productie-applicaties te herstellen, maar blijkt dat de kritieke klantapplicaties sneller moeten worden opgestart om reputatieschade te voorkomen. Wie beslist dan om het plan los te laten en te improviseren? Het risico is dat een rigide plan meer tijd kost dan het bespaart.

Flexibiliteit: improvisatie of chaos?

Aan de andere kant kan een flexibel herstelpad waardevol zijn, omdat het ruimte laat om in te spelen op de specifieke situatie. Maar hier schuilt ook gevaar: zonder een helder kader kan flexibiliteit al snel omslaan in chaos. Wie neemt beslissingen? Op basis van welke informatie bepaal je prioriteiten? En hoe voorkom je dat verschillende teams elkaar tegenwerken?

Een hybride aanpak, waarbij bepaalde kritieke onderdelen strak gepland zijn en andere flexibel blijven, kan helpen om het beste van beide werelden te combineren. Maar dat vraagt voorafgaand overleg en duidelijke afspraken over wie welke beslissingen mag nemen.

Wat moet altijd eerst?

Er zijn delen van je IT-infrastructuur waar je simpelweg geen of in ieder geval weinig keuzevrijheid hebt. Basisinfrastructuur zoals AD, DNS, DHCP, NTP en je virtualisatieplatform vormen de ruggengraat van je IT-omgeving. Deze componenten zijn vaak sterk afhankelijk van elkaar. Dit betekent dat je voor deze lagen van je infrastructuur een vast en goed getest herstelplan nodig hebt (zie ook mijn eerdere blog over testen).

Op applicatieniveau is er vaak meer speelruimte. Hier kun je prioriteiten stellen op basis van de impact op je organisatie én de situatie waarin je verkeert. Zijn klantgerelateerde systemen het belangrijkst? Of richt je je eerst op interne processen zoals HR en finance? De keuzes die je maakt, zouden idealiter gebaseerd moeten zijn op een Business Impact Analysis (BIA), waarin je vooraf vastlegt welke applicaties cruciaal zijn voor je bedrijfscontinuïteit. Toch hoeven de resultaten van de BIA geen definitief uitsluitsel te bieden.

De rol van testen en simuleren

Of je nu kiest voor een strakke planning, flexibiliteit, of een combinatie van beide, een succesvol herstel staat of valt met testen. Tijdens een cyberaanval neemt stress vaak over, wat kan leiden tot fouten of vertraagde beslissingen. Het testen van je herstelplannen helpt niet alleen om technische fouten te ontdekken, maar ook om organisatorische zwaktes bloot te leggen. Wie neemt de leiding? Hoe stressbestendig is die persoon? Hoe reageren teams onder druk? Zijn de rollen en verantwoordelijkheden duidelijk?

Het simuleren van verschillende scenario’s, inclusief onvoorspelbare elementen, kan helpen om je organisatie voor te bereiden op het onverwachte. Denk aan scenario’s waarbij bepaalde systemen langer uitvallen dan verwacht, of waarbij sleutelpersonen niet beschikbaar zijn.

Strategische keuzes: alles voorbereiden of niet?

Het antwoord op dit dilemma is niet zwart-wit. Een 100% uitgewerkt herstelpad geeft duidelijkheid en snelheid, maar beperkt je wendbaarheid. Volledig vertrouwen op improvisatie biedt flexibiliteit, maar vergroot de kans op fouten. De beste aanpak is vaak een balans: een solide plan voor je basisinfrastructuur en ruimte voor flexibiliteit op applicatieniveau.

Belangrijk is dat je vooraf nadenkt over de verantwoordelijkheden. Wie beslist welke onderdelen volledig voorbereid worden? Wie heeft tijdens een crisis de autoriteit om beslissingen te nemen? En hoe zorg je ervoor dat deze rollen goed op elkaar zijn afgestemd?

Een plan voor het onverwachte

Een cyberaanval is altijd onverwacht, maar je herstelstrategie hoeft dat niet te zijn. Door kritisch te kijken naar je IT-afhankelijkheden en duidelijke keuzes te maken in wat je voorbereidt en wat je flexibel laat, kun je je organisatie wapenen tegen de gevolgen van een aanval. Combineer dit met regelmatig testen en een heldere rolverdeling, en je creëert een hersteltactiek die zowel robuust als wendbaar is.

De vraag blijft: ben jij voorbereid op het onverwachte? Of laat je het over aan de improvisatie van het moment?

On-premise vs. cloud: wat verandert er voor herstel?

In het kader van cyber recovery maakt het absoluut uit welk sourcing model van toepassing is: gaat het om on-premise IT, of public cloud? En als het om (public) cloud gaat, is het dan op basis van IaaS, PaaS of SaaS? De verantwoordelijkheden die bij jou liggen verschillen dan namelijk nogal, zoals ook in onderstaande afbeelding is weergegeven.

Bron: https://www.ncsc.gov.uk/collection/cloud/understanding-cloud-services/cloud-security-shared-responsibility-model

Als je on-premise werkt, heb je volledige controle over je infrastructuur en data. Dit betekent echter ook dat je zelf verantwoordelijk bent voor alle herstelmaatregelen, inclusief back-ups en recovery. De cloud biedt flexibiliteit en schaalbaarheid, maar ook een verschuiving in verantwoordelijkheden. De mate van verantwoordelijkheid hangt af van het gebruikte cloudmodel: SaaS, PaaS of IaaS.

Wie is waarvoor verantwoordelijk? SaaS, PaaS en IaaS

SaaS (Software-as-a-Service)

Bij SaaS-diensten, zoals Microsoft 365 en Salesforce, biedt de leverancier een kant-en-klare oplossing. Je hoeft je geen zorgen te maken over infrastructuur of software-updates, maar je bent wel zelf verantwoordelijk voor het beschermen van je data.

• Voorbeeld: Wat gebeurt er als een storing of ransomware-aanval de SaaS-dienst treft? Kun je je bedrijf draaiende houden zonder toegang tot de applicatie(s)? Hoewel je je data kunt veiligstellen, kunnen workflows, rechtenstructuren en andere applicatie-afhankelijke data verloren gaan. Mogelijk valt je proces daardoor stil en moet je op pen en papier verder.

PaaS (Platform-as-a-Service)

PaaS-oplossingen, zoals Heroku en Google App Engine, bieden meer flexibiliteit, maar leggen ook meer verantwoordelijkheid bij de klant. De leverancier beheert de infrastructuur, maar applicaties, databases en configuraties zijn jouw verantwoordelijkheid.

• Voorbeeld: Als de platforminfrastructuur crasht, kun je je data en applicaties hebben, maar de onderliggende runtime-omgeving ontbreekt. Zijn je applicaties dusdanig ontwikkeld dat ze gemakkelijk in een andere cloudomgeving of zelfs lokaal kunnen worden uitgevoerd?

IaaS (Infrastructure-as-a-Service)

Bij IaaS-oplossingen zoals AWS of Google Cloud krijg je maximale flexibiliteit om je IT-infrastructuur in te richten, van virtuele servers tot alles wat daar op draait.

• Voorbeeld: Wat als een hele regio van je cloudleverancier wordt getroffen door uitval? Het repliceren van je virtuele machines naar een andere regio of zelfs een andere provider kan de sleutel zijn tot een succesvol herstel. Dit vereist echter niet alleen technische voorbereiding, maar ook aandacht voor de bijkomende kosten en licentievoorwaarden.

Het dilemma: vertrouw je je leverancier (genoeg)?

Zoals hierboven al een paar keer beschreven; hetgeen waarvoor je verantwoordelijk bent verschuift op het moment dat je gebruik maakt van cloud – en eigenlijk ook bij IT-dienstverleners in het algemeen. Als het gaat om cyber recovery van hetgeen buiten jouw verantwoordelijkheid valt, wordt het vertrouwen in je IT-dienstverlener mogelijk toch op een weegschaal gelegd: Vertrouw ik volledig op mijn leverancier, wil ik zelf kunnen herstellen, of is er een tussenweg?

1. Volledig vertrouwen op de leverancier: Dit is de eenvoudigste optie, waarbij je vertrouwt op de SLA’s en herstelmaatregelen van de provider. Maar hoe zeker ben je dat de leverancier je data en applicaties op tijd herstelt en je niet dagen- of wekenlang met pen en papier verder moet? Zorg ervoor dat je precies weet wat ze wel en niet bieden.
2. Zelf back-ups en herstelplannen beheren: Het zelf opslaan van data en configuraties biedt meer controle, maar roept vragen op: Kun je zonder toegang tot de cloudomgeving iets met die data en configuraties? Hoe kom je aan een alternatief voor de cloudomgeving waarin je de data en configuraties kunt toepassen? Heb je voldoende capaciteit en kennis om zo’n herstelplan uit te voeren? Zie dit als een variant op het exit-plan dat je mogelijk al hebt met je IT-dienstverlener maar met de waarschijnlijke afwijking dat je alle maatregelen al klaar hebt staan (“in place” hebt) om zonder inbreng van de IT-dienstverlener het exit-plan uit te voeren. Let wel op: dit kan tot complicaties leiden op het gebied van licenties, intellectueel eigendom, restricties ten aan zien van dataverplaatsing, middleware en/of API’s die wel/niet mogen worden gebruikt, etc. Hoewel een IT-dienstverlener dus mogelijk niet zit te wachten op het laten back-uppen van zijn IT buiten zijn omgeving, is er voor die partij ook een positief punt. Op het moment dat jij een cyber recovery oplossing inricht voor hetgeen de IT-dienstverlener aanbiedt, kun jij ook fungeren als (vertrekpunt voor) cyber recovery van de gehele dienstverlening van de IT-dienstverlener. Jij bent dan als het ware dus zijn cyber recovery-oplossing. De vraag is dan echter: “Wil je dat wel?
3. De tussenweg: Waar volledig vertrouwen wellicht te ver gaat, is een tussenweg tussen dit vertrouwen en zelf alles in beheer willen nemen rondom cyber recovery de meest voor de hand liggende keuze. Immers, in het verleden is niet voor niets de keuze gemaakt om naar de cloud te gaan (of uit te besteden). Door juist alles zelf (weer) op je te nemen, doe je de redenen voor uitbesteding grotendeels of zelfs volledig, teniet. Hoewel het ook in dit scenario tot juridische complicaties kan leiden, valt er wel wat te zeggen voor het zo nu en dan (laten) back-uppen van je data naar een omgeving waar jij zelf (ook) toegang tot hebt en zelf volledig in de hand hebt wat er met de back-ups gebeurt. Er valt zelfs iets te zeggen voor het  opzetten van een tweede (stand-by, standaard offline) omgeving die met beperkte functionaliteit en grootte. Zo’n omgeving kan de minimaal noodzakelijke procesgang ondersteunen die normaliter door je primaire cloud-dienstverlener wordt ondersteund. De noodzaak voor zo’n omgeving is vrijwel volledig afhankelijk van de noodzaak voor (zeer) snel herstel van procesgang. Er is een risico dat in zo’n omgeving de back-ups van je primaire dienstverlener niet (een op een) ingelezen kunnen worden – logisch, want meestal is het totaal verschillende techniek die wordt toegepast – dus voor (historische) gegevenskritieke processen is dit wellicht niet de optie. En fin, veel keuzes; allemaal met hun voor- en nadelen.

Wat past bij jouw organisatie?

Cyber Recovery in de cloud is geen eenvoudige keuze tussen vertrouwen en controle. Het vereist een balans tussen afhankelijkheid van de leverancier en maatregelen in huis hebben om zelf te kunnen herstellen. Overweeg daarbij de mogelijke technische oplossingen, juridische beperkingen en operationele haalbaarheid om een strategie te ontwikkelen die aansluit bij jouw organisatiebehoeften en risicobereidheid.

Wil je controle of gemak? Kun je vertrouwen op de beloften van je leverancier, of ga je voor zekerheid door middel van een eigen herstelplan? De belangrijkste vraag blijft: Ben je voorbereid op een cyberaanval, ongeacht waar je IT zich bevindt?

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.

Herstellen na een cyberaanval

Bij cyberaanvallen is het tegenwoordig niet meer de vraag óf, maar wannéér ze plaatsvinden. Voor organisaties is het cruciaal om snel en efficiënt te kunnen herstellen. Maar wat moet je precies veiligstellen om dit zo snel en efficiënt mogelijk te maken? In mijn vorige blog stond ik stil bij het type informatie. In deze blog ga ik in op de vorm waarin die informatie is opgeslagen.

Wat moet er veiliggesteld worden?

Om snel weer operationeel te zijn na een cyberaanval, moet je minimaal de volgende drie lagen veiligstellen in je back-ups:

• Data: Zonder toegang tot je data staat je bedrijf stil. Data vormt de basis van alles en moet dus als eerste worden veiliggesteld.
• Configuraties: Netwerk-, server- en applicatieinstellingen, zowel de functionele als die verband houden met beveiliging, zijn net zo belangrijk als data. Zonder juiste configuraties kan het opzetten van je systemen dagen, zo niet weken, langer duren.
• Broncode: Voor organisaties die zelf software ontwikkelen of installeren is de broncode essentieel. Als je deze verliest, kan het maanden duren om weer op hetzelfde niveau te komen.

Hoewel dit de basis is, moet je goed nadenken over wat je misschien over het hoofd ziet. Bijvoorbeeld: zijn de wachtwoorden die ik nodig heb voor installatie inbegrepen? En hoe zit het met eventueel benodigde certificaten?

Hoe ga ik herstellen: herstellen of opnieuw opbouwen?

Soms is het handig om van achter naar voren te denken: wat is het eindresultaat, hoe wil ik daar komen en wat heb ik nu nodig? Dit principe geldt in feite voor vrijwel alles bij Cyber Recovery, dus ook voor het bepalen wat je moet veiligstellen. Als je weet welke data en functionaliteit wilt kunnen herstellen en je weet hoe je dat wil doen, ben je er al zo’n beetje.

Hoe je kunt herstellen is in grofweg twee strategieën op te delen:

• Restore: Hierbij herstel je systemen vanuit bestaande back-ups.
• Rebuild: Bij deze strategie bouw je de systemen helemaal opnieuw op.

Belangrijk om te realiseren: je data zelf moet eigenlijk altijd vanuit een back-up worden hersteld.

Restore

Veel organisaties maken al back-ups, maar vaak niet doordacht genoeg. Denk na over

1. Wat: Maak je back-ups van alleen data, of ook van applicatiefunctionaliteit en netwerkconfiguraties?
2. Hoe: Maak je back-ups van volledige servers, specifieke bestanden of databases?

Een goede vuistregel is: back-up alles wat je nodig hebt om weer te kunnen draaien. Heb je bijvoorbeeld al nagedacht over hoe je een compleet systeem kunt herstellen, en niet alleen losse bestanden?

Het is verstandig om periodiek te controleren wat er nu in je back-ups zit, met name door te testen of je vanuit niets kunt herstellen wat je wilt herstellen. Pas dan weet je of je genoeg in je back-ups hebt opgenomen. Wellicht mis je bepaalde data, configuraties of gehele IT-systemen.

Rebuild

Het opnieuw opbouwen van je IT klinkt als veel werk, maar dat hoeft het niet te zijn. Tegenwoordig wordt steeds meer als code opgeslagen, zelfs je IT-infrastructuur (infrastructure as code). Zolang die code is veiliggesteld en je beschikt over de juiste tools om die code uit te rollen, kun je met automatisering snel functionaliteit herstellen.

Checklist: Ben jij voorbereid?

1. Heb je duidelijk wat er hersteld moet worden? (zie ook mijn vorige blog)?
2. Is je herstelstrategie helder (restore of rebuild)?
3. Restore-strategie: Ben je zeker van wat je nu veiligstelt in je back-ups?
4. Rebuild-strategie: Heb je de benodigde code en configuraties veiliggesteld om een herbouw te faciliteren?

Met deze benadering ben je goed voorbereid op een cyberaanval, ongeacht de complexiteit van je IT-omgeving. Wil je sparren over hoe je jouw cyber recovery-strategie verder kunt versterken? Neem gerust contact op. Samen zorgen we ervoor dat je snel en efficiënt kunt herstellen, zonder verrassingen.

Cyber Recovery: wat moet je echt herstellen en wat niet?

In eerdere blogs stonden we stil bij het belang van kunnen herstellen na een cyberaanval. Maar: hoe bepaal je wat je moet herstellen en wat minder urgent is? Moet je alles herstellen of richt je je op de belangrijkste onderdelen? Wat zijn eigenlijk de belangrijkste onderdelen? En: hoe bepaal je dat? Dit zijn enkele cruciale vragen die organisaties zichzelf moeten stellen wanneer ze een Cyber Recovery-plan opstellen.

Uiteindelijk komt het neer op het maken van doordachte keuzes op basis van functionele en technische inzichten. Echter, uit onderzoek blijkt dat veel organisaties nog onvoldoende overzicht in hebben in wat hun kritieke functies zijn. Sterker nog, onderzoek bevestigt ook dat veel organisaties überhaupt het overzicht missen in welke activiteiten zij uitvoeren, in welke mate deze bijdragen aan de organisatiedoelstellingen en welke IT daarin (en in welke mate) een rol speelt*.

Alles herstelbaar maken dan maar? Vanuit kosten perspectief is dat op de lange termijn wellicht ook niet handig: heb je een of meerdere (cloud)datacenters beschikbaar waarin alles hersteld kan worden? En, o ja, die datacenters moet je eigenlijk nooit hoeven te gebruiken.

Kortom: het lijkt erop dat het maken van doordachte keuzes in wat wel en niet hersteld moet worden de beste / meest langdurige oplossing is. Maar waar moet ik aan denken? Laten we dat verkennen aan de hand van een gestructureerde aanpak, waarbij we kijken naar kritieke functies, afhankelijkheden en hoe je prioriteiten stelt in je herstelstrategie.

Hoe bepaal je wat je moet herstellen?

Een van de grootste uitdagingen in Cyber Recovery is het bepalen van wat je echt nodig hebt om snel weer operationeel te zijn. De meeste organisaties werken met een Business Impact Analysis (BIA) om te bepalen welke functies en systemen prioriteit hebben. De BIA helpt bij het classificeren van activiteiten en tooling die cruciaal zijn voor je bedrijfsvoering. Maar hoe gedetailleerd is dat inzicht werkelijk? Vaak blijft het beperkt tot de tools die worden gebruikt en missen we een duidelijk beeld van de afhankelijkheden tussen systemen en (bedrijfs)activiteiten. Behalve dat dit laatste wat mij betreft cruciaal is om een BIA goed uit te kunnen voeren, mist er nog iets. Waar de BIA meestal is gericht op de afhankelijkheden van IT voor de continuïteit van de organisatie, mist vaak (terecht) in de BIA de afhankelijkheden van IT om de IT te continueren. Bijvoorbeeld: de BIA maakt (hopelijk) een verbinding tussen bedrijfsvoering en ondersteunende applicaties en andere IT-systemen. Echter, de IT-systemen die in de BIA zijn opgenomen, zijn op hun beurt ook weer afhankelijk van allerlei elementen. Denk aan certificaten, wachtwoordkluizen waarin wachtwoorden van beheeraccounts staan, besturingssystemen met bepaalde instellingen en ga zo maar door. Om goed te kunnen herstellen is ook dit inzicht een must.

Kortom, om te bepalen wat kritiek is, is inzicht nodig in:

1. De bedrijfsactiviteiten, in welke mate deze van belang zijn voor de continuïteit van de organisatie en welke (soort) informatie gebruikt/verwerkt wordt in die activiteiten;
2. De applicaties en andere IT-systemen die de bedrijfsactiviteiten ondersteunen en in welke mate dat ze dat doen;
3. De afhankelijkheden die de IT-systemen kennen om te kunnen functioneren.

Zonder deze inzichten herstel je niet de belangrijkste zaken en/of duurt herstel mogelijk (veel) langer dan nodig. Het mooie? De meeste organisaties zijn al zo ingericht dat deze drie inzichten opgehaald kunnen worden bij verschillende afdelingen:

Voor inzicht #1 en #2 zijn het de mensen op de werkvloer en/of management die de inzichten zou moeten kunnen geven:

• Het hebben van een dataclassificatiemodel, waarin ten minste classificaties ten aanzien van de beschikbaarheid, integriteit en vertrouwelijkheid van data wordt stilgestaan, helpt bij het bepalen van het bepalen van belang van activiteiten. Tegelijkertijd kan op basis van gestructureerde analyses en onderbouwingen er best wel eens een scheef beeld ontstaan over wat belangrijk is en wat minder. Daarom is het goed om ongeacht wat de modellen als uitkomst bieden altijd de resultaten onderling te vergelijken van activiteit tot activiteit en desnoods het gehanteerde model te overrulen.

Voor #3 moet je bij IT zijn:

• Een goed CMDB kan het gemakkelijk maken om het inzicht snel te bieden.
• Is beheer van je IT uitbesteed? Nog mooier, dan is het meestal aan de IT-dienstverlener om dit inzicht te hebben en is het aan jou om goede afspraken te maken over beschikbaar maken van IT na een cyberaanval.

Maar wat als je je vergist?

Hoewel automatisering van bovenstaande absoluut kan helpen, is er altijd een kans dat je wat zaken mist of verkeerd hebt opgenomen in de gevraagde inzichten. Er is immers in ieder van de uit te voeren activiteiten sprake van enige mate van afhankelijkheid van mensen. En waar mensen werken, worden fouten gemaakt.

Wat dus als die fouten zijn gemaakt bij het maken van die inzichten? Je zult het in deze reeks nog wel een paar keer lezen: testen, testen, testen. De enige manier om er echt achter te komen is door te gaan testen. Hoe en wat te testen, dat komt later nog wel eens aan bod.

Cyber Recovery-plan in kaart brengen

Veel organisaties hebben hun recovery-plannen nog niet volledig in kaart, vooral als het gaat om het bepalen van prioriteiten en afhankelijkheden. Zonder gedegen inzicht in wat er hersteld moet worden en in welke volgorde, loop je het risico op onnodige vertragingen en extra schade. Het is tijd om je herstelstrategie tegen het licht te houden: Heb jij helder wat er hersteld moet worden na een aanval?

Neem contact op om te ontdekken hoe we jouw Cyber Recovery-plan kunnen optimaliseren. Samen zorgen we ervoor dat je snel en effectief herstelt, zonder dat je iets over het hoofd ziet. Afspraak maken voor een vrijblijvend gesprek? Bel me op 06 417 731 52 of mail naar toine@arcpeople.nl.

* Kanttekening: wat dat betreft ligt er voldoende uitdaging om te gaan voldoen aan DORA en in iets mindere mate NIS2.