Inleiding
Business Continuity Management (BCM) is een essentieel onderdeel van een robuuste bedrijfsstrategie, waarbij begrippen als Recovery Time Objective (RTO), Recovery Point Objective (RPO) en Maximum Tolerable Downtime (MTD) centraal staan. Traditioneel worden deze termen bepaald op proces- of dienstniveau, maar is dat altijd de meest effectieve aanpak? In deze blog betogen we dat RPO en RTO beter op applicatieniveau kunnen worden gedefinieerd en dat, in de context van cyberdreigingen, een alternatief zoals Cyber RTO (CRTO) noodzakelijk is.
Ben jij voorbereid op een cyberaanval? En hoe zeker ben je dat je kunt herstellen na zo’n aanval? Lees verder
In deze blog staan we stil bij waarom het niet verstandig is om Cyber Recovery volledig uit te besteden, zelfs als je IT dat wel is. Ook geven we 5 tips over zaken die je écht zelf moet regelen. Lees verder
In deze blog geven we tips over herstellen na een cyberaanval. Tijd om jouw herstelstrategie onder de loep te nemen. Lees verder
Wat moet je precies veiligstellen om zo snel en efficiënt mogelijk te herstellen na een cyberaanval? In de vorige blog stonden we stil bij het type informatie. Nu gaan we dieper in op de vorm waarin die informatie is opgeslagen. Lees verder
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? Lees verder
Kun je volledig vertrouwen op je cloudleverancier, of moet je zelf herstelmaatregelen nemen als er een cyberaanval toeslaat? En hoe verschillen de opties tussen SaaS, PaaS en IaaS? Lees verder
Wat is belangrijker in cyber recovery: een waterdicht noodplan of ruimte voor improvisatie bij een onvoorspelbare cyberaanval? Lees verder
Direct herstellen om de schade te beperken, of eerst forensisch onderzoek doen om te achterhalen wat er is gebeurd bij een cyberaanval? Lees verder
Welke concepten zijn er op de markt beschikbaar en welke overwegingen spelen een rol bij de keuze voor een specifieke aanpak? Lees verder
De termen RTO, RPO en MDT worden traditioneel bepaald op proces- of dienstniveau, maar is dat altijd de meest effectieve aanpak? Lees verder
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:
- Procesgerichte benadering leidt tot suboptimale invulling: Processen bestaan vaak uit meerdere applicaties en systemen met verschillende herstelmogelijkheden.
- 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.
- 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.