Blog: Aantonen van Ransomware-bestendigheid SaaS toepassingen roept vraagtekens op

De aantoonbaarheid is enerzijds van belang vanwege de omvang van de dreiging maar anderzijds ook omdat toezichthouders daarom vragen. En die vragen zullen gaan groeien: nieuwe regelgeving, zoals de NIS2, gaat nog meer aandacht vragen van de aantoonbare beheersing van risico’s door leveranciers en ketenpartners. In deze blog daarom aandacht voor deze kwestie en gevonden lessen en overwegingen die je hierin als zakelijke gebruiker van SAAS oplossingen kan meenemen.

Immutable Storage en aantoonbaarheid
Bij de weerbaarheid tegen ransomware speelt het opslaan van de backup in zogenaamde “Immutable Storage” een cruciale rol. Het onbruikbaar maken van de backup, door deze te veranderen, te versleutelen of te verwijderen, wordt dan voorkomen.  

Maar hoe weet je zeker dat de backup van jouw SaaS-toepassing ‘’immutable’’ is opgeslagen? En hoe kan je dit aantonen aan je toezichthouders?  Een werkgroep vanuit CIOPN, bestaande uit Paul Samwel (CISO, ONVZ), Frans Voogd (Security Officer, Heijmans), Marcel van Essen (Risk & Security Coördinator, Havenbedrijf Amsterdam) en Ton Sundemeijer (Information Security Officer, TBI), heeft zich de afgelopen maanden gebogen over deze problematiek.

Behoeftes van de zakelijke gebruiker in 6 vragen
In theorie leek het toch simpel. Als we nu eenduidig formuleren wat we van de SaaS-leveranciers verwachten en deze vraagstelling formuleren op een manier waar de SaaS-leveranciers er wat mee kunnen, dan kunnen we eenvoudiger en effectiever dezelfde antwoorden ontvangen van onze leveranciers. In ons enthousiasme hebben we ons op deze lijn gelijk gestort op de inhoud. Daarbij kwamen we tot een inhoudelijk boodschap als:

Kan ik als afnemer samen met mijn SaaS-leverancier de dienstverlening binnen redelijke termijn herstellen na een geslaagde ransomware aanval bij mijn Cloud provider?

1. Maak je een back-up van applicatie, infrastructuur en data?
2. Is de back-up “Immutable”?
3. Wat is de retentie periode van de back-up?
4. Hoeveel tijd is benodigd voor herstel tot het moment dat een werkende omgeving wordt opgeleverd?
5. Vindt periodieke controle plaats op leesbaarheid met periodiciteit < retentieperiode?
6. Vindt periodieke test van functioneel herstel van SaaS-dienst plaats (op basis van de back-up van applicatie, infrastructuur en data)?

Benoem hierbij:

1. Wat doet in dit kader de SaaS leverancier?
2. Wat zijn in dit kader de taken van de afnemer (User Entity controls)?
3. In welke mate is de naleving van de maatregelen onderdeel van bestaande TPM-verklaringen (ISAE, SOC2)?
   
   

Obstakels
Hoe kan je dit resultaat nu verder brengen in de praktijk? Daarbij hebben we afstemming gehad met collega's van EY,  AFAS, Exact, Chrunchr en NOREA. Daarbij bleek dat zowel Exact als Crunchr hun ransomware-bestendigheid wel geadresseerd hebben in hun ISAE of SOC2 verklaringen. De wijze waarop verschilde echter aanzienlijk. Exact gaat uit van een risicogerichte benadering waarbij Ransomware als risico onderkend is en dus ook terug moet komen in de maatregelen (maar niet expliciet benoemd wordt) terwijl Crunchr het ‘immutable’ zijn van de storage wel expliciet in de verklaring benoemt.

Dit is een gevolg van het feit dat dergelijke verklaringen de te hanteren normen bij de leverancier leggen. Daarnaast gaven de leveranciers aan dat het instrument ISAE en SOC2 ook niet echt geschikt is voor een “rule based” aanpak waarbij de rules worden voorgeschreven. We hebben daarom geconstateerd dat het instrument ISAE verklaring niet eenvoudig gebruikt kan worden om deze eenduidigheid in de markt op gang te brengen.

Kan aankomende wetgeving helpen?
Zoals gezegd zal o.a. de NIS2 dit probleem nader naar voren brengen. Maar het kan ook op termijn een oplossing gaan afdwingen. Immers, vrijwel elk bedrijf zal met deze uitdaging geconfronteerd worden en zal dus een oplossing moeten vinden. Die oplossing zal niet uit de lucht vallen. Als CIO Platform Nederland kunnen we evengoed blijven zoeken naar een pragmatische en werkbare oplossing. Niemand zit immers te wachten op onmogelijke vraagstelling vanuit toezichthouders. Maar als we niks doen dreigt dit wel te gebeuren.

Ook het NOREA Report Initiative over de verslaggevingsstandaard verantwoording IT beheersing (NOREA | Consultatie verslaggevingstandaard verantwoording IT-beheersing (NOREA Reporting Initiative) kan een aanknopingspunt zijn. Deze is echter nog in consultatiefase. En daarvoor geldt hetzelfde: Norm Cyber-1-1f luidt: “The reporting organization should report on the backup strategy and activities to ensure that backups are conducted, secured, maintained and tested periodically.” Biedt dit wel voldoende zekerheid over de Ransomware-bestendigheid van de data?

Lessen
Door het traject hebben we een hoop lessen geleerd. Misschien kunnen we met extra input vanuit de deelnemers van CIO Platform Nederland weer een stap verder komen. Hieronder een drietal gevonden inzichten uit het proces van de afgelopen maanden:

Les 1:
Grote SaaS-leveranciers zijn zelf volop bezig met deze problematiek. Het is immers hun “licence to operate”. Mocht een SaaS-leverancier getroffen worden door een Ransomware aanval, dan heeft dit serieuze en wellicht desastreuze gevolgen voor hun bestaanszekerheid. De zorg dat de SaaS leveranciers hier onzorgvuldig mee omgaan lijkt derhalve ongegrond. Echter: aantoonbaarheid blijft wel een uitdaging. Zeker in het kader van DORA waarbij je als afnemer expliciet verantwoordelijk bent voor het valideren van de beveiligingskwaliteit van je (onder)aannemers.

Les 2:
SaaS-leveranciers zitten niet te wachten op extra vragen(lijstjes) van hun klanten. De grote leveranciers krijgen honderden van dergelijke lijstjes, te veel om er serieus aandacht aan te besteden en er voldoende kwalitatief antwoord op te kunnen geven. Om die reden heerst er toch wel een zekere aversie tegen aanvullende vragen vanuit hun klanten. Ze komen daardoor niet aan de belangrijke zaken zoals het beveiligen van onze data toe. Ze zouden graag één uniforme vragenlijst krijgen van al hun klanten zodat ze daar voldoende tijd aan kunnen besteden en de antwoorden kunnen publiceren op hun website. De hoeveelheid verschillende lijstjes is voor veel zakelijke gebruikers ook een herkenbare probleem.

Les 3:
De huidige ISAE3402 type 2 verklaringen bieden weinig houvast om aantoonbare ransomware-bestendigheid af te dwingen. Het ISAE3402 proces legt het bepalen van de scope en aard van de maatregelen immers neer bij de aanbieder. Een voorschrift over een bepaald type maatregel (zoals Immutable storage voor backup) voor een van de risico’s past niet in dat proces. Het toevoegen van deze vraagstelling betreft dus geen toevoeging op inhoud, maar een aanpassing van het proces van risk based naar rule based. De meest gebruikelijke TPM (ISAE3402) biedt daarom onvoldoende aangrijpingspunten. De SOC2, waarbij de scope van operational IT-controls niet geheel vrij is maar deels gebaseerd op de Trust Services Criteria, zou wel bruikbaar kunnen zijn. Echter, het aantal SOC2 verklaringen loopt in NL nog achter op het aantal bedrijven wat een ISAE3402 verklaring afgeeft. En daarbij is beschikbaarheid in SOC2 (nog) geen verplicht onderdeel en de diepgang van de betreffende control is  te beperkt om immutable storage te waarborgen ( “The integrity and completeness of back-up information is tested on at least an annual basis.”)

Conclusie: work in progress!
Kortom, het is een complexe maar belangrijke kwestie die niet eenzijdig kan worden opgelost. Het risico op kwetsbaarheden en beperkt toezicht blijven daardoor voorlopig bestaan. Het vereist dat we vanuit de zakelijke gebruiker alert moeten zijn en blijven zoeken naar betere antwoorden.  

Weet jij een bijdrage te leveren om deze problematiek verder te brengen en Nederland veiliger te maken? Hoe zie jij de toekomst en ontwikkeling van toezicht binnen cyber? Laat het ons weten!

Paul Samwel (CISO, ONVZ)
Frans Voogd (Security Officer, Heijmans),
Marcel van Essen (Risk & Security Coördinator, Havenbedrijf Amsterdam),
Ton Sundemeijer (Information Security Officer, TBI)

Voor opmerkingen en/of vragen stuur een bericht naar Idsard