- Software as a Service Risico s en maatregelen bij SaaS leveranciers

- Software as a Service Risico s en maatregelen bij SaaS leveranciers Afstudeerscriptie Postgraduate IT Audit opleiding Vrije Universiteit Amsterdam Scriptienummer: 1017 Datum: 23-09-2010 Auteurs: Anouk Jessurun, Nikola Mirkovic Werkgever: Deloitte Bedrijfscoach: Dhr. Dave Klingens RE Begeleider VU: Dr. ing. Abbas Shahim MSc. RE

Inhoudsopgave 1 Introductie en aanleiding 4 1.1 Probleemstelling 5 1.2 Afbakening en beperkingen van het onderzoek 5 1.3 Onderzoeksaanpak 7 1.4 Leeswijzer 8 1.5 Lijst van definities 8 2 Wat is Software as a Service (SaaS)? 9 2.1 Ontwikkeling van SaaS 10 2.2 SaaS in relatie tot cloud computing 11 2.3 Toepassingen SaaS applicaties 13 2.4 Architectuur van SaaS 13 2.4.1 SaaS Data architectuur 15 3 Assurance bij SaaS omgevingen 16 4 Risico analyse toegepast op SaaS 18 5 Verschillen tussen SaaS en andere outsourcing diensten 20 5.1 Geïdentificeerde verschillen en analyse 20 5.2 Verschillen tussen SaaS en Application Service Provider (ASP) 23 6 Risico s voor SaaS leveranciers 25 6.1 Applicatie eigenschappen SaaS 25 6.2 Leveringsmodel bij SaaS 25 6.3 Applicatiebeheer 26 6.4 Toegankelijkheid 27 7 Maatregelen voor SaaS leveranciers 30 7.1 Applicatie Eigenschappen 31 7.2 Applicatie beheer 32 7.3 Toegankelijkheid 32 7.3.1 Algemene maatregelen 32 7.3.2 Toegankelijkheid applicatie 33 7.3.3 Toegankelijkheid data 34 7.3.4 Toegankelijkheid netwerk 34 8 Conclusie literatuuronderzoek en conceptueel risico raamwerk 35 9 Praktijkcasus: Toetsing en aanvulling conceptueel risico raamwerk 36 9.1 Praktijksituatie : SaaS leverancier X 36 9.2 Interviews 36 9.3 Risico s en maatregelen in de praktijk 37 9.4 Conclusie uit praktijkcasus 42 9.5 Hoofdconclusie 43 2

9.6 Beperkingen en vervolgonderzoek 43 9.7 Reflectie 44 10 Literatuurlijst 45 Bijlage 1: Praktijkscasus vragen 48 Bijlage 2 Conceptueel risico raamwerk 50 3

1 Introductie en aanleiding De toename van SaaS diensten en relevantie met IT audit gebied In een recente studie van het onderzoeksbureau Gartner is voorspeld dat opbrengsten door Software as a Service (SaaS) zich zullen verdubbelen tot 2012. Vorig jaar is er wereldwijd 6.4 miljard uitgegeven aan SaaS, een groei van 27% (Gartner Research, 2008). Software as a Service is een concept waarbij software in de vorm van een dienst wordt aangeboden via het internet. De applicatie is eigendom van de SaaS leverancier, die ook het technisch onderhoud en vaak het beheer van de applicaties uitvoert. SaaS applicaties worden ontwikkeld voor een specifiek bedrijfsproces of functioneel proces. SaaS applicaties beschikken over de flexibiliteit om functionaliteiten te configureren, waardoor ze geschaald kunnen worden naar de grootte van de business die ze ondersteunen. IDC heeft een rapport uitgebracht waarin zij hebben aangetoond dat de meeste SaaS oplossingen op dit moment worden gebruikt voor toepassingen waarbij de afnemer gewend is om bedrijfsgegevens aan derden te verstrekken, zoals bij salarisverwerking en boekhouding (Vermeulen P., 2006). Deze applicaties die vaak financiële gegevens bevatten behoren vaak tot de scope van financiële reviews, quick scans en IT audits die uitgevoerd worden in het kader van jaarrekening controles. De verwachte groei en de relevantie van de applicaties die volgens het SaaS model worden aangeboden, maakt het ontwikkelen van een conceptueel risico raamwerk van risico s en maatregelen voor IT-auditors interessant. Tevens is er in de literatuur weinig informatie beschikbaar voor het reviewen van SaaS omgevingen. In dit onderzoek hebben wij middels een risico gebaseerde aanpak de kenmerken van SaaS onderzocht, de verschillen tussen SaaS en andere outsourcing diensten in kaart gebracht en de risico s van SaaS omgevingen geidentificeerd en uiteindelijk een conceptueel risico raamwerk met risico s en maatregelen gepresenteerd. Uitdagingen en risico s voor SaaS leveranciers Er zijn vele uitdagingen waar leveranciers die SaaS diensten aanbieden mee te maken krijgen. Een recent onderzoek heeft aangetoond dat 50% van de beveiligingsinbreuken extern gerelateerd is (Deloitte, 2009a). Doordat SaaS applicaties via het internet benaderd worden, worden SaaS leveranciers met hogere beveiligingseisen geconfronteerd ten aanzien van de integriteit van data. Data wordt via het internet verzonden en er zullen maatregelen moeten worden getroffen om ongeautoriseerd gebruik te voorkomen. Een andere uitdaging met betrekking tot de vertrouwelijkheid is dat confidentiële data van klanten die dezelfde applicatie gebruiken kan uitlekken aan derde partijen indien er geen maatregelen worden getroffen. Naast de uitdagingen op het gebied van integriteit en vertrouwelijkheid zien wij ook op het gebied van beschikbaarheid risico s voor SaaS leveranciers. De SaaS leverancier is afhankelijk van zijn internet leverancier voor het leveren van de dienst. De SaaS applicaties worden onbereikbaar indien de internetverbinding wegvalt. De beschikbaarheid van een SaaS applicatie garanderen is één van de vele uitdagingen voor de leveranciers. 4

De bovenstaande uitdagingen wijzen erop dat maatregelen toegespitst op SaaS diensten nodig zijn. De combinatie van een toenemend aanbod van (financiële) SaaS diensten en de risico s voor de leveranciers leidt ertoe dat de SaaS leveranciers meer te maken zullen krijgen met reviews en IT-audits. Er zijn tot op heden nauwelijks (wetenschappelijke) onderzoeken over risico s en maatregelen voor SaaS leveranciers geweest. Hiermee is ook het perspectief van de IT-auditor onderbelicht. Tevens is nauwelijks bekend met welke aspecten IT-auditors rekening dienen te houden bij het uitvoeren van een risicoanalyse in het kader van SaaS reviews en audits en wat de specifieke maatregelen voor SaaS diensten zijn. Wij pogen middels een literatuuronderzoek en een praktijkcasus een conceptueel kader te introduceren dat een handvat biedt tijdens het identificeren van risico s en maatregelen bij het auditen en reviewen van SaaS leveranciers. Hiermee willen wij een bijdrage leveren op zowel wetenschappelijk als op het IT-Audit vakgebied. 1.1 Probleemstelling Onderzoeksvraag Wat zijn de verschillen tussen SaaS en andere applicatie outsourcing diensten en welk conceptueel risico raamwerk kan als handvat gebruikt worden om SaaS leveranciers te reviewen? Deelvragen Om de onderzoeksvraag te beantwoorden dienen de volgende deelvragen te worden beantwoord: 1. Wat zijn de verschillen tussen SaaS en andere applicatie outsourcing diensten? 2. Welke IT risico s zijn specifiek voor SaaS? 3. Welke maatregelen zijn er om de IT risico s bij SaaS te mitigeren? 1.2 Afbakening en beperkingen van het onderzoek Deze scriptie is als volgt afgebakend: De focus ligt op de verschillen tussen SaaS en andere, traditionelere vormen van applicatie outsourcing en welke risico s specifiek zijn voor SaaS omgevingen. Zie Figuur 1 voor een overzicht van de afbakening van deze SaaS specifieke risico s. Alleen de risico s die uit de eigenschappen van SaaS (ofwel verschillen met traditionele outsourcing) volgen, zijn meegenomen in de risico analyse. 5

Figuur 1: Afbakening SaaS specifieke risico's Er is een kwalitatieve risico analyse uitgevoerd in tegenstelling tot een kwantitatieve analyse. Er is geen uitputtend overzicht van risico s opgesteld. Er is onderzoek gedaan naar business to business SaaS applicaties en niet naar business to customer SaaS applicaties (bv. Google Docs). Risico s met betrekking tot de informatievoorziening zijn geïdentificeerd. De risico s die tijdens dit onderzoek voor SaaS omgevingen geïdentificeerd zijn, dienen als input voor het samenstellen van een conceptueel risico raamwerk van risico s en maatregelen. Dit conceptuele risico raamwerk bevat geen normen of beheersmaatregelen en is een conceptversie van een verzameling specifieke SaaS IT risico s en maatregelen. Het conceptuele risico raamwerk is bedoeld om een handvat te bieden bij het identificeren (vaak in planningsfase van reviews en IT audits) van specifieke ITrisico s en maatregelen in SaaS omgevingen. Het onderzoek richt zich op het perspectief van de IT-auditor op de SaaS leverancier. Het perspectief van de afnemer van de SaaS dienst komt nauwelijks aan bod. Hiervoor is gekozen omdat de SaaS applicaties gehost worden op de IT omgeving bij de leverancier. De SaaS leveranicer maakt geen gebruik maakt van IaaS (infrastructure as a service) of een PaaS (platform as a service) oplossing. De focus ligt op het SaaS leveringsmodel. De focus bij de praktijkcasus ligt op één Nederlandse leverancier van SaaS diensten. 6

1.3 Onderzoeksaanpak De onderzoeksaanpak die gehanteerd wordt bij dit onderzoek is afgebeeld in Figuur 2. De deelvragen en onderzoeksvraag zoals genoemd in 1.1 Probleemstelling komen overeen met de blokken in Figuur 2. Figuur 2: Onderzoeksaanpak Als onderdeel van een risico analyse (A) is allereerst een literatuurstudie uitgevoerd, waarin verschillen tussen SaaS en traditionele applicatie outsourcing diensten in kaart zijn gebracht. Deze verschillen kunnen leiden tot risico s, uit deze verschillen zijn IT risico s geïdentificeerd, waarbij passende maatregelen zijn onderzocht. Uit dit literatuuronderzoek komen specifieke risico s en maatregelen voor SaaS omgevingen voort (B). Uit de verzameling van risico s en maatregelen is vervolgens een conceptueel risico raamwerk samengesteld. Naast de literatuurstudie is een praktijkcasus bij een SaaS leverancier uitgevoerd. Er zijn interviews gehouden met de IT managers van de SaaS leveranier. Met de uitkomsten zijn de risico s en maatregelen uit de literatuurstudie gevalideerd en aangevuld (C). Het geheel van risico s en maatregelen uit de literatuur en praktijk vormen het conceptuele risico raamwerk (D). Hiermee is de onderzoeksvraag beantwoord. 7

1.4 Leeswijzer De opbouw van de scriptie is conform de bovengenoemde onderzoeksaanpak. Hoofdstuk 2 en 3 lichten het begrip SaaS en het perspectief van de IT-auditor toe. Hoofdstuk 4 zet de gebruikte risicomethodiek uiteen. Hoofdstuk 5 geeft antwoord op deelvraag 1 (Wat zijn de verschillen tussen SaaS en andere applicatie outsourcing diensten?). Hoofdstuk 6 geeft antwoord op deelvraag 2 (Welke IT risico s zijn specifiek voor SaaS?). Hoofdstuk 7 geeft antwoord op deelvraag 3 (Welke maatregelen zijn er om de IT risico s bij SaaS te mitigeren?). Hoofdstuk 8 en 9 beantwoorden de onderzoeksvraag (Wat zijn de verschillen tussen SaaS en andere applicatie outsourcing diensten en welk conceptueel risico raamwerk kan als handvat gebruikt worden om SaaS leveranciers te reviewen?) 1.5 Lijst van definities Assurance Onafhankelijke professionele diensten die de kwaliteit van informatie, of zijn context, verbeteren voor besluitvormers. Applicatie Een applicatie is een computer programma waarin één of meerdere bedrijfsprocessen geautomatiseerd ondersteund dan wel uitgevoerd worden en/of bedrijfsgegevensverzamelingen vastgelegd worden. Informatiebeveiliging Informatiebeveiliging is gericht op het waarborgen van de gewenste kwaliteit van informatie en informatievoorziening. De kwaliteitscriteria waar informatiebeveiliging zich expliciet mee bezig houdt zijn: beschikbaarheid (continuïteit), integriteit (betrouwbaarheid) en vertrouwelijkheid (exclusiviteit). Risico Risico in relatie tot informatievoorziening is de gemiddelde schade over een gegeven tijdsperiode die kan worden berokkend doordat één of meer bedreigingen leiden tot een verstoring van één of meer objecten van de informatievoorziening (Overbeek, 2001). SaaS leverancier IT leveranicer welke SaaS diensten aanbiedt. SaaS afnemer Afnemer van SaaS diensten, ook wel klant. 8

2 Wat is Software as a Service (SaaS)? Er zijn verschillende definities van Software as a Service in de literatuur in omloop. De onderstaande definitie is afkomstig uit een wetenschappelijk artikel gepubliceerd in 2005 dat poogt een definitie van SaaS te geven. Software as a Service is online toegang (ongeacht tijd en locatie) tot een op afstand beheerde applicatie. SaaS staat parallel gebruik toe van eenzelfde applicatie door een groot aantal onafhankelijke gebruikers (klanten), biedt een aantrekkelijke betalingsstructuur vergeleken met de toegevoegde waarde voor de klant en een maakt nieuwe en innovatieve software mogelijk (Sääksjärvi, M., Lassila, A., and Nordström, H., 2005). Ook is internationaal IT-marktonderzoeks- en adviesbureau IDC tot een definitie van de term Software as a Service gekomen: SaaS verwijst naar de continue ondersteuning van applicaties waarbij de belangrijkste waarde voor de klant bestaat uit het wegvallen van activiteiten met betrekking tot onderhoud en beheer. SaaS heeft de volgende kenmerken: De klant heeft toegang tot de standaard applicatie via een netwerk en beheert de applicatie via het netwerk. De activiteiten worden beheerd vanuit centrale locaties in plaats van bij de klant, waarbij de klanten via het netwerk toegang hebben tot de applicaties. Delivery is gebaseerd op een one-to-many model. Dit is inclusief de architectuur, tariefstructuur, partnering en het beheer (Vermeulen, 2005). Hoewel de bovenstaande omschrijvingen het concept SaaS grotendeels afdekken, zijn deze voornamelijk vanuit het perspectief van de afnemer gedefinieerd. Onderzoeksbureau Gartner heeft een neutralere definitie opgesteld: Software die eigendom is van, geleverd wordt door en op afstand beheerd wordt door één of meerdere partijen. De leverancier levert de software gebaseerd op gestandaardiseerde programmatuur en data definities, waarbij de software wordt afgenomen in een one-to-many model door alle gecontracteerde afnemers gebaseerd op een pay-for-use of subscirption model (Desisto, Pring, 2009). SaaS moet niet gezien worden als een product of architectuuroplossing. SaaS staat meer voor een concept voor de manier waarop omgegaan wordt met software. De term SaaS, zoals gebruikt in deze scriptie, is een concept dat niet kan worden beschreven met één zin, daarom zullen wij het met een aantal kenmerken definiëren. De term Software as a Service, zoals gebruikt in deze scriptie bevat de volgende kenmerken: SaaS applicaties zijn webapplicaties. Deze applicaties zijn speciaal ontwikkeld om vanuit de webbrowser mee te werken. Er is geen software bij de client nodig om de applicatie te kunnen benaderen. Voor SaaS applicaties is een internet verbinding vereist. Het aanbod van een SaaS dienst verloopt volgens het one-to-many model. De SaaS leverancier biedt meerdere klanten dezelfde (standaard)applicatiesoftware en meerdere klanten maken gebruik van dezelfde infrastructuur en fysieke database. SaaS leverancier is de eigenaar en licentiehouder van de SaaS applicatie. Een SaaS applicatie wordt beheerd door één leverancier. Het betaalmodel is op basis van gebruik of abonnementsstructuur. 9

De bovenstaande kenmerken zijn tot stand gekomen door een combinatie van de eerder genoemde definities. Dit betekent echter niet dat dit een uitputtende lijst van de kenmerken van SaaS is, maar ze bieden echter wel een referentiekader voor het begrip SaaS. 2.1 Ontwikkeling van SaaS Om een begrip te krijgen van SaaS en relatie met de traditionelere systemen is het van belang dat er een inzicht wordt verkregen in de geschiedenis en het tot stand komen van SaaS. Daarom is in deze paragraaf de ontwikkeling van SaaS uiteengezet. Sinds het begin van de jaren 90 heeft het internet zich snel ontwikkeld op het gebied van snelheid en connectiviteit waardoor steeds meer toepassingen van het internet mogelijk werden. De technische mogelijkheden van het internet en de behoefte van klanten die niet de middelen hadden om dure ERP pakketten en applicaties aan te schaffen hebben geleid tot het ontstaan van de Application Service Providers (hierna: ASP s). Het traditionele software model, waarbij organisaties software kochten van leveranciers, in eigen data centers installeerden en zelf onderhoud pleegden werd doorbroken door ASP s. Door de software in eigen beheer te nemen en het aan te bieden aan hun klanten via het internet, zou dit moeten leiden tot voordelen zoals lagere onderhouds- en implementatiekosten voor de klant. ASP s installeren en beheren voornamelijk veel aparte klant-specifieke applicaties, hieraan kleven een aantal nadelen zoals hogere kosten voor onderhoud en er is minder kennis per applicatie aanwezig. Klanten van ASP providers moeten hierdoor toch technische kennis over de applicaties bezitten om de werking ervan te borgen. Ook werd de schaalbaarheid van de ASP diensten niet (volledig) benut; meer gebruikers en meer klanten leidden vaak ook tot hogere beheerskosten (Greschler, Mangan, 2002). Daarnaast werden door ASP s vaak traditionele software pakketten gekocht of overgenomen van de klant en beschikbaar gemaakt via het internet; het updaten en kosteffectief beheren van deze applicaties werd hierdoor lastiger (Nitu, 2009; Sääksjärvi et al, 2005). In 2001 dook de term SaaS op voor de eerste keer op in het artikel, "Strategic Backgrounder: Software as a Service", gepubliceerd door Software & Information Industry's (SIIA) ebusiness Division (SIIA, 2001). Een aantal jaren later lanceerden een aantal grote SaaS leveranciers (Salesforce, Microsoft, Oracle) de eerste SaaS toepassingen. De voordelen van SaaS zoals het niet hoeven aan te schaffen van software licenties (voor de klant), het snel kunnen aanpassen van functionaliteiten en het kosteffectief beheren van applicaties die voor meerdere klanten beschikbaar zijn (voor leverancier) zorgen ervoor dat SaaS steeds breder wordt geaccepteerd. In Figuur 3 is de evolutie van SaaS weergegeven; vanuit traditionele software (in-house) naar ASP s tot aan SaaS. Het is te zien dat het succes van SaaS ook te danken is aan de ontwikkeling van het internet en de virtualisatie. Het internet vanwege de snelheid en de toenemende toegankelijkheid wereldwijd en virtualisatie maakte het technisch mogelijk de webapplicaties schaalbaar te maken. 10

Figuur 3: De evolutie van SaaS 2.2 SaaS in relatie tot cloud computing Een concept dat onlosmakelijk verbonden is met SaaS is cloud computing. Cloud computing is echter een breder begrip dan SaaS, de cloud verwijst naar het internet en de infrastructuur die aan het oog van de gebruiker worden ontrokken. Cloud computing wordt door het National Institute of Standards and Technology (NIST) gedefinieerd als: Cloud Computing is een model voor het snel beschikbaar stellen van on-demand netwerktoegang tot een gedeelde pool van configureerbare IT-middelen (zoals netwerken, servers, opslag, applicaties en diensten), met een minimum aan management inspanning of interactie met de aanbieder. (Mell, 2009). De vijf essentiële kenmerken van cloud computing volgens NIST zijn: on demand self service, toegang via netwerk, gedeeld gebruik van middelen (resource pooling), hoge mate van elasticiteit en measured services. NIST heeft voor elk van deze kenmerken een uitgebreide beschrijving gegeven (Mell, 2009). Er zijn doorgaans drie soorten diensten (leveringsmodellen) van Cloud computing : - Infrastructure as a Service (IaaS) - IaaS is een dienst waarbij ITinfrastructuurvoorzieningen (opslag, processors, besturingssystemen, virtuele netwerken) gevirtualiseerd worden aangeboden via een netwerk (internet), waarbij de afnemer geen controle heeft over de onderliggende hardware en daar ook geen beheer over voert. - Platform as a Service (PaaS) - PaaS is een dienst waarbij applicatiehosting voorzieningen (applicatie server, portal, ESB, DBMS) als platform wordt aangeboden via een netwerk (internet), waarbij de afnemer geen controle heeft over de platformtechnologie en de onderliggende infrastructuur en daar ook geen beheer over voert. De afnemer kan zelf zijn eigen applicaties op het platform laten hosten en integreren. Op het platform kunnen de afnemers ook SaaS diensten onderling en met eigen applicaties integreren. Er is voor de afnemers slechts een beperkte mogelijkheid tot configuratie van de platformfunctionaliteit. 11

- Software as a service (SaaS) - SaaS is een dienst waarbij applicatiefunctionaliteit wordt aangeboden via het internet, waarbij de afnemer geen controle heeft over de applicatietechnologie en het onderliggende platform en daar ook geen beheer over voert. De bovenstaande leveringsmodellen kunnen zowel apart als naast elkaar worden geïntegreerd. In Figuur 4 is het overzicht van de leveringsmodellen als onderdeel van de cloud infrastructuur weergegeven. Deze leveringsmodellen kunnen gezien worden als verschillende lagen in een IT infrastructuur waarbij iedere laag diensten aan de direct daarboven liggende laag levert. Ook maakt iedere laag gebruik van de diensten die door de direct daar onderliggende laag wordt geleverd en voegt daar functionaliteit (waarde) aan toe. De focus van dit onderzoek ligt op een deel van de cloud infrastructuur, namelijk SaaS. Cloud infrastructuur SaaS Focus IaaS PaaS Figuur 4 Cloud infrastructuur en delivery modellen Naast de bovenstaande drie diensten heeft NIST vier deployment modellen gedefinieerd: - Community Cloud: Een cloudinfrastructuur die wordt gebruikt door verschillende organisaties en die een specifieke groep businesspartners ondersteunt. - Private Cloud: Een private cloud is een cloudinfrastructuur die uitsluitend wordt geëxploiteerd voor een bepaalde organisatie. - Public Cloud: Een public cloud is een cloudinfrastructuur die ter beschikking wordt gesteld aan een grote markt. De afnemers van de dienst zijn geen eigenaar van de middelen. - Hybrid Cloud: Een hybrid cloud is een cloudinfrastructuur die bestaat uit een samenstelling van twee of meer clouds (private, community, public) die ieder afzonderlijk bestaan, maar met elkaar zijn verbonden door middel van gestandaardiseerde technologie om interoperabiliteit en portabiliteit van gegevens en van applicaties te ondersteunen. SaaS kan worden uitgerold op alle vier deployment modellen, maar volgens de definitie van SaaS in dit onderzoek waarbij meerdere klanten door één applicatie bediend worden (one-tomany) valt de private cloud buiten de reikwijdte van dit onderzoek. Samenvattend kunnen we stellen dat cloud computing en SaaS geen synoniemen zijn. Cloud computing is een model dat zicht richt op de inrichting van de technische infrastructuur en SaaS is een leveringsmodel. Indien een applicatie wordt beheerd in een cloud infrastructuur, hoeft dit er niet op te duiden dat dit een SaaS applicatie is. Aan de andere kant is het wel zo dat alle SaaS applicaties onderdeel zijn van een cloud infrastructuur. 12

Ook kunnen we stellen dat bij het SaaS leveringsmodel, in tegenstelling tot IaaS en PaaS, de afnemer de minste controle en verantwoordelijkheden heeft (t.a.v. de IT omgeving) en de SaaS leverancier de meeste. Bij SaaS dient namelijk de leverancier alle lagen (netwerk, database, applicatie) van de gehele IT omgeving te beheren. Hier kunnen diverse risico s aan verbonden zijn, waar zowel IT-auditors als SaaS leveranicers in geïnteresseerd zijn. Dit is ook één van de hoofdredenen dat de focus van dit onderzoek op SaaS is gericht. 2.3 Toepassingen SaaS applicaties Verscheidene onderzoeken zijn reeds uitgevoerd om het gebruik van SaaS te onderzoeken. Volgens een onderzoek van IDC wordt SaaS voor verschillende doeleinden gebruikt, in de meeste gevallen wordt SaaS ingezet om toegang te krijgen tot nieuwe functionaliteit (45%). Daarnaast wordt SaaS ingezet om reeds bestaande functionaliteit te vervangen (32%) of om een nieuwe applicatie toe te voegen (20%). Volgens het IDC rapport wordt SaaS vooral gebruikt om kosteffectief toegang te krijgen tot nieuwe functionaliteit en niet zo zeer om de bestaande licentie kosten te besparen (Vermeulen, 2006). Naast het onderzoek van IDC naar de verschillende doeleinden van SaaS heeft Gartner ook onderzoek gedaan naar de toepassing van SaaS bij ondersteuning van bedrijfsprocessen. Uit dit onderzoek komt naar voren dat SaaS applicaties vooral worden toegepast voor het ondersteunen van het Customer Relationship Management Proces (CRM) en het Human Resource (HR). Daarnaast heeft Gartner ook onderzocht in welke bedrijfssegmenten de SaaS applicaties het meest worden toegepast. In dit onderzoek kwam naar voren dat SaaS vooral wordt toegepast in technologiebedrijven, maar ook bij financiële instellening en utility bedrijven wordt er gebruik gemaakt van SaaS applicaties. (Figuur 5) Figuur 5: Gebruik van SaaS bij ondersteuning van bedrijfsprocessen en in bedrijfssegmenten 2.4 Architectuur van SaaS De basis van SaaS is de multi-tenant architectuur. Bij het multi-tenant model zijn de ITarchitectuur zodanig opgebouwd dat meerdere afnemers ( tenants ) bedient kunnen worden. In het multi-tenant model heeft de SaaS leverancier alle software en data van de klanten op 13

een centrale locatie opgeslagen en kunnen zij via gescheiden kanalen de gewenste softwarefunctionaliteit gebruiken en de data benaderen. Hierbij is de SaaS leverancier verantwoordelijk voor het juist aanleveren en transporteren van de diensten. De diensten worden door de klanten afgenomen als webdiensten (Chung, 2009). Ondanks dat er in een multi-tenant architectuur gebruik wordt gemaakt van één technology stack (servers, switches, bandbreedte, data opslag, etc) en er één instantie van programmacode wordt gebruikt, zal de gebruikerservaring van klanten gelijk moeten zijn aan een gebruiker die een applicatie met één gebruikersinterface gebruikt. De multi-tenant architectuur optimaliseert het gebruik van een applicatie door een beperkte set van computer resources te gebruiken voor een groot aantal klanten (Fishteyn, z.d.). In Figuur 6 wordt de multi-tenant architectuur schematisch weergegeven. Andere varianten van SaaS architecturen ontstaan wanneer afnemers van meerdere leveranciers SaaS diensten afnemen voor een volledige applicatieportfolio. In het geval dat afnemers hun bedrijfsdata verspreid hebben over meerdere SaaS leveranciers en locaties spreekt men van een multi-vendor model. De verschillende SaaS diensten worden door de klanten al dan niet geïntegreerd afgenomen. Indien de SaaS diensten in grotere SaaS pakketten worden afgenomen van IT-integrators / resellers wordt het een multi-instance model genoemd. De klant heeft dan één contactpunt, de IT-integrator/reseller, dit zijn meestal grote softwarebedrijven en brancheorganisaties die verschillende diensten integreren tot grotere SaaS pakketten. Hierbij wordt de SaaS oplossing door meerdere partijen geleverd, waarbij de partijen die software leveren op hun beurt weer onderaannemers hebben die diensten zoals dataopslag of CPU capaciteit leveren. De data van de afnemers zijn verspreid over meerdere locaties, waarbij de data niet noodzakelijkerwijs zijn opgeslagen bij de betreffende softwareleverancier. Figuur 6: Multi-tenant architectuur Het kan ook voorkomen dat afnemers van meerdere SaaS integrators SaaS oplossingen afnemen. Deze afnemers zullen dan meestal grote internationale ondernemingen zijn. Deze SaaS architectuur wordt dan multi-integration model genoemd. Bij een multi-integration model leveren meerdere SaaS-integrators met verschillende onderaannemers een deel van de 14

software diensten aan, waarbij een deel van de diensten intern bij de klanten blijft. De data zijn dan verspreid over meerdere externe en interne locaties (Chung, 2009). In dit onderzoek richten we ons op SaaS applicaties die beschikken over een multi-tenant architectuur, dit is de meest basale SaaS architectuur. 2.4.1 SaaS Data architectuur In een SaaS omgeving, met name in een multi-tenant architectuur, worden data die horen bij de software bij de SaaS leverancier opgeslagen en beheerd. Voor de opslag van data worden verschillende data modellen gebruikt, waarvan de meest voorkomende zijn: geïsoleerde databases, geïsoleerde schema s en gedeelde schema s. Bij geïsoleerde databases, staan databases van verschillende klanten op een server, maar zijn deze logisch van elkaar gescheiden. In het geval van geïsoleerde schema s, delen de klanten de database, maar beschikken over een eigen schema in de database. In SaaS omgevingen kan het ook voorkomen dat de klanten de schema s delen, daarbij delen zij niet alleen de database, maar ook de schema s. In dit geval heeft iedere klant zijn eigen ID in de database (Chung, 2009). In Figuur 7 worden deze drie data modellen geïllustreerd. Figuur 7: Verschillende data architecturen van SaaS (Chung, 2009) 15

3 Assurance bij SaaS omgevingen In voorgaande hoofdstukken is gebleken dat SaaS een nieuwe technologische ontwikkeling is waarbij het aantal afnemers en het gebruik snel is gegroeid de afgelopen jaren. Daarnaast blijkt dat de afnemers uit veel verschillende industrieën komen en dat het gebruik de komende jaren zal stijgen. In toenemende mate zullen dan ook SaaS leveranciers van klanten (en hun IT-auditor) de vraag krijgen in hoeverre ze in beheersing zijn van hun bedrijfsprocessen. Voor IT-auditors is het daarom relevant om na te gaan welke vormen van third party assurance gebruikt kunnen worden bij het reviewen of auditen van SaaS ITomgevingen. Third party Assurance is het geven van zekerheid over de kwaliteit van de beheersing van deze processen van een SaaS leverancier. In dit hoofdstuk komen de vormen van Third Party Assurance aan bod en reeds beschikbare richtlijnen voor het verlenen van assurance in SaaS omgevingen. Third Party Assurance zoals SAS 70 of TPM s (Third Party Assurance aanpak) worden steeds vaker gebruikt voor het rapporteren van de interne beheersmaatregelen bij outsourcing leveranciers. Dit komt ook met name door de huidige gereguleerde omgeving welke nieuwe uitdagingen met zich mee brengt voor afspraken omtrent outsourcing, in het bijzonder met betrekking tot de Sarbanes-Oxley Act of 2002 ( SOX ). Daarnaast kan gebruik gemaakt worden van certificatie. Certificeren is een waarmerkingproces dat er toe leidt dat een organisatie of een product een kwaliteitswaarmerk krijgt, een soort stempel van betrouwbaarheid. Voorbeelden van certificaten zijn de certificaten op basis van de Code van Informatiebeveiliging, SysTrust en Webtrust. In juni 2010 heeft Gartner een artikel gepubliceerd waarin zij aangeven dat IT-leveranciers SAS 70 standaard onterecht als een vorm van certificering gebruiken. Gartner zegt dat de leveranciers de klanten misleiden door tevens te beweren dat SAS 70 veiligheid, privacy en continuïteit garandeert. Volgens Gartner mag een koper van een dienst met een security certificaat verwachten dat de degene die het certificaat heeft verstrekt systematisch een standaard en een uitgebreide lijst van processen en technische issues heeft getoetst. Gartner benadrukt dat dit niet het geval is bij het uitvoeren van een SAS 70. Ze geven aan dat de SAS 70 audit geen gap analyse is die een vergelijking maakt tussen hetgeen dat wordt uitgevoerd tegenover een best practice of necessary practice. Zij benadrukken dat de SAS 70 niet voorschrijft welke controls geëvalueerd dienen te worden in een bepaalde situatie en dat de SAS 70 slechts een richtlijn is voor de voorbereiding, procedure en te hanteren formaat van een audit rapport (Gartner Research, 2010). Volgens Gartner zijn niet traditionele omgevingen, met name multi-tenant (zoals SaaS) omgevingen, moeilijk in kaart te brengen, omdat deze omgevingen vaak specifieke technische kwetsbaarheden hebben en specifieke veiligheidsprocessen vereisen die niet in een generiek model als een best practice te vatten zijn. Volgens Gartner wordt SAS 70 nauwelijks gebruikt voor het toetsen van het ontwerp (functionaliteit en architectuur) en bouw van een SaaS omgeving en geeft het vaak geen zekerheid over de robuustheid van de SaaS omgeving, terwijl deze aspecten juist nauw verbonden zijn met informatiebeveiliging. Uit bovenstaand blijkt dat er behoefte is aan richtlijnen voor het verlenen van assurance in SaaS omgevingen. De Information Systems Audit and Control Association (ISACA), de Amerikaanse beroepsvereniging van IT-auditors heeft in augustus 2010 de Cloud 16

Computing Management Audit/Assurance Program uitgebracht (ISACA, 2010b). Dit audit programma kan als een tool gebruikt worden tijdens het auditen van organisaties die cloud computing gebruiken. De focus van het uitgebrachte document ligt op: De invloed van governance op cloud computing. De contractuele afspraken tussen de cloud leverancier en de klant. Beheersmaatregelen (Cloud controls) specifiek gericht op cloud computing. Deze beheersmaatregelen welke onderdeel maken van het cloud computing audit programma zijn in te delen in 3 categorien: Planning and Scoping the Audit, Governing the Cloud en Operating in the Cloud. Daarnaast beschrijft het document dat de gedefinieerde cloud controls niet als een complete set van maatregelen moeten worden gezien, maar meer als startpunt bij audits gebruikt kunnen worden en aangepast dienen te worden aan de situatie van de cloud omgeving. Er zijn een aantal fundamentele verschillen tussen het onderzoek in deze scriptie en het uitgebrachte document van de ISACA: Het audit programma richt zich voornamelijk op de gehele Cloud omgeving en niet specifiek op de SaaS omgeving. Zie paragraaf 2.2 van hoofdstuk 2 voor de relatie tussen Cloud computing en SaaS. Er wordt een set van beheersmaatregelen in het audit programma weergegeven waarbij niet aangegeven is welke risico s hiermee afgedekt worden. Ons onderzoek richt zich juist op de risico s (die uit de verschillenanalyse voortkomen) en maatregelen. Een groot deel van het audit programma heeft een klant focus in plaats van een leveranciers focus. Ons onderzoek richt zich op het perspectief van de leverancier. 17

4 Risico analyse toegepast op SaaS In voorgaand hoofdstuk is door Gartner aangegeven dat een SAS 70 geen richtlijnen geeft tegen welke normen SaaS omgevingen geaudit dienen te worden, er is daarom volgens Gartner behoefte aan een gedegen risico analyse specifiek bij de SaaS leverancier. Uit voorgaande hoofdstuk blijkt ook dat het bij SaaS omgevingen van belang is dat IT-auditors bij SaaS omgevingen specifieke toegespitste maatregelen gebruiken in het kader van het verstrekken van certificaten of het uitvoeren van een SAS 70. Dit is niet anders bij reviews of jaarrekeningcontroles; daarom dient een gedegen risico analyse uitgevoerd te worden alvorens men een normenkader met beheersmaatregelen zou kunnen toepassen. De ISACA geeft tevens in hun IT-audit richtlijnen weer dat IT-auditors tijdens de planningsfase van een audit een risico gebaseerde aanpak dienen te gebruiken (ISACA, 2010a). Figuur 8: Deloitte risico management en focus (Deloitte, 2009b) De toegepaste risico analyse in dit onderzoek is gebaseerd op een risico gebaseerde aanpak zoals deze wordt gehanteerd bij Deloitte. Deloitte (Deloitte, 2009b) ziet risicomanagement als een proces van systematische analyse van risico s waaraan een organisatie bloot staat. In het kader van risicomanagement heeft Deloitte een risico framework ontwikkeld, genaamd de Risk Intelligent Enterprise. Met dit raamwerk krijgen organisaties het vermogen in de hele organisatie risico s systematisch te identificeren, meten, managen, rapporteren en monitoren. Binnen de Risk Intelligent Enterprise zijn drie componenten te onderscheiden: Risk governance (o.a. strategische beslissingen), Risk infrastructure and management (o.a. opstellen van een risico programma) en Risk ownership (o.a.het risico proces). Met name 18

het component Risk ownership geeft middels een risico proces aan hoe invulling kan worden gegeven aan het systematisch analyseren van risico s. Onderstaand zijn de stappen van het risico proces toegelicht (zoals afgebeeld in Figuur 8), waarbij wordt aangegeven hoe deze stappen bij de risico analyse van SaaS zijn uitgewerkt: 1. Identify Risks: In deze stap is een gapanalyse uitgevoerd, waarmee verschillen tussen SaaS en traditionele applicatieoutsourcing zijn geïdentificeerd (zie hoofdstuk 5). Uit deze verschillen zijn dan de (bedrijfsrisico s en IT) risico s die specifiek gerelateerd aan SaaS zijn geïdentificeerd. De risico identificatie vindt plaats middels een literatuurstudie (zie hoofdstuk 6). 2. Assess & Evaluate: In deze stap zijn de IT-risico s middels een praktijkcasus gevalideerd en aangevuld. Er is bij een SaaS leverancier nagegaan in hoeverre de ITrisico s voorkomen in de praktijk (zie hoofdstuk 9). 3. Integrate risks: IT risico s uit stap 2 zijn opgenomen in het conceptuele risico raamwerk (zie Figuur 11). 4. Respond to risks: Volgens het Risk Intelligent Enterprise raamwerk kan er op risico s op vier verschillende manieren worden gereageerd:vermijden, mitigeren, overdragen en accepteren. Middels passende maatregelen uit de literatuurstudie en een praktijkcasus is aandacht gegeven aan het mitigeren van risico s. De laatste twee stappen van het risico proces Design, Implement & Test controls en Monitor, Assure & Escalate, vallen buiten de reikwijdte van dit onderzoek. Zoals aangegeven en toegelicht in hoofdstuk 1.2, Afbakening en beperkingen van het onderzoek zijn geen beheersmaatregelen gedefinieerd. 19

5 Verschillen tussen SaaS en andere outsourcing diensten Wat is er anders aan Software as a Service? Is het weer de zoveelste variant op applicatie outsourcing of is het wezenlijk anders? In dit hoofdstuk hebben we verschillen tussen de traditionelere applicatie outsourcing en SaaS onderzocht en in kaart gebracht. SaaS is reeds in hoofdstuk 2 gedefinieerd. Om een adequate vergelijking te kunnen maken is eerst beschreven wat wij in deze scriptie onder het begrip traditionele applicatie outsourcing verstaan. Dit hoofdstuk heeft niet de intentie om alle verschillen uitputtend op te sommen, de bedoeling is om inzage te geven in de belangrijkste verschillen tussen SaaS en traditionele applicatie outsourcing. Deze verschillen dienen als basis voor de identificatie van specifieke SaaS risico s. De definitie van traditionele applicatie outsourcing die in deze scriptie wordt gehanteerd, heeft de volgende kenmerken: Traditionele applicaties zijn client-server applicaties. De lokaal geïnstalleerde client applicaties communiceren via het intranet met een centrale server. Traditionele applicaties kunnen intern ontwikkeld zijn door de IT afdeling van de klant of de licenties van de applicaties zijn aangeschaft bij een software leverancier In traditionele applicatie outsourcing heeft de klant de mogelijkheid om de volgende diensten van de applicatie outsourcing leverancier af te nemen: hosting, technische en/of functioneel applicatiebeheer en applicatieonderhoud. De klant kan er ook voor kiezen zelf technisch en functioneel applicatiebeheer uit te voeren of applicatie onderhoud te laten uitvoeren door de software leverancier. 5.1 Geïdentificeerde verschillen en analyse Als we de kenmerken van traditionele applicatie outsourcing naast de kenmerken van SaaS leggen zoals beschreven in verschillende literatuurstudies komen we tot een overzicht van verschillen zoals afgebeeld in Figuur 9. De kolom genaamd Onderwerp bevat de onderwerpen waarop SaaS verschilt met traditionele applicatie outsourcing, zoals gevonden in verscheidene literatuurbronnen. Op basis van deze onderwerpen en de analyse van gevonden verschillen, zijn de volgende vier categorieën ontstaan waarop de verschillen kunnen worden ingedeeld: Applicatie eigenschappen: De eigenschappen van de applicaties zoals type applicatie en software architectuur zijn onderdeel van deze categorie. Leveringsmodellen: Het licentiemodel en betalingsmodel zijn onderdeel van deze categorie. Applicatiebeheer: Alle kenmerken met betrekking tot beheer zijn onderdeel van deze categorie zoals software ontwikkeling, code aanpassingen en beheren van upgrades. Toegankelijkheid. Alle kenmerken die te maken hebben met de toegang tot de applicatie of database zijn onderdeel van deze categorie. 20