Assurance in the cloud

Inleiding

Privé kunt u via de clouds van Apple, Google, etc. op ieder apparaat en iedere plek ter wereld uw foto’s en databestanden openen en met anderen delen. U richt het zo in dat u niets hoeft te doen op uw laptop, smartphone of tablet, want alles wat u doet wordt automatisch voor u in de cloud opgeslagen. En ook uw e-mail zal zich wel ergens in de cloud bevinden.

Vanuit het bedrijfsleven is de cloud niet meer weg te denken. Slogans als ‘Wij leveren cloudintegratiediensten waarmee uw datacenterdiensten transformeren van een kapitaalintensieve omgeving die moeizaam schaalbaar is naar een omgeving die zich snel aanpast en schaalt naar de groeiende vraag’ zijn aan de orde van de dag. Variërend van al dan niet tijdelijk wat extra capaciteit inhuren (IAAS), een compleet ingericht platform gebruiken waarop alle software staat om een complete webwinkel te ontwikkelen (PAAS) tot het aanbieden van onlinediensten als het voeren van de financiële of logistieke administratie zonder zelf pakketten aan te schaffen (SAAS), het kan allemaal en het gebeurt inmiddels veelvuldig.

Natuurlijk ontstaat daarbij de vraag hoe betrouwbaar deze diensten zijn en hoe de aanbieders die betrouwbaarheid en vooral beveiliging, continuïteit en privacy garanderen. Bij de selectie van een cloudprovider zijn dat vraagstukken die meestal wel maar soms ook niet te regelen zijn. Dat is mede afhankelijk van de aard van de dienstverlener en de omvang van het contract. Voor mijn Google e-mailaccount geldt eenvoudig ‘take it or leave it’, maar als een multinational overgaat tot gmail blijken er wel specifieke afspraken mogelijk te zijn. In dit artikel wordt eerst ingegaan op de behoefte aan assurance, worden de nieuwe risico’s en control frameworks besproken inclusief de assuranceproducten en wordt vervolgens stilgestaan bij de noodzakelijke dynamisering van de assurancerapporten en de assurancedienstverlening zelf. Tot slot wordt ingegaan op de ontwikkeling van concepten als Continuous monitoring en Continuous auditing om antwoord te geven op de uitdaging die cloud voor assurance betekent.

Behoefte aan assurance

Onlosmakelijk met cloud computing, net als met de ‘klassieke uitbesteding’, is er het punt van kwetsbaarheid: is alles beschikbaar en wat gebeurt er verder met mijn data? Anderzijds is de kwetsbaarheid bij een professionele externe serviceprovider wellicht kleiner dan bij een onprofessionele interne IT-afdeling. Hoe dan ook, de vraag doet zich voor op welke wijze gebruikers zelf nog voldoende grip hebben op de IT-uitbesteding en op basis waarvan zij hun verantwoordelijkheid inhoud kunnen geven. Het zal duidelijk zijn dat dat verschillend is met de aard van de dienstverlening. Bij IAAS-oplossingen zijn de risico’s nog redelijk beperkt en heeft de gebruikende organisatie zelf nog middelen om voor een belangrijk deel voor de betrouwbaarheid maatregelen te treffen. Aan de andere kant, bij SAAS-oplossingen in een publieke cloud zijn de mogelijkheden erg beperkt.

Er zijn al veel waarschuwende vingertjes geheven over de veiligheid en vertrouwelijkheid van data in de cloud! Ook al komen er soms ook positieve berichten over cloud computing (zie bijgaand kader), het zijn uitzonderingen en zij roepen veel kritiek over zich heen. Toch vindt cloud computing nu al veelvuldig plaats en blijft de vraag op zijn plaats welke zekerheid een uitbestedende partij nog heeft.

Risico en controleframeworks

Hoewel het aantal cloud computing-gerelateerde incidenten relatief klein lijkt in vergelijking met traditionele IT, kan de impact van een incident groot zijn, omdat een beveiligingsincident bij een cloud service-dienstverlener bijna altijd meerdere organisaties (afnemers) raakt. Er zijn diverse rapporten en artikelen geschreven over beveiligingsrisico’s rond cloud computing, onder andere NIST, CSA en ISACA hebben hierover gepubliceerd. Een recent en breed geaccepteerd rapport binnen Europese overheden en organisaties is dat van ENISA[In het tweede kwartaal van 2013 verwachten we de MSc-scriptie van Peter van Ulden getiteld ‘Security in the Cloud’. Het resultaat van deze scriptie is een cloud control-framework gebaseerd op de cloud computing-beveiligingsrisico’s gedefinieerd door ENISA, dat gebruikt kan worden ter ondersteuning bij het maken van op cloud computing-beveiliging gebaseerde beslissingen.], het ‘Cloud Computing Security Risk Assessment’. In dit rapport worden de unieke cloud computing-beveiligingsrisico’s uitgebreid belicht en beschreven. ENISA heeft de risico’s verdeeld in drie categorieën: ‘beleid & organisatie, technische risico’s en juridische risico’s’.

Voor de standaard beveiligingsrisico’s van IT zijn standaarden als ISO 27001/2 en Cobit de facto bepalend. Deze standaarden zijn gericht op traditionele IT-oplossingen en sluiten niet goed aan bij de nieuwe beveiligingsrisico’s die cloud computing met zich meebrengt. Hoewel er nog geen algemeen geaccepteerde specifieke cloudstandaarden op de markt zijn, zijn er wel organisaties die een poging daartoe doen of eraan werken. Enkele voorbeelden hiervan zijn:

• CSA – Cloud Controls Matrix
  
  Het CSA CCM levert een controleframework dat een grondig inzicht geeft in de beveiligingsconcepten en -principes gerelateerd aan de CSA-richtlijnen. De fundering van de Cloud Controls Matrix zijn andere door de industrie geaccepteerde beveiligingsstandaarden, regelingen of frameworks, zoals onder meer ISO 27001/2, ISACA COBIT en NIST. Het CSA CCM is erop gericht om op de traditionele manier achteraf assurance af te geven over een bepaalde periode.
• Het ISO/IEC 27017 is in ontwikkeling en betreft een specifieke invulling van de ISO 27002 voor de cloudomgeving. Op korte termijn zal deze standaard nog niet beschikbaar komen.

Assuranceproducten

In Nederland was al decennia geleden een goed product ontwikkeld en beschreven in de NIVRA-serie Automatisering en Controle en met name in NIVRA-geschrift 26, Deel 4 Mededeling door de accountant met betrekking tot de betrouwbaarheid en continuïteit van geautomatiseerde gegevensverwerking. Dit geschrift gaf al een duidelijke richtlijn voor een mededeling ten behoeve van derden. Tegenwoordig kennen we binnen het accountants- en IT-auditorsdomein de opvolgers in de vorm van de internationale standaarden ISAE 3000 en ISAE 3402. Hoewel de standaarden bedoeld zijn als richtlijnen voor het doen van mededelingen ten behoeve van derden bij uitbesteding van diensten zijn er geen inhoudelijke normen voorgeschreven waaraan die diensten van de dienstverleners moeten voldoen. Die moeten dus uit andere bronnen komen. Bekend is in dit kader het Studierapport ‘Normen voor de beheersing van uitbestede ICT-beheerprocessen’, uitgegeven door NOREA en PvIB, dat bedoeld is voor zowel de serviceprovider, de klantorganisatie als de IT-auditor. Hoewel dit Studierapport in de praktijk met grote regelmaat wordt gebruikt, stamt het nog uit een periode waarin cloud computing bepaald geen gemeengoed was en derhalve is de inhoud van dit rapport hierop niet afgestemd.

Zoals in de vorige paragraaf is aangegeven, is er inmiddels een aantal publicaties die wel normenstelsels voor cloud computing bevatten. Alleen geldt daarvoor ook dat integrale toepassing nauwelijks realistisch is uit het oogpunt van de kosten die gemoeid zijn met het laten beoordelen van de beheersingsmaatregelen door een externe IT-auditor. De vraag komt dan ook op voor welke onderwerpen een klantorganisatie behoefte heeft aan een assurancerapportage van een onafhankelijke IT-auditor en welke vorm van rapportage daarvoor het meest geschikt is.

In de praktijk is het meest gangbare assurancerapport nog steeds het ISAE 3402 (SOC 1)-rapport. Dit is de opvolger van SAS 70 en is specifiek gericht op controls rond financial reporting. De focus in dit soort rapporten ligt vooral op het kwaliteitsaspect betrouwbaarheid. De kwaliteitsaspecten continuïteit, security en privacy die in het kader van cloud computing meer relevant zijn, passen minder goed in de scope van een dergelijk rapport en zijn deels zelfs expliciet uitgesloten. In de Verenigde Staten wordt daarom in toenemende mate gebruikgemaakt van het zogenaamde SOC 2-rapport waarin juist expliciet aan deze aspecten aandacht wordt besteed (‘Security, Availability, Confidentiality, Processing Integrity en Privacy’). In Nederland kan een SOC 2-rapport worden uitgebracht onder de internationale ISAE 3000-standaard. Het voordeel van SOC 2 is dat hierin expliciet controledoelstellingen en een set van minimale normen zijn benoemd zodat een marktstandaard is gezet. Natuurlijk kan ook van de ‘kale’ ISAE 3000-standaard gebruik worden gemaakt, waarbij vervolgens een normenstelsel wordt ingevoegd dat of gebaseerd is op een normenstelsel dat al door de serviceprovider is opgesteld of bijvoorbeeld is afgeleid uit één van de kenmerkende cloud-normenstelsels (zie vorige paragraaf).

Naast de bovengenoemde ISAE-assurancerapportages wordt in cloudverband ook gewezen op de ISO 27001/2-standaard, die met name security als kenmerk heeft. In elk geval is het praktisch mogelijk om in een assurancerapport ook een mapping op te nemen naar de meest bekende standaarden, zodat de gebruiker kan zien welke elementen in het rapport zijn afgedekt.

Hoewel niet exclusief voor cloud computing is een korte beschrijving opgenomen van de sterke en zwakke punten van de verschillende meest gebruikte assurancerapportages, te weten ISAE 3000 algemeen, ISAE 3000 / SOC 2 en ISO 27001/2. Zie ook het artikel van Ronald Koorn en Suzanne Stoof in deze Compact.

Tabel 1. De sterke en zwakke punten van ISAE 3000 algemeen, ISAE 3000 / SOC 2 en ISO27001/2.

Hoewel dit overzicht oppervlakkig en verre van compleet is, geeft het enig houvast bij de achtergrond. In de wandelgangen wordt wel gesteld dat de ISAE-normen vrijer zijn te definiëren dan de ISO-normen (voorgedefinieerd), maar dat de controle op de naleving van de beheersingsmaatregelen bij ISAE strenger is dan bij ISO.

Deze standaarden hebben als nadeel dat ze tamelijk star zijn. De ontwikkeling van de standaarden duurde jaren en aanpassingen op de standaarden navenant, hoewel de normenkaders wel voor iedere audit aangepast kunnen worden. Ook het resultaat is tamelijk star. Veelal wordt gerapporteerd in perioden van een jaar en bij ISO zelfs drie jaar.

Het doel van dergelijke rapportages is tweeledig: vooraf dient goed nagedacht te worden over de noodzakelijke beheersingsmaatregelen in relatie tot de dienstverlening. In de praktijk leidt dat veelal tot een kwalitatief beter doordacht stelsel van interne controle. Achteraf wordt vastgesteld of de beheersing van het gewenste niveau is geweest. Ook dat is feitelijk een preventieve maatregel, want achteraf vertellen dat een beheersingsmaatregel in het verleden niet goed heeft gefunctioneerd is niet zo zinvol: of het kwaad is al geschied en dat heeft de klantorganisatie dan al zelf ervaren of het gebrekkig functioneren heeft geen kwaad tot gevolg gehad en dan maakt het over het afgelopen jaar ook niet meer uit. Kortom, de doelstelling van dergelijke onderzoeken is toekomstgericht: eerst het verbeteren van het stelsel van interne beheersing en vervolgens vaststellen of bevindingen uit het verleden aanleiding zijn voor de toekomst om verbeteringen in de processen en/of hulpmiddelen aan te brengen.

De vraag doet zich nu voor of de periodieke ‘zekerheid’ van de huidige assurancerapportages toereikend is voor de doelgroep, veelal de gebruikersorganisaties van de clouddienstverlening. Vraagtekens kunnen worden geplaatst bij de lange doorlooptijd (veelal een jaar) en bij de inhoud.

Dynamisering

In de vorige paragraaf is de vraag opgekomen of gebruikersorganisaties van clouddiensten nog behoefte hebben aan assurancerapportages die tot een jaar teruggaan. In toenemende mate zal dit niet meer het geval zijn. De assurancestandaarden houden overigens het frequenter rapporteren niet tegen maar geven er ook geen expliciete richtlijnen over. Ook nu komt het in de praktijk voor dat reeds per kwartaal wordt gerapporteerd.

Figuur 1. Dynamiseren door frequenter te rapporteren.

Op zich zullen de kosten slechts heel beperkt toenemen, want nog steeds wordt uitgegaan van een jaarlijkse audit, waardoor de waarnemingen zich over een jaar verspreiden. Wel zal ieder kwartaal een deel van de jaarlijkse controleactiviteiten moeten plaatsvinden, dus mogelijk zal de controlefrequentie iets omhoog gaan. De rapportages zijn afkomstig van de laatste vier kwartalen, zij omvatten dus wel steeds de bevindingen over een heel jaar, maar kunnen uit meerdere auditjaren komen. Eventuele tekortkomingen uit een eerdere periode kunnen door het management worden toegelicht en de auditor kan aangeven vanaf welk kwartaal de tekortkomingen zijn opgelost of niet meer voorkomen. Dit maakt het voor de lezer heel transparant, want de opvolging van tekortkomingen wordt hierdoor duidelijk zichtbaar gemaakt.

De vraag is of deze vorm van dynamiseren voldoet aan de behoeften van de uiteindelijke gebruiker.

Hierbij zijn er twee gedachtelijnen te onderkennen:

1. Vertrouwen en assurance

Deze gedachtegang sluit enigszins aan met de jaarrekeningcontrole. Door het jaar heen publiceert de organisatie (en publiceren los daarvan ook bijvoorbeeld veel analisten) allerlei gegevens die niet van een accountantsverklaring zijn voorzien, maar toch veelvuldig door stakehouders worden gebruikt. In dat licht lijkt het jaarverslag met de accountantsverklaring een late bevestiging van wat al door het jaar heen is gebeurd. Maar het geeft wel het beeld dat de organisatie over kwalitatief goede interne procedures beschikt om door het jaar heen ‘betrouwbare’ signalen af te geven.

In de cloudomgeving betekent dit dat jaarlijks bijvoorbeeld een ISAE 3000 / SOC 2-rapport wordt afgegeven en door het jaar heen de cloudprovider (ongecontroleerde) informatie over de kwaliteit van de dienstverlening verstrekt, bijvoorbeeld door periodieke Service Level Rapportages of accountmanagementgesprekken. Voor grotere groepen gebruikers kan natuurlijk ook gedacht worden aan dashboards op het internet.

De toereikendheid van deze gedachtelijn is dat enig vertrouwen onontbeerlijk is in de relatie tussen uitbestedende partij en serviceprovider en dat daarmee de tussentijdse berichtgeving wordt geaccepteerd totdat het tegendeel wordt bewezen. En voor dat bewijs geldt dan de periodieke assurancerapportage door een onafhankelijke derde partij. In dat kader zou overigens het proces van periodieke informatieverstrekking niet misstaan in de scope van het assuranceonderzoek.

2. Continuous auditing

Een andere gedachtelijn is dat zowel de serviceprovider als de klanten behoefte hebben aan een continu inzicht in de kwaliteit van dienstverlening en dat de serviceprovider de beste kwaliteit levert door daar heel transparant in te zijn. Ook weer in de vergelijking met de accountantsverklaring bij de jaarrekening: hoewel de accountant vaak het stelsel van interne controle (‘key controls’) beoordeelt, wordt een uitspraak gedaan over de getrouwheid van de jaarcijfers, niet de controls. Anders gesteld, ook voor de assurance bij cloudprocessing kan er behoefte zijn aan inzicht in concrete cijfers (KPI’s) naast assurance over (key) controls. Zeker bij IT-serviceproviders liggen veel kwaliteitsaspecten in systemen vast en is het met beperkte tooling niet zo’n grote opgave op een bijna continue wijze de beschikbare informatie te analyseren (‘continuous monitoring’) en te rapporteren in heldere dashboards, bijvoorbeeld op het internet. Het is daarbij mogelijk dat de externe auditor deze wijze van informatie verzamelen, analyse en rapportage met grote frequentie beoordeelt (‘continuous auditing’) en dat op enigerlei wijze ook kenbaar maakt. Hoewel daar nog geen goede voorbeelden van zijn, zijn vormen als web-seals hierbij denkbaar.

Deze vorm van assurance is vooral cijfermatig (‘substantive’) en geeft niet echt inzicht in de interne beheersingsmaatregelen. Daarmee wijkt zij dus af van de ‘controls’ assurance die wordt gerapporteerd in ISAE- en ISO-standaarden. Maar niet alle behoeften van gebruikers lenen zich voor substantive testing. In figuur 2 zijn voorbeelden gegeven van onderwerpen die zich goed lenen voor cijfermatige reporting en onderwerpen die meer passen bij de traditionele wijze van controls-assurancerapportage. Ook hier kan dus naast de dashboards nog een (beperkte) ISAE 3000 / SOC 2-rapportage worden opgeleverd.

Figuur 2. Voorbeelden van onderwerpen voor rapportage via dashboards resp. traditionele controls testing.

In de ultieme cloudsituatie moeten serviceprovider en externe auditor in staat zijn de ‘assurance on demand’ te leveren waarvoor continuous monitoring/auditing steeds meer zal opkomen.

Voorbeelden van dashboards zijn op het internet te vinden, bijvoorbeeld http://outageanalyzer.com (zie figuur 3), of http://www.sciencelogic.com/product/technologies/public-cloud (zie figuur 4), of het voorbeeld in figuur 5, waarbij niet de cloudprovider zelf het dashboard publiceert maar andere partijen (Unified monitoring van Nimsoft).

Figuur 3. Outage Analyzer.

Figuur 4. Amazon Web Services Dashboard.

Figuur 5. Unified Monitoring van Nimsoft.

Subserviceorganisaties

Naast dynamisering komt ook bij cloud computing vaak de vraag op over hoe om te gaan met subserviceorganisaties, oftewel organisaties waaraan de cloudprovider zelf weer heeft uitbesteed. Lang niet iedere cloudprovider besteedt diensten uit aan andere (sub)serviceproviders. Dan is er dus ook geen probleem en zal het assurancerapport alle relevante diensten en controls bevatten en kan de auditor die ook bij de cloudprovider controleren.

Indien er wel sprake is van uitbesteding door de cloudprovider geven de standaarden hiervoor de opties van ‘Carved out’ of ‘Inclusive’. Ingeval de cloudprovider niet de verantwoordelijkheid kan nemen voor de controls van de subserviceorganisatie, dan wel dat het de auditor niet toegestaan is de controls bij de subserviceprovider te controleren, dient ‘Carved out’ te worden toegepast. In dat geval zijn de diensten en controls van de subserviceprovider niet in scope bij de beoordeling van de cloudprovider. Voor de gebruiker van het rapport van de serviceprovider kan dit leiden tot een ‘blinde vlek’ in de totale keten en daarmee in zijn beeld van de totale beheersing. Mogelijk dat de subserviceprovider zelfstandig een assurancerapport uitbrengt, dat alsnog de blinde vlek voorkomt. In de praktijk betekent dit dat door de assurancevraag bij één partij vaak de hele keten van partijen wordt betrokken en in dat kader valt op dat steeds vaker juist – in tegenstelling tot de behoefte – de ‘Carved out’-methode wordt toegepast. Als compensating control zien we in het geval van carve out wel dat additionele controls worden opgenomen bij de cloudprovider, waaruit moet blijken dat de dienstverlening van de subserviceorganisatie wordt gemonitord. Denk daarbij weer aan service level agreements, periodieke terugkoppeling, etc. Zeker als de keten van uitbestedingen langer wordt en de dienstverlening in verre landen plaatsvindt, wordt het probleem steeds groter. Geen enkele assurancestandaard voor cloud computing heeft hier een oplossing voor en door de open markt voor cloud computing kan er ook geen systeem van regulering à la PCI-DSS van de grond komen, waarbij alle organisaties die creditcardgegevens opslaan aan die richtlijnen moeten voldoen.

Indien het krijgen van assurance over de hele keten echt van belang is, zal de uitbestedende partij dat nu van tevoren moeten overzien en eisen moeten stellen aan de cloudprovider over het wel of niet uitbesteden door de cloudprovider c.q. over de assurance die de cloudprovider bij uitbesteding door de hele keten heen kan bieden.

Conclusie

De opkomst van cloud computing leidt tot nieuwe behoeften op het gebied van verstrekking van assurance over de clouddienstverlening, met name over de beveiliging, privacy en beschikbaarheid. Meer fundamenteel is de vraag of assuranceverstrekking in staat is mee te bewegen met de ontwikkelingen. In zijn ultieme vorm is cloud computing zo dynamisch dat assurance in de traditionele vorm een belemmering kan gaan worden.

Dynamisering kan deels voor oplossingen zorg dragen, zeker voor die controls die niet praktisch zijn uit te drukken in actuele KPI’s of dashboards. Voor assurance voor diensten die wel in actuele KPI’s of dashboards zijn vast te leggen, lijken oplossingen in de vorm van continuous monitoring en auditing goed mogelijk.

Voor assurance over een hele keten van uitbestedende partijen staat de keten van cloudproviders en ook de beroepsgroep nog voor een uitdaging. Cloudproviders zullen niet in staat zijn (of niet willen zijn) door de hele keten heen assurance af te dwingen en daardoor zal de auditor dat ook niet kunnen doen. Indien wel assurance in de keten wordt geborgd doordat iedere partij een eigen assurancerapport oplevert, is er mogelijk voor de auditor van de uitbestedende partij een regiefunctie weggelegd om vast te stellen dat alle assurancerapporten bij elkaar het juiste beeld voor de oorspronkelijke uitbestedende partij opleveren.

Een mogelijke oplossing, die door cloudproviders nu wordt onderzocht, is de zekerheid niet meer bij de controls te zoeken maar de zekerheid te verbinden aan de datasets van de cliënt. Deze datasets kunnen uniek worden geïdentificeerd en zodanig opgeslagen dat ongeautoriseerde wijzigingen direct zichtbaar worden gemaakt. De technische mogelijkheden hiertoe zijn reeds ontwikkeld rond het dataverkeer en ook de mogelijkheden op gebied van encryptie zijn reeds bekend. Een andere mogelijkheid is het zoeken van zekerheid bij het systeem van de cloudprovider. Deze dient een systeem te hebben waarmee wordt bijgehouden waar de data van de cliënt zich bevindt. Dit systeem dient dan de waarborgen te bevatten dat het kwaliteitsaspect rond bijvoorbeeld security en privacy voldoende wordt afgedekt. Voor de beschikbaarheid dienen dan additionele maatregelen te worden getroffen, bijvoorbeeld door dubbele opslag bij verschillende ketens. Voordat deze oplossingen betrouwbaar en controleerbaar werken doet de uitbestedende partij er goed aan zich af te vragen welke risico’s gelopen worden door uitbesteding aan cloudproviders en welke assurance vereist is om de eigen verantwoordelijkheid nog te kunnen dragen. Indien de cloudprovider niet in staat is die assurance door de keten heen te kunnen verstrekken, zal de uitbestedende partij er verstandig aan doen niet met deze serviceprovider in zee te gaan c.q. beperkingen te eisen in de wijze waarop de cloudprovider met de diensten voor de uitbestedende partij mag omgaan en dat in een assurancerapport te laten controleren.