Een ransomware recovery plan dat werkt

De meeste organisaties hebben een backup. Veel minder hebben een recovery plan dat ze ook daadwerkelijk getest hebben. Dat verschil is precies wat ransomware-aanvallers uitbuiten. Dit artikel gaat over wat een recovery plan werkend maakt.

De drie elementen die niet mogen ontbreken

Immutable backups. Een backup die een aanvaller kan versleutelen of verwijderen, is geen backup. AWS S3 Object Lock en Azure Blob Storage immutability policies zorgen ervoor dat data voor een vaste periode niet gewijzigd of gewist kan worden, ook niet door iemand met admin-rechten. Stel de retentieperiode in op minimaal 30 dagen en gebruik Governance Mode alleen als je een goede reden hebt om de lock eerder te verwijderen. Compliance Mode is stricter en bij voorkeur de keuze voor kritische data.

Gescheiden recovery netwerk. Als je recovery-omgeving op hetzelfde netwerksegment zit als de aangetaste productieomgeving, ben je opnieuw kwetsbaar zodra je begint te herstellen. Een out-of-band recovery netwerk, bij voorkeur in een aparte cloud-account of subscription, houdt de schade beheersbaar. Je kunt hier naartoe herstellen, valideren, en dan gecontroleerd terugkoppelen naar productie.

Regelmatige restore-tests. Een backup waarvan je nooit getest hebt of hij werkt, is geen backup. Plan minstens elk kwartaal een volledig restore-test van kritische systemen. Leg de resultaten vast: hoe lang duurde het, wat ging er mis, wat was de RPO en RTO in de praktijk versus op papier?

De 3-2-1-1-0 regel

De klassieke 3-2-1 backup-regel (3 kopieën, 2 verschillende media, 1 offsite) is een goed startpunt maar niet meer voldoende. De uitgebreide variant:

• 3 kopieën van je data
• 2 verschillende opslagmedia
• 1 offsite kopie
• 1 offline of air-gapped kopie
• 0 fouten bij de laatste restore-test

Die laatste nul is het lastigst. Hij vereist dat je de test daadwerkelijk uitvoert en documenteert. Geen exceptions.

RTO/RPO: wees eerlijk

Recovery Time Objective (hoe lang mag herstel duren?) en Recovery Point Objective (hoeveel data mag je verliezen?) staan in vrijwel elk DR-document. Het probleem is dat ze zelden getoetst zijn aan de realiteit.

Kijk kritisch naar je huidige RTO/RPO-afspraken:

• Is je backup-frequentie consistent met je RPO? Een dagelijkse backup bij een RPO van 4 uur is een probleem.
• Heb je de RTO gemeten onder realistische omstandigheden (stress, beperkte bezetting, externe afhankelijkheden)?
• Zijn je RTO/RPO-afspraken gedekt door je cyberverzekeraar?

Als je de antwoorden niet weet, is dat al een bevinding.

Tabletop exercises

Een tabletop exercise is een gesimuleerd incident in een vergaderruimte. Geen echte systemen, geen echte data, wel echte beslissingen. Je loopt een scenario door: “het is maandag 03:00, je SOC krijgt een melding, wat doe je?”

Goed doorlopen tabletop exercises laten zien:

• Wie belt wie? Is dat opgeschreven?
• Wie heeft bevoegdheid om systemen af te schakelen?
• Wat communiceer je naar klanten, en wanneer?
• Weet iedereen waar de offline back-ups staan?

Plan er minstens één per jaar, liefst twee. Huur een externe facilitator in als de interne bias het scenario te makkelijk maakt.

Dag 1: wat je doet en wat je niet doet

Wanneer het incident bevestigd is, zijn de eerste uren bepalend.

Doe dit:

Isoleer aangetaste systemen zo snel mogelijk van het netwerk. Dit stopt laterale verspreiding. Schakel niet uit tenzij je instructie krijgt van forensisch onderzoek, want vluchtig geheugen bevat waardevolle informatie.

Bel direct drie partijen:

• NCSC (Nationaal Cyber Security Centrum) als je een vitale aanbieder bent of overheidsorganisatie. Voor anderen is melden aan de AP verplicht als er persoonsgegevens betrokken zijn.
• Je cyberverzekeraar. Niet na drie dagen nadenken, maar op dag 1. Veel polissen stellen eisen aan hoe je het incident beheert.
• Een IR-specialist. FOX-IT en Northwave zijn in Nederland de meest bekende partijen die 24/7 beschikbaar zijn voor incident response.

Doe dit niet:

Betaal niet meteen. De eerste impuls om “gewoon te betalen en door te gaan” is begrijpelijk maar zelden de juiste keuze. Er is geen garantie dat de decryptiesleutel werkt, dat de aanvallers je data niet alsnog publiceren, of dat ze niet opnieuw toeslaan. Bespreek dit met je IR-specialist en verzekeraar voordat je een beslissing neemt.

Wil je je team beter voorbereiden? Kijk naar incident response trainingen voor praktische voorbereiding.

Documenteer voor het incident

Alles wat je nodig hebt op dag 1 moet beschikbaar zijn zonder toegang tot je eigen systemen. Druk het uit, sla het op in een kluis, of leg het op een volledig gescheiden systeem:

• Contactlijst (IR-partij, verzekeraar, NCSC, management)
• Locatie van offline backups en herstelsleutels
• Netwerksegmentatie-diagram
• Beslissingsbevoegdheden per scenario

Een recovery plan dat alleen in je ITSM-tool staat, is nutteloos als je ITSM-tool versleuteld is.