Veel pogingen om ransomware te herstellen beginnen op dezelfde manier. De een haalt het noodherstelplan tevoorschijn. De ander belt de leverancier van de back-upoplossing. En dan botst het plan, dat waarschijnlijk was opgesteld met het oog op natuurrampen of onbedoeld verwijderen, op de realiteit en loopt het volledig in het honderd.

De tekortkomingen in de paraatheid voor herstel zijn opvallend en hardnekkig consistent bij alle organisaties, zelfs bij die welke fors hebben geïnvesteerd in detectie en weerstand. Dit wijst op een structureel probleem. Organisaties hebben decennialang gewerkt aan het opzetten van beveiligingsprogramma’s en het aanscherpen van hun vermogen om dreigingen te onderkennen. Slechts een fractie van die tijd is besteed aan herstelvermogen, en baanbrekende AI-modellen zoals Mythos maken duidelijk waarom dat een kostbare fout is.

De toch al lage drempel voor ransomware-aanvallers zal binnenkort vrijwel verdwenen zijn. De aanvallers van vandaag kunnen vrijwel elke verdediging doorbreken als ze maar gemotiveerd genoeg zijn. Over een jaar, als het juiste AI-model zelfstandig kwetsbaarheden opspoort, hoeven ze misschien niet eens meer zo gemotiveerd te zijn.

De kosten van een niet-getest herstelplan lopen op. Als uw organisatie deze veranderingen alleen bekijkt vanuit het perspectief van hoe bedreigingen sneller kunnen worden opgespoord, laat u de helft van het probleem onopgelost.

Wat organisaties steeds weer verkeerd doen

De onderstaande tekortkomingen komen niet alleen voor bij organisaties met zwakke beveiligingsprogramma’s. Ze doen zich ook voor bij bedrijven met geavanceerde detectiesystemen, sterke teams en aanzienlijke beveiligingsbudgetten. De rode draad is dat er in herstelcapaciteit minder is geïnvesteerd en minder is getest dan in detectiecapaciteit.

De vertrouwenskloof op het gebied van back-ups

Dit is de gevaarlijkste fout, omdat het lijkt alsof het probleem is opgelost.

Je hebt back-ups. De taken zijn voltooid. Het dashboard staat op groen. Je meldt aan de raad van bestuur dat er back-ups zijn. Je hebt het vakje aangevinkt en bent verder gegaan, waarschijnlijk al jaren geleden.

Dan vindt de aanval plaats. Kunnen die back-ups het hoofd bieden aan een aanvaller die de omgeving in kaart heeft gebracht, over bevoegdheden beschikt en zich bewust richt op de back-upinfrastructuur?

In de praktijk komt Fenix24 er vaak achter dat back-upinfrastructuur zich op hetzelfde netwerksegment bevindt als de productomgeving. We komen ‘onveranderlijke’ repositories tegen waar het serviceaccount nog steeds verwijderingsrechten heeft. We zien back-uptaken die al jarenlang succesvol worden uitgevoerd zonder dat iemand ooit een volledige herstelbewerking heeft gecontroleerd.

Ransomware-aanvallers richten zich op back-ups omdat slachtoffers hierdoor kunnen ontsnappen zonder te betalen. Met Frontier AI-modellen die omgevingen zelfstandig in kaart kunnen brengen, wordt die aanpak nog nauwkeuriger. Als een model kwetsbaarheden in een heel besturingssysteem kan opsporen, kan het ook de back-upserver vinden die uw team drie jaar geleden heeft geïnstalleerd en sindsdien nooit heeft verplaatst.

Om back-ups echt betrouwbaar te maken, zijn drie zaken nodig: onveranderbaarheid (zelfs een aanvaller met beheerdersrechten kan ze niet wijzigen of verwijderen), segmentatie (de back-upomgeving is niet bereikbaar vanuit het gecompromitteerde netwerk) en geteste herstelprocedures (er is een volledig herstel getest, niet alleen bevestigd als voltooide taak). Veel organisaties beschikken over één van deze drie elementen. Maar veel minder organisaties hebben ze alle drie. En degenen die ze alle drie hebben, zijn daar meestal gekomen omdat ze op de harde manier hebben geleerd wat er gebeurt als je dat niet doet.

De RTO-fictie

Volgens uw RTO is dat 48 uur. Het werd opgenomen in een plan, ging door naar een presentatie voor de raad van bestuur en werd onderdeel van het gemeenschappelijke risicobewustzijn binnen de organisatie.

Geweldig, maar… niemand heeft ooit getest hoe lang het duurt om volledig te herstellen in een scenario waarin de identiteitsgegevens zijn gecompromitteerd, de toegang tot back-ups beperkt is en het team met verstoorde communicatie moet werken. Een simulatieoefening waarbij iedereen aantekeningen bij de hand heeft en het SIEM-systeem naar behoren functioneert, telt niet mee. Een gepland onderhoudsvenster waarin één systeem vanuit een back-up wordt hersteld, telt evenmin mee.

Een realistische test van het herstelvermogen gaat uit van het ergste scenario. Het identiteitsbeheer ligt plat. De toegang tot back-ups is beperkt. De communicatie verloopt moeizaam. De helft van het team moet beslissingen nemen terwijl ze geen oog dicht hebben gedaan. De CISO is op safari zonder mobiele telefoon.

Bij vrijwel elke opdracht zien we de gevolgen van niet-geteste RTO’s. Het cijfer op papier en de werkelijkheid in de praktijk komen zelden overeen. Wanneer er een verschil is, stapelen de gevolgen zich op: omzetverlies, verstoring van de bedrijfsvoering, klantenverloop, reputatieschade en blootstelling aan regelgeving – risico’s die de organisatie nooit in haar risicobeeld heeft meegenomen, omdat ze vertrouwde op een cijfer dat niemand had getest.

Identiteitsreconstructie

Active Directory speelt vrijwel altijd een centrale rol bij een aanval. Het zou dan ook een even centrale rol moeten spelen in het herstelplan. In de praktijk zien we weliswaar volwassen, goed gestructureerde plannen voor het herstellen van applicaties en databases, maar valt er een stilte wanneer het gesprek op het herstel van AD komt. Geen offline back-ups. Geen gedocumenteerd herstelproces. Geen geteste schatting van de hersteltijd. Geen duidelijk antwoord op de vraag welke domeincontrollers veilig zijn, welke serviceaccounts te vertrouwen zijn, of hoe geprivilegieerde toegang veilig kan worden hersteld.

Dit is belangrijker dan in de meeste herstelplannen wordt erkend. Niets stroomafwaarts is te vertrouwen totdat de identiteit is hersteld en als veilig is geverifieerd. Applicaties, databases, eindpunten, bestandsdelingen, beheerderstoegang, serviceaccounts, cloudintegraties, bevoorrechte workflows. Het hangt allemaal op de een of andere manier af van identiteit. Als de identiteit is gecompromitteerd, is alles wat zich daaraan baseert om te authenticeren, bijgevolg ook gecompromitteerd.

De organisaties die identiteitsherstel goed aanpakken, hebben hier ervaring mee. Ze beschikken over offline back-ups van Active Directory. Ze hebben een gedocumenteerd en getest proces om het systeem vanuit een schone staat opnieuw op te bouwen. Ze weten hoe lang dit duurt, omdat ze dit hebben gemeten. Alle anderen komen er pas achter tijdens de zwaarste week van hun carrière.

Blindheid voor afhankelijkheden

Als het systeem uitvalt, stelt iemand altijd de vraag die bepalend is voor de snelheid van het herstel: „Wat komt als eerste weer online?“

In veel te veel organisaties zit het antwoord alleen in het hoofd van één ingenieur. Soms is er helemaal geen antwoord te vinden.

Herstel is geen opsomming van systemen. Het is een proces. Je kunt een ERP-systeem niet weer in gebruik nemen als de database waarvan het afhankelijk is nog steeds niet werkt. Je kunt applicaties niet weer online zetten als de identiteitsinfrastructuur waarmee ze authenticeren nog niet is hersteld. Je kunt kritieke workflows niet herstellen als het ondersteunende netwerk, de opslag, DNS, geheimen en serviceaccounts ontbreken of gecompromitteerd zijn.

Zonder een actueel afhankelijkheidsmodel verliezen herstelteams kostbare tijd door in de verkeerde volgorde te werk te gaan. Ze zetten applicaties weer online voordat de infrastructuur waarvan die applicaties afhankelijk zijn, klaar is. Ze ontdekken tijdens het herstelproces, onder druk en terwijl het bedrijf schade lijdt, dat er afhankelijkheden ontbreken. Een herstelproces dat dagen zou moeten duren, sleept zich wekenlang voort omdat de volgorde vanaf het begin verkeerd was.

Bij de meeste organisaties liggen de gegevens over bedrijfsmiddelen verspreid over tientallen systemen. Ze zijn verouderd en spreken elkaar tegen. De CMDB zegt het ene, het netwerkteam zegt het andere, en de applicatiebeheerder die het volledige overzicht had, is acht maanden geleden vertrokken. Onder normale omstandigheden is die versnippering vervelend. Tijdens een actief herstelproces is het rampzalig.

De organisaties die zich het snelst herstellen, lossen dit niet pas tijdens het incident op. Zij weten het al. Tier 0-systemen zijn geïdentificeerd. Afhankelijkheden zijn in kaart gebracht op basis van actuele gegevens, niet van statische diagrammen. Herstelprocedures zijn opgesteld op basis van echte relaties en getest voordat ze nodig zijn. Alle anderen stellen het plan onder tijdsdruk en zonder duidelijkheid helemaal zelf op.

De kloof tussen vredes- en oorlogstijd

Beveiligingsprogramma’s worden in vredestijd ontworpen en gedocumenteerd. In vredestijd werkt het SIEM-systeem. Het SOC is bemand. De forensische partner is met één telefoontje bereikbaar. Mensen zijn uitgerust. De communicatiekanalen zijn beschikbaar. Beslissingen kunnen dagen of wekenlang worden besproken.

In oorlogstijd is het precies het tegenovergestelde.

De organisaties die in oorlogstijd goed functioneren, hebben daar in vredestijd al op geoefend. Ze voerden simulaties uit om reddingsoperaties, coördinatie, de volgorde van handelingen en besluitvorming onder moeilijke omstandigheden te testen. Zo ontdekten ze wat er mis zou gaan.

De organisaties die het moeilijk hebben, gingen ervan uit dat het plan stand zou houden zodra alles in brand stond. Door AI gecomprimeerde tijdlijnen van aanvallen zullen olie op het vuur gooien.

Veerkracht en herstel in een wereld waarin AI geen grenzen meer kent

De meeste aannames over veerkracht en herstelvermogen gaan bij een daadwerkelijke aanval niet op.

• "Onveranderlijke back-ups" blijken toch niet zo onveranderlijk te zijn.
• Niet alleen gegevens gaan verloren, maar ook de infrastructuur.
• Onvoldoende inventarisatie van bedrijfsmiddelen en afhankelijkheden leidt tot dagen- of wekenlange uitval.
• RTO’s en RPO’s zijn niet realistisch.

Analisten zetten alles op een rijtje als het gaat om de toekomst van veerkracht. Wilt u het stappenplan voor het ontwerpen en implementeren van echte cyberveerkracht? Download dan het nieuwe technische validatierapport van Omdia: Architect and Execute Resilience with Fenix24.

Wat bepaalt of je het overleeft

Er zijn drie factoren die het verschil maken tussen organisaties die zich snel herstellen en organisaties die wekenlang in het duister tasten (of zich helemaal niet herstellen). Frontier AI verandert de werkwijze niet. Het verandert de snelheid. Daardoor wordt elke factor juist nog belangrijker, niet minder.

Identiteit moet als eerste worden hersteld. Hier valt niet over te onderhandelen en het is de stap die de meeste organisaties het minst vaak hebben uitgevoerd. Active Directory en de identiteitsinfrastructuur behoren tot de eerste doelwitten bij een moderne ransomware-aanval. Ze moeten ook als een van de eerste dingen worden hersteld. Niets stroomafwaarts kan worden vertrouwd totdat de identiteit is hersteld en geverifieerd als schoon. Applicaties, databases, serviceaccounts, bevoorrechte workflows, cloudintegraties. Het wordt allemaal op de een of andere manier geauthenticeerd tegen de identiteit. Door AI versnelde aanvallen veranderen die afhankelijkheidsketen niet. Ze verkorten de tijd die je hebt om erop te reageren.

Back-ups moeten bestand zijn tegen een aanvaller, niet alleen tegen hardwarestoringen. De meeste organisaties beschikken over back-ups. Maar de meeste hebben geen back-ups die bestand zijn tegen een aanvaller die over geldige inloggegevens beschikt, uw omgeving door en door kent en precies weet waar de back-upinfrastructuur zich bevindt. Een back-upstrategie die is ontworpen voor hardwarestoringen of onbedoelde verwijdering is niet hetzelfde als een back-upstrategie die is ontworpen voor een slimme aanvaller met bevoorrechte toegang.

Herstel moet de werkelijke afhankelijkheidsstructuur volgen, niet de veronderstelde. Je kunt een ERP-systeem niet weer in bedrijf stellen als de database waarvan het afhankelijk is nog steeds niet werkt. Je kunt kritieke workflows niet herstellen als de ondersteunende infrastructuur ontbreekt of is aangetast. Herstel is een reeks stappen, en die volgorde moet kloppen. In de meeste organisaties vormen niet in kaart gebrachte afhankelijkheden een van de grootste oorzaken van vertraging bij herstelwerkzaamheden. Geautomatiseerde afhankelijkheidskartering op basis van live telemetrie, die actueel blijft naarmate de omgeving verandert, maakt het verschil tussen een herstelplan dat de werkelijkheid weerspiegelt en een plan dat de laatste keer weerspiegelt dat iemand een spreadsheet heeft bijgewerkt.

Deze drie factoren golden vijf jaar geleden. Ze zullen over vijf jaar nog steeds gelden. Wat Mythos en baanbrekende AI veranderen, is de prijs die je betaalt als je je hierin vergist. Wanneer de aanval zich sneller voltrekt dan de mens kan reageren, wordt elke tekortkoming in de paraatheid om te herstellen duurder en zichtbaarder.

Belangrijke herstelstatistieken

Als uw rapportage aan de raad van bestuur wel detectie maar geen herstel omvat, is dit het juiste moment om daar verandering in te brengen. Dit zijn indicatoren die een CISO met dezelfde nauwkeurigheid kan rapporteren als detectie-indicatoren, en ze geven een heel andere wending aan het gesprek.

De daadwerkelijk gemeten hersteltijd. Niet de vastgelegde RTO. De tijd die daadwerkelijk is gemeten tijdens een hersteloefening op basis van een realistisch inbraakscenario. Vermeld het aantal keren en de datum waarop dit voor het laatst is getest.

Overlevingspercentage van back-ups. Het percentage back-upopslagplaatsen dat aan alle drie de criteria voldoet: onveranderlijk, gesegmenteerd en gevalideerd door middel van een volledige herstelprocedure. Een enkel samengesteld cijfer dat de raad van bestuur in de loop van de tijd kan volgen.

Dekking van afhankelijkheidsketen van niveau 0. Het percentage kritieke applicaties waarvan de afhankelijkheidsketens volledig in kaart zijn gebracht en de herstelprocedures zijn gedocumenteerd. Dit geeft aan in hoeverre het herstelproces gepland is en in hoeverre het op de situatie wordt afgestemd.

Tijd voor identiteitsherstel. Hoe lang het duurt om Active Directory vanuit een schone staat opnieuw op te bouwen. Als dit getal niet is getest, geef dan aan dat het niet is getest.

Wat er de komende 90 dagen moet gebeuren

U hoeft de voorbereiding op het herstel niet in één keer te regelen, maar het ‘Mythos-venster’ is wel degelijk reëel. De aandacht van het management gaat momenteel uit naar AI-bedreigingen. Het zal nooit makkelijker zijn om investeringen in herstel te beargumenteren dan in het komende kwartaal.

Controleer of back-ups bestand zijn tegen aanvallen. Test of back-ups het overleven als een aanvaller er bewust op aast. Test de onveranderbaarheid, segmentatie en volledige herstelmogelijkheden. Als u dit intern niet met zekerheid kunt doen, schakel dan een bedrijf in dat gespecialiseerd is in het herstellen van ransomware-schade en dit beroepsmatig test.

Breng de afhankelijkheidsrelaties in kaart die bepalend zijn voor de volgorde van herstel. Breng Tier 0-systemen in kaart. Leg vast welke applicaties afhankelijk zijn van welke infrastructuur. Stel herstelprocedures op basis van feitelijke relaties op, niet op basis van aannames. Als uw omgeving complex genoeg is, vereist dit tools die realtime telemetriegegevens binnen uw hele infrastructuur met elkaar in verband brengen, en geen handmatig bijgehouden spreadsheet die al verouderd is nog voordat u op ‘Opslaan’ hebt geklikt.

Zorg voor een beproefd herstelcijfer. Voer een hersteloefening uit waarbij je uitgaat van het ergste scenario: identiteitsdiefstal, aanvallen op back-ups, verstoorde communicatie. Meet de tijd die het kost. Breng in kaart waar het team vastloopt. Die meting vormt je uitgangspunt en het cijfer dat je aan je raad van bestuur presenteert.

Breng herstel en detectie samen in beeld. Neem de bovenstaande statistieken op in je volgende dashboardupdate. Presenteer detectie en herstel als twee kanten van dezelfde medaille. Het verschil spreekt waarschijnlijk voor zich.

Herstelachterstanden zijn geen statische risico’s die je kunt aanpakken wanneer het je uitkomt. Het zijn activa die in waarde dalen. Elk kwartaal dat je wacht, wordt de omgeving moeilijker in kaart te brengen, worden de afhankelijkheden complexer en loopt de capaciteit van de aanvaller steeds verder voor op jouw herstelcapaciteit.

CISO’s hebben jarenlang gewerkt om een plek aan tafel te veroveren door aan te tonen dat ze risico’s konden beperken. Het komende decennium zal in het teken staan van het bewijzen dat je de bedrijfsvoering ook tijdens een datalek in stand kunt houden. Dat vereist andere vaardigheden, andere investeringen en andere gesprekken met het management. De organisaties die dit vroeg onder de knie krijgen, zullen zich herstellen. De organisaties die dat niet doen, zullen wekenlang lessen moeten leren die ze in rustige tijden al hadden kunnen leren.

Ga aan de slag met een veerkrachtbeoordeling

Zijn uw back-ups bestand tegen een vastberaden aanvaller? De veerkrachtbeoordeling van Fenix24 stelt uw omgeving op de proef, voordat een incident dat voor u doet.

De veerkrachtbeoordeling wordt mogelijk gemaakt door Argos99, ons veerkrachtplatform voor grote ondernemingen, dat realtime telemetriegegevens uit uw gehele infrastructuur met elkaar in verband brengt om elk onderdeel, elke afhankelijkheid en elke lacune in kaart te brengen. Dit betekent dat de veerkrachtbeoordeling van Fenix24 de dekking van back-ups op applicatieniveau evalueert, en niet alleen de status van de taken. Het brengt in kaart wat van wat afhankelijk is en genereert op basis van die relaties een volgorde voor het herstel. Alles wat we beoordelen, is gebaseerd op wat we hebben geleerd uit honderden praktijkgevallen van herstel na inbreuken.

Sla de standaardcontroles maar over. Die zijn vaak bedoeld om te bevestigen wat u al denkt te weten, niet om de waarheid aan het licht te brengen. Maak vandaag nog een afspraak voor een veerkrachtbeoordeling. Neem contact met ons op via 423.305.7890 of stuur een e-mail naar info@fenix24.com.