Assurance verstrekking bij Cloud computing leveranciers en klanten “In Control”
Ing. Anneke Zuidberg, IT Auditor
Gegevens auteur:
Ing. Anneke Zuidberg, IT Auditor Univé. Telefoonnummer werk : 06 18656654 Mail werk :
[email protected] Gegevens afstudeerbegeleider Vrije Universiteit Amsterdam : Dr. Wiekram Tewarie RE, docent Vrije Universiteit Amsterdam Mail:
[email protected] Dr. René Matthijsse RE, hoofddocent Vrije Universiteit Amsterdam Mail:
[email protected] Gegevens bedrijfsbegeleider Univé : Alexander Sluiter RE, senior IT Auditor Univé. Mail:
[email protected] Referentienummer VU : 2007
Assurance verstrekking bij voor Cloud computing leveranciers en klanten “In Control”
1 april 2014
2
Versie 1.0
Voorwoord Deze scriptie is het resultaat van een onderzoek naar de mogelijkheid om alternatieven te bieden voor het verstrekken van assurance voor Cloud computing op een manier die voldoet aan de behoeften van zowel klanten als leveranciers. Zelf ben ik geïnteresseerd in de effecten van een nieuwe technologie op de manier waarop we als auditors assurance kunnen verlenen. Daarnaast vind ik het belangrijk om klantgericht en effectief werkzaamheden te kunnen uitvoeren. Deze twee interesses komen samen in het onderzoek dat ik heb uitgevoerd. Met deze scriptie rond ik mijn postgraduate opleiding IT Audit aan de Vrije Universiteit Amsterdam af. De doelgroep van dit onderzoek zijn de klanten en leveranciers van Cloud computing diensten. Terugkijkend op het onderzoek merk ik dat ik veel geleerd heb tijdens het onderzoekstraject. Met name dat het laten rijpen van ideeën en zoeken van nieuwe invalshoeken tot inspirerende inzichten kan leiden. Dit onderzoek had ik niet uit kunnen voeren zonder de steun van een aantal mensen om mij heen. Graag wil ik van deze gelegenheid gebruik maken om deze mensen te bedanken. Mijn academische begeleider Wiekram Tewarie wil ik bedanken voor hun luisterend oor, het reviewen van mijn stukken en het meedenken over het resultaat. Mijn interne begeleider van Univé, Alexander Sluiter, wil ik bedanken voor de begeleiding en steun op zowel inhoudelijk als procesmatig vlak. Hij maakte, ondanks drukte, altijd tijd voor me vrij. Mijn werkgever heeft me gesteund door tijd vrij te geven om me volledig op de scriptie te kunnen concentreren. Mede daardoor heb ik de door mezelf gestelde deadline kunnen halen. Ook wil ik mijn respondenten bedanken voor de tijd die ze in het interview en de review hiervan hebben gestoken, en de openheid waarmee ze hun professionele mening met me hebben gedeeld. Tenslotte wil ik graag mijn gezin bedanken voor alle steun die ik tijdens mijn studie en het schrijven van mijn scriptie heb ontvangen. Zonder hun onvoorwaardelijke steun en positieve inbreng was het studietraject aanzienlijk moeilijk te volbrengen geweest. Vries, 30 maart 2014 Anneke Zuidberg
1 april 2014
3
Versie 1.0
Management samenvatting Cloud computing, is het een evolutie of revolutie? Hoe het ook zij, inmiddels is Cloud computing niet meer weg te denken uit zakelijk- en privégebruik. Redenen om op deze nieuwe technologie over te gaan zijn kostenbesparing, flexibiliteit en schaalbaarheid en beveiliging en licentiebeheer. Daardoor kan de klant zich richten op kernactiviteiten. Uit onderzoeksresultaten en verwachtingen in de ICTwereld blijkt dat het gebruik van cloud computing de komende jaren explosief zal toenemen. Zo voorspelt onderzoeksbureau Gartner dat de wereldwijde omzet uit Cloud computing dat in 2014 de wereldwijde omzet naar verwachting gegroeid zal zijn tot 148,8 miljard dollar. (Pring, 2010) Uitbesteden ontslaat de eigenaar niet van verplichtingen. Een eigenaar van de uitbestede dienst blijft eindverantwoordelijk en moet over de uitbestede dienst een assurance verklaring laten afgeven, bijvoorbeeld om te gebruiken als input voor de jaarrekening. Het verstrekken van assurance op de uitbestede IT gebeurt nu veelal op basis van TPM-verklaring, bijvoorbeeld in de vorm van een ISAE3402/SOC 1 verklaring. Bedrijven (zowel klanten als leveranciers) sturen steeds meer op het afgeven van ISAE3402 verklaringen die generiek zijn, herbruikbaar voor alle afnemers van een dienst. Standaard verklaringen zijn goedkoper en zouden onderling beter te vergelijken moeten zijn. De onderlinge vergelijkbaarheid is vaak nog niet gerealiseerd. Dat blijkt ook uit mijn scriptie. Onderzoek van het internationale management consultingbedrijf BOOZ toont aan dat van de 160 onderzochte industrie-overstijgende standaarden met een expliciete scope op Cloud computing slechts 3 bruikbaar en rijp genoeg zijn voor het afgeven van assurance op clouddiensten (Pütter, 2012). Het betreft de standaarden OAuth, OpenStack en OCCI. De hoofdvraag van mijn scriptie is: “Welke tekortkomingen kent de huidige manier van assurance verlenen voor Cloud computing, welke oorzaken zijn hiervoor te benoemen en welke alternatieven zijn hiervoor te beschrijven?” Doel van mijn onderzoek is inzicht te krijgen in een aantal vragen: 1. welke verklaringen en onderliggende normenkaders er gebruikt worden voor het verlenen van assurance; 2. waarom de huidige manier van auditen en afgeven van assurance voor IT in het tijdperk van Cloud computing niet voldoet aan de compliance eisen en de eisen/behoefte van leveranciers en de klant en 3. welke alternatieven kunnen worden beschreven voor het afgeven van een assurance verklaring die voldoet aan de eisen en behoeften van leveranciers en klanten. Als eerste heb ik en theoretisch kader ontwikkeld over hosting, outsourcing en Cloud computing, en de huidige normenkaders voor het verstrekken van assurance. Op basis van theorie van onder andere ISO en NIST heb ik onderzocht in hoeverre er assurance op Cloud computing kan worden verstrekt met behulp van de huidige normenkaders en verklaringen. Vervolgens heb ik een case study uitgevoerd bij drie bedrijven. Hierbij heb ik gekozen voor drie invalshoeken, te weten een klant en leverancier van Cloud computing, en een onafhankelijke non-profit organisatie die onder andere Cloud richtlijnen heeft ontwikkeld en een methodiek voor het certificeren van cloudleveranciers (EuroCloud Star audit). Op basis van de analyse van theorie en de case study heb ik de centrale vraag en de deelvragen beantwoord. Ik heb in de conclusie een aantal aanscherpingen aangedragen van onder meer het te hanteren normenkader waarmee assurance op Cloud computing kan worden 1 april 2014
4
Versie 1.0
verstrekt. Aanvullend heb ik de onderwerpen beschreven die een potentiële afnemer van Cloud computing zou kunnen doorlopen om de basis- en randvoorwaarden in te kunnen richten, die nodig zijn voor het afnemen van Cloud computing. De onderzochte normenkaders en standaarden voor deze scriptie heb ik geselecteerd op basis van een gedegen onderzoek van Booz en mijn eigen literatuuronderzoek. De kaders zijn naar mijn mening een goede basis voor een control framework ten behoeve van Cloud computing. Conclusie Niet alle momenteel gebruikte vormen van Assurance rapportage zijn geschikt voor het aantonen van de mate van beheersing van de IT-processen als gevolg van de verplichtingen over de scope van de rapportage. Een aantal op dit moment geaccepteerde risico’s gerelateerd aan onderwerpen zoals data locatie en data retentie, complexe techniek en virtualisatie die nog niet (voldoende) kunnen worden aangetoond moeten expliciet buiten scope van de audit worden gehouden en deze uitsluiting van de scoping moet duidelijk benoemd zijn in de assurance rapportage. Ook is het op basis van standaard rapportages nog niet voldoende mogelijk om een uitgebreid onderzoek te doen naar de prestaties van onderaannemers. De vraag of het voor de uitbestedende partij wettelijk verplicht is om van de prestaties van onderaannemers kennis te hebben heb ik tijdens een kort literatuuronderzoek nog niet voldoende kunnen beantwoorden. Momenteel is er onvoldoende inzicht in de volledige (leveranciers)keten bij Cloud computing. Daarnaast is onvoldoende duidelijk in hoeverre het de verantwoordelijkheid van de uitbestedende klant is om dit inzicht te hebben. Het effect van de ondoorzichtige keten in combinatie met gebrek aan uniformiteit versterkt het risico cumulatief. Het is voor een klant niet meer voldoende om achteraf een assurance rapportage te ontvangen. De behoefte aan realtime rapportage en sturing is door de Cloud computing technologie en de compliance verplichtingen toegenomen. Door actueel inzicht in de prestaties van de afgenomen dienst kan door een organisatie worden bijgestuurd waardoor meer assurance kan worden verkregen. De mate waarin momenteel aan deze realtime rapportage en sturing invulling kan worden gegeven door klanten en leveranciers voldoet nog niet. Onder andere doordat: *de rapportages onvoldoende inzicht geven in prestaties van onderaannemers; *de rapportages nog geen inzicht geven in alle belangrijke issues zoals datalocatie en –retentie, inzicht in de werking van de complexe Cloud computing techniek etc.; * de klanten de uitkomsten van rapportages begrijpen en kunnen vertalen naar hun organisatie, risico’s en te nemen maatregelen ter bijsturing. Het is niet mogelijk geweest om in deze scriptie alternatieven te beschrijven voor het verstrekken van assurance als gevolg van de complexiteit van de Cloud computing techniek en het ontbreken van technologie om de locatie van data, dataretentie en de uitvoering van deze complexe techniek aan te tonen. In plaats van alternatieven heb ik op basis van mijn onderzoek kunnen vaststellen dat het mogelijk is assurance over Cloud computing te verstrekken door : 1. het aanscherpen van normenkaders en standaarden; 2. het bewust toepassen van (SOC) formats van assurance en 3. het volgen van een stappenplan om te komen tot een volwassen leveranciers- en klantorganisatie. 1 april 2014
5
Versie 1.0
Er zijn een aantal onderwerpen waarvoor ten behoeve van het kunnen verstrekken van assurance voor Cloud computing meer aandacht nodig is, dan voor traditionele hosting of outsourcing. Dat komt door de voor Cloud computing onderkende risico’s: * inrichting Corporate en IT Governance; * “In Control” systeem en volwassenheidsniveau; * kennis; * scope en diepgang beoordeling auditobject; * inzicht in de (leveranciers)keten; * mogelijkheid tot het uitvoeren van een assurance opdracht voor cloudcomputing. Wanneer wordt overwogen om data en/of een informatiesysteem onder te brengen “in de Cloud” wordt op basis van het uitgevoerde onderzoek geadviseerd aan de volgende onderwerpen aandacht te besteden: Stap 1. Beschrijven van Corporate en IT Governance Stap 2. Vaststellen en onderhouden van data classificatie Stap 3. Risico gebaseerde analyse van de mogelijke uitbesteding Stap 4. Inrichten Technische, Organisatorische en Procedurele (TOP) maatregelen Stap 5. Inrichten realtime rapportages op basis van geautomatiseerde SLA rapportages Zowel voor de klant als de leverancier zou er voldoende aandacht voor deze onderwerpen moeten zijn, om op deze manier een gelijkwaardige en volwassen relatie te kunnen aangaan. Als vervolgonderzoek heb ik drie onderwerpen aangedragen. Deze zijn de mogelijkheden voor het aantonen van de data locatie, de wettelijke verplichtingen t.a.v. inzicht in prestaties van onderaannemers voor de uitbestedende partij en de haalbaarheid van het opstellen van een Cloud computing Assurance kubus.
1 april 2014
6
Versie 1.0
Inhoud
1.
2.
3.
4.
5.
6.
7.
Inleiding ........................................................................................................................................... 8 1.1.
Onderwerp .............................................................................................................................. 8
1.2.
Aanleiding ................................................................................................................................ 8
1.3.
Doelstelling en Centrale vraagstelling ..................................................................................... 9
1.4.
Onderzoeksaanpak .................................................................................................................. 9
Normenkaders voor assurance op IT diensten.............................................................................. 10 2.1.
Verklaringen en normenkaders voor assurance ................................................................... 10
2.2.
Corporate Governance en IT Governance............................................................................. 13
2.3.
De rol van data classificatie voor assurance ......................................................................... 15
2.4.
Meningen over het verstrekken van assurance voor Cloud computing ............................... 15
2.5.
Samenvatting......................................................................................................................... 20
Uitbesteding van IT........................................................................................................................ 21 3.1.
Hosting en traditionele outsourcing; definities, voor- en nadelen ....................................... 21
3.2.
Uitbesteding IT in de vorm van Cloud computing ................................................................. 23
3.3.
Voor- en nadelen van Cloud computing................................................................................ 25
3.4.
Samenvatting hosting en outsourcing................................................................................... 28
3.5.
Samenvatting Cloud computing ............................................................................................ 29
Risicobeheersing bij Cloud computing en assurance verstrekking .............................................. 30 4.1.
Aanleiding van de analyse ..................................................................................................... 30
4.2.
Beoordeling openstaande risico’s Cloud computing van NIST ............................................. 32
4.3.
Conclusie; de NIST risico’s zijn op dit moment niet allemaal te auditen .............................. 35
Case study...................................................................................................................................... 39 5.1.
Beschrijving omgeving case study ......................................................................................... 39
5.2.
Bevindingen case study ......................................................................................................... 40
5.3.
Analyse case study ................................................................................................................ 44
Conclusie en aanbevelingen .......................................................................................................... 46 6.1.
Conclusie ............................................................................................................................... 46
6.2.
Aanbevolen stappenplan voor Cloud computing .................................................................. 51
Slotwoord ...................................................................................................................................... 54
1 april 2014
7
Versie 1.0
1. Inleiding 1.1. Onderwerp Mijn afstudeerscriptie gaat over het onderwerp Assurance verstrekking voor Cloud computing . In dit hoofdstuk worden de aanleiding, probleemstelling en de doelstelling behandeld. 1.2. Aanleiding Tijdens de oriënterende gesprekken met docenten over mijn afstudeeronderwerp kwam naar voren dat de momenteel gebruikte normenkaders zoals onder andere de ISAE3402/SOC 1 rapportage niet voldoet voor Cloud computing, evenals de manier van auditen. Oorzaken hiervoor zijn het tijdsbeslag die het opstellen van een rapportage vraagt van auditors en de geaudite organisatie, met bijbehorende kosten. Daarnaast geeft de verklaring inzicht achteraf terwijl er steeds meer behoefte ontstaat aan realtime inzicht. Een korte scan van de aanwezige literatuur onderschrijft dit. Zo toont onderzoek van het internationale management consultingbedrijf BOOZ aan dat van de 160 onderzochte standaarden slechts 3 bruikbaar en rijp genoeg zijn, voor het afgeven van assurance op Cloud computing, te weten OAuth, OpenStack en OCCI (Pütter, 2012). Het onderwerp van mijn afstudeerscriptie is dan ook “Assurance verstrekken voor Cloud computing; leveranciers en klanten in Control”. De onderwerpen hieronder schetsen het kader van waaruit de aanleiding is ontstaan. Groei in uitbesteding IT diensten Er heeft op IT gebied een forse verschuiving van hosting naar uitbesteding plaatsgevonden. Een volgende stap in de IT evolutie is de outsourcing naar diverse vormen van Cloud computing. Redenen om uit te besteden zijn kwaliteitsverbetering, innovatie en kostenbesparing (Zaal, 2012). In 2012 werden Cloud computing al door 50 procent van de ICT-bedrijven in Nederland geleverd. Eindverantwoordelijkheid uitbestede diensten Uitbesteden ontslaat de eigenaar niet van verplichtingen. Een eigenaar van de uitbestede dienst blijft eindverantwoordelijk en moet over de uitbestede dienst een assurance verklaring laten afgeven, bijvoorbeeld om te gebruiken als input voor de jaarrekening. Leveranciers sturen steeds meer op het afgeven van ISAE3402/SOC1 verklaringen die generiek zijn en daardoor herbruikbaar voor alle afnemers van een dienst. Standaard verklaringen zijn goedkoper en zouden onderling beter te vergelijken moeten zijn. De onderlinge vergelijkbaarheid is echter vaak nog niet gerealiseerd. Hosting of Cloud computing, en wat betekent dit voor het afgeven van assurance Bedrijven onderzoeken de mogelijkheden om over te gaan van traditionele hosting naar Cloud computing. Daardoor wordt de vraag actueel of, en op welke manier, assurance voor Cloud computing kan worden verstrekt actueel voor (onder andere) Internal Audit. Daniele Cattedu en Giles Hogben stellen in een paper van ENISA dat het vaststellen van cloud assurance een significant tijdsbeslag legt op interne resources van de business. Tevens geven cloud leveranciers aan dat door de verplichte onderzoeken die zijn uitgevoerd op basis van NIST documenten en het grote aantal audit-verzoeken van klanten, een zware belasting voor security medewerkers veroorzaken (Cattedu/Hogben, 2009). Naast de genoemde nadelen van kosten en belasting voor de organisatie ten behoeve van het afgeven van assurance geven de twee onderzoekers van de University of Memphis aan dat de sectoren die cloud services gebruiken, erg bezorgd zijn over hun data security (Dasgupta/Naseem, jaartal onbekend). Literatuur wijst uit dat er een constant spanningsveld tussen kostenreductie en kwaliteitseisen is voor Cloud computing (zichtbaarheid, compliance, controle en toekomstgerichtheid). 1 april 2014
8
Versie 1.0
Onderzoek naar geschikte vorm van assurance voor Cloud computing Het aanbieden van Cloud computing is een snelgroeiende markt. Doordat steeds meer bedrijven in allerlei vormen gebruik gaan maken van Cloud computing , is er ook steeds meer behoefte aan een vorm van assurance die past bij de door Cloud computing aangeboden vormen van dienstverlening (Olavsrud, 2012). In deze scriptie worden de factoren die kunnen bijdragen aan een betere assurance verklaring onderzocht, benoemd en beschreven, vanuit de optiek van zowel klant als leverancier. 1.3. Doelstelling en Centrale vraagstelling Doelstelling van mijn onderzoek is het beschrijven van een aantal alternatieven voor het afgeven van assurance voor Cloud computing op een dusdanige manier dat de assurance voldoet aan de eisen en behoefte van de leveranciers en klanten van Cloud computing. Om de doelstelling van het onderzoek te kunnen bereiken, heb ik de volgende Centrale vraag geformuleerd: “Welke tekortkomingen kent de huidige manier van assurance verlenen voor Cloud computing , welke oorzaken zijn hiervoor te benoemen en welke alternatieven zijn hiervoor te beschrijven?”
De centrale vraagstelling bevat een beschrijvend en een adviserend gedeelte. In het beschrijvende deel maak ik een samenvatting van de problematiek over assurance voor Cloud computing beschreven zoals die nu in veel artikelen en scripties beschreven wordt, met de oorzaken zoals die in de artikelen worden aangegeven en/of zoals ik die zelf zie. Hierin komt ook aan bod waarom Cloud computing een wezenlijk ander object is om assurance over af te geven dan hosting. Bovendien vat ik samen welke onderzoeken er naar de geschiktheid van normenkaders op het gebied van assurance voor Cloud computing zijn uitgevoerd en wat de uitkomsten van deze onderzoeken zijn. Het beschrijvende deel is nodig als fundament voor de te kiezen alternatieven. In het adviserende deel worden de alternatieven beschreven die kunnen worden gekozen om assurance op Cloud computing te kunnen geven op een manier die aansluit bij de eisen en behoefte van de leverancier en de klant. Deelvragen 1. Welke huidige normenkaders worden er gebruikt voor het verlenen van assurance, en in hoeverre zijn deze geschikt voor het afgeven van assurance voor Cloud computing? (beschrijvend) 2. Waarom voldoet de huidige manier van auditen en afgeven van assurance voor IT in het tijdperk van Cloud computing niet aan de compliance eisen en de eisen/behoefte van leveranciers en de klant, en welke tekortkomingen liggen hieraan ten grondslag? (analyserend). 3. Welke alternatieven kunnen worden beschreven voor het afgeven van een assurance verklaring die voldoet aan de eisen en behoeften van leveranciers en klanten? (beschouwend/adviserend) 1.4. Onderzoeksaanpak
Ik heb gekozen voor een praktijkonderzoek. Ik heb hiervoor theorieonderzoek uitgevoerd, een vergelijking van door NIST benoemde risico’s met toonaangevende normenkaders en standaarden en een case study bij een leverancier en klant van Cloud computing en een (onder andere) certificerende stichting.
1 april 2014
9
Versie 1.0
2. Normenkaders voor assurance op IT diensten In dit eerste hoofdstuk behandel ik de rapportages en normenkaders die momenteel gebruikt worden ten behoeve van het verstrekken van assurance voor IT diensten in het algemeen en voor Cloud computing in het bijzonder. Om deze informatie in perspectief te kunnen plaatsen ten opzichte van assurance verstrekking voor traditionele IT, start dit hoofdstuk met de uitleg van de term “assurance” en de te gebruiken formats en normenkaders voor traditionele hosting en outsourcing. Aansluitend wordt aan de hand van publicaties van Booz en Qualys aangegeven welke zorgenpunten er nog zijn op het gebied van het verstrekken van assurance voor Cloud computing.
2.1. Verklaringen en normenkaders voor assurance Een “assurance-opdracht” is een opdracht waarbij een accountant een conclusie formuleert die is bedoeld om het vertrouwen van de beoogde gebruikers, niet zijnde de verantwoordelijke partij, in de uitkomst van de evaluatie van, of de toetsing van het object ten opzichte van de criteria, te versterken.” (NIVRA website). Belangrijke elementen uit deze definitie zijn de conclusie die voor de opdrachtgever aanvullende zekerheid over een onderwerp kunnen geven, en het feit dat er bij de opdracht 3 partijen betrokken zijn. Een assurance verklaring kan met een beperkte of redelijke mate van zekerheid worden afgegeven. Verder uitleg over assurance wordt gegeven in bijlage 1. Voor een assurance opdracht of verklaring wordt gebruik gemaakt van rapportageformats en van met de opdrachtgever afgesproken toetsings- of evaluatiecriteria, gevat in een normenkader. Hieronder wordt dieper in gegaan op mogelijke formats en normenkaders. Huidige formats voor de assurance verklaring Een assurance verklaring voor outsourcing wordt van oorsprong vaak afgegeven middels een Third Party Mededeling (TPM verklaring), bijvoorbeeld in de vorm van een ISAE-3402/SOC1 verklaring (voorheen SAS-70). Een veelgehoorde klacht van leveranciers die graag een generieke TPM verklaring willen opstellen, is het veelvoud aan normen dat door de klanten wordt aangeleverd ter toetsing van de kwaliteit van de geleverde dienstverlening door de leverancier. Door het verschil in scope en normenkaders van de verschillende klanten is het voor de leverancier niet mogelijk om een dergelijk generieke verklaring op te laten stellen voor alle klanten. Bij het verstrekken van assurance voor Cloud computing is dit nog steeds een veelgehoorde klacht. Door het gebrek aan eenduidige normenkaders is voor de traditionele hosting en outsourcing een assurance verklaring een kostbare aangelegenheid voor zowel klant als leverancier. Daarbij is de ISAE 3402 verklaring de meest vormvaste, eenduidige soort assurance verklaring die kan worden afgegeven. De kanttekening moet worden geplaatst dat ook “onder” de normen van de ISAE 3402 verklaring vaak een gedetailleerder control framework en/of ICS-kader ligt dat door de service organisatie wordt gebruikt. Deze kaders zijn niet vormvast en kunnen in scope en diepgang verschillen. Eén van de verschillen tussen een generieke TPM verklaring en een ISAE-3402/SOC1 rapport is dat het ISAE3402 rapport een vaste vorm heeft, met vaststaande kwaliteitsaspecten die moeten worden beoordeeld (collegemateriaal Han Boer, 11 oktober 2013). De door de auditor gekozen normen moet passen onder deze voorgeschreven kwaliteitsaspecten. Een TPM rapport is een leeg rapport waarbij
1 april 2014
10
Versie 1.0
de auditor de vorm, kwaliteitsaspecten en normen zelf in overleg met de opdrachtgever op kan stellen. Een tweede en zeer belangrijk verschil is dat bij de TPM verklaring de auditor alleen een verklaring opstelt in het assurance rapport. Bij een ISAE-3402/SOC1verklaring stelt zowel de verantwoordelijke partij als de auditor (los van elkaar) een verklaring op in het assurance rapport. Voor het opstellen van de verklaring door de serviceorganisatie moet deze organisatie zelf ook inzicht in de opzet en werking en prestaties van de processen hebben, oftewel de serviceorganisatie moet daarvoor “In Control” zijn. Bij een TPM verklaring is dat voor de serviceorganisatie niet noodzakelijk (collegemateriaal Han Boer, 11 oktober 2013). Uitleg van de verschillende SOC verklaringen SOC staat voor Service Organisatie Control-rapport. De merknaam SOC is door het Amerikaans Instituut voor Accountants (AICPA) gelanceerd, in eerste instantie als alternatieve naam voor het ISAE-3402/SOC1rapport. De soorten SOC rapporten zijn te onderscheiden door een nummer. Een ISAE-3402/SOC1 rapport heeft uitsluitend betrekking op beheersmaatregelen die een (indirecte) relatie hebben met de financiële verslaglegging van de uitbestedende organisatie. De standaard geeft aan dat voor een assurance verklaring die niet gericht hoeft te zijn op financieel relevante beheersmaatregelen gebruik moet worden gemaakt van de Richtlijn 3000 (ook wel ISAE 3000 genoemd). (Boer en van Beek, 2013) De SOC 2 rapportage is gericht op een specifiek IT gerichte scope. De principles and criteria oftewel normen uit het rapport hebben betrekking op het beheersen van IT-infrastructuur, software, gegevens-/informatieopslag en de hierop betrekking hebbende handmatige en geautomatiseerde uitvoeringsprocedures. De principles en criteria betreffen een aantal kwaliteitsaspecten, te weten beveiliging, beschikbaarheid, integriteit van bewerking, vertrouwelijkheid en privacy. Daarmee is de rapportage breed toepasbaar voor het afgeven van assurance op IT-gerelateerde processen. Het rapport kan betrekking hebben op één of meer van de genoemde kwaliteitsaspecten, met als basisset de principles en criteria voor beveiliging. Wanneer er kwaliteitsaspecten niet worden beoordeeld, moet dit in het rapport worden gemotiveerd. Als laatste is er de SOC 3 rapportage die als focus dezelfde principles en criteria als de SOC 2 rapportage heeft. Het is echter een kort rapport, zonder de detailrapportage van SOC 2, en is geschikt voor brede publicatie. Wanneer het rapport op internet wordt gepubliceerd moet een verkort rapportagemodel worden gebruikt dat sterk lijkt op een certificaat. Door de vorm van deze rapportage en het ontbreken van de detailrapportage mag er geen uitsluiting van onderaannemers zijn toegepast (zogeheten carve out). Het doel van de rapportage, te weten het zekerheid bieden aan gebruikers van de naleving van principles en criteria door de service organisatie (en daarmee ook de eventuele onderaannemers) moet eenduidig uitlegbaar zijn en vergelijkbaar met SOC 3 rapportages van andere service organisaties. De onderlinge vergelijkbaarheid en verstrekte zekerheid zijn de redenen dat er geen carve out mag zijn toegepast. Verschillen tussen de ISAE 3402 verklaring en de (NOREA) Richtlijn 3000 Voor een assurance verklaring die niet gericht is op financieel relevante beheersmaatregelen kan gebruik worden gemaakt van SOC2/SOC3 of de Richtlijn 3000. Daar waar de ISAE 3402/SOC1 standaard gericht is op financieel relevante beheersmaatregelen, biedt de Richtlijn 3000 meer vrijheidsgraden.
1 april 2014
11
Versie 1.0
In het kort zijn er de volgende verschillen tussen de Richtlijn 3000 en de ISAE 3402 verklaring: •
• •
•
Een ISAE3402 verklaring heeft betrekking op controls ten behoeve van de financiële verantwoording en heeft betrekking op een service organisatie. De opdrachtgever moet ook de serviceorganisatie zijn. Het object van een Richtlijn3000 assurance-rapport mag breder zijn. Voor een ISAE3402 verklaring is een management bewering van de serviceorganisatie verplicht, voor een richtlijn3000 rapport gewenst. Een ISAE3402-rapport heeft een voorgedefinieerde vorm met verplichte onderdelen. In een ISAE3402 rapport mogen geen beheersmaatregelen worden opgenomen die niet financieel van aard zijn. Een richtlijn3000 rapportage kent deze eisen aan vorm en scope niet. Er moeten alleen een aantal verplichte onderdelen worden behandeld. Daardoor kunnen ook processen worden opgenomen die geen invloed hebben op de financiële verantwoording. De voorgedefinieerde kwaliteitsaspecten van een ISAE3402 gaan over continuïteit (alleen in vorm van backup/recovery, geen uitwijk bijvoorbeeld), juistheid en tijdigheid. Een richtlijn3000 opdracht heeft geen voorgedefinieerde kwaliteitsaspecten.
Te gebruiken normenkaders zoals het COBIT-framework, procesmodellen en ISO normen De te auditen IT processen/IT objecten kunnen met behulp van modellen als ITIL (technisch beheer), ALS (applicatiebeheer) en BISL (functioneel beheer) worden beoordeeld. Ook Cobit is voor de beoordeling van processen geschikt om te gebruiken, of de standaard van Norea en het Platform voor Informatiebeveiliging “Handreiking, normen voor de beheersing van uitbestede ICTbeheerprocessen (Norea, 2008) ISO 27001 specificeert 133 controles die gebruikt kunnen worden om beveiligingsrisico’s te verkleinen. De normen van ISO 27001 kunnen worden gebruikt om de kwaliteit van de beheersmaatregelen ten behoeve van de beveiliging en continuïteit van diensten te beoordelen. Kortom, om een oordeel (met beperkte of redelijke mate van zekerheid) over IT diensten te kunnen geven, kan de IT-auditor gebruik maken van diverse assurance richtlijnen en -rapportages, normenkaders, modellen en procesbeschrijvingen. Van het object van onderzoek is de locatie bekend in het geval van hosting of outsourcing. Verder is het aantal partijen dat betrokken is bij het leveren van de dienst zeer klein en is de datalocatie ook bekend. Voor Cloud computing zijn deze kenmerken niet van toepassing. Daardoor zijn er extra eisen en aandachtspunten die moeten worden geadresseerd in het normenkader en de assurance verklaring. Daarnaast moet voor het afgeven van de assurance verklaring de scope van de assurance opdracht zorgvuldig worden afgewogen. In het geval van een op financiële verantwoording gerichte scope is een ISAE-3402/SOC1 rapportage een geschikt format. De SOC2/SOC3 rapportage is gericht op het verstrekken van assurance over de IT-gerelateerde processen. De ISAE3000 rapportage is vormvrij qua scope en kwaliteitsaspecten, en kan breder gebruikt worden.
1 april 2014
12
Versie 1.0
2.2. Corporate Governance en IT Governance Voordat ik verder ga wil ik benadrukken dat uitbestede diensten deel uitmaken van de IT Governance van een bedrijf. Het bedrijf is dan ook verantwoordelijk voor het “vragen” van assurance over de uitbestede diensten ten behoeve van het eigen “In Control Programma” van het uitbestedende bedrijf. Zowel beursvennootschappen als niet-beursgenoteerde vennootschappen en nonprofitorganisaties worden geconfronteerd met ‘codes’ voor Corporate Governance1. Voorbeelden zijn de Nederlandse Code voor Corporate Governance van de commissie Tabaksblad en de Amerikaanse Sarbanes-Oxley Act 2002. De essentie van Corporate Governance is “het goed besturen van organisaties en het aantoonbaar maken dat dit ook zo gebeurt” (Kennisgroep IT Governance Norea, 2004). In de ‘codes worden onder andere eisen gesteld aan de beheersing van de bedrijfsprocessen zodat de betrouwbaarheid van verantwoordingen gewaarborgd en aantoonbaar wordt. Er wordt in de ‘codes’ een onderscheid gemaakt naar de ‘principle-based’ benadering op basis van algemene randvoorwaarden en best practices, en de ‘rule-based’ benadering op basis van regulering, wetgeving en harde eisen. Voor de interne beheersing en afleggen van externe verantwoording moet een bedrijf ook rekening houden met branche-specifieke voorschriften, zoals de Solvency II richtlijnen voor verzekeringsmaatschappijen. De inzet van IT-toepassingen vormt een belangrijke schakel in de bedrijfsvoering en de realisatie van de organisatiedoelstellingen. De beheersing van de informatievoorziening vormt daarmee een integraal onderdeel van de beheersing van de organisatie. IT-Governance maakt daardoor onmiskenbaar onderdeel uit van Corporate Governance. Het gaat over “besturen, beheersen, uitvoering, verantwoording afleggen over het toezicht op de informatievoorziening binnen een organisatie.” (Kennisgroep IT Governance Norea, 2004) Vanuit de uitgangspunten van Corporate Governance zijn er drie aandachtsgebieden voor IT Governance in een organisatie: • de beheersing van de informatievoorziening in de organisatie door het besturen, beheersen en uitvoeren van de informatievoorziening; • het afleggen van verantwoording over de beheersing van IT naar buiten toe en • het uitoefenen van toezicht op de IT-beheersing door bijvoorbeeld de Raad van Commissarissen binnen de organisatie en door toezicht van toezichthouders als bijvoorbeeld DNB. De 5 elementen die hierboven genoemd worden, zijn door Tewari 2(2013) in een driehoek verband geplaatst, gebaseerd op het besturingsparadigma van De Leeuw (zie figuur 5). Binnen de huidige omgevingen wordt de beheersing van de bedrijfsprocessen mede bepaald door: • de kwaliteit van de informatiesystemen, geprogrammeerde controles binnen systemen en • gebruikerscontroles; • de beheersing van IT-veranderingstrajecten; • de beheersing van de IT-infrastructuur, waarop de systemen draaien; • de beheersing van IT-risico’s. 1
Governance voor een onderneming betreft onderwerpen als consistent management, samenhangend beleid, processen en beslissingsrechten voor een bepaalde bevoegdheid. 2 Collegemateriaal voor de Vrije Universiteit Amsterdam
1 april 2014
13
Versie 1.0
Figuur 1 Besturingsmodel voor IT Governance (Bron: Wiekram Tewari)
Er zijn ten behoeve van de beheersing van de bedrijfsprocessen verschillende spelers en producten te benomen die bijdragen aan het behalen van doelen op alle domeinen. Wilders beschrijft in het artikel “Marktwerking of marteltuig” een aantal spelers die bij sturing en beheersing betrokken zijn en een aantal bijbehorende producten. De relaties tussen de spelers en de producten heb ik weergegeven in figuur 6 (Wilders, 2013).
Figuur 2 Lines of defence die bijdragen aan sturing en beheersing van processen
Er zijn in de loop der jaren verschillende IT Governance modellen opgesteld. Hoewel de modellen het begrip op een verschillende manier hebben uitgewerkt, is de rode draad het “zodanig effectief en efficiënt organiseren van de IT-werkprocessen dat zij daarmee een bijdrage levert aan de business wensen, en daar rekenschap over aflegt.” (Kennisgroep IT Governance Norea, 2004) In de praktijk wordt IT Governance door bedrijven op uiteenlopende manieren ingevuld. ITGovernance heeft vergaande impact op de rol, de werkzaamheden en de opleiding van IT-auditors. De IT-auditor kan voor organisaties een bijdrage leveren aan de beheersing van de 1 april 2014
14
Versie 1.0
informatievoorziening, bijvoorbeeld in een adviserende, controlerende, faciliterende en/of certificerende rol (zie ook figuur 6). 2.3. De rol van data classificatie voor assurance
Uit mijn onderzoek blijkt dat dataclassificatie een belangrijk element is voor de Cloud omgeving. Het geeft namelijk aan dat een basisvoorwaarde is voor een klant om te kunnen bepalen of data of een informatiesysteem geschikt is om in een cloud omgeving onder te brengen. Het vergt een bepaald volwassenheidsniveau van de organisatie van de klant om de dataclassificatie op te stellen en onderhouden, en het data-eigenaarschap in te kunnen vullen. Daarnaast vergt het een zelfde niveau van de leverancier om de beveiligingseisen en gewenste maatregelen toe te passen in een beheerste beheeromgeving. Met behulp van classificatieniveaus van data en informatiesystemen kan er een vereist beschermingsniveau worden bepaald. Op grond hiervan kan de data-eigenaar vaststellen welke beveiligingseisen van toepassing zijn en welke maatregelen moeten worden genomen. Basiselementen om te kunnen komen tot deze beslissingen zijn onder andere architectuurprincipes, beleidsuitgangspunten en beveiligingseisen. Informatiebeveiliging is “het geheel van maatregelen en procedures om informatie te beschermen.” (Informatie Beveiligings Dienst Gemeenten, 2013). Deze doelstelling wordt onder andere onderschreven door het Nationaal Cyber Security Center (NCSC) en de ISO 27002 “Code voor Informatiebeveiliging”). Het heeft als doel het waarborgen van de continuïteit, integriteit en vertrouwelijkheid van informatie. Daarnaast het beperkten van gevolgen van eventuele beveiligingsincidenten. De mate waarin data moet worden beschermd wordt uitgedrukt in classificatieniveaus voor de beschikbaarheid, integriteit en vertrouwelijkheid van informatie. De BIG3classificatie wordt in veel bedrijven als uitgangspunt genomen, vandaar dat ik dit uitgangspunt voor mijn scriptie heb geselecteerd. De kwaliteitseisen die worden gesteld aan data en de bijbehorende classificatieniveaus zien er als volgt uit (Informatie Beveiligings Dienst Gemeenten, 2013): • Beschikbaarheid: hoeveel en wanneer data toegankelijk is en gebruikt kan worden. De onderscheiden niveaus zijn: niet nodig; noodzakelijk; belangrijk en essentieel. • Integriteit: het in overeenstemming zijn van informatie met de werkelijkheid en dat niets ten onrechte is achtergehouden of verdwenen (juistheid, volledigheid en tijdigheid). De onderscheiden niveaus zijn: niet zeker; beschermd; hoog en absoluut. • Vertrouwelijkheid: de bevoegdheden en de mogelijkheden tot muteren, kopiëren, toevoegen, vernietigen of kennisnemen van informatie voor een gedefinieerde groep van gerechtigden. De onderscheiden niveaus zijn: openbaar; bedrijfsvertrouwelijk, vertrouwelijk en geheim. 2.4. Meningen over het verstrekken van assurance voor Cloud computing In deze paragraaf wordt kort het onderzoek van Booz & Co beschreven waarin wordt onderzocht welke normen en standaarden er binnen de wereld van Cloud computing gelden, en hoe bruikbaar deze normen en standaarden zijn. Daarnaast wordt het onderzoek behandeld dat het bedrijf Qualys 3
BIG staat voor Baseline Informatiebeveiliging Nederlandse Gemeenten
1 april 2014
15
Versie 1.0
heeft uitgevoerd naar nieuwe eisen voor security en compliance auditing voor Cloud computing. Booz & Co is een toonaangevend wereldwijd management consulting bedrijf, gericht op de vormgeving van de senior agenda van 's werelds toonaangevende instellingen. Qualys is een Amerikaans commercieel bedrijf dat twee Cloud managementtoepassingen aanbiedt: een Cloud platform waar een overzicht gegeven wordt van security en compliance regels en oplossingen, en een tool waarmee security tests kunnen worden uitgevoerd, beveiligingslekkenbeheer, controle op voldoen aan policy’s, malware- en website securitytesting4. Standaarden die volgens Booz geschikt zijn voor assurance op Cloud computing 5 Booz heeft in opdracht van het Duitse ministerie van economische zaken een onderzoek gedaan naar de normen en standaarden die binnen de wereld van Cloud computing gelden. De conclusie van het onderzoek luidt: "De normen en standaarden binnen de omgeving van Cloud computing zijn nog steeds in ontwikkeling." Er moet snel wat verbeterd worden, zowel op nationaal, Europees als mondiaal niveau. (Pütter, 2012). Booz heeft drie gebieden benoemd bij het ontwikkelen van standaarden voor assurance op Cloud computing: •
•
•
Technologie: bestandsformaten en uitwisselingsmogelijkheden, het ontwikkelen van modellen, protocollen en interfaces, standaardcomponenten en referentie-architecturen. Voorbeelden van standaarden zijn o.a. CloudAudit, Google DLF en OpenStack. Management: business modellen, service-level agreements, contracten, managementmodellen en –processen, richtlijnen, audits, etc. Voorbeelden zijn onder andere ITIL, ISO 27001 en ISO 27002. Juridische zaken: wettelijke voorschriften, verplichtingen en bedrijfsbeleid. Voorbeelden zijn o.a. de Europese richtlijn voor bescherming van persoonsgegevens en het Open Cloud manifest.
In het onderzoek onderkent Booz vervolgens ruim 160 verschillende instituten die werkzaamheden verrichten op het gebied van standaardisering voor Cloud computing. Booz heeft op basis van hun belangrijke rol in het ontwikkelen van standaardisering de 19 belangrijkste instituten benoemd in onderstaand figuur.
4
Deze informatie is afkomstig van de websites van beide bedrijven.
5
De teksten die in deze paragraaf worden behandeld zijn deels een letterlijke (vertaalde) quote uit het paper. Omwille van de leesbaarheid verwijs ik niet bij ieder onderdeel van de tekst naar de bron, maar doe dat slechts eenmalig aan het begin van de tekst.
1 april 2014
16
Versie 1.0
Figuur 3 Belangrijkste standaardisatie organisaties voor Cloud computing, uiteindelijke selectie (bron onderzoek FZI en Booz, 2012)
Booz heeft de 160 industrie-overstijgende standaarden die een expliciete scope op Cloud computing beoordeeld aan het begin van 2012. De beoordeling heeft plaats gevonden op de uitdagingen van Cloud computing, te weten efficiency, effectiviteit, transparantie, informatiezekerheid, databescherming, interoperabiliteit, portabiliteit, competitie en compliance. De top 20 van standaarden zijn vervolgens gescoord naar doorzettingsvermogen en rijpheid/kwaliteit. Deze laatste scoring heeft geleid tot uitkomst van 3 best presenterende standaarden: OAuth, OpenStack en OCCI. De standaard OpenStack vergelijk ik in hoofdstuk 4 met de nadelen op Cloud computing volgens NIST. De schrijvers van het onderzoek doen een beroep op bedrijven en politiek om de standaardisatie naar een hoger plan te trekken. Ze schrijven: "De Duitse economie draagt de hoofdverantwoordelijkheid voor een actievere rol bij de standaardisering wanneer ze hun belangen op gebied van Cloud computing vertegenwoordigd willen zien." Een gevolg zou kunnen zijn dat Duitsland een eigen keurmerk krijgt voor een goed beveiligde en ingerichte cloud. (Pütter, 2012). Nieuwe eisen voor informatiebeveiliging en compliance auditing voor Cloud computing6 Het bedrijf Qualys stelt in de paper “New Requirements for Security and Compliance Auditing in the Cloud” dat Cloud computing zorgt voor nieuwe uitdagingen voor IT beveiliging en Compliance. (Qualys, 2014)Daarnaast zijn er uitdagingen voor audit professionals die bedrijfsdata en IT assets moeten beschermen, en die de compliance aan security controls moeten checken. De cloud ontwortelt voorspelbaarheid van traditionele IT-architecturen, veiligheidscontroles en auditprocedures. Cloud computing dwingt klanten om twee essentiële mogelijkheden aan cloud leveranciers af te staan: 1) controle van gegevens, programma's en acties en 2) zichtbaarheid op status van gegevens en programma gebruik. In de paper wordt beschreven hoe de wereld van IT-
6
De teksten die in deze paragraaf worden behandeld zijn deels een letterlijke (vertaalde) quote uit het paper. Omwille van de leesbaarheid verwijs ik niet bij ieder onderdeel van de tekst naar de bron, maar doe dat slechts eenmalig aan het begin van de tekst. Daar waar informatie van andere bronnen wordt aangehaald, wordt dit expliciet gemeld.
1 april 2014
17
Versie 1.0
veiligheid, audit en naleving in cloud omgevingen moet veranderen. Verder worden in de paper richtlijnen gegeven voor auditors die de effectiviteit moeten beoordelen van security-controls die worden gebruikt in een Cloud computing systeem. Qualys gebruikt ook de NIST definitie voor Cloud computing. Er zijn vele soorten clouds. Allen delen een definiërende eigenschap: de klanten moeten controle en zichtbaarheid afstaan aan clouddienst-leveranciers. NIST versterkt dit idee in de Special Publication 800-146 “Cloud Computing Synopsis and Recommendations “(NIST, 2012): • controle: de mogelijkheid om te beslissen, met hoog vertrouwen, wie en wat toegang mag worden verleend tot klantgegevens en programma's, en de mogelijkheid om acties uit te voeren (zoals het wissen van gegevens of een verbinding tot een netwerk verbreken) met hoog vertrouwen zowel dat de acties zijn genomen en dat geen aanvullende acties zijn ondernomen die de initiële acties van de klant ondermijnen(bijvoorbeeld een verzoek van de klant om een gegevensobject te wissen moet niet worden ondermijnd worden door de stille generatie van een kopie van het gegevensobject). • zichtbaarheid: de mogelijkheid om te controleren wat de status is van de klantgegevens en programma's en hoe worden klantgegevens en programma's gebruikt door anderen. Gezien de aard van gedeelde verantwoordelijkheden in cloud omgevingen, is het belangrijk dat leveranciers de uitbreiding faciliteren van audit en compliance tools in de gebieden die zij rechtstreeks beheren. Ondernemingen hebben deze samenwerking nodig omdat er steeds nieuwe beveiligingsvoorschriften en nieuwere wetten zijn die een aanvulling vormen op de huidige de Third Party assessment bij leveranciers van Cloud computing . Deze zijn de klanten vanuit compliance overwegingen verplicht om te (laten) doen bij de cloud leveranciers. Deze aanvullende voorschriften zijn een gevolg van gegevens mobiliteit als gevolg van het nieuwe werken (altijd en overal) met mobiele apparaten, en door outsourcing en offshoring. Al eerder is aangegeven dat er door het gebruik van mobiele apparaten en cloud toepassingen niet meer automatisch mag worden vertrouwd op de statische omgeving waarin de data is opgeslagen en wordt gebruik. Traditionele monitoring- en auditingtools nemen cloud systemen en mobiele apparatuur niet mee in hun controles. Bovendien zijn de besturingssystemen die voor mobiele apparaten worden gebruikt niet (altijd) geschikt voor de genoemde traditionele monitoring- en audittools. Voor Cloud computing wordt er vanuit gegaan dat de leverancier van een clouddienst eigenaar is van deze controls. Dat doet echter geen afbreuk aan de verantwoordelijkheid die de uitbestedende organisatie heeft en houdt. De onderzoeksraad “Global IT Council voor Cloud Services” van Gartner definieert 7 rechten en plichten, waardoor de onderlinge relatie tussen leverancier en klant verbeterd wordt (van Tuil, 2010). Deze rechten en plichten bepalen mede de noodzaak tot het afgeven van een passende assurance op Cloud computing: 1. Het recht om eigen data te behouden en te controleren 2. Het recht op een SLA waarin wanprestaties, herstel van dienstverlening en zakelijke gevolgen worden gedekt 3. Het recht op informatie over en invloed op veranderingen die impact hebben op de business processen van de afnemer 4. Het recht om op voorhand de technische beperkingen of vereisten te kennen 1 april 2014
18
Versie 1.0
5. Het recht om de juridische achtergronden te kennen. 6. Het recht om te weten welke beveiligingsprocessen de aanbieder volgt 7. De plicht om software licentievoorschriften te begrijpen en na te leven Qualys heeft op basis van ISO27002 nieuwe eisen voor Cloud beveiliging opgesteld, op basis van de elf secties van een standaard beveiligingsplan van een organisatie. Deze onderwerpen betreffen net als het onderzoek van Booz de hoofdonderwerpen techniek, management en recht. De benoemde maatregelen gaan onder andere in op : * het uitvoeren van een risico analyse; * beveiligingsassesments; * screening van personeel; * effectieve controls voor fysieke en logische beveiliging en systeembeveiliging; * een gedegen authenticatie- en autorisatiesyteem en * effectief configuratiemanagement. Voor organisaties die ook moeten voldoen aan de NIST standaard, wordt door Qualys verwezen naar de NIST Special publication 800-53 (april 2013). Daarin wordt in een bijlage een mapping gemaakt tussen de NIST standaard en ISO27002. De IT industrie is standaard oplossingen aan het ontwikkelen voor Cloud computing. Volgens Qualys worden er inspanningen van hoog niveau uitgevoerd door de Cloud Security Alliance (CSA) en een belangrijke subgroep genaamd CloudAudit. Deze werkgroep ontwikkelt een gemeenschappelijke interface en een “namespace” waarmee klanten die geïnteresseerd zijn hun audit processen (cloud of anderszins) kunnen stroomlijnen. Daarnaast biedt het Cloud computing aanbieders de mogelijkheid de Audit, Assertion, Assessment, and Assurance7 van hun infrastructuur 8(IaaS), platform (PaaS) en applicatie (SaaS) te automatiseren. Hiermee kunnen cloudleveranciers gemachtigde klanten uitnodigen om hetzelfde te doen via een open, uitbreidbare en beveiligde interface en methodologie. (Cloudaudit, 2014) Ik verwacht dat na verloop van tijd zulke leveranciersgedreven initiatieven zoals hierboven het voor klanten van Cloud computing eenvoudiger wordt om gegevens in de cloud te beveiligen en deze beveiliging te auditen. Een recent artikel uit de Automatiseringsgids onderschrijft deze drive van leveranciers. Amazon.com is een Amerikaans E.commerce bedrijf. Daarnaast is Amazon leverancier van Amazon Web Services (AWS), een collectie van web services die samen een Cloud computing platform vormen, aangeboden via Internet. In november heeft Amazon op een conferentie in Las Vegas drie nieuwe diensten aangeboden. Eén van deze diensten genaamd CloudTrail speelt in de op de wens van klanten om inzicht te krijgen in de cloud. Deze dienst is een trackingservice die beheerders van toepassingen in AWS een gedetailleerd inzicht geeft in het doen en laten van eindgebruikers, inclusief elke interactie van Application Programming Interfaces (API). Dit maakt het voor beheerders mogelijk om misbruik te traceren. (Zaal, 2013)
7
Het geheel van het vaststellen van te onderzoeken objecten, stellingen/beweringen over deze objecten, het vaststellen van de uitkomst van deze beweringen en het geven van een mate van zekerheid over de uitkomsten van de onderzochte objecten op een geautomatiseerde manier.
8
1 april 2014
19
Versie 1.0
Door het bouwen van beveiligings- en auditmogelijkheden rechtstreeks in de cloud infrastructuren geloven de leveranciers dat vaste kosten die anders te hoog zouden zijn voor individuele gebruikersorganisaties, te dragen zijn. Volgens Qualys, Dave Molnar en Stuart Schechter van Microsoft Research (2011, p11) zal het uiteindelijk mogelijk zijn om beveiligings- en auditkenmerken in Cloud computing te bouwen, waardoor hosting tools zoals Cpanel ondersteund worden bij de volgende activiteiten: • • • • • • • • • •
Netwerk- en operating system audit tools; Volgen van alle geïnstalleerde software, uitgevers, versies en patch niveaus; Creditcard opslag en fraude detectie; Public/private key generatie, certificaat generatie en opslag; Geautomatiseerde authenticatie en –bescherming van intra-tenant netwerkcommunicatie; Veilige logging van systeemhandelingen (alleen toevoegen, niet wijzigingen/verwijderen); Spam filtering Password hashing en –opslag CAPTCHA generatie en –verificatie (CAPTCHA staat voor Completely Automated Public Turing Test To Tell Computers and Humans Apart. Software widgets zoals een “wachtwoordsterkte-meter”
2.5. Samenvatting Hoewel allerlei bedrijven en instituten zich bezighouden met de nieuwe uitdagingen voor IT beveiliging en compliance ten behoeve van Cloud computing is deze markt nog duidelijk in beweging. In opzet zijn alle (zorgen)punten die van belang zijn voor het “In Control” zijn met een Cloud computing dienst benoemd. Het is echter nog niet voor alle risico’s en verplichtingen mogelijk om aantoonbaar te voldoen aan deze kwesties. Daarnaast moet de vorm van Assurance rapportage kritisch worden beoordeeld door de aanvullende normen en kwaliteitsaspecten die voor Cloud computing van belang zijn. Een ISAE3402/SOC1 is niet langer standaard de meest geschikte rapportagevorm.
1 april 2014
20
Versie 1.0
3. Uitbesteding van IT
In dit hoofdstuk wordt de uitbesteding van IT vanuit historisch perspectief beschreven. Cloud computing wordt kort uitgelegd, en voor- en nadelen worden benoemd. Om het concept van Cloud computing in perspectief te plaatsen, wordt teruggekeken naar traditionele hosting en outsourcing. Ook de voor- en nadelen van hosting en outsourcing zijn beschreven. 3.1. Hosting en traditionele outsourcing; definities, voor- en nadelen Traditionele hosting wordt uitgevoerd door het rekencentrum van het eigen bedrijf. De definitie van een rekencentrum is: “een expliciete organisatie die is gedefinieerd door het management, met duidelijk gedelegeerde verantwoordelijkheden voor het beheer en uitvoering van alle taken. Deze taken moeten zorgen voor de goede werking van het operationele automatisering milieu en de toepassingssystemen, als vereist voor het leveren van de support volgens specifiek gedefinieerde vereisten”. (Van Biene-Hershey, 1996, p. 520). Een rekencentrum bestaat uit een concentratie van data, informatiesystemen, infrastructuur en human resources. De afhankelijkheid van de organisatie van de beschikbaarheid van de data, de informatiesystemen en de expertise van het computercentrum is groot. Dat maakt de manier waarop het computercentrum gemanaged wordt zo belangrijk voor het functioneren van de organisatie. Een rekencentrum kan op twee manieren ondersteuning bieden aan de organisatie: inhouse of outsourced. Inhouse: het inhouse rekencentrum maakt integraal onderdeel uit van de organisatie en wordt beheerd door eigen medewerkers. Diensten worden in 1 pakket aangeboden. Outsourced: een outsourced rekencentrum levert als hostende organisatie een service. Deze hostende organisatie maakt geen onderdeel van de eigen organisatie uit. In het geval van outsourcing kan de stapel van diensten door verschillende leveranciers worden aangeboden. Zo kan bijvoorbeeld de ene leverancier ten behoeve van de sourcing van een applicatie van een bedrijf de infrastructurele- en platformhosting verzorgen, en wordt de software voor een bepaald verzekeringspakket door twee andere sourcende partijen geleverd. Het aantal partijen dat betrokken is bij het leveren van een geoutsourcete dienst is beperkt, en alle leveranciers zijn bekend bij de klant. Dat maakt het voor de klant relatief eenvoudig om een Assurance verklaring te vragen aan alle betrokken leveranciers. Vanuit een auditperspectief maakt het niet uit of de hosting inhouse is, of geoutsourcet wordt. Het is alleen van belang om te weten waar, hoe en door wie de audit wordt uitgevoerd. Het is van belang dat er “third party review” plaatsvindt, letterlijk “een afspraak gecontroleerd door een derde partij”. In audittermen betekent dit dat door een derde partij zijnde niet de opdrachtgever en niet de belanghebbende, assurance moet geven over de geleverde dienst (zie verder hoofdstuk 3). Rekencentrum-audits zijn volgens van Biene om twee redenen erg belangrijk (Biene, M, 1996, p520): •
Het management heeft bewijs nodig dat het bedrijf geen onacceptabele risico’s loopt als gevolg van handelingen en werkwijzen door het rekencentrum organisatie;
1 april 2014
21
Versie 1.0
•
Een assessment op het bestaan van een aantal general controls binnen het computer centrum is nodig om de jaarlijkse financiële jaarrekening-verantwoordelijkheden uit te voeren.
Hosting In de vorige paragrafen is een aantal keren verwezen naar “hosting”. De term hosting werd oorspronkelijk gebruikt in de definitie van een Wide Area Network (WAN), waarbij een host een machine is dat onderdeel uitmaakt van het WAN (Tanenbaum, 2003, p169), Tegenwoordig wordt het woord ‘server’ voor een host gebruikt, deze term zal in deze scriptie worden gebruikt. Hosting wordt tegenwoordig gebruikt als term om de dienstverlening aan te geven die wordt verstrekt. De fysieke locatie van deze dienstverlening is veelal op een andere geografische plaats dan het bedrijf van de klant. Toegang tot de service wordt meestal via een directe netwerkconnectie of via internet verleend. Deze vorm van hosting werd al toegepast vanaf het begin van de commerciële dienstverlening op het gebied van computers. Bedrijven kopen processortijd van mainframes die worden gehost door andere, commerciële, computerbedrijven onder de noemer outsourcing. Of de processortijd of opslagcapaciteit gebruikt wordt of niet, voor de afgesproken capaciteit moet worden betaald. Kenmerkend voor de traditionele vormen van dienstverlening (hosting, outsourcing) is dat er in het datacenter servers staan met elk een eigen functie. Bijvoorbeeld mailservers, applicatieservers, webservers, servers voor bestandsopslag, etc. In deze omgevingen werken individuele servers met verschillende taken niet als een groep samen. Iedere server heeft zijn eigen functie en inrichting. Workload, opslagcapaciteit en rekenkracht kunnen door de verschillende servers niet worden gedeeld. Hoewel iedere server traditioneel gezien zijn eigen functie heeft, is er wel een onderverdeling te maken in shared hosting, waarbij een server voor meerdere klanten wordt ingezet, en dedicated hosting, waarbij de server alleen voor één klant wordt ingezet.
Figuur 4 Ontwikkeling van in-house management naar hosted omgevingen in de cloud (Bron: Bootsma, 2012)
1 april 2014
22
Versie 1.0
In deze figuur is te zien dat bij hosting (in figuur 1 Inhouse IT genaamd) de diverse benodigde bouwblokken9 in een serverroom staan, en met behulp van een interne directe verbinding door een werkstation (PC) te benaderen is vanuit de kantoorlocatie. In het geval van outsourced IT staan de benodigde bouwblokken in een datacenter, oftewel het rekencentrum van de outsourcende partij. De verbinding tussen het datacenter en het werkstation wordt gelegd via een beveiligde verbinding door middel van een Virtual Private Network (VPN) of beveiligde data lijn. Deze verbinding is dan alleen voor de klant beschikbaar. Zoals uit de bovenstaande figuur blijkt is voor een klant die voor Cloud computing kiest niet duidelijk welke aanbieder welk bouwblok levert ten behoeve van de dienst, en op welke fysieke locatie de bouwblokken staan. De Cloud computing dienst wordt benaderd via een internet verbinding. Voordeel- het grootste voordeel van traditionele hosting is dat de klant zelf volledig inzicht en controle heeft in welke partij wel deel van de uitvoering van de dienst uitvoert. Doordat de IT inhouse wordt beheerd en er geen toegang van “buitenaf” nodig is, is er een kleinere kans op sabotage/hacking van buitenaf. Ook in het geval van outsourcing heeft de klant inzicht in welke leverancier de geoutsourcete dienst aanbiedt, daarmee kunnen gericht afspraken worden gemaakt. Wanneer de toegang tot de outsourced IT via internet wordt verkregen, wordt de kans op sabotage/hacking van buitenaf groter. Nadelen- vooral hogere kosten voor de klant (aanschaf/licenties/beheerkosten) en beperkte elasticiteit/schaalbaarheid van servers. Voor zowel hosting als outsourcing wordt wel altijd het risico van “inside attacks” gelopen door medewerkers of beheerders. 3.2. Uitbesteding IT in de vorm van Cloud computing Cloud computing is een term waar we in 2013 niet meer omheen kunnen. Onderzoeken door verschillende partijen laten (verschillende) cijfers zien van gebruik van Cloud computing door bedrijven en particulieren. Zo voorspelde onderzoeksbureau Gartner in 2010 dat de wereldwijde omzet uit Cloud computing dit jaar uitkomt op 68,3 miljard dollar; een groei van 16,6 procent ten opzichte van 2009. Gartner geeft daarbij tevens aan dat het om een doorlopende trend gaat. In 2014 zal de wereldwijde omzet naar verwachting gegroeid zijn tot 148,8 miljard dollar. (Pring, 2010) Definitie: Cloud computing is een gebied wat nog volop in ontwikkeling is. Haar uiteindelijke potentieel, de te benutten mogelijkheden en risico’s zijn nog niet volledig in beeld. Dat begint al met de definitie. Er zijn veel verschillende partijen die een in nuance verschillende definitie hanteren. Het is aan de klant om de essentie uit de definitie te halen, zodat kan worden ingeschat of het concept voor het bedrijf geschikt is, en de risico’s te beheersen.
9
Zoals hardware, operating system, database etc. Zie voor de uitleg bijlage 2 Definities.
1 april 2014
23
Versie 1.0
Voor deze scriptie is de definitie van het National Institute of Standards and Technology (NIST) als uitgangspunt gekozen: “Cloud computing is een model om netwerktoegang te faciliteren tot een gedeelde verzameling van IT bronnen (netwerken, servers, opslag, applicaties en diensten). Deze IT bronnen kunnen snel worden ingericht, en worden uitgebracht met een minimale beheer inspanning en/of leveranciersinteractie. Het model bevordert beschikbaarheid van IT bronnen. Het model kent vijf kenmerkende karakteristieken waarmee Cloud computing zich onderscheid van traditionele hosting en outsourcing. Verder kent Cloud computing 4 servicemodellen en 3 delivery modellen, waar de klant uit kan kiezen10 (NIST, SP 800-145 (2011)”
Figuur 5 Overzicht elementen Cloud computing, gebaseerd op definitie NIST
Een belangrijk kenmerk van Cloud computing zijn de drie servicemodellen, oftewel het type dienst dat door de klant wordt afgenomen. De scheiding tussen beheer en controle door klant en leverancier is essentieel bij de keuze voor Cloud computing, in combinatie met het gekozen servicemodel. De klant bepaalt op deze manier immers hoe en waar deze zelf invloed uit kan oefenen. In onderstaande figuur worden de aangeboden diensten schematisch weergegeven inclusief de scheiding tussen beheer door de Cloud computing leverancier en het beheer door de klant. In de blokken van de servicemodellen worden voorbeelden gegeven van Cloud computing leveranciers.
10
Nadere uitleg van deze cloud elementen is te vinden in bijlage 4.
1 april 2014
24
Versie 1.0
Figuur 6 Voorbeelden van cloud servicemodellen (Bron www.itengine.ru)
Verminderde invloed op (vormgeving) IT middelen. Uit de hiervoor beschreven ontwikkelingen richting outsourcing en Cloud computing blijkt dat de invloed op de vormgeving van de IT-omgeving verminderd. Er worden standaard diensten afgenomen die voor iedere klant in grote mate gelijk zijn vormgegeven. Uiteraard is de invloed die een klant kan uitoefenen op een clouddienst die is ondergebracht in een Private Cloud groter dan bij een afgenomen dienst uit een Public Cloud. Maar zelfs bij een Private Cloud maakt een klant gebruik van standaard bouwblokken. Alleen op die manier is kostenbesparing, flexibiliteit en schaalbaarheid haalbaar. Door het gebruik van virtualisatie worden middelen optimaal ingezet voor de klant. Virtualisatie, oftewel de simulatie van de software en/of hardware die op andere software loopt, zorgt voor een verminderde controle op de IT-omgeving, evenals het concept van multi tenancy (middelen delen met meerdere afnemers). Bestanden worden verspreid over meerdere (virtuele) servers en datacentra, die zich niet noodzakelijk in hetzelfde land bevinden. De leverancier bepaalt de security instellingen, updatebeleid, etc. en geeft over zijn bedrijfsvoering voor alle klanten ook maar één assurance verklaring af die gebaseerd is op één standaard normenkader. 3.3. Voor- en nadelen van Cloud computing Er zijn diverse redenen om Cloud computing te gebruiken in het voordeel van een organisatie. Kostenbesparing, flexibiliteit, schaalbaarheid en het kunnen richten op de kernactiviteiten van de organisatie worden als de voornaamste redenen genoemd. Ik noem hieronder een aantal voordelen. Omdat ze niet allemaal rechtstreeks verband houden met de vraagstelling van de scriptie worden ze niet uitgebreid toegelicht. •
•
Vormen van kostenbesparing Geen investeringen, alleen huur van apparatuur en licenties. Daarnaast wordt alleen betaald voor daadwerkelijk gebruik (Pay-per-use). Flexibiliteit en schaalbaarheid Deze worden vooral vormgegeven door de “on-demand self service”, “resource pooling” en “rapid elasticity”. Diensten groeien mee met de vraag die het bedrijf gedurende de tijd heeft, zowel in positieve als negatieve zin.
1 april 2014
25
Versie 1.0
•
•
•
Beveiliging en licentiebeheer Cloud computing biedt veilige en redundante opslag en voorkomt piraterij op het gebied van licentiebeheer (Horlings, 2011, hoofdstuk 2). De dataopslag wordt uitgevoerd door een leverancier die gespecialiseerd is de beveiliging van data, bij voorkeur gespreid over meerdere datacenters. Richten op kernactiviteiten Door het outsourcen van diensten in de cloud kan het bedrijf zich richten op zijn kernactiviteiten en gebruikt het IT als business enabler. Hier moet de kanttekening bij geplaatst worden dat er door de mogelijkheid van vendor-lockin een nieuwe afhankelijkheid ontstaat die ondanks juridische contracten en regelingen niet altijd even goed af te dekken is. Het nieuwe werken en maatschappelijk verantwoord ondernemen Voordelen die minder vaak genoemd worden zijn optimale ondersteuning van het nieuwe werken en maatschappelijk verantwoord ondernemen. Doordat bij Cloud computing de ITmiddelen veel efficiënter worden ingezet, is duurzaamheid een bijkomend voordeel.
Naast de hierboven genoemde voordelen bestaan er ook nadelen voor Cloud computing. Bij het beschrijven van de deliverymodellen hierboven is al genoemd dat security instellingen door de aanbieder van de clouddienst veelal eenzijdig en voor alle klanten wordt bepaald. En doordat data en applicaties uit handen worden gegeven, wordt ook het gevoel van controle uit handen gegeven. Dit is uiteraard bij outsourcing ook al het geval, maar het wordt versterkt door elementen als internettoegang, virtualisatie en multi tenancy. Vanuit vele invalshoeken is er inmiddels geschreven over Cloud computing, en de voor- en nadelen. De meest genoemde nadelen van Cloud computing zoals genoemd in diverse papers en boeken 11 zijn: •
•
Beveiliging in het algemeen In diverse onderzoeken staat zorgen over security issues bij Cloud computing in de top 3. Media melden regelmatig cybercrime aanvallen. Daarnaast is ook niet altijd goed duidelijk in hoeverre de leverancier heeft gezorgd voor de informatiebeveiliging in de breedste zin van het woord. De assurance verklaring die door de leverancier wordt afgegeven geeft hier ook niet altijd (voldoende) inzicht in voor de klant. Beveiligingszorgen over mobile devices en Bring Your Own Device (BYOD) Mobiele apparaten als laptops, tablets en smartphones introduceren nieuwe risico’s, mede doordat eenvoudig (gevoelige) data via Cloud computing toegankelijk is en/of wordt opgeslagen op deze mobiele apparatuur, zelfs wanneer dit niet de bedoeling is. Toegang tot een traditionele hosting of outsourcete omgeving is vanuit een mobiel apparaat vele malen omslachtiger en moeilijker en zal daardoor veel minder plaatsvinden. ISACA heeft een paper geschreven waarin adviezen over de beveiliging van mobile devices wordt gegeven (zie bijlage 4). Voor assurance op Cloud computing is dit relevant omdat er potentiële risico’s
11
Ik heb hiervoor artikelen gelezen van Computable, de Automatiseringsgid, de IT Auditor ed. Verder heb ik papers gelezen van Mike Chung van KPMG, papers van Deloitte, en een boek van Jeroen Horlings over Cloud computing. Als laatste zijn de voor- en nadelen regelmatig in college’s van de VU aan de orde geweest.
1 april 2014
26
Versie 1.0
•
•
•
•
12
ontstaan op het gebied van informatiebeveiliging als de beveiliging van verzending of bewerking van data voor een mobile device niet goed is geregeld. Beveiligingszorgen over virtualisatie Het is mogelijk dat een leverancier minimaal even goed de informatiebeveiliging heeft georganiseerd als de klant dat vroeger zelf heeft gedaan. Desondanks zijn er terechte security zorgen als gevolg van virtualisatie. De security is bij virtualisatie als gevolg van de virtualisatielaag zelf die de virtuele omgeving controleert (zogenaamde hypervisor) veranderd. Er wordt door de virtualisatielaag feitelijk een nieuw besturingssysteem bovenop het bestaande besturingssysteem (zoals bijvoorbeeld Windows) toegevoegd die als coördinator tussen de virtuele machines fungeert, en die het mogelijk maakt om van het ene naar het andere besturingssysteem over te schakelen (Horlings, 2011, p. 121). De huidige versies van de virtualisatie-software hebben allemaal nog zwakke plekken als het om veiligheid gaat. Hierdoor kunnen ongenode gasten toegang krijgen tot het gehele virtuele netwerk, ondanks genomen beveiligingsmaatregelen op lokaal niveau. Daarnaast zijn de complexiteit van een virtuele omgeving en het virtuele geheugen. Gartner constateert dat ruim 60 procent van alle virtuele servers minder veilig is dan de fysieke servers die ze vervangen. (Woude, 2013) Locatie van data Waar de leverancier de data bewaard is belangrijk vanuit het oogpunt van beschikbaarheid en kwaliteit van toegankelijkheid, maar ook vanuit juridisch oogpunt. De klant moet zich afvragen waar de data volgens wet- en regelgeving en toezichthouders mag worden opgeslagen en waar de klant zelf wil dat de data wordt opgeslagen. Het volume van data is de laatste decennia explosief gestegen. De Amsterdam Internet Exchange (AMS-IX) heeft het dataverkeer dat maandelijks op het internetknooppunt wordt verwerkt zien groeien van 50 petabyte 12( in 2007 tot meer dan 500 petabyte in oktober van dit jaar. Om voor een dergelijk volume van data bij te houden waar de data opgeslagen is geweest op ieder moment gedurende een periode, lijkt vooralsnog een onmogelijke opgave. Afhankelijkheid van de aanbieder (vendor lockin en exit strategie) Bij het opstellen van een contract wordt niet altijd (voldoende) aandacht besteed aan de migratie- en exit strategie aan het einde van het samenwerkingsverband. Verder moet bij het aangaan van het contract goed worden nagedacht over problemen die kunnen ontstaan bij faillissement van een leverancier (vendor lockin). Hoe is de continuïteit en eigenaarschap van data dan geregeld? Een andere vorm van vendor lockin is de afhankelijkheid van een leverancier als gevolg van het gebruik van eigen standaarden van de leverancier een risico. Bovendien is de migratie van data van de oude naar de nieuwe leverancier bijna niet te doen als gevolg van het huidige volume van data bij veel bedrijven. Fysiek transport ligt dan voor de hand, maar daarvoor moet wel duidelijk zijn waar alle data zich bevindt. NB: al deze punten zijn geen specifiek risico voor Cloud computing, ze komen ook voor bij traditionele IT uitbestedingen. Ze worden echter wel versterkt door Cloud technologie en dragen daardoor bij aan de noodzaak tot een andere assurance dan voorheen. Afhankelijkheid van internet Het is duidelijk dat Cloud computing voor 100% afhankelijk is van het gebruik van internet. Om te kunnen werken is een internetverbinding de eerste noodzakelijke vereiste. Niet alleen
Eén petabyte is 1000 terabytes dus een biljard bytes
1 april 2014
27
Versie 1.0
•
het aanwezig zijn van de verbinding maar ook de kwaliteit van de verbinding en alle tussenliggende apparatuur is van belang. Afhankelijk van welk deliverymodel wordt afgenomen, kan dit van groot belang zijn. Denk bijvoorbeeld aan het afnemen van zware rekenkracht of het snel beschikbaar zijn van data. Standaard SLA’s en het verkrijgen van (maatwerk) assurance Cloud computing is voor een leverancier het meest rendabel als voor alle klanten volgens de standaard afspraken van het SLA kan worden gewerkt. Uitzonderingen of extra garanties (bijvoorbeeld een hogere uptime garantie) zijn dure extra’s voor de klant. Allemaal zaken om vooraf goed door te spreken binnen het bedrijf van de klant, bij voorkeur onderbouwd door een risico analyse en in te regelen mitigerende maatregelen. Naast een standaard SLA biedt een leverancier standaard rapportages en standaard assurance verklaringen aan. Iedere afwijking op deze standaard die door een klant wordt gevraagd is een dure keuze, hoe legitiem ook vanuit bijvoorbeeld wettelijke verplichtingen voor het bedrijf. Over iedere afwijking van de standaard moet goed worden nagedacht door de klant, en moeten heldere afspraken worden gemaakt met de leverancier. Als laatste is nog niet duidelijk hoe en in welke mate informatie voor de klant inzichtelijk moet zijn van onderaannemers van de leverancier vanuit de eindverantwoordelijkheid van de uitbesteding. Onder andere uit de casestudie verderop in deze scriptie blijkt dat SLA-management en – rapportages een belangrijk onderdeel zijn voor het verkrijgen van assurance over Cloud Computing.
3.4. Samenvatting hosting en outsourcing Het concept van hosting en outsourcing wordt door bedrijven in alle soorten en maten gebruikt. Kenmerken van deze vormen zijn : • • •
•
Kosten: de aanschaf- en licentiekosten zijn voor de klant en de kosten voor de IT omgeving staan vooraf vast, los van daadwerkelijk gebruik; Niet flexibel: de IT omgeving is niet schaalbaar of elastisch; Beheer, locatie en toegang: beheer door eigen medewerkers of als een dienst door een derde partij, de locatie en functie van de servers is vooraf bekend, het object van onderzoek is statisch, de toegang tot de servers en data is door middel van een eigen verbinding of een combinatie van internet en firewalls geregeld (of een VPN verbinding/beveiligde datalijn); Standaarden en normenkaders; de normenkaders en standaarden voor het afgeven van assurance zijn opgesteld en algemeen geaccepteerd en de wensen over de invulling van de normenkaders onderliggend aan de Assurance verklaring kunnen tussen klanten verschillen waardoor één standaard verklaring voor een outsourcende leverancier niet altijd even eenvoudig is.
1 april 2014
28
Versie 1.0
3.5. Samenvatting Cloud computing Het concept van Cloud computing is steeds meer in opmars, en is inmiddels ook bij klanten niet meer weg te denken uit het dagelijkse gebruik. Kenmerken van deze vormen zijn : • • • •
• •
Kent een aantal karakteristieken: On-demand self-service, Broad network access, Resource pooling (multi tenancy model), Rapid Elasticity en Measured Service; Kent een aantal Services: Cloud Software as a Service (SaaS), Cloud Platform as a Service (PaaS) en Cloud Infrastructure as a Service (IaaS); Kent een aantal delivery modellen: Private cloud, Community cloud, Public cloud en Hybrid cloud; Verschillen met “klassieke IT”: Multi tenancy, huur van diensten, geen investeringen, snelle elasticiteit en schaalbaarheid en externe opslag van data buiten IT domein van de dataeigenaar; Voordelen ten opzichte van “klassieke IT”: grote flexibiliteit, kostenbesparing, vergroting van schaalbaarheid en transparantie van kosten (door Pay-per-Use); Nadelen/risico’s van Cloud computing: - Mate van beveiliging, privacy en inzicht hierin, en beschikbaarheid van data - Een verandering in het bedrijfsmodel van de afnemer; van uitvoerend in de IT naar aansturend richting leveranciers, en bepalen/bewaken van IT- en Informatie beleid. - Technologie; er is een gedegen kennis nodig van gebruikers van de Cloud technieken, om: - risico’s en kansen in te schatten ten behoeve van de keuze voor Cloud computing en geschikte vorm van servicemodel en delivery; - de IT organisatie van de leverancier (inhoudelijk) goed te kunnen aansturen; - beleid te kunnen vaststellen en bewaken op Cloud computing gebied. - Wetgeving en compliance op het gebied van het eeuwige spanningsveld tussen statische wet- en regelgeving en de dynamische omgeving van de cloud. Dat uit zich vooral in: - geschillenbeslechting; - beschikbaarheid; - auditibility en ruimte voor ‘eigen’ assurance wensen van afnemers; - beëindigen van de relatie (vooral leveranciersafhankelijkheid, zie verder hieronder); - onderaannemers; - databescherming privacy en bescherming van persoonsgegevens. - De leverancier blijft eigenaar van hard- en software, daardoor is er voor de afnemer een afhankelijkheid van de leverancier, met als risico’s - vendor lockin; - escrow; - connectivity met andere leveranciers; - verschillen in assurance waardoor onderlinge vergelijkbaarheid assurance verklaringen moeilijk is. • Onderaannemerschap en het inzicht wat de afnemer krijgt in de kwaliteit van de onderaannemer en de assurance op de dienstverlening van de onderaannemer.
1 april 2014
29
Versie 1.0
4. Risicobeheersing bij Cloud computing en assurance verstrekking Binnen Cloud computing worden nog openstaande risico’s onderkend. NIST is één van de organisaties die risico’s aandragen. Dit inzicht in risico’s is voor Cloud computing van belang, temeer beslissers zich zorgen hierover maken. In dit hoofdstuk vergelijk ik de benoemde risico’s in de publicatie “ Cloud computing Synopsis and Recommendations “ (NIST, 2012) met diverse standaarden en normenkaders die in de praktijk worden gebruikt, als fundament voor een assurance rapportage. Op basis van deze analyse wordt vastgesteld of in deze bronnen de door NIST benoemde risico’s geadresseerd worden in opzet en werking, of niet. 4.1. Aanleiding van de analyse Uit een onderzoek onder de lezers van de Automatiseringsgids en IBM (juni 2013) blijkt dat ITbeslissers nog een aantal zorgen hebben over Cloud computing (Roerdinkholder, 2013). De voornaamste zorgen zijn: 1. veiligheid en dataprivacy; 2. garanderen van integrale IT diensten over clouddiensten en niet-clouddiensten heen; 3. eisen vanuit regulerende (overheids)instanties; 4. veranderende Governance tussen business en IT, en 5. vendor lockin. Ook in het paper “The cloud is ready for you, are you ready for the Cloud?” van Booz (Stroh, Acker & Kumar, 2009) wordt aangegeven dat CIO’s terecht zich zorgen maken over beveiliging, business continuity, beschikbaarheid van data en kosten. Volgens de auteurs kan een CIO deze zorgen overwinnen door voldoende aandacht te geven aan de reputatie van de leverancier op het gebied van security, uptime, performance, service richting klanten en hoe up to date de technologische infrastructuur is. Verdere aandachtspunten zijn service level agreements, business continuity plannen, exit strategie en het prijsmodel van de leverancier op basis waarvan de prijsafspraken worden gemaakt (Stroh, Acker & Kumar, 2009). In de publicatie “ Cloud computing Synopsis and Recommendations “ (NIST, 2012, hoofdstuk 8) worden de openstaande punten en risico’s van Cloud computing uitgewerkt die nog niet (voldoende) zijn uitgekristalliseerd. Het doel van het beschrijven van deze punten is het bewust maken van de lezer hoe Cloud computing gerelateerd is aan deze issues in zowel lokaal beheerde en outsourcete IT computing services. Ook wordt in het document bij een aantal punten aangegeven of er voor dat punt momenteel een mitigerende maatregel beschikbaar is. Dat kan zijn een technische, procedurele of organisatorische maatregel, of een combinatie hiervan. Analyse van normenkaders en standaarden Ik heb op basis van voorgaand theorie onderzoek en het onderzoek “normungs und standardisierungsumfeld von cloud computing” van Booz (Bernat, Zink, 2012) gekozen voor 4 normenkaders en standaarden, die ik hieronder vergelijk met de openstaande punten en risico’s van NIST. Op basis van deze vergelijking trek ik per openstaand punt van NIST de conclusie of in de normenkaders en de standaard het risico voldoende, deels of onvoldoende wordt geadresseerd. In dit hoofdstuk wordt de vergelijking op hoofdpunten weergegeven. In bijlage 2 wordt de volledig uitgewerkte vergelijking getoond. 1 april 2014
30
Versie 1.0
Figuur 7 Aanpak analyse normenkaders versus openstaande punten NIST (eigen figuur)
Gekozen kader CloudControls Mike Chung heeft samen met CloudVPS een richtlijn voor Cloud computing ontwikkeld genaamd CloudControls (CC). Deze controls zijn gebaseerd op 61 Cloud computing gerelateerde risico’s. NEN is voornemens om deze risico’s in het ontwerp NPR 5317 Cloud computing in 2014 op te leveren voor commentaar. Gekozen kader Atos Cloud Security Control Framework Dit framework (ACSCF) geeft een opsomming van controls die ingezet kunnen worden bij gebruik van Cloud computing. Vanuit een “dreigingen” workshop die een klant volgt, wordt een risicomatrix gegenereerd. De risico workshop begeleiders vertalen het risico beeld naar de betreffende maatregelen uit het cloud control framework waarbij het aan het management van de betreffende dienst is maatregelen te nemen of het bijbehorende risico te dragen of compenserende maatregelen te nemen. Vervolgens evalueert de klant de control selectie met het Cloud Service Management om samen af te spreken welke controls geïmplementeerd moeten worden. Het resultaat is een Cloud beveiligings Baseline waarmee de beveiligingsmaatregelen worden beschreven die moeten worden geïmplementeerd bij de leverancier. Gekozen kader ter vergelijking van OpenStack Voor deze scriptie heb ik gekozen voor OpenStack13 omdat deze het meest volledige beeld weergeeft in de standaard, grofweg in te delen naar toegangsbeveiliging, techniek en opslag. Het is een compleet framework voor het bouwen van Cloud infrastructuren. OAuth is alleen gericht op identity management in de breedste zin. De standaard van OCCI is een API voor (vooral IaaS) Cloud management en richt zich op interoperabiliteit, portabiliteit en integratie.
13
OpenStack bestaat uit een uitgebreide verzameling gratis Open Source protocollen voor ontwikkelaars, website eigenaren en gebruikers om toegang tot gebruikersdata te beheren over websites heen. Wordt oa gebruikt door Yahoo!, Myspace en Google.
1 april 2014
31
Versie 1.0
Gekozen kader ter vergelijking van Cloud Security Alliance Security, Trust and Assurance Registry (CSA STAR) Ook zijn de punten uit documentatie van de CSA STAR geanalyseerd: worden bij een audit op bestaan en werking van Cloud computing de genoemde risico’s van NIST geaudit? Het zijn documenten Consensus Assessment Initiative (CAI Questionnaire) , de CSA Security Guide en de Cloud Controls Matrix14 (CMM R1.1). De normenkaders van CSA en EuroCloud zijn door SIG-leden tijdens een SIG-enquête gekozen als geschikt kandidaat normenkader om cloud services te certificeren en auditen (CSA/ENISA, 2013). De voorkeur is gegeven aan de CSA STAR audit omdat deze een volwassenheidsgroei van audits (van selfassesment, certification, third party attestation tot continuous auditing) ondersteund met drie duidelijke documenten. De EuroCloud Star Audits gaan niet verder dan een toetsing van (delen van het) bestaan van door de leverancier opgegeven selfassesment. 4.2. Beoordeling openstaande risico’s Cloud computing van NIST De risico’s van NIST zijn ingedeeld naar een aantal categorieën. Op basis van deze indeling heb ik de conclusies verwoord. Hierbij moet het voorbehoud worden gemaakt dat weloverwogen is gekozen voor de documentatie die gebruikt is voor de analyse. Mogelijk hebben de organisaties die eigenaar zijn van de documenten, in andere documenten de risico’s van NIST wel geadresseerd. Het is echter voor de afstudeerscriptie niet haalbaar om alle documentatie geschreven door de deze organisaties door te nemen ten behoeve van de volledigheid van de analyse. Gekozen is voor drie iconen ter beoordeling: - betekent dat het risico volledig wordt benoemd; - betekent dat het risico deels wordt benoemd en - betekent dat het risico niet wordt benoemd. NB: In de kolom CSA hieronder staat het eerste oordeel voor de beoordeling van de CAI Questionnaire en het tweede oordeel voor de Security Guide NIST Computerprestaties
CC
ACSCF
OpenStack
CSA
Latency / Offline data synchronisatie / Schaalbare programmering / Data-opslag management Conclusie: De technische risico’s worden deels niet en deels matig geadresseerd door zowel CloudControls, OpenStack als de CSA STAR audit. Er is in de diverse documenten voldoende aandacht voor de risico’s behorend bij data-opslagmanagement. De technische risico’s hebben deels te maken met efficiency van de ingezette middelen (denk aan grid computing en parallel processing). Voor een Service Organisatie Control-rapportage waarmee voor een klant assurance wordt verstrekt, is efficiency niet van belang. De manier waarop met offline data-synchronisatie wordt omgegaan heeft echter de maken met juistheid en volledigheid van data, en is van belang voor een ISAE-3402/SOC1verklaring. Deze standaard is ontwikkeld om inzage te geven in, en assurance te geven over, beheersingsmaatregelen die (indirect) bijdragen aan een juiste en volledige financiële verslaglegging door de uitbestedende organisatie. Juistheid en volledigheid kunnen alleen met een redelijke of beperkte mate van zekerheid worden bepaald als kan worden gegarandeerd dat offline data op een correcte manier wordt geïntegreerd met de online data. 14
Ik heb gebruikt gemaakt van de CSA CAI Question set v1.1, waarin de CSA-CAI v1.1 en de CCM R1.1 zijn opgenomen, van de CSA site, dd 21-1-2014.
1 april 2014
32
Versie 1.0
Alleen bij het gebruik van het ACSCF kan met een beperkt inzicht in de risico’s gerelateerd aan de onderwerpen ressorterend onder Computerprestaties, assurance worden verleend. Afhankelijk van de relevantie van het risico voor de klant en voor de gekozen vorm van Cloud computing moet door de klant worden afgewogen of er aanvullend werkzaamheden moeten worden verricht ten behoeve van het verkrijgen van extra zekerheid. Met behulp van de overige standaarden en normenkaders kan dit niet, omdat de wijze van afhandeling van offline data-synchronisatie niet (voldoende) wordt geadresseerd. Dit punt is relevant voor Cloud computing omdat juist de locatie van data niet statisch is zoals bij (outsourced) traditionele IT toepassingen en er mogelijk data “kwijt raakt”. NIST CC ACSCF OpenStack CSA Cloud betrouwbaarheid Netwerk afhankelijkheid / Cloudleverancier uitval N.v.t. / Safety-critical processing N.v.t. N.v.t. N.v.t./ Conclusie: De safety-kritische processen en de maatregelen bij cloudleverancier-uitval wordt door alle bronnen voldoende geadresseerd. De kanttekening moet wel worden geplaatst dat bij het gebruik van het ACSCF normenkader voldoende kennis van de klant en verantwoordelijkheid nodig is. Het onderwerp Internet connectivity wordt niet geadresseerd door CloudControls, ACSCF en OpenStack. Door CSA worden hieraan wel eisen gesteld in de CSA Security Guide. Wanneer de leverancier deze guide heeft opgevolgd kan de leverancier dit niet aantonen omdat de Cloud Control Matrix en de CAI Questionnaire geen vragen over de gestelde eisen en genomen maatregelen tov Internetconnectivity worden gesteld. Bij gebruik van de Cloud controls kan worden aangetoond dat wordt voldaan aan de betrouwbaarheid van de Cloud keten inclusief de eisen die gesteld worden aan cryptografie voor de verzending van data via het internet. De afweging of Cloud computing (en in welke vorm) geschikt is voor safety-critical processing moet vooraf door de klant worden gemaakt in het geval van Cloud Controls. NIST CC ACSCF OpenStack CSA Economische doelen Business continuity N.v.t. / Service Level Agreement evaluatie N.v.t. / Portability van workload N.v.t. / Cloudleverancier interoperabiliteit N.v.t. / Disaster recovery N.v.t. / Conclusie: Hieronder vallen een aantal issues. Het issue Business continuity & disaster recovery wordt door alle bronnen voldoende geadresseerd. De manier waarop servicelevelrapportage wordt gegenereerd en geëvalueerd (met de bijbehorende onderwerpen als continuous monitoring en –auditing) worden alleen door CloudControls niet geadresseerd. Portabiliteit van workload en interoperabiliteit tussen cloudleveranciers worden benoemd in de Security guide van CSA en door ACSCF. Alleen CSA beschrijft in de CSA Security guide de open issues die nog spelen. Het Cloudcontrol framework van CloudControls gaat uit van bestaande standaarden maar benoemt interoperabiliteit wel. Business continuity en Servicelevel management zijn belangrijke elementen voor het aantonen van de juistheid en volledigheid van (verwerking van) gegevens, en het voldoen aan wet- en regelgeving. Op het gebied van Business continuity kan met behulp van de bronnen assurance worden verleend op de juiste en volledige financiële verslaglegging volgens ISAE 3402. In de paragraaf 2.7 Monitoring van de ISAE3402 verklaring wordt de wijze waarop de interne kwaliteit wordt bewaakt benoemd. Door gebruik van de standaard OpenStack zijn de benoemde risico’s niet afgedekt. Voor de overige kaders geldt dat met een beperkt inzicht in de risico’s assurance worden verleend. Afhankelijk van de relevantie van het risico voor de klant en voor de gekozen vorm van Cloud computing moet door de klant worden afgewogen of er aanvullend werkzaamheden moeten worden verricht ten behoeve van het verkrijgen van extra zekerheid.
1 april 2014
33
Versie 1.0
NIST Compliance
CC
ACSCF
OpenStack
CSA
Gebrek aan zichtbaarheid N.v.t. / Fysieke datalocatie / Wet- en regelgeving N.v.t. / Ondersteuning van forensisch onderzoek / Conclusie: Compliance gaat over zichtbaarheid over de werking van de dienst, fysieke datalocatie, voldoen aan wet- en regelgeving en ondersteunen van forensisch onderzoek. CloudControls, ACSCF en CSA noemen in hun controls alleen dat de fysieke datalocatie in opzet moet voldoen aan de juridische eisen die gesteld zijn. Ze adresseren beide niet hoe in werking aangetoond kan/moet worden waar data op welk tijdstip opgeslagen is geweest. Het voldoen aan wet- en regelgeving (met uitzondering van de locatie van data) en het ondersteunen van forensisch onderzoek wordt door CloudControls, ACSCF en CSA (met uitzondering van de fysieke data-locatie) voldoende geadresseerd. Een kernbegrip van juistheid is rechtmatigheid. De normenkaders beschrijven in opzet waar aan moet worden voldaan. Doordat technisch nog niet kan worden aangetoond waar data fysiek opgeslagen is geweest gedurende de periode waarover wordt geaudit, kan er over de datalocatie geen assurance worden verleend. NIST CC ACSCF OpenStack CSA Informatiebeveiliging Ongewenste data-onthulling / Data privacy / Systeemintegriteit / Multi tenancy / Browsers / Hardware support voor betrouwbaarheid / van remote systemen Key management / Conclusie: CloudControls en OpenStack behandelen het onderwerp van ongewenste data-onthulling niet, CSA en ACSCF doen dit wel. Dataprivacy wordt door CloudControls, ACSCF en CSA geadresseerd. OpenStack richt zich wel op een aantal technische zaken, maar door het ontbreken van dataclassificatie in de standaard kan niet worden gecontroleerd bij (redundante) opslag of gevoelige gegevens op de verkeerde plaats worden opgeslagen. Het onderwerp systeemintegriteit wordt door CloudControls en CSA beschreven in opzet, en door ACSCF voor autorisaties en toegang. Alle bronnen besteden geen aandacht aan monitoring tools en virtual security appliances, waardoor er geen werking kan worden beoordeeld. Het onderwerp multitenancy wordt voldoende geadresseerd door alle bronnen. De eisen die de bronnen stellen aan de toegang tot een clouddienst middels een browser worden wisselend geadressseerd: CloudControls en OpenStack niet, ACSCF wel en CSA wel in de Cloudcontrolmatrix maar slechts beperkt in de CSA Securityguide. Hierbij kan worden gedacht aan up-to-date browsers, patchmanagement, alleen bepaalde browsers toestaan, gebruik van cryptografie, etc. De hardwaresupport voor de betrouwbaarheid van remote systemen en het gebruik van keymanagement wordt door alle bronnen niet voldoende geadresseerd. Informatiebeveiliging kan niet alleen op basis van de bovengenoemde bronnen worden geaudit, daarvoor zijn er teveel hiaten in opzet en/of toetsing van de werking. Daardoor kan er geen assurance worden verleend zonder aanvullende werkzaamheden. Tabel 1 Beoordeling openstaande NIST risico's
1 april 2014
34
Versie 1.0
Zoals ik al eerder heb aangegeven in hoofdstuk 3 zijn er verschillende beheersingsmaatregelen per SOC-rapport gedefinieerd. Voor cloudcomputing is het, afhankelijk van het gekozen service- en deliverymodel, meer of minder belangrijk om assurance over de (NIST) Cloud computing risico’s te verkrijgen. De rapportagevorm die een auditor per beheersingsmaatregel mag kiezen verschilt. Daardoor moet een auditor een bewuste afweging maken over de gepaste rapportagevorm waarin de assurance over het NIST risico zou kunnen worden verstrekt (mits de risico’s te auditen zijn). Dat moet voor de uitvoering van een assurance opdracht zorgvuldig worden bepaald. Vóór het aangaan van een overeenkomst voor het afnemen van een Cloud Computing dienst moet de klant bepalen of de door de leverancier aangeboden assurance rapportage met het onderliggend normenkader een geschikte vorm heeft voor het verstrekken van assurance over de door de klant vastgestelde risico’s . 4.3. Conclusie; de NIST risico’s zijn op dit moment niet allemaal te auditen In dit hoofdstuk heb ik geanalyseerd of de aan de NIST risico’s- gerelateerde onderwerpen met behulp van de geselecteerde normenkaders en standaard te auditen zijn. Op basis van de drie deelvragen verbind ik conclusies aan deze analyses. Deelvraag 1. Welke huidige normenkaders worden er gebruikt voor het verlenen van assurance, en in hoeverre zijn deze geschikt voor het afgeven van assurance voor cloud computing? De ISAE3402/SOC1 verklaring wordt gebruikt voor het afgeven van assurance door de service organisatie. Het normenkader dat als toetsingskader voor dit rapport wordt gebruikt door CC, Atos en CSA is een uitgebreid control framework. Uit mijn vergelijking van deze control frameworks met de openstaande risico’s van NIST blijkt dat deze normenkaders alle risico’s van Cloud computing slechts deels voldoende in opzet en werking afdekken: 1. De computerprestaties worden alleen door het ACSCF in beperkte mate geadresseerd en aangetoond; 2. De Cloud betrouwbaarheid wordt alleen door CloudControls voldoende geadresseerd en aangetoond; 3. Voor de economische doelen kan in beperkte mate assurance worden verleend door alle normenkaders en 4. De compliance issues en informatiebeveiliging worden in alle bronnen niet voldoende geadresseerd, en kunnen niet alleen op basis van de beordeelde bronnen worden geaudit, daarvoor zijn er teveel hiaten in opzet en/of toetsing van de werking. Deelvraag 2. Waarom voldoet de huidige manier van auditen en afgeven van assurance voor IT in het tijdperk van Cloud computing niet aan de compliance eisen en de eisen/behoefte van leveranciers en de klant, en welke tekortkomingen liggen hieraan ten grondslag? (analyserend). De huidige manier van assurance verlenen voldoet niet omdat:
1. een aantal onderwerpen in de bestudeerde normenkaders niet geadresseerd worden. De adressering van deze onderwerpen zijn juist voor de cloud computing van belang omdat de organisatie anders risico’s loopt.
1 april 2014
35
Versie 1.0
2. Het technisch nog niet voldoende mogelijk is om de technieken die voor Cloud computing gebruikt worden zoals virtualisatie en de rol van de hypervisor goed te monitoren met behulp van nieuwe generatie monitoring tools en virtual security appliances. 3. De fysieke locatie van data gedurende een periode technisch nog niet kan worden vastgelegd en daardoor ook niet aangetoond. 4. De ISAE-3402/SOC1 rapportagevorm betrekking heeft op beheersingsmaatregelen die een relatie hebben met de financiële verslaglegging van de uitbestedende organisatie. De SOC2/SOC3 rapportage waarmee assurance wordt verstrekt over de beheersing van de IT processen heeft een bredere scope en kent andere beheersingsmaatregelen (zie paragraaf 2.1). De door mij onderzochte NITS onderwerpen die in het kader van cloud van belang zijn, kunnen niet geschaard worden de beheersmaatregelen van de SOC1 rapportage. Een SOC2/SOC3 rapportage of een vormvrije ISAE3000 rapportage is hiervoor wel geschikt. Deze rapportage wordt echter door de bedrijven van de case study niet gebruikt. 5. De gedegen kennis van Cloud computing techniek, wet- en regelgeving en de manier waarop assurance moet worden verleend nog niet altijd door alle betrokken partijen voldoende wordt beheerst en beheerd en 6. Er economische motieven meespelen bij het verstrekken van assurance. Voor het verlenen van een hoge graad van assurance wordt een organisatorische en technische inrichting gevraagd die afbreuk doet aan een van de kernwaarden van cloud computing, namelijk dat het de goedkoopste vorm van computing is. Het is aan de klant om voor al deze aspecten een bewuste risico afweging te maken die passend is bij de compliance eisen en behoeften van de klant. Deelvraag 3. Welke alternatieven kunnen worden beschreven voor het afgeven van een assurance verklaring die voldoet aan de eisen en behoeften van leveranciers en klanten? Voor de klant geldt dat bij het afnemen van Cloud computing steeds meer wordt overgegaan tot gestandaardiseerde dienstverlening. Denk dan aan gestandaardiseerde rapportages en assurance verklaringen. Dit leidt tot meer transparantie over de dienstverlening dan bij traditionele hosting. De eventuele extra eisen die een klant stelt zijn echter duur en tijdrovend voor de leverancier. Bovendien zijn sommige eisen die de klant stelt strijdig met de wensen van andere klanten die dezelfde dienst afnemen (vb. right tot audit). Afhankelijk van het afgenomen service- en delivery model wat is gekozen is er aanvullend onderzoek ten behoeve van het verkrijgen van assurance nodig en/of realtime monitoring. Een ISAE3402/SOC1 verklaring heeft immers een heel specifieke scope ten behoeve van financiële verslaglegging en is vormvast. Alleen door bestudering van het onderliggende normenkader kan worden bepaald of de ISAE3402/SOC1 assurance verklaring voldoende de bij de risico analyse geadresseerde issues raakt. Op basis de bestudering van de theorie heb ik geen alternatieven kunnen aandragen . Dit komt door het feit dat: −
de Cloud computing omgeving nog onvoldoende volwassen is;
−
de toe te passen meettechnieken voor Cloud computing nog niet toereikend zijn en
−
onvoldoend strikte nationale en internationale regelgeving bestaan om van een provider een ”beveiligingshygiene” te kunnen afdwingen.
1 april 2014
36
Versie 1.0
Er zijn echter wel verschillende opties mogelijk om te komen tot assurance op een beheerste Cloud computing omgeving. Dit betreft dan meer het aanscherpen van het normenkader door het bewust opnemen van de onderwerpen die gerelateerd zijn aan de door NIST benoemde risico´s. Daarnaast kunnen er aanvullende maatregelen worden genomen ten behoeve van meer assurance op Cloud computing. Dat kan worden gedaan door bewust één van de onderstaande opties te kiezen in de samenwerking tussen klant en leverancier: 1. Er wordt een vorm van standaard assurance rapportage verstrekt door de leverancier die voor alle door de klant gewenste kwaliteitsaspecten en normen assurance verstrekt. Hierbij moet de gewenste scope in acht genomen worden die passend is bij de behoefte van de klant en geschikt is voor de rapportagevorm. Een ISAE3402/SOC1 voor beheersmaatregelen die een relatie hebben met de financiële verslaglegging van de uitbestedende organisatie, een SOC2/SOC3 rapportage voor de beheersing van IT-gerelateerde processen van de leverancier inclusief onderaannemers, en een ISAE3000 rapportage voor overige beheersingsvraagstukken. 2. Er wordt een vorm van standaard assurance rapportage verstrekt die voor een deel van de door de klant gewenste kwaliteitsaspecten en normen assurance verstrekt. Voor het overige deel van de door de klant gewenste kwaliteitsaspecten worden aanvullende werkzaamheden uitgevoerd door een auditor ingehuurd door de leverancier of klant. Het onderzoek wordt gebaseerd op gebaseerd op een door de klant en leverancier opgestelde risico analyse. Dit resulteert in een assurance rapportage (met redelijke of beperkte mate van zekerheid) of een rapport van bevindingen. 3. Er wordt een vorm van standaard assurance rapportage verstrekt die voor een deel van de door de klant gewenste kwaliteitsaspecten en normen assurance verstrekt. Voor het overige deel van de door de klant gewenste kwaliteitsaspecten wordt gesteund op de werkzaamheden die door de leverancier in het kader van het In Control Systeem worden uitgevoerd, en waar over wordt gerapporteerd. Indien nodig kan de klant een audit uit laten voeren op de opzet en werking van het “In Controlproces” om over de betrouwbaarheid en kwaliteit van dit In Control Systeem aanvullende zekerheid te krijgen. Ook in dit geval moet de klant zelf op basis van een risico analyse vaststellen of de benoemde risico’s voldoende worden bewaakt en aangetoond met behulp van het In Control systeem. 4. Er wordt een vorm van standaard assurance rapportage verstrekt die voor (een deel van) de door de klant gewenste kwaliteitsaspecten en normen assurance verstrekt. Daarnaast monitort de klant zelf mee of participeert de klant in een Security Operating Center (SOC) waardoor de klant realtime inzicht heeft in de mate van beheersing door de leverancier. Op basis van deze participatie en SLA/ICS rapportages heeft de klant een zeer volledig inzicht in de mate van beheersing van de door de klant als relevant bevonden kwaliteitsaspecten. Overige bevindingen Een klant heeft steeds meer kennis nodig van de techniek van Cloud computing en de wijze waarop aan wet- en regelgeving moet worden voldoen, om op een beheerste wijze een dienst uit te kunnen besteden en om de eindverantwoordelijkheid als uitbestedende partij te kunnen dragen. De leverancier moet nieuwe-generatie technologie inzetten om aan te kunnen tonen dat wordt voldaan aan contractuele verplichtingen. Sommige van deze technologieën zijn nog niet of niet voldoende ontwikkeld. Medewerkers van leveranciers moeten voldoende scholing krijgen om de nieuwe technologie op een verantwoorde manier te kunnen gebruiken. Samengevat moeten zowel klanten als leveranciers samen een inhaalslag maken om de nieuwe technologie op een verantwoorde 1 april 2014
37
Versie 1.0
manier te kunnen omarmen en in te zetten. Door de complexiteit van de nieuwe technologie en de strengere wet- en regelgeven moet de rapportage over deze nieuwe technologie op ieder moment van de dag actueel inzicht geven voor zowel de klant als leverancier. Een klant moet zich ook goed realiseren dat zekerheid over andere dan de prestatie-normen over de dienst, een waarde vertegenwoordigen. Dat moet de klant meenemen in de aanbesteding en de vergelijking van cloud providers. In gereguleerde omgevingen (bv met DNB als supervisor) wordt dit afgedwongen. In niet gereguleerde omgeving bepaald de markt de waarde van de zekerheid.
1 april 2014
38
Versie 1.0
5. Case study
Voor het praktijkonderzoek heb ik interviews gehouden met een leverancier (ATOS), een klant (Univé) en een stichting die o.a. frameworks en methodes voor assurance opstelt (EuroCloud). Met behulp van de case study ben ik nagegaan hoe deze drie partijen te werk gaan: - welke assurance wordt gevraagd of verleend; - welke rapportagevorm en normenkaders worden hiervoor gebruikt en - welke verschillen en problemen worden door de partijen onderkend. De geïnterviewden van de leverancier en klant hebben tijdens het interview als ‘professionals’ hun persoonlijke mening over het besproken onderwerp. In dit hoofdstuk geef ik als eerste een korte omschrijving van de bedrijven gegeven waar de interviews zijn gehouden. Vervolgens beschrijf ik de bevindingen vanuit de drie verschillende invalshoeken; klant, leverancier en een stichting ter bevordering van het gebruik van Cloud computing. Als laatste geef ik een analyse op de bevindingen en geef ik een conclusie op de case study. 5.1. Beschrijving omgeving case study
Beschrijving omgeving Univé De oudste Univé-verzekeraar stamt uit 1794 en is opgericht door een lokale gemeenschap in NoordGroningen ten behoeve van het samen dragen van de financiële gevolgen van brandschade. Momenteel zijn er nog 18 Regionale Univé’s actief als brandverzekeraar en bemiddelaars in financiële producten (o.a. schadeverzekeringen, zorgverzekeringen en levensverzekeringen). De verbindende schakel is de Univé Groep die bestaat uit de Coöperatie Univé U.A. en de dochtervennootschappen N.V. Univé Schade en N.V. Univé Her de Univé. Univé is een coöperatieve organisatie die gericht is op het bieden van financiële zekerheid aan haar leden, en wordt gedreven door ledenbelang. Circa 1,3 miljoen verzekerden met 3,7 miljoen verzekeringen zijn bij Univé verzekerd. Univé onderscheid zich van andere verzekeraars door haar klanttevredenheid en doordat ze voor verzekerden in het land “Dichtbij” zijn. Er werken in totaal 3800 medewerkers bij Univé. De omzet van de Univé Groep in 2012 bedraagt 441 miljoen. Het interview is gehouden met de Manager Regie van de afdeling Informatievoorziening van de Coöperatie Univé. Beschrijving omgeving Atos Atos is een internationaal IT services bedrijf met een omzet in 2012 van 8,8 miljard en 76.400 medewerkers in 47 landen. Het bedrijf levert Hi-Tech transactionele diensten, Consulting & technologie Services, systeemintegratie en Managed Service en is gericht op technologie die bedrijven ondersteunen in hun vooruitgang. Atos is werkzaam in de marktsectoren: Manufacturing, Retail & Services, Gezondheidszorg & vervoer, Telecom, Media & technologie en Energiebedrijven. Het is de wereldwijde informatie-technologiepartner voor de Olympische en Paralympische spelen. Atos is genoteerd op de NYSE Euronext Paris-markt. Het interview is gehouden met de Chief Security Officer en de Lead Auditor van Atos, beide verantwoordelijk voor de Benelux en de Nordics.
1 april 2014
39
Versie 1.0
Beschrijving omgeving EuroCloud EuroCloud is een onafhankelijke non-profit organisatie die een stimulator wil zijn voor bedrijven, technologische relaties en applicatie-integratie in Europa. De stichting is opgericht in Frankrijk in 2009. Het bedrijf wil de Cloud industrie vertegenwoordigen in Europa, rekening houdend met lokale verschillen, en wil een uitstekend platform zijn voor uitwisseling met Amerika of Azië. Het bedrijf organiseert congressen, roadshows en reikt awards uit. Verder heeft het bedrijf diverse cloudrichtlijnen ontwikkeld en een methodiek voor het certificeren van cloudleveranciers (EuroCloud Star audit). In minder dan drie jaar is EuroCloud vertegenwoordigd door leden in 30. Het interview is gehouden met de directeur van EuroCloud Europa. 5.2. Bevindingen case study In deze paragraaf zet ik de bevindingen uit de case study op een rij. Algemeen • •
Cloud computing is volgens alle partijen een evolutie op de reeds ingezette ontwikkelingen bij hosting en outsourcing, en een combinatie van techniek en diensten die geleverd worden. Over de mate waarop inzicht kan worden gegeven in de assurance van de complete keten van leveranciers, en de mate waarin dit nodig is, verschillen de partijen van mening. De stichting vindt dat voor een audit een deep dive nodig is en dat de klant de gehele keten van leveranciers die bijdragen aan de levering van een clouddienst moet kennen en de prestaties die deze leveranciers hebben geleverd. Volgens de klant is de assurance van onderaannemers een verantwoordelijkheid is van de hoofdleverancier. De leverancier heeft hier geen uitspraak over gedaan.
Gebruik van een assurance verklaring voor Cloud computing •
•
Momenteel wordt de ISAE 3402 SOC 1 verklaring door klant en leverancier gebruikt om assurance over clouddiensten te verstrekken. Volgens hen voldoet deze voor het verstrekken van assurance, aangevuld met frequente (realtime) rapportages, alerts en aanvullende zekerheid (bijv. op basis van een ISAE 3000 verklaring). Aanvullend geeft de stichting aan dat er moet worden gekeken naar het type afgenomen clouddienst , op basis daarvan moet de Assurance verklaring worden gekozen. Mogelijk is dit een mix van meerdere verklaringen of aanvullende mitigerende maatregelen van de leverancier(s) van de clouddienst. De huidige ontwikkelingen in de media hebben eens te meer duidelijk gemaakt dat een risico afweging altijd vooraf moet worden gemaakt bij het kiezen voor een vorm van softwareafname, welke vorm dan ook. Een cloud dienst is daarin echter niet per definitie veiliger of onveiliger dan een dienst die in een gedeeld rekencentrum bij een partij wordt afgenomen.
Waarde van de assurance op Cloud computing •
De waarde van de ISAE3402 verklaring zit in de combinatie van: 1) alerts over onderwerpen die voor de dienst belangrijk zijn (vb wetswijzigingen), 2) de frequente rapportage die inzicht verschaft over de dienst en die een middel ter verantwoording en voor sturing zijn en 3) de ISAE 3402 verklaring als aanvullende assurance. De ISAE 3402 verklaring alleen voldoet niet meer tegenwoordig.
1 april 2014
40
Versie 1.0
•
•
•
•
De huidige manier van assurance nog minder effectief dan een aantal jaren geleden. De behoefte aan continuous monitoring en –auditing wordt groter door complexe techniek met een snellere lifecycle. Wanneer de frequentie van assurance wordt verhoogd door bijvoorbeeld continuous, testen, monitoring en –auditing in te voeren, geeft dit op zich niet meer ‘formele’ assurance maar wel meer/vaker kans op bijsturen. De verhoogde frequentie van bijsturing waar nodig geeft wel meer assurance. Inzicht in kwaliteitsaspecten en performance (afhankelijk van soort dienst wat wordt afgenomen) zijn voor de afnemer zelf belangrijk, maar ook voor de 2e/3e line of defence en externe toezichthouders. De reden waarom Cloud computing nog geen convenience good is bij klanten heeft te maken met het feit dat: 1) de klant voor Cloud computing meer kwaliteitseisen heeft dan bij ‘reguliere’ convenience goods, 2) de klant meer en vaker kwaliteitscontroles op Cloud computing uit moet voeren en 3) de klant verantwoordelijk blijft voor de uitbestede (cloud)dienst, inclusief diensten die door subcontractors worden aangeboden. Door de complexiteit en het uit handen geven van werkzaamheden met het bijbehorende inzicht, geeft dit klanten (nog) geen gevoel van comfort. Klanten hebben steeds meer behoefte heeft aan informatie van de service provider die input kan leveren ten behoeve van het eigen “Internal Control System” van de klant.
Aandachtspunten voor het “In Control zijn” bij clouddiensten •
• •
•
Een belangrijk aandachtspunt is de kennis over technologie die zowel klanten als leveranciers moeten hebben bij Cloud computing, om in te kunnen schatten of de geleverde assurance voldoende de technische risico’s afdekt. Als die kennis er niet is zullen ook continuous monitoring en –auditing niet helpen om meer assurance te verlenen of de waarde van de verstrekte assurance op waarde te kunnen schatten. Klanten moeten een cultuuromslag maken in hun aansturende regierol. Deze rol is nog niet bij iedere klant even volwassen. Vanuit auditperspectief bevat de ideale assurance verklaring nul pagina’s. Vanuit operationele afspraken moet het mogelijk zijn om een kwalitatief goede rapportage te leveren voor de klant. De klant kan de rapportage op operationeel en tactisch niveau gebruiken om bij te sturen, zeker als de rapportage een hogere periodiciteit heeft dan de huidige assurance verklaring. Wanneer er een audit op het proces en de producten van de “In Control” rapportage wordt uitgevoerd zou dit voldoende moeten zijn. Vanuit security oogpunt bekeken is het heel belangrijk dat duidelijk is wat de klant kan verwachten, en wat de assurance ‘waard’ is. Een verklaring is altijd een foto van een huidige situatie en omstandigheden veranderen snel. Het is dan ook heel belangrijk om vanuit security perspectief een heel eerlijk beeld aan de klant te kunnen schetsen. Er zijn bij de leverancier een aantal klanten (circa 5%) die “realtime” mee monitoren, in een vorm van continuous monitoring waarbij informatie realtime wordt gedeeld met de klant. Deze situatie stelt hoge eisen aan de professionaliteit van de klant en vertrouwen in de vaardigheden van de leverancier om eventuele incidenten op te lossen. Een andere mogelijkheid is een Security Operating Center (SOC) waar medewerkers van zowel de klant als de leverancier(s) aan deelnemen.
1 april 2014
41
Versie 1.0
Belangrijke kwaliteitsaspecten voor Cloud computing •
•
•
•
De leverancier vindt betrouwbaarheid en integriteit van data en processen primair van belang. De aspecten vertrouwelijkheid en beschikbaarheid missen in de lijst van ISO 9126. Deze elementen moeten door de klant op gewicht en mate van ‘kwaliteit’ worden geworden in samenspraak met een architect, op basis van dataclassificatie. Helaas is de huidige stand van de techniek nog niet geschikt om de wijze en kwaliteit van afhandeling van geclassificeerde data te kunnen bepalen, en hierover te kunnen rapporteren. Volgens klant vindt de volgende punten van belang: overdraagbaarheid, functionaliteit, betrouwbaarheid, onderhoudbaarheid, bruikbaarheid en efficiency. In de lijst van ISO 9126 missen de aspecten kennismanagement, compliance en beveiliging. Met name het laatste aspect is belangrijk omdat er een andere wijze van beveiliging moet worden toegepast, met compartimenten en een gelaagde beveiliging, op basis van classificatie van gegevens. Hierbij is de context van waar informatie ontstaat en wordt aangeboden van belang. Volgens de stichting zijn betrouwbaarheid, onderhoudbaarheid, overdraagbaarheid en bruikbaarheid belangrijke aspecten. Het is niet zozeer dat er kwaliteitsaspecten missen, het gaat meer over de onderlinge vergelijkbaarheid van verklaringen. Een bruikbare (assurance) verklaring kan alleen worden verstrekt wanneer: 1) de volledige keten is in scope, inclusief onderaannemers, 2) er is volledige transparantie over wie is betrokken bij het leveren van de dienst en 3) SIG scoping wordt gebruikt. Er zijn accentverschuivingen op kwaliteitsaspecten. Dit wordt onder andere veroorzaakt door de andere technologie van Cloud computing zoals virtualisatie en rapid software development. Er is meer aandacht dan eerder voor databeveiliging. Het is echter maar de vraag of dat terecht is. Bij traditionele IT had er net zoveel aandacht voor moeten zijn.
Key risico’s voor Cloud computing •
•
•
De leverancier noemt als key risico’s: 1) een ondoorzichtige (leveranciers)keten bij Cloud computing, 2) een onvolwassen demand/supply organisatie bij outsourcing. Omdat Cloud computing een logisch vervolg is op outsourcing, wordt deze onvolwassenheid geërfd van het tijdperk van outsourcing, 3) Onvoldoende begrip ten aanzien van de noodzaak tot uniformering van diensten, services en informatieverstrekking (incl. assurance). Het effect van de ondoorzichtige keten in combinatie met gebrek aan uniformiteit versterkt het risico cumulatief, 4) huidige onvolwassenheid van de regievoerder van de klant, 5) nog niet (voldoende) ingericht relatiemanagement op alle lagen van de organisatie ten behoeve van volwaardig partnership met veel wederzijds vertrouwen en 6) onvoldoende grote (commerciële) acceptatiegraad van leverancier en klant. De klant noemt als grootste risico dat het voor een leverancier moeilijk is om verschillende stakeholders tevreden te stellen, met name op het gebied van het voldoen aan wet- en regelgeving. Door de complexiteit en voortdurende wijzigingen is wet- en regelgeving moeilijk bij te houden voor leveranciers en klanten. De stichting heeft 4 key risico’s geïdentificeerd: 1) Datalocatie en- privacy, 2) gebruik van virtualisatie, 3) vendor lockin, en 4) verschillende virtuele systemen voor verschillende levels/types van services.
1 april 2014
42
Versie 1.0
Managen van risico’s voor Cloud computing •
Het belangrijkste risico om te managen is databeveiliging, dataverlies en –lekkage volgens alle drie de geïnterviewde partijen. Volgens klant en leverancier is dit geen ander risico dan bij klassieke IT. Volgens EuroCloud is het risico groter doordat nog niet technisch kan worden aangetoond waar data zich bevindt en door wie de data is benaderd, bewerkt, vastgelegd, gearchiveerd of verwijderd. De verschillen tussen wet- en regelgeving van de verschillende landen en het feit dat door virtualisatie niet duidelijk is waar data zich op enig moment in de tijd heeft bevonden, maakt het alleen maar belangrijker om de aantoonbaarheid van locatie, toegang en bewerking van data op korte termijn mogelijk te kunnen maken. De stichting werkt aan een volgende generatie-certificering waarbij dit wel mogelijk is.
Verschillen in assurance per bedrijfstak • •
•
Veelal wordt het ISAE 3402 type II SOC 1 rapport als basis assurance beschouwd, met daarbovenop specifieke assurance eisen vanuit bijvoorbeeld toezicht houders. Met name bedrijfstakken die internationaal georiënteerd zijn hebben een voorsprong, zij zijn minder angstig over het delen van informatie en beter bekend met de verschillen in wet- en regelgeving. Bepaalde industriebranches en branches die veel privacygegevens vastleggen hebben nog aarzelingen bij het afnemen van clouddiensten. Niet alleen vanwege de mogelijke Assurance verlening die niet voldoet, maar ook vanwege de benodigde beschikbaarheid van diensten en de mate waarin data (nog niet goed) kan worden beschermd. Voor MKB en de mediabranche zijn clouddiensten uitermate geschikt.
Ontwikkelingen op het gebied van Cloud computing •
•
•
Leverancier: 1) meer integratie in 1 of 2 appliances, als mengvorm van techniek en functionaliteit, 2) een grotere frequentie van assurance afgifte, in de vorm van makkelijke “delen” of webseals (zoals een ISAE 3402 Soc3 verklaring), 3) een grotere vraag naar kwalitatieve assurance en 4) ontwikkeling van technieken ten behoeve van het afhandelen van geclassificeerde data. Klant: 1) IT voorzieningen zullen zich steeds meer standaardiseren en transformeren naar een gelijkwaardige structuur als nutsbedrijven, 2) het verkrijgen van voldoende assurance op individuele eisen wordt steeds lastiger, mede doordat steeds minder inzichtelijk is welke techniek achter Cloud functionaliteit zit en 3) het blijft zaak om scherp te blijven op waar grenzen worden overschreden en daar voldoende beleid op te ontwikkelen. Daarvoor is het hebben van de juiste kennis en rollen om dit afdoende te kunnen invullen een basisvoorwaarde. Stichting: ontwikkelingen gedreven door data retentie en databeveiliging binnen de zone die is afgesproken in de SLA: 1) volwassenheid van SLA’s, geschikt voor klant en leverancier, passend bij wet- en regelgeving van de klant, 2)Code of conduct voor data privacy, 3) ontwikkelingen van volwassen assurance die past bij Cloudtechnieken en Clouddiensten. Deze Assurance verklaringen moeten passen bij de afgesproken verplichtingen in contracten en SLA’s en moeten aangetoond kunnen worden, 4) richtlijnen op landniveau, 5) ontwikkeling van volgende generatie certificaten die data kan volgen ten behoeve van locatie
1 april 2014
43
Versie 1.0
van opslag, toegang en bewerking en 6) het ontwikkelen van een volwassen en evenwichtige relatie tussen klant en leverancier, met voldoende kennis aan beide kanten, vanuit hun eigen (eind)verantwoordelijkheden. 5.3. Analyse case study
Uit de case study komen in de voorgaande paragraaf een aantal overeenkomsten en verschillen naar voren. De analyse van de case study heb ik hieronder ingevuld onder de verschillende deelvragen. Per deelvraag vergelijk ik deze uitkomsten van de deelvragen met de beantwoording van de deelvragen op basis van de theorie van hoofdstuk 4. Overeenkomsten en verschillen tussen theorie en praktijk maak ik daarmee duidelijk. Deelvraag 1. Welke huidige normenkaders worden er gebruikt voor het verlenen van assurance, en in hoeverre zijn deze geschikt voor het afgeven van assurance voor cloud computing? (beschrijvend) Assurance voor Cloud computing wordt door Atos verstrekt op basis van de ISAE3402 SOC1, waar nodig aangevuld met aanvullende rapportages en/of assurance verklaringen. Volgens Univé en Atos verstrekt de ISAE3402 SOC1 verklaring voldoende assurance voor Cloud computing. Aanvullende rapportages of assurance verklaringen zijn volgens Atos mogelijk op verzoek van de klant ten behoeve van het verstrekken van assurance die extra/aanvullende zekerheid geeft. EuroCloud vindt dat verschillende assurance verklaringen nodig zijn om de verschillende aspecten van Cloud techniek, service- en deploymentmodellen te kunnen belichten. De ISAE3402 verklaring is namelijk gericht op het geven van assurance op de integriteit van transacties ten behoeve van de jaarrekening en geeft geen verklaring over transactiesystemen als bijvoorbeeld een IaaS dienst volgens de directeur van EuroCloud. Ook is EuroCloud van mening het meest belangrijk voor het afgeven van assurance op Cloud computing het verstrekken van transparantie is, over de gehele keten van Cloud computing inclusief onderaannemers. De verplichtingen die door de leverancier zijn aangegaan in contracten en SLA’s moeten transparant en aantoonbaar zijn voor de klant, gedurende de uitvoering van de dienst en ten behoeve van het verstrekken van assurance. Een ideale Assurance verklaring geeft een statement af over alle onderwerpen die vastgelegd zijn in de contracten en SLA’s. Wanneer dat niet in 1 verklaring past, moet een mix van verklaringen worden verstrekt waarmee de Assurance behoefte van de klant op een redelijke en weldoordachte manier wordt afgedekt. De stelling van EuroCloud komt overeen met mijn conclusie van deelvraag 1 op basis van de theorie.
1 april 2014
44
Versie 1.0
Deelvraag 2.Waarom voldoet de huidige manier van auditen en afgeven van assurance voor IT in het tijdperk van Cloud computing niet aan de compliance eisen en de eisen/behoefte van leveranciers en de klant, en welke tekortkomingen liggen hieraan ten grondslag? (analyserend). Alle drie de partijen zijn van mening dat overeenkomst voor het afnemen van Cloud computing zou moeten worden aangegaan op basis van: - een risico analyse op basis van eisen van het proces of dienst van de klant, en op basis van dataclassificatie; - duidelijk beschreven (eind)verantwoordelijkheden van zowel de klant als de leverancier; - gedegen kennis van klant en leverancier op het gebied van Cloud computing, wet- en regelgeving, de manier waarom de klant “In control” wil en moet zijn en eisen op het gebied van databeveiligingen retentie, zodat op basis van kennis en analyse kan worden gekozen voor de benodigde verstrekking van informatie gedurende het afnemen van clouddiensten en het verstrekken van assurance voor de klant. Over de mate waarin de huidige manier van het verstrekken van assurance voor Cloud computing al dan niet voldoet zijn de geïnterviewde partijen het niet eens. Atos is van mening dat er voor databeveiliging meer aandacht is dan voorheen. Voor traditionele IT had er ook veel aandacht voor databeveiliging moeten zijn. Volgens Univé is een ISAE3402 verklaring met een aantal aanvullende informatiebeveiligingspunten van ISO voldoende voor de afgenomen dienst van de MS Office 365 suite. Volgens EuroCloud is de toegenomen aandacht voor databeveiliging en –retentie terecht, in combinatie met lokale wet- en regelgeving. Daarnaast bevat een clouddienst meerdere aspecten die niet door een ISAE3402-SOC1 verklaring alleen kunnen worden afgedekt. Daar waar bij het verstrekken van assurance geen inzicht en assurance over de gehele leveranciersketen kan worden verstrekt, voldoet volgens EuroCloud de verstrekte assurance niet. Atos en Univé laten zich hier niet over uit. Deze antwoorden zijn niet eenduidig en sluiten maar deels aan bij mijn conclusie van deelvraag 2 op basis van de theorie. Ik ben van mening dat met behulp van de doorontwikkeling van de Cloud computing evolutie deze verschillen kunnen worden opgelost. 3. Welke alternatieven kunnen worden beschreven voor het afgeven van een assurance verklaring die voldoet aan de eisen en behoeften van leveranciers en klanten? Uit de case study blijkt dat de alternatieven beschreven door zowel klant, leverancier als EuroCloud een mix zijn diverse elementen. Voorbeelden zijn: voldoende kennis , volwaardige volwassen klantleverancier relatie, realtime monitoring en –rapportage, grote rol voor Regie bij een uitbesteding naar Cloud computing, en een reeks van andere technische, organisatorische en procedurele maatregelen. Uit de case study blijkt verder dat er nog geen eenduidige mening bestaat over de mate waarin kan worden aangetoond waar data zich heeft bevonden, en wat de klant moet weten over de prestaties en assurance van onderaannemers. Hierover moet duidelijkheid worden gecreëerd door leveranciers, accountantskantoren en instituten als NEN, NIST en CSA. Het antwoord op deze deelvraag uit de case study sluit aan bij het antwoord op deze deelvraag vanuit de theorie. Naar mijn mening is het niet mogelijk om één oplossing aan te dragen om In Control te zijn voor Cloud computing, dat moet per situatie worden beoordeeld (zie hfdst. 6).
1 april 2014
45
Versie 1.0
6. Conclusie en aanbevelingen
In dit hoofdstuk geef ik een conclusie gegeven over de gestelde Centrale vraag met deelvragen op basis van het theorie onderzoek, de analyse van de NIST risico’s tegen normenkaders en standaarden en de case study die ik heb uitgevoerd. Vervolgens geef ik aanbevelingen. Situatieschets vanuit de onderzochte theorie en case study Er wordt bij Cloud computing steeds meer overgegaan tot gestandaardiseerde dienstverlening door de leverancier. Daar horen ook gestandaardiseerde rapportages en assurance verklaringen bij. Eventuele extra eisen die een klant stelt, zijn duur en tijdrovend voor de leverancier. Bovendien zijn sommige eisen die de klant stelt strijdig met de wensen van andere klanten die dezelfde dienst afnemen (vb. right tot audit). De complexiteit van de gebruikte technologieën is toegenomen bij Cloud computing. De eisen ten aanzien van het voldoen aan compliance en informatiebeveiliging worden ook steeds strenger. Deze combinatie vraagt om een volwassen, gelijkwaardige relatie tussen de klant en leverancier, en gedegen kennis bij beide partijen. De klant moet een proactieve, risico-gebaseerde houding aannemen als verantwoordelijke voor de uitbestede clouddienst. Deze houding moet niet alleen gericht zijn op bekende risico’s, maar ook “out of the box” nieuwe, onbekende, problemen. Zowel klanten als leveranciers hebben meer kennis nodig van de techniek van Cloud computing en de wijze waarop aan wet- en regelgeving moet worden voldaan. Wanneer een klant kiest voor een cloudoplossing is het belangrijker dan ooit om zelf voldoende kennis te hebben over de techniek en dienst die uitbesteed wordt. Door de complexere techniek en strengere wet- en regelgeving is het een gevaarlijke illusie om te denken dat met het uitbesteden van de dienst ook de problemen verdwijnen. Daarnaast houdt de klant bij het uitbesteden van een dienst de eindverantwoordelijkheid, en moet deze ook zelf “In Control” blijven over de wijze van uitvoering van de dienst en de mate waarin assurance kan worden verleend. Bij voorkeur met behulp van realtime inzicht en rapportages. 6.1. Conclusie
De doelstelling van het onderzoek is het beschrijven van een aantal alternatieven voor het afgeven van assurance voor cloud computing op een dusdanige manier dat de assurance voldoet aan de eisen en behoefte van de leveranciers en klanten van clouddiensten. Deze alternatieven kunnen voor Univé worden ingezet om assurance af te geven. Om de doelstelling van het onderzoek te kunnen bereiken is de volgende Centrale Vraag geformuleerd: “Welke tekortkomingen kent de huidige manier van assurance verlenen voor Cloud computing, welke oorzaken zijn hiervoor te benoemen en welke alternatieven zijn hiervoor te beschrijven?”
1 april 2014
46
Versie 1.0
Conclusie op de Centrale vraagstelling
Tekortkomingen assurance op Cloud computing Niet alle op dit moment gebruikte vormen van Assurance rapportage zijn geschikt voor het aantonen van de mate van beheersing van de IT-processen als gevolg van de verplichtingen over de scope van de rapportage. De ISAE-SOC1 rapportage voldoet vanwege zijn financiële scope niet volledig, een SOC2/SOC3 of ISAE3000 rapportage voldoet wel qua scope en rapportagevorm. Daarnaast is het voor een klant niet meer voldoende om achteraf een assurance rapportage te ontvangen. De behoefte aan realtime rapportage en sturing is door de Cloud computing technologie en de compliance verplichtingen toegenomen. Door actueel inzicht in de prestaties van de afgenomen dienst kan door een organisatie worden bijgestuurd waardoor meer assurance kan worden verkregen. De mate waarin momenteel aan deze realtime rapportage en sturing invulling kan worden gegeven door klanten en leveranciers voldoet nog niet. Oorzaken Een aantal op dit moment geaccepteerde risico’s zoals data locatie en data retentie, complexe techniek en virtualisatie die nog niet (voldoende) kunnen worden aangetoond omdat ze niet in de beoordeelde normenkaders van ATOS, KPMG, OpenStack en CSA zijn opgenomen. Daarnaast is het technisch niet mogelijk om deze punten voldoende aan te tonen. Deze risico’s moeten daarom expliciet buiten scope van de audit en audit rapportage worden gehouden. Ook is het op basis van standaard rapportages nog niet voldoende mogelijk om een deepdive te maken naar de prestaties van onderaannemers. De vraag of het voor de uitbestedende partij wettelijk verplicht is om van de prestaties van onderaannemers kennis te hebben, is nog niet voldoende te beantwoorden. Alternatieven voor het verstrekken van assurance Het is niet mogelijk om alternatieven te beschrijven voor het verstrekken van assurance als gevolg van de complexiteit van de Cloud computing techniek en het ontbreken van technologie om de locatie van data, dataretentie en de uitvoering van deze complexe techniek aan te tonen. Het verstrekken van alternatieven is echter ook niet nodig. Voor op dit moment kan aandacht te besteden aan onderstaande punten de tekortkomingen in Assurance verklaringen voorlopig worden opgevangen. Daarom kunnen alternatieven pas worden ontwikkeld wanneer meer fundamenteler onderzoeken naar solide Cloud cumputing oplossingen is uitgevoerd Het is daadwerkelijk mogelijk om assurance over Cloud computing te verstrekken door: 1. het aanscherpen van normenkaders en standaarden; 2. het bewust toepassen van (SOC) formats van assurance en 3. het volgen van een stappenplan om te komen tot een volwassen leveranciers- en klantorganisatie. Onderdeel van dit stappenplan is het verkrijgen van realtime inzicht en het vergroten van de assurance door realtime en tijdige bijsturing door de betrokken organisaties.
1 april 2014
47
Versie 1.0
Onderbouwing van de conclusie Deelvraag 1. Welke huidige normenkaders worden er gebruikt voor het verlenen van assurance, en in hoeverre zijn deze geschikt voor het afgeven van assurance voor cloud computing? ISAE-3402/SOC1 De assurance die wordt verstrekt door een ISAE3402/SOC 1 verklaring voldoet niet voor Cloud computing. Oorzaak hiervoor is de scoping van de beheersmaatregelen ten behoeve van de financiële verslaglegging, en de hierbij in de SOC 1 rapportage vastgelegde kwaliteitsaspecten. De rapportagevorm dwingt af dat wanneer er geen sprake is van een op financiële verantwoording gerichte scope, de ISAE 3000 standaard moet worden gebruikt. Kwaliteitsaspecten die niet bijdragen aan de financiële verantwoording mogen niet aan het normenkader van de SOC 1 verklaring worden toegevoegd. SOC2/SOC3 en ISAE3000 De SOC2 en SOC 3 rapportage met de bijbehorende kwaliteitsaspecten voldoen wel qua vorm en kwaliteitsaspecten voor het verstrekken van assurance op Cloud computing. Als in een ISAE3000rapportage voor dezelfde kwaliteitsaspecten als die van de SOC2/SOC3 rapportage worden gekozen, voldoet deze rapportagevorm ook. Wanneer echter nader wordt ingezoomd op een geschikt normenkader dat ten grondslag ligt aan de kwaliteitsaspecten van de SOC 2/SOC 3 of ISAE3000, blijkt dat de door mij beoordeelde normenkaders niet voldoen voor het aantonen van de beheersing van de door NIST benoemde risico’s op het gebied van: - computerprestaties; - Cloud betrouwbaarheid; - economische doelen; - compliance issues en - informatiebeveiliging. Deelvraag 2. Waarom voldoet de huidige manier van auditen en afgeven van assurance voor IT in het tijdperk van Cloud computing niet aan de compliance eisen en de eisen/behoefte van leveranciers en de klant, en welke tekortkomingen liggen hieraan ten grondslag? (analyserend). Inzicht in de (leveranciers)keten Momenteel is er onvoldoende inzicht in de volledige (leveranciers)keten bij Cloud computing. Daarnaast is onvoldoende duidelijk in hoeverre het de verantwoordelijkheid van de uitbestedende klant is om dit inzicht te hebben. Het effect van de ondoorzichtige keten in combinatie met gebrek aan uniformiteit versterkt het risico cumulatief. Aantonen data locatie en –retentie, gebruik complexe techniek en virtualisatie Hoewel de onderzochte normenkaders en standaarden voor deze scriptie een gedegen basis bieden voor een control framework ten behoeve van Cloud computing, worden daarin niet alle risico’s geadresseerd of kunnen ze (nog) niet worden aangetoond. Daardoor kan er op dit moment geen volledige assurance worden verstrekt voor Cloud computing, als gevolg van de veranderde eisen door het gebruik van de Cloud computing technologie.
1 april 2014
48
Versie 1.0
Verschuiving van inzicht achteraf naar realtime inzicht Het is voor een klant niet meer voldoende om achteraf een assurance rapportage te ontvangen. De behoefte aan realtime rapportage en sturing is door de Cloud computing technologie en de compliance verplichtingen toegenomen. Door actueel inzicht in de prestaties van de afgenomen dienst kan door een organisatie worden bijgestuurd waardoor meer assurance kan worden verkregen. De mate waarin momenteel aan deze realtime rapportage en sturing invulling kan worden gegeven door klanten en leveranciers voldoet nog niet. Onder andere doordat: *de rapportages onvoldoende inzicht geven in prestaties van onderaannemers; *de rapportages nog geen inzicht geven in alle belangrijke issues zoals datalocatie en –retentie, inzicht in de werking van de complexe Cloud computing techniek etc.; * de klanten de uitkomsten van rapportages begrijpen en kunnen vertalen naar hun organisatie, risico’s en te nemen maatregelen ter bijsturing. 3. Welke alternatieven kunnen worden beschreven voor het afgeven van een assurance verklaring die voldoet aan de eisen en behoeften van leveranciers en klanten? De mogelijkheid tot het uitvoeren van een assurance opdracht voor cloudcomputing Of een assurance opdracht kan worden uitgevoerd hangt als laatste af van de mate waarin een aantal aspecten kunnen worden afgesproken met de leverancier en vervolgens kunnen worden aangetoond: * de locatie van data, toegang tot data, archivering van- en verwijdering van data ; * maatregelen ter beperking van het risico’s bij het gebruik van beheerwachtwoorden en de hypervisor; * de manier waarop virtual security appliances worden ingezet en of ze worden gebruikt voor monitoring, sturing en verbetering van security; * gebruik van keymanagement en gebruik van cryptografie bij het verzenden van informatie via internet; * securityzorgen in het algemeen, dit betreft inzicht in de mate van informatiebeveiliging door de leverancier; *securityzorgen over mobile devices en BYOD, dit betreffen nieuwe risico’s ten aanzien van informatiebeveiliging; * hoe kan aantoonbaar worden voldaan aan lokale wet- en regelgeving (compliance); * voldoen de standaard SLA’s en de (maatwerk) assurance of moeten aanvullende afspraken worden gemaakt; * zijn de computerprestaties voldoende beheerst; * is de informatiebeveiliging ingericht op een manier die past bij de data die in de Cloud toepassing wordt opgeslagen, en is deze assessment op basis van dataclassificatie uitgevoerd; Scope en diepgang beoordeling auditobject Wanneer een assurance opdracht moet worden uitgevoerd moet ook in het geval van een uitbestede dienst zoals Cloud computing het object van onderzoek en de reikwijdte van de opdracht heel duidelijk worden vastgesteld en afgebakend. De werking van de hierboven genoemde technische risico’s kan momenteel niet of niet eenvoudig worden bepaald. Daardoor moet goed worden overwogen wat de scope en objecten van de opdracht zijn. Of en de mate waarin er mogelijk aanvullend onderzoek nodig is, is afhankelijk van het afgenomen service- en delivery model. Op basis 1 april 2014
49
Versie 1.0
van een risico analyse worden de voor het specifieke gekozen Cloud computing model alle risico’s in kaart gebracht door de klant. Alleen door bestudering van het onderliggende normenkader kan worden bepaald of de kwaliteitsaspecten en het normenkader van de door de leverancier afgegeven assurance verklaring voldoende de in de risico analyse benoemde risico’s raakt en voldoende mitigerende maatregelen zijn getroffen. De waarde van de assurance verklaring wordt onder andere bepaald door: * de mate waarin klant en leverancier “In Control” zijn; * het normenkader dat aan de verklaring ten grondslag ligt; * uniformiteit van gebruik van diensten, services, control frameworks en SLA rapportages door de gehele (leveranciers)keten, en * de kwaliteit van het auditteam en de kennis van de lezer. Ten behoeve van de (realtime)informatieverstrekking aan de klant moet de leverancier nieuwegeneratie technologie inzetten om aan te tonen dat wordt voldaan aan de contractuele verplichtingen (o.a. data locatie en –retentie, voldoen aan informatiebeveiligingsbeleid en wet en regelgeving). Er zijn verschillende opties mogelijk om te komen tot assurance op een beheerste Cloud computing omgeving: 1. Verstrekken van standaard assurance rapportage door de leverancier die voor alle door de klant gewenste kwaliteitsaspecten en normen assurance verstrekt. Hierbij moet de gewenste scope in acht genomen worden die passend is bij de behoefte van de klant en geschikt is voor de rapportagevorm. Een ISAE3402/SOC1 voor beheersmaatregelen die een relatie hebben met de financiële verslaglegging van de uitbestedende organisatie, een SOC2/SOC3 rapportage voor de beheersing van IT-gerelateerde processen van de leverancier inclusief onderaannemers, en een ISAE3000 rapportage voor overige beheersingsvraagstukken. 2. a. Verstrekken van standaard assurance rapportage verstrekt die voor een deel van de door de klant gewenste kwaliteitsaspecten en normen assurance verstrekt (ook hier passend bij de scope). b. Voor het overige deel van de door de klant gewenste kwaliteitsaspecten worden aanvullende werkzaamheden uitgevoerd door een auditor ingehuurd door de leverancier of klant. Het onderzoek wordt gebaseerd op gebaseerd op een door de klant en leverancier opgestelde risico analyse. Het resultaat van dit onderzoek is een assurance rapportage (met redelijke of beperkte mate van zekerheid) of een rapport van bevindingen. 3. a. Verstrekken van standaard assurance rapportage die voor een deel van de door de klant gewenste kwaliteitsaspecten en normen assurance verstrekt. b. Voor het overige deel van de door de klant gewenste kwaliteitsaspecten wordt gesteund op de werkzaamheden die door de leverancier in het kader van het In Control Systeem worden uitgevoerd, en waar over wordt gerapporteerd. c. Indien nodig kan de klant een audit uit laten voeren op de opzet en werking van het “In Controlproces” om over de betrouwbaarheid en kwaliteit van dit In Control Systeem aanvullende zekerheid te krijgen. Ook in dit geval moet de klant zelf op basis van een risico analyse vaststellen of de benoemde risico’s voldoende worden bewaakt en aangetoond met behulp van het In Control Systeem. 4. a. Verstrekken van standaard assurance rapportage die voor (een deel van) de door de klant gewenste kwaliteitsaspecten en normen assurance verstrekt. b. Daarnaast monitort de klant zelf mee of participeert de klant in een Security Operating Center 1 april 2014
50
Versie 1.0
(SOC) waardoor de klant realtime inzicht heeft in de mate van beheersing door de leverancier. Op basis van deze participatie en SLA/ICS rapportages heeft de klant een zeer volledig inzicht in de mate van beheersing van de door de klant als relevant bevonden kwaliteitsaspecten. 6.2. Aanbevolen stappenplan voor Cloud computing Om de Centrale vraag te kunnen beantwoorden zijn in de scriptie vanuit verschillende invalshoeken bronnen onderzocht en mensen geïnterviewd zodat kan worden bepaald welke tekortkomingen, oorzaken en alternatieven er kunnen worden benoemd. Uit het onderzoek is een reeks van (ontbrekende) maatregelen naar voren gekomen. Deze bevinden zich op verschillende niveaus van de klant- en leveranciersorganisatie, en zullen hieronder worden behandeld. Wanneer wordt overwogen om data en/of een informatiesysteem onder te brengen “in de Cloud” wordt op basis van het uitgevoerde onderzoek geadviseerd aan de volgende onderwerpen aandacht te besteden, om daarmee een Wanneer wordt overwogen om data en/of een informatiesysteem onder te brengen “in de Cloud” wordt op basis van het uitgevoerde onderzoek geadviseerd aan de onderstaande onderwerpen aandacht te besteden. Zowel voor de klant als de leverancier zou er voldoende aandacht voor deze onderwerpen moeten zijn, om op deze manier een gelijkwaardige en volwassen relatie te kunnen aangaan. Stap 1. Beschrijven van Corporate en IT Governance De voorgaande hoofstukken hebben aangetoond dat door de complexe techniek van Cloud computing en de afname van een dienst waarbij een deel van de controle uit handen wordt gegeven, het des te belangrijker is om als organisatie “In Control” te zijn ten behoeve van de verstrekte en ontvangen dienst. Kwaliteit en het constant verbeteren van processen moet niet “erbij” worden gedaan maar moet deel van het proces zijn. Het is een basisvoorwaarde voor het kunnen invullen van proceseigenaarschap op een volwassen manier. Het is echter zaak om niet alleen bottum-up “In control” te zijn maar ook vanuit strategisch niveau. Dat kan worden bereikt door de inrichting van Corporate Governance en IT Governance (zie verder paragraaf 2.2 voor de motivatie hiervoor). Stap 2. Vaststellen en onderhouden van data classificatie Dataclassificatie is een basisvoorwaarde voor het risico gebaseerd aangaan van een uitbesteding voor het beheer van data. Bij Cloud computing heeft de klant de grootste zorgen over de locatie en retentie van data, en de wijze waarop toegangsbeheer is geregeld. De analyse van hoofdstuk 4 wijst uit dat de locatie van data en de beveiliging van data niet alleen risico’s zijn die door NIST worden geadresseerd, maar ook nog niet in voldoende mate door de onderzochte standaard en frameworks worden ondersteund. Op basis van de dataclassificatie kan worden bepaald welke risico’s worden gelopen bij het afnemen van een clouddienst, en of deze risico’s in voldoende mate te mitigeren zijn. Ook kan de classificatie inzichtelijk maken welke afspraken moeten worden gemaakt over: * welke partij welke verantwoordelijkheden moet dragen; * de mate waarin continuous monitoring en –auditing kunnen en/of moeten worden ingezet; * het gebruik van een Security Operations Center (SOC) en * de wijze waarop actieve Regie en SLA management moet worden ingericht bij klant en leverancier.
1 april 2014
51
Versie 1.0
Opmerking [w1]: Dit ben je vergeten weg te halen. Zie zin eronder.
Dataclassificatie en –eigenaarschap zijn een belangrijk fundament voor het beheerst kunnen aangaan van een Cloud computing-overeenkomst. Stap 3. Risk based analyse van de mogelijke uitbesteding Wanneer wordt overwogen om (een deel van) de IT uit te besteden moet er een riskbased analyse worden uitgevoerd door de klant. Deze analyse kan bijvoorbeeld op basis van de Enterprise Risk Management Model (ERM) van COSO. De volgende stappen moeten worden doorlopen: a. voer een workshop uit waarbij alle mogelijke dreigingen en risico’s worden benoemd; b. genereer een risicomatrix op basis van stap a; c. selecteer op basis van de risicomatrix potentieel geschikte leveranciers met een volwassen (GRC) organisatie; d. selecteer op basis van de geschikte leverancier passende Cloud service- en deployment modellen voor alleen dié applicaties die in een Cloud omgeving kunnen draaien; e. kies een leverancier en het af te nemen service- en deploymentmodel; f. bepaal op basis van de controls framework van de leverancier welke de risico’s in de opgestelde risicomatrix afdekken, en voorzie ze van een weging. Wanneer de leverancier niet (voldoende) de risico’s af kan dekken, moet de leveranciersselectie opnieuw worden gestart; g. evalueer samen met de leverancier de control selectie en spreek samen af welke controls geïmplementeerd moeten worden. Dat wordt vastgelegd in contracten en SLA’s; h. het resultaat is een Cloud beveiligings Baseline waarmee de beveiligingsmaatregelen worden beschreven die moeten worden geïmplementeerd bij de leverancier. Stap 4. Inrichten Technische, Organisatorische en Procedurele (TOP) maatregelen Samengevat kan worden gesteld dat bij stap 3. er een serie van technische, organisatorische en procedurele (TOP) maatregelen zijn beoordeeld voor een klant voor Cloud computing kiest, zowel maatregelen van de leverancier als de klant. Wanneer eenmaal is gekozen voor Cloud computing moet deze reeks van TOP maatregelen worden afgesproken, vastgelegd en bewaakt tussen de klant en de leverancier. Over deze maatregelen moet realtime of in ieder geval met een hoge frequentie worden gerapporteerd. Stap 5. Inrichten realtime rapportages op basis van geautomatiseerde SLA rapportages Het verkrijgen van assurance op clouddiensten moet in de toekomst worden gezocht in het frequent verkrijgen van kwalitatief goede en frequente rapportage. De klant kan de rapportage op operationeel en tactisch niveau gebruiken om bij te sturen. Tijdige sturing geeft extra assurance op de uitgevoerde clouddienst en draagt bij aan het behalen van een level of trust voor de klant. Wanneer er een audit op het proces van de “In Control” rapportage wordt uitgevoerd zou dit voldoende moeten zijn om de kwaliteit van de output te kunnen waarborgen. In tegenstelling tot gegevensbeoordeling ten behoeve van een assurance verklaring die achteraf plaats vindt, kan een systeembeoordeling ook ingezet worden met een voorspellende waarde. Immers, wanneer er geen aanpassingen in het proces plaatsvinden en er voldoende mitigerende maatregelen “in place” zijn in het proces is ook voor de toekomst de kwaliteit van de output van het proces te voorspellen. De processen die in een “In Control” systeem worden geraakt moeten minimaal overeenstemmen met de control activities van de ISAE3402 te weten fysieke toegang, omgevingcontrols, IT 1 april 2014
52
Versie 1.0
infrastructuur changemanagement, incident- & problemmanagement en capaciteitsmanagement. Aanvullend kunnen in de “In Control”-rapportage alle normen worden opgenomen die nodig zijn om alle kwaliteitsaspecten die van belang zijn bij Cloud computing, te kunnen toetsen en aantonen, gestoeld op de uitgevoerde risico analyse van stap 3 en 4.
1 april 2014
53
Versie 1.0
7. Slotwoord
Cloud computing is qua techniek, uitnuttingsmogelijkheden én verschaffen van assurance nog in ontwikkeling. Uit de scriptie zijn drie belangrijke onderwerpen te filteren die in een vervolgonderzoek kunnen worden opgepakt: 1. Kunnen aantonen van de data locatie Het eerste onderwerp is de wijze waarop de locatie van data en de werking van de ingerichte informatiebeveiliging beter kan worden aangetoond. Mogelijkheden zijn tooling die per dataelement de locatie van het element kan vastleggen en vervolgens beoordelen of er een schending plaats heeft gevonden ten opzichte van de voor het element afgesproken locatie. Een andere benadering is een continue bewaking van de zone waarin data mag worden opgeslagen, de ingerichte informatie- en logische toegangsbeveiliging en alle changes hierop. Ook dan kan worden aangetoond of data zich binnen de zone heeft bevonden of niet, en of aan de afgesproken informatie- en logische toegangsbeveiliging is voldaan. 2. Kennis van prestaties van onderaannemers De mate waarin een klant op de hoogte moet zijn van de prestaties van de onderaannemers en de mate waarin voor deze bedrijven assurance kan worden verstrekt, is nog steeds niet volkomen duidelijk. Nader onderzoek naar wet- en regelgeving hierover is eens te meer voor Cloud computing van belang omdat door de complexe techniek en wet- en regelgeving duidelijkheid moet worden verschaft over wettelijke verplichtingen hieromtrent. 3. Opstellen van een Cloud computing Assurance kubus De combinatie van het gekozen servicemodel (IaaS, Paas of Saas) en deploymentmodel (private, community, public of hybrid) zorgt voor specifieke technische aandachtspunten en risico’s, en verschillende controls die moeten worden ingezet. Momenteel hebben veel bedrijven en instellingen normenkaders opgesteld waarmee een mate van Control kan worden bereikt over Cloud computing. Een onderzoek waarbij de verschillende normenkaders worden geanalyseerd op hun toegespitste toegevoegde waarde voor een specifieke combinatie van een service- en deployment model kan klanten en leveranciers ondersteunen in het kiezen van de juiste controls voor de afgenomen dienst.
Figuur 8 Voorbeeld Cloud computing Assurance kubus
1 april 2014
54
Versie 1.0
Bijlage 1 Assurance voor IT hosting en IT-outsourcing Om te kunnen bepalen welke normenkaders voor het geven van assurance op IT hosting geschikt zijn, is kennis van de onderstaande definities rondom het afgeven van assurance van belang. Definities “Een "assurance-opdracht" is een opdracht waarbij een accountant een conclusie formuleert die is bedoeld om het vertrouwen van de beoogde gebruikers, niet zijnde de verantwoordelijke partij, in de uitkomst van de evaluatie van of de toetsing van het object van onderzoek ten opzichte van de criteria, te versterken.” (NIVRA, z.j) Wanneer een assurance verklaring wordt afgegeven, moet bij het aannemen van de opdracht duidelijk zijn welke mate van assurance wordt afgegeven; een redelijke of beperkte mate van zekerheid. Immers, op grond van het Stramien van de NIVRA mogen er twee soorten van assuranceopdrachten door een accountant* worden uitgevoerd: de assurance-opdracht tot het verkrijgen van een redelijke mate van zekerheid en de assurance-opdracht tot het verkrijgen van een beperkte mate van zekerheid. *lees: auditor Het verschil in de mate van zekerheid komt tot uiting in de doelstelling van de opdracht en de formulering van de conclusie van de opdracht. Het NIVRA formuleert dit in het Stramien voor Assuranceopdrachten als volgt: “De doelstelling van een assurance-opdracht tot het verkrijgen van een redelijke mate van zekerheid is het reduceren van het opdrachtrisico tot een aanvaardbaar laag niveau rekening houdend met de omstandigheden van de opdracht als basis voor een positief geformuleerde conclusie van de accountant. De doelstelling van een assurance-opdracht tot het verkrijgen van een beperkte mate van zekerheid is het reduceren van het opdrachtrisico tot een niveau dat aanvaardbaar is rekening houdend met de omstandigheden van de opdracht, maar waarbij het risico hoger is dan voor een opdracht tot het verkrijgen van een redelijke mate van zekerheid, als basis voor een negatief geformuleerde conclusie van de accountant.” Er zijn 5 elementen in de omschrijving van een Assurance opdracht, waaraan deze opdracht moet voldoen (Fijneman, Roos Lindgreen & Veltman, 2005): •
•
Het tripartietemodel. Dit model bestaat uit een auditor, een verantwoordelijke partij en een beoogde gebruiker. De auditor auditeert een verantwoordelijke partij (die al dan niet verantwoording aflegt) en rapporteert op basis van de audit aan een beoogde, belanghebbende gebruiker. Het object van onderzoek. Bij een IT-audit is het object van onderzoek een product, proces of combinatie hiervan. Het product kan de applicatie zijn, het proces het stelsel van beheersmaatregelen (application controles) rondom de applicatie. De application controls bestaand uit geprogrammeerde controls in de applicatie en gebruikerscontroles er omheen. Daarmee wordt de mens als uitvoerder van beheersmaatregelen en gebruikerscontroles object van onderzoek. Een object kan worden onderzoek naar ontwerp (‘opzet’) een moment in de tijd (‘bestaan’) of een periode in de tijd (‘werking’). De auditor mag vanuit het uitgangspunt van onpartijdigheid alleen objecten onderzoeken waar hij/zij zelf géén (mede)verantwoordelijkheid draagt.
1 april 2014
55
Versie 1.0
•
•
•
Toetsings- of evaluatiecriteria. Voor deze criteria worden verschillende woorden gebruikt als eisen, standaarden, normen- of toetsingskaders of (control) objectives. Die laatste worden beschreven als “de doelstellingen die met het onderzoeksobject, zoals een stelsel van interne beheersingsmaatregelen, moeten worden bereikt”. Proces van aanvaarding en uitvoering van een opdracht. Het uitvoeren van de opdracht begint met het overeenkomen van opdrachtvoorwaarden, waarbij deze tegemoet moet komen aan de behoeften van de beoogde gebruiker van de opdracht. De verantwoordelijke partij moet bereid zijn medewerking te verlenen, waardoor hoor en wederhoor van toepassing is. De auditor bepaalt welke werkzaamheden nodig zijn om een conclusie te kunnen onderbouwen. Formuleren van conclusie (oordeel) met een bepaalde mate van zekerheid. Op basis van de vooraf overeengekomen mate van zekerheid die wordt afgegeven, wordt de conclusie op een negatieve (beperkte mate van zekerheid) danwel positieve manier (redelijke mate van zekerheid) afgegeven. Het is voor een auditor eenvoudiger om over opzet en bestaan een redelijke mate van zekerheid af te geven, dan over de werking.
Bij het uitvoeren van de opdracht is de auditor gehouden aan de grondslagen van de Code of Ethics voor IT-auditors van NOREA, te weten integriteit, objectiviteit, deskundigheid en zorgvuldigheid, geheimhouding en professioneel gedrag. De assurance-opdracht en de uitvoering hiervan dienen te voldoen aan het de richtlijnen uit het raamwerk “Raamwerk voor assurance-opdrachten door ITAuditors”. Een Assurance rapport moet voldoen aan de richtlijn van NIVRA. Er is naast het geven van een redelijke of beperkte mate van zekerheid t.b.v. assurance, nog een indeling te maken. Deze is meer historisch van aard: • •
•
•
Assurance is van oudsher met name rulebased, en er wordt gecontroleerd of is voldaan aan compliance en wet- & regelgeving. Tegenwoordig is de basis voor het afgeven van assurance meer gedreven vanuit riskmanagement. De aard van de Assurance werkzaamheden zijn dan meer regievoerend van aard, waarbij wordt getoetst of de mate van beheersing van de risico’s en toegepaste maatregelen, voldoende is. Dit betekent ook dat de organisatie die wordt getoetst meer zelf “In control” moet zijn. Er wordt dat immers getoetst of de door de organisatie aangebrachte beheersingsmaatregelen “in place” zijn en voldoende het risico mitigeren. De werkzaamheden zijn meer principlebased en de assurance bevat een advieselement. Een derde en opkomende vorm van assurance is gericht op vendormanagement. Hierbij wordt een potentiële leverancier gescreend zodat kan worden bepaald of deze leverancier voldoet aan de eisen van de klant vóór wordt overgegaan tot een contractuele verbintenis. De advisorytak van de beroepsgroep IT-auditing is ook steeds meer in opkomst. Dit heeft deels te maken met de terugloop in assurance werkzaamheden. Daarnaast geeft de klant ook steeds meer aan niet genoeg te hebben aan een Assurance verklaring achteraf. De behoefte om op dagelijkse basis “In control” te zijn, en op de hoogte van de kwaliteit van geleverde prestaties wordt steeds groter. Deze behoefte wordt aangevuld met een adviesfunctie op boardroom-niveau. De adviezen die daar worden gegeven kijken niet terug maar geven, gebaseerd op getoetste prestaties, advies ter verbetering en verandering. Het advies is dan niet alleen inhoudelijk maar waar nodig ook gericht op verandermanagement.
1 april 2014
56
Versie 1.0
Bijlage 2
Vergelijking tussen de NIST risico’s en andere bronnen
In deze bijlage is een korte letterlijke vertaling gemaakt van deze open issues zoals deze door NIST zijn beschreven. Daar waar nodig is deze letterlijke vertaling aangevuld met een noot van de auteur. Per risico wordt aangegeven of het een risico is dat zich volgens de auteur alleen bij Cloud computing voordoet of niet. Vervolgens wordt per risico geanalyseerd of het risico door CC en ATOS worden onderschreven. Er is gekozen voor deze verschillende bronnen omdat ze een beeld geven vanuit verschillende perspectieven. (externe auditor en leverancier). Er is geen (toonaangevende) input vanuit het klantperspectief gepubliceerd op dit gebied, daarom ontbreekt deze in de vergelijking. Beoordeling openstaande risico’s Cloud computing benoemd door NIST In onderstaande tabel worden de door NIST beschreven (openstaande) risico’s voor Cloud computing gecontroleerd in een aantal documenten, standaarden en normenkaders zoals beschreven in de stappen hierboven: Worden de risico’s in deze documenten benoemd of niet? Gekozen is voor drie iconen ter beoordeling: - betekent dat het risico volledig wordt benoemd; - betekent dat het risico deels wordt benoemd en - betekent dat het risico niet wordt benoemd. Computerprestaties: Cloud computing zorgt voor performanceproblemen die niet noodzakelijk anders zijn dan performance issues bij andere vormen van gedistribueerde gegevensverwerking. Ze zijn echter wel de moeite waard om hier te noemen. Latency: de tijdvertraging die een systeem ervaart bij de verwerking van een aanvraag. Latency ervaren door cloudgebruikers omvat meestal ten minste één Internet round-trip tijd, dat wil zeggen, de tijd die nodig is voor een requestbericht om te reizen naar een leverancier plus de tijd die het duurt voor het antwoordbericht te worden ontvangen door een klant. Cloudspecifiek probleem? In geval van Cloud computing altijd, in geval van outsourcing alleen bij gebruik internetverbinding. Dat is dus bijna altijd het geval bij de huidige staat van offshoring van gesourcete diensten. Risico onderschreven door…. CC: ACSCF: Niet expliciet maar kan passen bij o.a. Niet expliciet maar kan passen bij o.a. controls CC-MULTI-01 en CC-OUTS-06. A.03.7.3 Dit vraagt echter om kennis bij de klant om dit punt specifiek te adresseren. Ondersteund door standaard of OpenStack: CSA CMM/ CAI: CSA Security Guide: met normenkader te auditen? Hoofdstuk Object Storage. Niet benoemd Domain 8 “Latency is well managed”. Offline data synchronisatie: Toegang tot documenten opgeslagen in de cloud wanneer een klant geen netwerktoegang heeft, en de bijbehorende synchronisatie van documenten en procesdata Cloudspecifiek probleem? Nee, of het nu gaat om een internetverbinding als toegangspoort of een intern netwerk, of een combinatie van beide, in alle gevallen zorgt het uitvallen van de verbinding die toegang geeft tot de data voor problemen. In alle gevallen zou er tijdens het ontwerp nagedacht moeten worden over mogelijkheden tot offline werken en bijbehorende mogelijkheden tot synchronisatie van documenten en procesdata. Risico onderschreven door…. CC: ACSCF: Niet benoemd. A.03.2.4 Met normenkader te auditen? OpenStack: CSA CMM/ CAI: CSA Security Guide: Niet Niet benoemd. Niet benoemd benoemd Schaalbare programmering: De mogelijkheid om flexibel te up- en downscalen vraagt om nieuwe computermodellen zoals gridcomputing en parallel processing, zodat de nieuwe technologie optimaal voordeel kan bieden. Cloudspecifiek probleem? Ja. Gridcomputing is het aan elkaar koppelen van computers om ze samen te laten werken. Parallel processing is het gebruik
1 april 2014
57
Versie 1.0
van meer dan één CPU of processor om een programma of een berekening uit te voeren. Door de inzet van virtualisatie zijn dit veel belangrijkere issues bij Cloud computing dan in de traditionele vormen van IT. Applicaties moeten naar verwachting herontworpen worden om de volledige voordelen van deze vormen optimale te kunnen benutten. Risico onderschreven door…. CC: ACSCF: De controls en risico’s zijn niet Norm A.03.7.3 gaat wel in op het voldoen gedetailleerd genoeg beschreven om aan de gestelde eisen van dit punt te kunnen beoordelen. systeemperformance. De control is echter niet gedetailleerd genoeg beschreven om dit punt te kunnen beoordelen. Ondersteund door standaard of OpenStack: CSA CMM/ CAI: CSA Security Guide: Niet met normenkader te auditen? Gridcomputing: Hoofdstuk 3 Niet benoemd benoemd Image Service en Hoofdstuk 4 Networking Parallel processing: Niet geadresseerd, alleen parallelle opslag in hoofdstuk 7 Data-opslag management: 1. Up- en downscalen van opslagcapaciteit; 2. Kennen en beperken van de fysieke toegang van de opgeslagen data 3. Controleren hoe data is gewist 4. Toegang tot het beschreven proces van veilig weggooien van dataopslag-hardware Toepassen van (logische) toegangscontrole van data wanneer data wordt gehost door een externe partij Cloudspecifiek probleem? Ja. Door het gebruik van virtualisatie van apparatuur en netwerken is de locatie van data niet altijd bekend en goed zichtbaar. Daarnaast kan data ogenschijnlijk zijn gewist maar kan dit in de praktijk toch niet het geval zijn (zie onder andere de punten van trustchains en snapshots, dat zijn de onderste punten van de tabel). Risico onderschreven door…. CC: ACSCF: CC-OUTS-12, CC-OUTS-17, CC-OUTS-19, Oa A.03.2.4, A.03.2.5, A.03.3.5, AS.03.5.18 en CC-OUTS-20 en CC-OUTS21. AS.03.5.19 Ondersteund door standaard of OpenStack: CSA CMM/ CAI: CSA Security Guide: met normenkader te auditen? In Hoofdstuk 6 Object In IS-18, IS-19, DG-04 en 3.3.4.3 Dynamic and Storage worden deze punten DG-05. Shared Storage, 5.4 The geadresseerd. Data Security Lifecycle en 5.6.4 Data loss prevention. Cloud betrouwbaarheid: Betrouwbaarheid verwijst naar de kans dat een systeem binnen de grenzen van een gespecificeerde omgeving voor een bepaalde periode foutvrij werkt. Voor de cloud is betrouwbaarheid een functie van vier componenten, te weten: 1) hardwareen softwarefaciliteiten van de leverancier(s), 2) personeel van de leverancier(s), 3) connectiviteit met de afgenomen diensten en 4) personeel van de afnemer van de clouddienst. Noot van de auteur: NIST benoemt de hard- en software van de klant niet als een component. Netwerk afhankelijkheid: De afhankelijkheid van internet-connectivity. Dit wordt bemoeilijkt door zones met dekkingsbeperkingen (denk aan metro, vliegtuig of afgelegen locaties) en door de cryptografie-eisen die aan de verzending van data wordt gesteld als het internet wordt gebruik voor toegang tot Cloud computing. Cloudspecifiek probleem? Voor Cloud computing en outsourcete toepassingen altijd, tenzij in het laatste geval gebruik wordt gemaakt van een vaste verbinding/huurlijn. Dit is echter een verouderd principe, de kans is vele malen groter dat een outsourced toepassing via internet of een VPN verbinding benaderd wordt. In geval van hosting alleen wanneer via “thuiswerken” toegang wordt gezocht tot het eigen netwerk. Risico onderschreven door…. CC: ACSCF: O.a. in CC-OUTS-22 en CC-OUTS-23 Wordt niet benoemd, alleen de wijze van toegang tot netwerkomgevingen Ondersteund door standaard of OpenStack: CSA CMM/ CAI: CSA Security Guide: 6.3.1 met normenkader te auditen? Wordt niet benoemd. Wordt niet benoemd. Interoperability Recommendations; onderdeel Frameworks. Cloudleverancier uitval Ondanks de in SLA afspraken en clausules afgesproken beschikbaarheidsmogelijkheden is het mogelijk dat een service of apparaat uitvalt als gevolg van menselijk handelen of door de natuur (overstroming, tornado, etc.) De afnemer van een clouddienst moet zich hierbij afvragen: * Welke frequentie en duur van uitval kan de afnemer tolereren zonder impact op hun business processen? * Wat zijn de (veerkrachtige) alternatieven die een afnemer heeft voor onvoorziene situaties waarbij langdurige uitval van
1 april 2014
58
Versie 1.0
toepassing is? Cloudspecifiek probleem? Deels. Ook in het geval van een outsourced dienst of gehoste dienst moet er in opzet riskbased worden nagedacht over dit business continuity probleem en moeten hier mitigerende maatregelen voor worden bedacht en uitgevoerd. In de praktijk is dit ook voor iedere gehoste of outsourced dienst niet altijd even goed geregeld, of is er geen eenvoudig/snel/goedkoop alternatief bij een afnemer voorhanden. In een traditionele outsourcing is de outsourcer transparant is wat betreft de derde partijen. Bij een cloudleverancier kan een heel netwerk aan derde en vierde partijen betrokken zijn. Zie ook de opkomst van cloud orchestration services partners. Hierdoor is de transparantie van de dienst zodanig beperkt dat geen goede inschatting gemaakt kan worden van de risico’s op beschikbaarheid van de dienst. Risico onderschreven door…. CC: ACSCF: O.a. in CC-OUTS-22 en CC-OUTS-23 A.03.2.4, A0.3.7.3, A.03.7.4, A.03.8.5, AS.3.10.1, AS.3.10.2 AS.3.10.4 en A.05.6.1 Ondersteund door standaard of OpenStack: n.v.t. CSA CMM/ CAI: CSA Security guide: met normenkader te auditen? Dit zijn afspraken over een In OP-04, RI-05, RS-01, domain 7 totale dienst en niet per RS-03 en RS-04. traditional security, soort dienst. Er zijn wel een business continuity, & te nemen stappen en disaster recovery inrichtings-keuzes beschreven in geval van shutdown van het systeem in hoofdstuk 2: Compute. Deze raken echter niet het beschreven NIST risico. Safety-critical processing Veiligheidskritieke systemen (vb systemen voor luchtvaart, kerncentrales, etc) worden doorgaans gereguleerd door overheidsinstanties. Voorbeelden zijn systemen voor nucleair materiaal, luchtvaart of medische apparatuur. Het zijn systemen die een inherent risico hebben voor potentieel verlies van leven en eigendommen. De regelgeving (door NIST ‘pedigree’ genaamd) waarmee de systemen worden beheerst vanuit de overheid zijn in een cloudomgeving niet goed te beoordelen. Het is daarom niet aan te bevelen om deze systemen in een cloud-productie omgeving te servicen. Ontwikkelen en testen van veiligheidskritieke omgevingen in de cloud kan wel worden overwogen. Cloudspecifiek probleem? Deels. Hoewel Cloud computing als gevolg van het gebruik van het technische principe van virtualisatie minder zichtbaar is voor de afnemer, en er daardoor niet altijd (voldoende) zichtbaar is of is voldaan aan de regelgeving, geldt dit ook voor outsourcete toepassingen. In beide gevallen zal er in meer of mindere mate gebruik worden gemaakt van onderaannemers voor het uitvoeren van een onderdeel van de geleverde dienst. Dat bemoeilijkt de zichtbaarheid van het voldoen aan regelgeving. In het geval van een outsourcete dienst is het aantal onderaannemers vaak wel minder groot dan bij een clouddienst. Risico onderschreven door…. CC: n.v.t. ACSCF: De controls zijn geschreven voor de Zit impliciet in A.03.2.2, maar vraagt kennis situatie waarin al voor clouddiensten het nemen van verantwoordelijkheden productie-omgeving is gekozen. van klant en leverancier. Ondersteund door standaard of OpenStack: n.v.t.. CSA CMM/ CAI: n.v.t.. CSA Security Guide: The met normenkader te auditen? De standaard is geschreven De standaard is editorial note on risk, en voor de situatie waarin al geschreven voor cloudDomain 2: Governance en voor clouddienst-productieleveranciers. Enterprise Risk omgeving is gekozen. Verantwoordelijkheid Management. voor dit risico ligt bij de klant. Economische doelen: Cloud computing biedt een kans voor klanten om gebruik te maken van computing-bronnen met geringe startkosten. Daarnaast wordt een kostenreductie bereikt door ‘scalability’ en ‘pay-as-you-go’. Ook al kunnen deze voordelen substantieel zijn, er moeten een aantal economische risico’s worden overwogen. Business continuity: Wanneer systemen in eigen eigendom en beheer zijn, kan een klant doorgaan een product te gebruiken, ook al kan de leverancier (om welke reden ook) geen support leveren of ook al is deze failliet. Voor public clouds, community clouds en overige outsourced diensten zijn klanten afhankelijk van (nagenoeg) realtime levering van diensten van leveranciers. Voor bedrijven met tijd-kritische computing-behoeftes betekent een onderbreking van een dienst een (tijdelijke) sluiting van het bedrijf. Er zijn meerdere aanpakken denkbaar om dit risico te mitigeren, bijvoorbeeld door gebruik van redundante clouds, monitoring van de performance en gezondheid van de leverancier of door gebruik van hybrid clouds. Cloudspecifiek probleem? Deels. Dit probleem doet zich net zo goed voor bij gehoste of outsourcete toepassingen. Redundante oplossingen zijn voor Cloud computing wel complexer door de versnippering van uitvoering van de toepassing en de locatie van alle data en vragen
1 april 2014
59
Versie 1.0
om een meer geavanceerde oplossing dan in het geval van traditionele IT toepassingen. Risico onderschreven door…. CC: ACSCF: Kan worden geschaard onder CC-OUTS- A.03.2.4, A0.3.7.3, A.03.7.4, A.03.8.5, 22, CC-OUTS-23, CC-OUTS-31 en CCAS.3.10.1, AS.3.10.2 AS.3.10.4 en A.05.6.1 OUTS-33. Ondersteund door standaard of OpenStack: n.v.t., De CSA CMM/ CAI: CSA Security guide: met normenkader te auditen? standaard is geschreven In OP-04 en RI-05. domain 7 voor de inrichting van een traditional security, Cloud computing productiebusiness continuity, & omgeving, niet voor uitval disaster recovery hiervan. NB : Hierbij geldt dat de klant specifieke architectuur- en SLA eisen in de ontwerpfase aan moet dragen, en een gedegen kennis van Cloud computing en bijbehorende techniek moet hebben. Daarbij moet de klant de vaardigheid hebben om de vertaling van SLA informatie naar de ontwerpeisen te kunnen maken. Service Agreement evaluation: Op het moment worden SLA’s door mensen gegenereerd en door mensen beoordeeld. De gebruikte terminologie van SLA’s is ook nog niet altijd voor eenduidig gebruik uitlegbaar, denk aan termen als beschikbaarheid en security. Wanneer een SLA template met eenduidig geaccepteerde en uitlegbare kan worden ontwikkeld, kunnen de specificaties van zo’n SLA (deels) geautomatiseerd gelezen en geëvalueerd worden. Een geautomatiseerde SLA kan een potentiele klant ondersteunen in het vergelijken van algemene voorwaarden en instellingen. Daardoor kan een klant de SLA-voorwaarden van een aan te schaffen clouddienst op een objectieve manier vergelijken. Dit bevordert een efficiënte cloud-marktplaats, waar Cloud computing worden aangeboden. Daarnaast kan SLA-management tijdens de afname van een dienst (deels) geautomatiseerd verlopen, waarbij een klant realtime SLA-informatie kan verkrijgen, zonder menselijke interpretaties. Cloudspecifiek probleem? Nee. Definitie-problematiek is onafhankelijk van de soort dienst. En lang niet alle toepassingen worden ondersteund door een (deels) geautomatiseerde gegenereerde en gelezen SLA. Wel voorzie ik dat het gevoel van ongrijpbaarheid van Cloud computing wat bij veel afnemers heerst een remmende factor is voor het afnemen van een clouddienst. Dit is een prikkel voor leveranciers van Cloud computing en van SLA-tools om de automatisering van SLA’s, continuous monitoring en –auditing in een sneller tempo op te pakken, omdat hierdoor de afname van Cloud computing kan worden bevorderd. Risico onderschreven door…. CC: ACSCF: Er wordt gesteld dat er moet worden A.03.1.3, A.03.5.23, A.03.9.3, A.03.9.4, gemonitord en gerapporteerd (CCA.04.1.2, A.04.1.3, A04.2.2, A.04.5.2 en OUTS-05, CC-OUTS-22 en CC-OUTS 31). A.04.5.3. Is gericht op monitoring systeem Er zijn een aantal risico’s en vragen van klant, en op incidenten en changes van gedefinieerd over definitie’s in SLA’s, leverancier. maar er zijn geen eisen gesteld aan de wijze van genereren en analyseren van de SLA. Ondersteund door standaard of OpenStack: n.v.t., uit de CSA CMM/ CAI: CSA Security Guide: met normenkader te auditen? standaard zijn wel Oa in CO-03, IS-23, RMAandachtspunten voor meetitems t.b.v. de SLA te 03, RM-04. SLA-afspraken worden in halen (al dan niet alle domains genoemd. geautomatiseerd) maar deze Continuous monitoring zijn niet als dusdanig wordt in domain 9: gemarkeerd in de standaard Incident Response en domain 14: Security as a Service genoemd. Portability van workload: Een initiële barrière om over te gaan op een clouddienst is het verhuizen van lokale workloads in de cloud infrastructuur van de leverancier. Voor de klant is de keuze eenvoudiger te maken als de leverancier een praktische methode aanbiedt om workloads te verhuizen naar de leverancier, of wanneer nodig terug naar de klant. Daarnaast zou een klant eenvoudig en eenduidig de workloads moeten kunnen migreren van de ene leverancier naar de andere. Wanneer deze twee mogelijkheden integraal zouden worden ondersteund door leveranciers, zou dit een concurrerende cloud-marktplaats ondersteunen. Cloudspecifiek probleem? Deels. Verhuizen van een gehoste naar een outsourcete dienst of van de ene outsourcete naar de andere outsourcete dienst heeft altijd al gezorgd voor problemen. Bijvoorbeeld door het gebrek aan referentie-architecturen, standaardisatie en technologie-afhankelijkheid. Een overstap van een gehoste applicatie naar een SAP toepassing of een overstap van een Windows- naar Unixplatform is ook niet eenvoudig. Echter, door de toegenomen complexiteit van technologie voor Cloud computing , de ontwikkelingen rondom standaardisatie die nog in de kinderschoenen staat en het vaak grotere aantal onderaannemers, is de portability nu nog minder eenvoudig bij Cloud computing dan bij traditionele IT omgevingen. Risico onderschreven door…. CC: ACSCF: Dit punt wordt deels geadresseerd, Deel s in A.03.11.4 (ontwerp volgens alleen de export en het transport van industriestandaarden) en A.05.7.1
1 april 2014
60
Versie 1.0
klantdata naar andere clouds, niet de (standardised open interfaces). initiële import van workload. Ondersteund door standaard of OpenStack: n.v.t., De CSA CMM/ CAI: CSA Security Guide: met normenkader te auditen? standaard is geschreven Wordt niet benoemd. Domain 2: Governance en voor de inrichting van een Enterprise Risk Cloud computing-productieManagement en Domain 6: omgeving. Dit punt betreft Interoperability and specifieke tooling t.b.v. portability portabiliteit. Interoperabiliteit tussen cloud leveranciers Voor operaties zoals de overdracht van data en afbeeldingen van virtuele machines tussen leveranciers zijn gestandaardiseerde formats nodig. Deze formats zijn nodig voor de daadwerkelijke overdracht, maar ook voor de facturering en identificatie (identity management). Er zijn een aantal standaarden zoals Open Virtualisation Format en the Cloud Data Management Interface. Er is echter nog meer ontwikkeling van formats nodig, en er moet meer kennis omtrent deze standaarden worden opgedaan, om de kosten van interoperabiliteit tussen leveranciers te reduceren. Cloudspecifiek probleem? Deels. Net als voor portability van workload van een traditionele IT omgeving is ook interoperabiliteit nog een gebied wat niet voldoende rijp en ontwikkeld is. Maar ook dit is niet een compleet specifiek probleem voor Cloud computing . Risico onderschreven door…. CC: ACSCF: CC-OUTS-03. Verwezen wordt naar Deel s in A.03.11.4 (ontwerp volgens industrie standaarden. Openstaande industriestandaarden) en A.05.7.1 issues zoals geadresseerd door NIST (standardised open interfaces). worden niet genoemd. Ondersteund door standaard of OpenStack: n.v.t., De CSA CMM/ CAI: CSA Security Guide: met normenkader te auditen? standaard is geschreven Wordt niet benoemd. Domain 2: Governance en voor de inrichting van een Enterprise Risk Cloud computing-productieManagement en Domain 6: omgeving. Dit punt betreft Interoperability and specifieke tooling t.b.v. portability. Noodzaak voor portabiliteit. frameworks en gebruik van standaarden wordt benadrukt. Disaster recovery Dit omvat zowel fysieke als elektronische ongevallen met eigendommen van de klant. Denk aan natuurrampen, hardware diefstal en elektrische ongevallen. Voor elk van deze ongevallen moeten van tevoren disaster recovery plannen worden opgesteld. Deze plannen moeten kunnen worden toegepast op alle (cloud)gehoste IT services en moeten snel kunnen worden uitgevoerd. Deze traditioneel al bekende ongevallen zijn in het geval van een clouddienst gecompliceerder om te beschrijven en uit te voeren, omdat een klant mogelijk niet weet waar hun diensten worden gehost. Cloudspecifiek probleem? Deels. Dit is geen nieuw probleem maar is zoals hier boven al beschreven voor Cloud computing moeilijker omdat de klant mogelijk niet weet waar diensten worden gehost. Hiervoor is dan ook goed overleg en een goede samenwerking nodig met de leverancier van de clouddienst. Risico onderschreven door…. CC: ACSCF: CC-OUTS-23 A.3.10.1, A.3.10.2 , A.3.10.3 en A.3.2.4, Ondersteund door standaard of OpenStack: n.v.t., De CSA CMM/ CAI: CSA Security guide: met normenkader te auditen? standaard is geschreven In DG-04, RS-01, RS-02, domain 7 voor de inrichting van een RS-03 en RS-04. traditional security, Cloud computing-productiebusiness continuity, & omgeving, niet voor uitval disaster recovery hiervan. Compliance Wanneer data of verwerking van gegevens worden verhuisd naar een cloud, blijft de klant de eindverantwoordelijkheid houden voor de compliance (werken overeenkomstig de geldende wet- en regelgeving). De leverancier kan in de beste positie zijn om de compliance regels uit te oefenen omdat deze direct toegang tot de data heeft. Daarom zouden de compliance issues contractueel benoemt moeten worden, waarbij de taken en verantwoordelijkheden duidelijk worden benoemd, bijvoorbeeld in de vorm van een RACI. Gebrek aan zichtbaarheid Klanten hebben mogelijk onvoldoende zicht op hoe de cloud waarin zij een dienst afneemt, werkt. Als dat zo is, kan de klant onvoldoende verklaren of hun dienst wordt uitgevoerd op een veilige en compliant manier. Verschillende modellen van Cloud service levering voegen verschillende niveaus van controle toe of verwijderen verschillende niveaus van controle voor de klant. De keuze van een klant om aanvullende monitoring mechanismes toe te laten voegen op de leveranciers site is plausibel en wordt ook toegepast voor een variëteit van niet-cloud diensten op dit moment. Cloudspecifiek probleem:
1 april 2014
61
Versie 1.0
Deels. Doordat Cloud computing minder transparant en complexer is dan de traditionele IT toepassing, is het gebrek aan zichtbaarheid groter bij Cloud computing. Het is echter geen nieuw probleem. Dit punt heeft een relatie met SLA management, en de mogelijkheden om geautomatiseerd performance van diensten te monitoren en de (on)mogelijkheden om een deep dive te maken tot op het laagste niveau van onderaannemerschap. Het aantal onderaannemers is mogelijk (veel) groter dan in het geval van outsourcing. Risico onderschreven door…. CC: ACSCF: CC-OUTS-07, CC-OUTS-14 t/m CC-OUTS- A.03.14 t/m A.03.16 en A.03.11.3. De punten 16, CC-OUTS-25 t/m CC-OUTS-30. zijn hoogover en gaan niet specifiek genoeg Punten zijn echter meer gericht op in op SLA-rapportage en mate van inzicht en auditen dan op SLA-rapportage. mogelijkheden tot een deepdive. Daardoor is het inzicht niet actueel genoeg voor de klant. Ondersteund door standaard of OpenStack: n.v.t., uit de CSA CMM/ CAI: CSA Security Guide: In met normenkader te auditen? standaard zijn wel CO-04 t/m CO-06 en SA10.5 Monitoring meetitems ten behoeve van 03. De punten zijn Applications in the Cloud de SLA te halen (al dan niet hoogover en gaan niet worden een aantal punten geautomatiseerd) maar deze specifiek genoeg in op hoog-over geadresseerd. zijn niet als dusdanig SLA-rapportage en mate In het gehele document gemarkeerd in de standaard van inzicht en wordt SLA-management en mogelijkheden tot een –reporting genoemd. deepdive. NB: Het is zowel bij documentatie van CC als CSA niet duidelijk of informatie van onderaannemers wordt meegenomen en gepresenteerd, en in hoeverre een deep dive tot aan de laagste onderaannemer (waar nodig) mogelijk is. Dit vraagstuk is echter ook in het geval van outsourcing een issue. De (Third party) auditor van de leverancier moet op basis van auditrapporten van onderaannemers een oordeel vellen over de prestaties van onderaannemers, en dit oordeel meenemen in de ISAE 3402 van de (hoofd)leverancier. Dit is op dit moment in het geval van outsourcing ook een geaccepteerde werkwijze. Fysieke datalocatie Leveranciers maken bedrijfseconomische beslissingen over waar de fysieke datacentra worden gesitueerd. Deze beslissingen worden gebaseerd op parameters als bouwkosten, energiekosten, veiligheids- en security overwegingen, beschikbaarheid van opgeleide medewerkers, personeelskosten en de kwaliteit van de publieke infrastructuur. Klanten moeten echter voldoen aan internationale en/of federale wetten en regels die mogelijk de opslag van data buiten fysieke grenzen verbieden. Alhoewel de leverancier mogelijk technologieën gebruikt om logische controle over data toe te passen en cryptografische mechanismes inbouwt om het risico van ongeautoriseerde onthulling van gegevens te voorkomen, moeten klanten nog steeds compliant zijn met de statuten en verordeningen. Daardoor kunnen de door de leverancier genomen maatregelen niet voldoende zijn, of niet voldoende inzicht bieden voor de klant. Cloudspecifiek probleem? Ja. Het grote voordeel van gegevens in de cloud bewaren is juist dat het niet meer uitmaakt waar dat gebeurt en dat data wereldwijd beschikbaar is. En dat kan strijdig zijn met de wet- en regelgeving waar een klant aan moet voldoen. Daar waar bij een gehoste of outsourcede dienst er dedicated of shared dataservers werden ingezet, waarvan de locatie bekend was, is dat bij Cloud computing niet meer standaard het geval. Daarnaast zorgt de generatie van steeds grotere volumes aan data er voor, dat op recordniveau nagenoeg niet meer vast te leggen en aan te tonen is waar de het record wanneer opgeslagen is geweest. Risico onderschreven door…. CC: ACSCF: CC-OUTS-12, CC-OUTS-16 en CC-OUTSA.03.2.2, A.03.2.8 over opzet. De wijze 17 over opzet. waarop de locatie van data moet/kan worden aangetoond wordt niet benoemd. Ondersteund door standaard of OpenStack: CSA CMM/ CAI: CSA Security Guide: In met normenkader te auditen? De standaard schrijft voor CO-05 beschrijft dat opzet benoemd in 1.5 dat data redundant wordt vooraf tot op data niveau Cloud Security Reference opgeslagen in regio’s, wordt vastgelegd aan model en in Domain 5: zone’s, servers en drives welke wetten en regels Information management mvb OpenStack Object moet worden voldaan. De en Data security. Specifiek Storage. norm gaat over opzet en aandacht voor “Possible” niet over en “Allowed” locations of aantoonbaarheid. data. NB: In alle gevallen wordt niet beschreven dat per object moet worden vastgelegd waar het object opgeslagen is (geweest). Dus hoe is aan te tonen dat aan de contracteisen is voldaan? Dat punt wordt niet geadresseerd. Wet- en regelgeving 15 Klanten kunnen gebonden zijn aan een variëteit aan regelgeving, denk aan de Sarbanes-Oxley Act (SOX ) of Payment Card 16 Industry Data Security Standaard (PCI DSS ). Klanten zijn eindverantwoordelijk voor de data die bewerkt wordt in de
15
De SOX-wet legt tal van regels op aan bedrijven die aan een Amerikaanse beurs genoteerd zijn (en haar buitenlandse filialen), of een buitenlands bedrijf met een genoteerde vestiging.
1 april 2014
62
Versie 1.0
cloudsystemen van leveranciers. De klant moet daarom assurance verkrijgen van de leverancier dat deze bijdraagt aan de compliant zijn met de vereiste regelgeving door de klant. Klanten moeten ook assurance verkrijgen over het feit of een leverancier passende jurisdictie voor de data heeft toegepast. Wanneer de leverancier niet compliant heeft gehandeld, moeten rechtsmiddelen bij voorbaat zijn vastgelegd. Deze behoefte van de klant is moeilijk uitvoerbaar voor leveranciers omdat deze de uitvoering en configuratie van de dienst voor de klant als eigenaars-informatie beschouwen, en niet altijd aan de klant willen tonen. Dit gebrek aan zichtbaarheid maakt het voor een klant moeilijk om er zeker van te zijn dat een leverancier compliant is met de vereiste regelgeving, tenzij een leverancier een onafhankelijke audit door een trusted third party uit laat voeren. En zelfs dan is de frequentie waarmee de audit uitgevoerd wordt gedurende een jaar een beperking voor de zekerheid die kan worden gegeven over het gehele jaar, omdat een cloudsysteem stilletjes ‘out of compliance’ kan glijden. Cloudspecifiek probleem? Ja, dit punt is een verlengde van het aandachtspunt van de fysieke datalocatie. Voor beide aandachtspunten geldt dat het nagenoeg niet mogelijk is om assurance met een redelijke mate van zekerheid af te geven, aangezien de wijze en frequentie van monitoring van de locatie van data een tijdrovend en arbeidsintensief/systeem intensief proces is. Daarnaast worden specifieke audits door auditors van afnemers door andere afnemers van dezelfde clouddienst soms als inbraak op hun privacy gezien. Risico onderschreven door…. CC: ACSCF: CC-OUTS-07, CC-OUTS-16 en CC-OUTSA.03.1.4 en A.03.1.5. Niet benoemd hoe 19 achteraf wordt aangetoond waar data opgeslagen is, of dat dit actief wordt gemonitord. Ondersteund door standaard of OpenStack: CSA CMM/ CAI: CSA Security Guide: In met normenkader te auditen? n.v.t., uit de standaard zijn CO-04 en CO-05. Niet opzet benoemd in 1.5 wel meetitems t.b.v. het benoemd hoe achteraf Cloud Security Reference aantonen van het al dan niet wordt aangetoond waar model en in Domain 5: compliant zijn, maar deze data opgeslagen is, of dat Information management zijn niet als dusdanig dit actief wordt en Data security. Specifiek gemarkeerd in de standaard. gemonitord. aandacht voor “Possible” Dat is ook niet mogelijk en “Allowed” locations of omdat wet- en regelgeving data. Niet benoemd hoe per land & beroepsgroep achteraf wordt varieert en in beweging is. aangetoond waar data opgeslagen is, of dat dit actief wordt gemonitord. Ondersteuning van forensisch onderzoek Als onderdeel van beveiligingsplan-inspanningen als gevolg van een incident, is het doel van een digitaal forensisch onderzoek om : (1) onderscheiden wat er is gebeurd, (2) begrijpen welke gedeelten van het systeem werden getroffen, (3) leren hoe om te voorkomen dat dergelijke incidenten zich opnieuw gebeurt en (4) het verzamelen van informatie voor eventuele toekomstige juridische acties. Forensisch onderzoek in de cloud werpt echter een aantal nieuwe problemen op, zoals: • hoe zijn incidentverantwoordelijkheden gedefinieerd in SLA's? • hoe worden systeemklokken gesynchroniseerd in datacentra ten behoeve van het reconstrueren van een keten van gebeurtenissen? •hoe worden gegevensschendingen gemeldt, en zijn deze conform de wetten van de verschillende landen? • Welke gegevens kan een cloudleverancier zien bij het vastleggen van een ‘foto’ van een gedeelde harddrive en welke gegevens zou de cloudleverancier mogen zien? • Wat is de klant toegestaan om te zien in een controlelogboek, met andere woorden is informatie met betrekking tot andere cloudklanten beschermd? • Wat is de verantwoordelijkheid van een klant met betrekking tot het rapporteren van een incident in een PaaS-model? • Kan een leverancier wettelijk ingrijpen in een aanval op een toepassing in haar cloud als het is slechts een indirecte contractuele relatie betreft? Cloudspecifiek probleem? Grotendeels. In het geval van een shared hosting zijn een aantal van de genoemde problemen niet nieuw (bijv. incidentverantwoordelijkheid, inzicht in controlelogboeken, etc). De problemen zijn dan echter veel kleiner en minder complex, en daardoor makkelijker van te voren vast te leggen.
16
Een informatiebeveiligingsstandaard voor organisaties die kaart-eigenaarsgegevens gebruiken voor de grote debet-, credit-, prepaid-, E-purse-, betaalautomaat- en klantkaarten.
1 april 2014
63
Versie 1.0
Problemen die te maken hebben met de melding gegevensschending conform de wetten van het land waarin de data is opgeslagen, zijn wel cloudspecifiek omdat in het geval van outsourcing de locatie van dataservers bij de klant bekend is (tenzij er gebruik van onderaannemers wordt gemaakt). Een groot deel van de genoemde nieuwe problemen hebben vooral te maken met het vooraf vastleggen van rechten, taken en verantwoordelijkheden per afgenomen clouddienst. Dat kan een complexe materie zijn wanneer per land waar de data potentieel kan worden opgeslagen de rechten, taken en verantwoordelijkheden moeten worden vastgelegd en actueel gehouden. Als laatste wil ik noemen dat het virtuele geheugen (een soort zwart gat) die niet door een traditionele security appliance kan worden gemonitord. Daarvoor moet bewust een soort virtuele security appliance worden ingezet. Dat maakt forensisch onderzoek veel lastiger of daar waar de virtuele security appliance niet is ingezet, zelfs onmogelijk. Gartner verwacht dat in 2014 70% van de workloads uitgevoerd wordt door virtuele machines. Risico onderschreven door…. CC: ACSCF: CC-OUTS-13, CC-OUTS-14, CC-OUTS-29 A.03.5.24 en CC-OUTS-30. Ondersteund door standaard of OpenStack: CSA CMM/ CAI: CSA Security Guide: met normenkader te auditen? De standaard beschrijft in IS-24. Aandacht in Domain 3: diverse hoofdstukken een Legal Issues; Contracts and aantal auditregels, logging Electronic Discovery voor van toegang en de trail die opslag in “forensic sound kan worden teruggeleid tot matter”, en in Domain 9: een account. Deze gegevens Incident Response. Nadruk vormen de basis voor wordt gelegd op mogelijkheden om (on)mogelijk-heden: “Even forensisch onderzoek te in a private cloud, forensics doen. may be extremely difficult, and clients may need to notify opposing counsel or the courts of these limitations. Luckily, forensics is rarely warranted in Cloud computing, not because it is Cloud computing, but because it is usually a structured data hierarchy or virtualization that does not lend itself to forensic analysis.” Informatiebeveiliging: Beveiliging van informatie heeft betrekking op de bescherming van de vertrouwelijkheid en integriteit van gegevens en zorgen voor beschikbaarheid van de gegevens. Een organisatie die eigenaar is van IT-activiteiten en zelf deze activiteiten uitvoert neemt normaliter de volgende soorten maatregelen voor de beveiliging van gegevens: • organisatorische/administratieve controle die specificeren wie data-gerelateerde handelingen uit mag voeren (aanmaken data, toegang tot data, onthulling van data, transport en verwijdering/vernietiging van data, • fysieke toegangsmaatregelen t.b.v. de bescherming van opslagmedia en de voorzieningen voor de huisvesting van opslagapparaten • technische controls voor Identity en Acces Management, encryptie van data en andere audit- afhandelingsdata (vb auditlogin) en compliance eisen. Wanneer een organisatie diensten afneemt van een cloud, zal alle data die gegenereerd en bewerkt wordt fysiek vastliggen op locaties die door de leverancier worden bediend, en het eigendom zijn van de leverancier. In dit context is het essentieel om te bepalen of de aanbieder dezelfde of equivalente controls t.b.v. informatiebeveiliging zal implementeren. Denk dan aan: • compliance eisen bij het verhuizen van data naar de cloud, • mogelijkheden voor een klant om te bepalen of de leverancier aan de afgesproken contractuele verplichtingen en operationele configuraties heeft voldaan, • de manier waarop data-encryptie is opgezet (vb hoe sterk is het data-encryptie-algoritme), key management, etc. Dataprocessing en applicaties die draaien op een public cloud lopen andere informatiebeveiligingsrisico’s dan een onsite gehoste omgeving. Bijvoorbeeld het aanvalsoppervlakte van een cloud, de mogelijke pool van cloud-aanvallers, systeem complexiteit, de expertise level van cloud administrators, etc. Het laatste aandachtspunt voor informatiebeveiliging is de logische scheiding van user workloads en de logische mechanismen om de klantresources te beschermen. Deze blijken tot op heden niet zo veilig als fysieke scheidin. Ongewenste data-onthulling: Wanneer een klant kiest voor Cloud computing voor niet gevoelige gegevens en een separate omgeving voor gevoelige gegevens, moet er voor worden gewaakt dat per ongeluk gevoelige gegevens op de Cloud toepassing worden geplaatst zonder de juiste beschermingsmaatregelen. Cloudspecifiek probleem?
1 april 2014
64
Versie 1.0
Grotendeels. Ook in een combinatie tussen een gehoste en outsourcede omgeving is dit mogelijk. Er is immers altijd de factor mens aanwezig bij het behandelen en wegschrijven van data. In de basis is voor dit punt een data-classificatie essentieel. Deze classificatie moet bij de behandeling van data consequent worden toegepast door toepassingen en databases en moet worden vertaald in autorisaties en locaties voor toegang tot data en het vastleggen van data. Als gevolg van de toevoeging van de virtualisatielaag (hypervisor) die de virtuele omgeving controleert, zijn er meer zwakke plekken in het besturingssysteem dan bij traditionele IT. Door lekken in de hypervisor kunnen ongenode gasten toegang krijgen tot het gehele virtuele netwerk ondanks beveiligingsmaatregelen op lokaal niveau. Dan is het maar de vraag of de dataclassificatie en -autorisaties standhouden. En door het virtuele geheugen wat hierboven al is genoemd, is het ook steeds moeilijker om ongewenste data-onthulling aan het licht te brengen. Risico onderschreven door…. CC: ACSCF: Dit punt wordt niet benoemd. A.03.2.5 t/m A.03.2.8, A.03.3.3 t/m A.03.3.7, A.03.5.1 t/m A.03.5.34 en A.03.11.8 Ondersteund door standaard of OpenStack: CSA CMM/ CAI: CSA Security guide: In met normenkader te auditen? De standaard beschrijft zoals DG-05 t/m DG-08, FS-03 1.4 Multitenancy, 5.6.3.4 eerder aangegeven datat/m FS-07, IS-01 t/m IS-34 SaaS encryption, 10.2 opslag in regio’s, zones, etc. en SA-08. Authentication, Er wordt echter niet over authorization, and dataclassificatie gesproken, compliance – application waardoor niet kan worden security architecture in the gecontroleerd bij cloud, domain 13: (redundante) opslag of Virtualization, domain 14: gevoelige gegevens op de Security as a service. verkeerde plaats worden Aandacht voor virtualisatie opgeslagen. en hypervisorrol. Data privacy: Privacy behandelt de vertrouwelijkheid van gegevens voor specifieke entiteiten, zoals klants of anderen waarvan informatie wordt verwerkt in een systeem. Privacy betreft juridische en aansprakelijkheid. Het zou niet alleen als een technische uitdaging moeten worden benaderd maar ook als een juridische en ethische bezorgdheid moeten worden bekeken. Beschermen van de privacy in elke computing systeem is een technische uitdaging; in een cloud wordt deze uitdaging bemoeilijkt door de gedistribueerde aard van clouds en het mogelijke gebrek aan bewustzijn van de klant over waar gegevens worden opgeslagen en wie toegang heeft of kan hebben. Cloudspecifiek probleem? Grotendeels. Een breuk in de data privacy is een gevolg van ongewenste data onthulling. Zie daarom de argumenten hierboven genoemd. Risico onderschreven door…. CC: ACSCF: CC-OUTS-20, CC-OUTS-21 en CC-OUTS A.03.1.5, A.03.2.1 t/m A.03.2.8, A.03.3.3 t/m 36. A.03.3.8, A.03.4.1, A.03.4.2, A.03.5.1, A.03.5.4, A.03.5.7, A.03.5.8 t/m A.03.5.11, A.03.5.17 t/m A.03.5.19 Ondersteund door standaard of OpenStack: CSA CMM/ CAI: CSA Security Guide: met normenkader te auditen? Hoofdstuk 1: Identity Service CO-05, DG-01 t/m DG-08, Domain 3: Legal Issues; wordt in zijn geheel geweid FS-03 t/m FS-06, HR-01, Contracts and Electronic aan toegang, Public Key HR-02, IS-01, IS-04, IS-07, Discovery, Domain 5: Infrastructure certificaten IS-08 t/m IS-11, IS-17 t/m Information Management (PKI), de inrichting van de IS-19. and Data Security en Secure Socket Layer (SSL) Domain 14: Security as a voor communicatie op Service. internet, etc. . Er wordt echter niet over dataclassificatie gesproken, waardoor niet kan worden gecontroleerd bij (redundante) opslag of gevoelige gegevens op de verkeerde plaats worden opgeslagen. Systeemintegriteit: Clouds hebben behoefte aan bescherming tegen opzettelijke omverwerping of sabotage van de functionaliteit van een cloud. Binnen een cloud er zijn belanghebbenden: klants, leveranciers en een scala aan beheerders. De mogelijkheid om rechten toe te kennen tot toegang voor elk van deze groepen, terwijl kwaadwillige aanvallen op afstand worden gehouden, is een belangrijke eigenschap van het handhaven van de integriteit van de cloud. In een cloudsetting maakt elk gebrek aan zichtbaarheid in de cloudmechanismen het moeilijker voor klants om de integriteit van de cloud-gehoste toepassingen te controleren. Cloudspecifiek probleem?
1 april 2014
65
Versie 1.0
Grotendeels. Een cloudomgeving is complex, en door beheerders ook nog niet altijd ten volle begrepen. Fouten zijn daardoor eenvoudig gemaakt, en aanvallen niet altijd tijdig onderkend. Door de eerder genoemde hypervisor met bijbehorende barsten en lekken in het besturingssysteem is de systeemintegriteit moeilijker te bewaken. Daarnaast is deze integriteit alleen te bewaken met inzet van virtual security appliances. Gardner verwacht dat ruim 60% van alle virtuele servers minder veilig zijn dan de fysieke servers die ze vervangen. Risico onderschreven door…. CC: ACSCF: CC-OUTS-20, CC-OUTS-36 en CC-OUTSOa A.03.2.1 t/m A.03.2.8, A.03.3.3 t/m 39 voor autorisaties. CC-OUTS-14 en A.03.3.6, SA.03.11.1 t/m SA.03.11.7 voor CC-OUTS-30 voor incidentafhandeling. voor autorisaties en toegang. Geen expliciete Verder CC-MULTI-03 en CC-MULTI-04 aandacht voor virtual security appliances. voor multitenancy issues. Er wordt geen aandacht besteed aan monitoring tools en virtual security appliances. Ondersteund door standaard of OpenStack: CSA CMM/ CAI: CSA Security Guide: met normenkader te auditen? Er wordt geen aandacht CO-05, DG-01 t/m DG-08, Preventieve maatregelen besteed aan monitoring FS-03 t/m FS-06, HR-01, beschreven in Domain 10: tools en virtual security HR-02, IS-01, IS-04, IS-07, Application Security en appliances. IS-08 t/m IS-11, IS-17 t/m repressief in Domain 9: IS-19 en SA-01 t/m SA-07 Incident Response. voor autorisaties en Doordat er geen expliciete toegang. Geen expliciete aandacht is voor virtual aandacht voor virtual security appliances kan er security appliances. geen werking worden beoordeeld. Multi tenancy: Cloud computing kent aanzienlijke economische efficiëntie door de verdeling van de middelen aan de kant van de leverancier. Voor IaaS kunnen verschillende VM’s hardware via een hypervisor delen; voor PaaS kunnen verschillende processen een besturingssysteem, ondersteunende gegevens en netwerkservices delen; voor SaaS kunnen verschillende klants dezelfde toepassing of database delen. Om dat de mechanismen die aan de leverancierskant worden toegepast om te delen afhankelijk zijn van complexe utilities om de workload van klanten de isoleren, wordt het risico van mislukte isolatie gelopen. Gebreken in logische scheiding zijn gedocumenteerd in het verleden. Het opbouwen van vertrouwen die een logische scheiding vraagt als een geschikt alternatief voor fysieke scheiding is een langdurige onderzoeksprobleem. Het vertrouwen in logische scheiding kan worden vergroot door gegevens te coderen voordat deze worden ingevoerd in een cloud. Nadeel hiervan is dat deze gegevens zullen moeten worden gedecodeerd om verwerkt te worden met alle gevolgen van snelheidsvermindering van dien. Voor clouds die berekeningen afhandelen kan risicomitigatie middels het beperken van types gegevens die bewerkt worden in de cloud een mogelijkheid zijn. Ook is het een optie om bepaalde gegevens te laten verwerken door leveranciers met gespecialiseerde isolatie mechanismen. Cloudspecifiek probleem? Ja. De mechanieken van multi tenancy gaan vele malen verder dan bijvoorbeeld een shared server in het geval van een outsourced dienst. Het vraagt vooraf bij het keuze van Cloud computing diepgaande kennis omtrent de techniek achter serviceen deliverymodellen. Daarnaast vraagt het diepgaande kennis voor beheerders van leveranciers, informatiebeveiligers van zowel leverancier als klant en servicemanagers van de klant tijdens de afname van een clouddienst. Risico onderschreven door…. CC: ACSCF: CC-MULTI-02 t/m CC-MULTI-04 A.03.5.11, A.03.11.6, A.03.11.9 en A.03.11.10 Ondersteund door standaard of OpenStack: CSA CMM/ CAI: CSA Security Guide: met normenkader te auditen? Veel aandacht voor isolatie IS-11, SA-06, SA-09 en SA- In 1.4 Multitenancy, van virtuele machines, 10. Domain 5: Information VLAN’s, domains en isolatie management and Data van multi tenants security, Domain 10: Application Security, Domain 13: Virtualisation en Domain 14: Security as a Service. Browsers: Veel cloudtoepassingen gebruiken browsers van de klant als een grafische interface. Hoewel leveranciers soms clienttools voor cloudadministratie distribueren, worden browsers ook gebruikt voor klant account setup en resource administratie, met inbegrip van de verschaffing van de financiële informatie die nodig is om te openen en gebruiken van een account bij een leverancier. Helaas, browsers zijn complex en hebben aangetoond dat ze beveiligingsfouten herbergen, en kwetsbaar zijn in bijna elke openbare veiligheidsuitdaging. Leveranciers die gebruikmaken van een verscheidenheid aan klant browsers en versies, klant-bestuurde eindsystemen en browsers, maken mogelijk gebruik van browsers die niet correct kunnen worden beheerd voor beveiliging of geen actuele versie hebben. Wanneer de browser van de klant is ondermijnd worden alle diensten die de klant
1 april 2014
66
Versie 1.0
heeft toevertrouwd aan een cloudleverancier bedreigd. Er zijn mitigerende maatregelen denkbaar als: beperken van het type browser waarmee toegang tot de clouddienst wordt verkregen, verzekeren dat browsers up-to-date zijn, etc. Cloudspecifiek probleem? Grotendeels. Toegang tot een clouddienst is altijd webbased, een gehoste service niet, en een outsourcede dienst niet altijd. Hoewel er door NIST diverse mogelijkheden worden genoemd om dit risico te mitigeren, zijn er altijd kosten, lagere functionaliteit en verminderd gemak verbonden aan deze oplossingen. Daardoor is het maar de vraag of deze maatregelen consequent zullen worden ingezet. Risico onderschreven door…. CC: ACSCF: Het up-to-date houden van software IS.03.5.20 NB: Deze norm regelt wel de (op alle lagen) wordt niet geadresseerd. actualiteit en patchmanagement van de Ook wordt de verantwoordelijkheid die leverancier maar niet van de klant, het een klant hierin heeft als het ‘zijn’ model gaat immers alleen over eisen richting browser betreft, niet benoemd. leverancier. Ondersteund door standaard of OpenStack: CSA CMM/ CAI: CSA Security Guide: met normenkader te auditen? Er worden versie-eisen aan IS-20. NB: Deze norm Patchmanage-ment wordt drivers en de S3 API regelt wel de actualiteit in diverse hoofdstukken (middleware en patchmanagement genoemd, voor devices en programmatuur) gesteld. Er van de leverancier maar virtual machines. Geen worden geen eisen gesteld niet van de klant, het melding van up-to-date aan het up-to-date zijn van model gaat immers alleen softwarereleases of gebruikte browsers (zowel over eisen richting actuele versies van aan de klant- als leverancier. browsers. Ook alleen leverancierskant) patchman-agement van de leverancier Hardware support voor betrouwbaarheid van remote systemen: In sommige gevallen kan een klant hardware ondersteuning inschakelen om de betrouwbaarheid van externe systemen te begrijpen. Bijvoorbeeld een Trusted Platform Module (TPM) heeft als doel het vastleggen van een set van checksums die worden gegenereerd bij het opstarten van het systeem. Met behulp van de checksums kan vervolgens worden bepaald of het systeem in feite van bekende onderdelen starten. Wanneer virtuele machines migreren, lijkt dit ‘trustchain’ te breken in de TPM. Verschillende groepen hebben geprobeerd om dit probleem op te lossen. Dat is tot op heden nog niet gelukt. Noot van ACSCF: In een cloud structuur wordt alleen bij uiterste noodzaak nog herstart. Dit moet in het achterhoofd worden gehouden bij het bepalen van de kans tijdens een risico analyse.
1 april 2014
67
Versie 1.0
Cloudspecifiek probleem? Ja en nee. Dit is geen specifiek Cloud computing risico maar specifiek risico bij hardware-virtualisatie. Aanvullend op het risico hierboven wil ik het volgende toevoegen. Doordat er bij virtualisatie geen echte hardware gebruikt wordt, is er geen hardwarematige bescherming van de checksums mogelijk is. De TPM is namelijk een chip op het moederbord van een computer, en een virtuele computer heeft geen moederbord. Er bestaat (nog) geen oplossing met dezelfde functionaliteiten als de TPM-chip voor gevirtualiseerde hardware. De checksums die in een beveiligde (TPM)chip zitten worden gebruikt om te controleren of de bestanden nodig om te "booten" wel te vertrouwen zijn. Als die controle niet kan worden gedaan kan het zijn dat de opstart bestanden zijn aangepast. Daarmee is de trustchain mogelijk te breken. Een specifiek risico voor Cloud computing is dat de klant niet voor 100% zeker weet dat de cloudleverancier de opstartbestanden van de klant heeft aangepast. Wanneer dit onder eigen beheer wordt uitgevoerd met virtualisatie kan de klant zelf de integriteit van de virtuele opstartdisks bewaken. Samenvattend kan dit virtualisatie probleem zich voordoen bij een gewenste migratie van virtuele machines en bij sabotage. Doordat bij Cloud computing per definitie gebruik wordt gemaakt van virtualisatie, is dit wel een probleem dat zich altijd voordoet bij Cloud computing . Risico onderschreven door…. CC: ATOS: Dit punt wordt niet geadresseerd en er SA.03.11.08 benoemd wel trusted en wordt ook geen monitoring of untrusted networks, maar gaat niet dieper in rapportage op dit gebied benoemd. op trustchains of checksums, en monitoring hierop. Het punt blijft te algemeen. Ondersteund door standaard of OpenStack: CSA CMM/ CAI: CSA Security Guide: met normenkader te auditen? Trustchains voor SSL SA-08 benoemd wel Aspecten als trusted zones, communicatie worden trusted en untrusted chanels, hardware, benoemd, trusted computor networks, maar gaat niet networks, key hardware! pools en een dieper in op trustchains management worden roottrust tussen alle of checksums, en genoemd, maar trusthypervisor nodes monitoring hierop. Het chains en het mogelijk (knooppunten). Echter het punt blijft te algemeen. doorbreken hiervan wordt doorbreken van een niet geadresseerd. trustchain (al dan niet opzettelijk) kan nog niet worden gemonitord. Key management: Adequate bescherming van cryptografiesleutels van de klant vraagt om (een vorm van) samenwerking van cloudleveranciers. Er zijn situaties waarbij door “zeroing” (leeghalen) van een geheugenbuffer een sleutel niet daadwerkelijk verwijderd is: (1) het geheugen wordt ondersteund door een hypervisor die de sleutelgegevens blijvend maakt, (2) de VM heeft een ‘snapshot’ genomen voor hersteldoeleinden en de ‘snapshot’ is bewaard gebleven of (3) de VM wordt geserialiseerd voor migratie naar andere hardware. Dit in tegenstelling tot bij dedicated hardware die kan worden gewist. Het is een open kwestie over het veilige gebruik van cryptografie binnen een cloud. Cloudspecifiek probleem? Ja. Ook dit is een specifiek hardware-virtualisatie risico. Wanneer van een draaiend virtueel systeem een snapshot wordt gemaakt, wordt er een kopie van het geheugen gemaakt. Daar kunnen op dat moment cryptosleutels in zitten. Het risico bestaat bij hardware-virtualisatie dat kopieën van het geheugen (inclusief cryptokeys) buiten de virtuele machine kunnen komen, onder controle van de cloudleverancier (en dus niet de klant). Risico onderschreven door….
CC: CC-OUTS-35 en CC-OUTS-36 benoemen wel het gebruik van sleutels, maar dit specifieke punt wordt niet geadresseerd.
Ondersteund door standaard of met normenkader te auditen?
OpenStack: Er is in het algemeen aandacht voor het gebruik en verwijderen van snapshots. Er is geen specifieke aandacht voor het verbieden van het kopieren van snapshots met cryptosleutels buiten de virtuele machine. Dat is juist het meest belangrijke aandachtspunt.
1 april 2014
68
ATOS: A.03.5.19 gaat over effective key management maar gaat niet dieper in op de wijze waarop met de bovengenoemde risico’s wordt omgegaan. Het punt blijft te algemeen. CSA CMM/ CAI: CSA Security Guide: In IS-19 gaat over effective 5.6 Data Security en 13.1.7 key management VM Encryption maar gaat niet dieper in op de wijze waarop met de boven-genoemde risico’s wordt omgegaan. Het punt blijft te algemeen.
Versie 1.0
Bijlage 5
Literatuurlijst
•
“Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG)”, versie 1.0, oktober 2013 http://new.kinggemeenten.nl/sites/default/files/document/gr_1891/13-1018-handreikingdataclassificatie.pdf
•
“Das normungs- und Standardisierungsumfeld von Cloud computing”, Bernnat, R, Bieber, N., december 2011, Paper opgesteld als Studie voor het Bundesministerium für Wirtschaft und Technologie (BMWi)
•
“Nieuwe ontwikkelingen IT –gerelateerde Service Organisation Control-rapportages”, Boer, J.C. en Beek, van J.J.(2013), Compact 2013(2) http://www.compact.nl/printversie/C-2013-2-Boer.htm
•
“15E_Cloud_Computing_v09”, Bootsma, H., (2012), collegesheets VU opleiding IT Auditing
•
“Cloud computing Information Assurance Framework”, Cattedu, D. en Hogben, G., november 2009, http://www.enisa.europa.eu/activities/risk-management/files/deliverables/cloudcomputing-information-assurance-framework
•
CloudAudit: “Automated Audit, Assertion, Assessment, and Assurance”. Geraadpleegd op 16 januari 2014 via http://www.cloudaudit.org/CloudAudit/Home.html
•
“Summary Certification SIG Survey”, CSA/ENISA (2013) https://20130428C-SIG-SurveryReportCertification-v2
•
“MEGHNAD V2.0: MOGA-Based Insurance Model for Cloud Service Security and Compliance”, Dasgupta, D. en Naseem, D., jaartal onbekend http://issrl.cs.memphis.edu/files/papers/Dasgupta-CICS2013-submission.pdf
•
“Grondslagen IT-auditing” (1e druk). Fijneman, R., Lindgreen, E., Veltman, P. (2005), Den Haag: Academic Service
•
“NEN-ISO/IEC 27002:2007 nl – Informatietechnologie - Beveiligingstechnieken - Code voor informatiebeveiliging”, Nederlands Normalisatie-instituut (www.nen.nl), 1 november 2007 http://www.nen.nl/web/Normshop/Norm/
•
“Stramien voor Assurance”, Nivra, website, jaartal onbekend http://www.nba.nl/hraweb/hra1/200901/html/38060.htm
•
“Special Publication 800-146 “Cloud Computing Synopsis and Recommendations”, NIST, mei 2012
1 april 2014
69
Versie 1.0
•
“Handreiking, normen voor de beheersing van uitbestede ICT-beheerprocessen” door de werkgroep Standaard Normenkader Beheersing en Beveiliging, Norea, 2008, http://www.norea.nl/Sites/Files/0000021661_NoreaPvIBhandreiking.pdf
•
“Cloud vraagt om zichtbaarheid en controle”, Olavsrud, T., 20 februari 2012, http://computerworld.nl/article/13526/cloud-vraagt-om-zichtbaarheid-en-controle.html
•
“Forecast: Public Cloud Services, Worldwide and Regions, Industry Sectors, 2009-2014”, Pring, 2010 https://www.gartner.com/doc/1378513
•
“Cloudstandaarden flink onder de maat”, Putter, 7 maart 2012, http://computerworld.nl/article/13561/-cloudstandaarden-flink-onder-de-maat-.html
•
“New Requirements for Security and Compliance Auditing in the Cloud”. Qualys, geraadpleegd op 16 januari 2014 via http://www.qualys.com/forms/whitepapers/compliance_auditing_cloud/
•
“Full virtualization technologies: guidelines for secure implementation and management”, Radack, S., 2011 http://csrc.nist.gov/publications/nistbul/April2011-ITL-Bulletin.pdf
•
“IT-beslissers zien cloudmogelijkheden vrij zoning in”, Roerdinkholder, J. , 19 juni 2013 http://www.automatiseringgids.nl/achtergrond/2013/12/it-beslissers-ziencloudmogelijkheden-vrij-zonnig-in
•
“The Cloud is ready for you, are you ready for the cloud?”, Stroh, S., Acker, O en Kumar, A., 2009 http://www.booz.com/media/uploads/Cloud_Is_Ready_for_You.pdf
•
“Rechten en plichten binnen cloud”, Tuil, van K,, 12 juli 2010 http://computerworld.nl/article/12088/rechten-en-plichten-binnen-cloud.html
•
“Marktwerking of martelwerktuig”, Wilders, Y, juni 2013 http://www.iia.nl/actualiteit/audit-magazine/archief
•
Whitepaper “MKB Servicedesk”, Cloud computing 1, jaartal onbekend https://www.sra.nl/~/media/Webzine/Spring/Documenten/Openbaar/ICT/Benut-je-onlinekansen-cloud-computing.pdf
•
“Virtualisatie is gevaar voor security”, Woude, E., 16 december 2013 http://www.computable.nl/artikel/opinie/virtualisatie/4949727/2333390/virtualisatie-isgevaar-voor-security.html
1 april 2014
70
Versie 1.0
•
“Outsourcing gaat weer gewoon over geld”, Zaal, R., 22 juni 2012, http://www.automatiseringgids.nl/nieuws/2012/25/outsourcing-gaat-weer-gewoon-overgeld
•
“Amazon versterkt zijn grip op de cloud”, Zaal, R., 14 november 2013 http://www.automatiseringsgids.nl/nieuws/2013/46/amazon-versterkt-zijn-grip-op-de-cloud
Gebruikte internetbronnen: http://automatiseringsgids.nl/ https://cloudsecurityalliance.org/ http://computable.nl/ http://enisa.com/ http://isaca.nl/ http://nen.nl/ http://norea.nl/ http://Platform voor Informatiebeveiliging.nl/ http://cloudsecurityalliance.nl/
1 april 2014
71
Versie 1.0