- 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

2

Introductie en aanleiding

4

1.1 1.2 1.3 1.4 1.5

5 5 7 8 8

Probleemstelling Afbakening en beperkingen van het onderzoek Onderzoeksaanpak Leeswijzer Lijst van definities

Wat is Software as a Service (SaaS)? 2.1 2.2 2.3 2.4

Ontwikkeling van SaaS SaaS in relatie tot cloud computing Toepassingen SaaS applicaties Architectuur van SaaS 2.4.1 SaaS Data architectuur

9 10 11 13 13 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 5.2 Verschillen tussen SaaS en Application Service Provider (ASP)

20 23

Risico’s voor SaaS leveranciers

25

6.1 6.2 6.3 6.4

25 25 26 27

6

7

Applicatie eigenschappen SaaS Leveringsmodel bij SaaS Applicatiebeheer Toegankelijkheid

Maatregelen voor SaaS leveranciers

30

7.1 Applicatie Eigenschappen 7.2 Applicatie beheer 7.3 Toegankelijkheid 7.3.1 Algemene maatregelen 7.3.2 Toegankelijkheid applicatie 7.3.3 Toegankelijkheid data 7.3.4 Toegankelijkheid netwerk

31 32 32 32 33 34 34

8

Conclusie literatuuronderzoek en conceptueel risico raamwerk

35

9

Praktijkcasus: Toetsing en aanvulling conceptueel risico raamwerk

36

9.1 9.2 9.3 9.4 9.5

36 36 37 42 43

Praktijksituatie : SaaS leverancier X Interviews Risico’s en maatregelen in de praktijk Conclusie uit praktijkcasus Hoofdconclusie 2

9.6 Beperkingen en vervolgonderzoek 9.7 Reflectie

43 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

Onderwerp

SaaS

Traditionele applicatie outsourcing

Applicatie Eigenschappen Type applicatie

Web applicatie

Client – Server applicatie

Software architectuur

‘one-to-many’ (‘multi-tenant’)

‘one-to-one’

Leveringsmodel Licentiemodel

De software licentie is eigendom De software (licentie) is eigendom van de van de leverancier klant

Betalingsmodel

Betalen-per-gebruik/ ‘Subscription’

Onderhoudskosten

Applicatie beheer Code aanpassingen mogelijk

SaaS leverancier

Klant, Software leverancier

Software ontwikkeling

SaaS leverancier

Door leverancier of interne IT afdeling

Beheer van upgrades

SaaS leverancier

Klant, Software leverancier

Klanten hebben geen toegang tot servers en databases

Klanten hebben vaak wel toegang tot servers en databases

Toegankelijkheid van interne ICT afdeling (bij de klant)

Toegankelijkheid Data architectuur

Toegang tot de applicatie

-Geïsoleerde database (per klant) - Geïsoleerde schema’s - Gedeelde schema’s

Dedicated database server (per klant)

Internet

Intranet

Figuur 9: Vergelijking eigenschappen SaaS en traditionele applicatie outsourcing

Applicatie eigenschappen Applicatie outsourcing beperkt zich doorgaans tot één applicatie voor één enkel proces voor één enkele afnemer. SaaS oplossingen daarentegen bieden meerdere applicaties voor meerdere bedrijfsprocessen aan (Chung M., 2009). De SaaS applicaties worden met name aangeboden volgens het ‘multi-tenant’ model, waarbij de IT –componenten gebouwd zijn om meerde afnemers (‘tenants’) te bedienen. Volgens onze SaaS definitie zijn SaaS applicaties altijd web-applicaties, waarbij alle software en bedrijfsdata van klanten door de SaaS 21

leveranciers doorgaans op een centrale locatie worden opgeslagen. De SaaS leverancier benut het schaal voordeel, door verschillende afnemers met dezelfde IT componenten te bedienen. Een overzicht van de verschillen in applicatie eigenschappen bij SaaS en applicatie outsourcing is te zien in Figuur 9. Leveringsmodellen Bij traditionele applicatie outsourcing is de klant eigenaar van de applicatie, terwijl bij SaaS de SaaS leverancier eigenaar is van de applicatie. Bij traditionele applicatie outsourcing heeft de klant licenties van een applicatie gekocht bij een software leverancier of beschikt deze over een applicatie die door zijn interne IT afdeling is ontwikkeld. De klant besteedt de applicatie uit aan de applicatie outsourcings leverancier, die neemt de applicatie ‘inhuis’ en voert het beheer en onderhoud aan de applicatie uit. In een SaaS omgeving is de SaaS applicatie eigendom van de SaaS leverancier en draait op de infrastructuur van de SaaS leverancier. Bij een SaaS leveringsmodel is de softwarefabrikant dus ook degene die de infrastructuur beschikbaar stelt en het technisch beheer en onderhoud van de applicatie voor zijn rekening neemt (Kouwenberg F., Burgering R., 2008). De SaaS leverancier voert in sommige gevallen ook het functioneel applicatiebeheer uit. Bij een SaaS leveringsmodel wordt de software betaald via een betalen-per-gebruik of een abonnementsconstructie, ook wel ‘subscription’ genoemd (Vroom M., 2007). Bij traditionele applicatie beheer kan de klant applicaties outsourcen die hij heeft aangekocht bij een softwareleverancier. Indien de klant gebruik wil maken van nieuwe versies van de applicatie kan hij een softwarecontracht afsluiten bij de softwareleverancier. (Kouwenberg F., Burgering R., 2008) Een overzicht van de verschillen in leveringsmodellen bij SaaS en applicatie outsourcing is te zien in Figuur 9. Applicatiebeheer In de verschillen met betrekking tot de leveringsmodellen kwam reeds naar voren dat de SaaS leverancier de eigenaar is van de SaaS applicatie. De SaaS leverancier voert ook de wijzigingen uit aan de SaaS applicatie zoals het wijzigen van de programmacode en de software ontwikkeling. De SaaS leverancier is in het algemeen verantwoordelijk voor het totale technische beheer van de SaaS applicatie, waaronder het beheren van de upgrades / patches. Bij applicatie outsourcing worden deze taken vaak uitgevoerd door de interne IT afdeling, of deels door de interne IT afdeling en deels door de softwareleverancier. Een ander verschil met betrekking tot applicatiebeheer is dat klanten in een traditionele applicatie outsourcings omgeving toegang hebben tot de databases en servers en hun intern gestelde beveiligingsmaatregelen kunnen hanteren om de data te beschermen. In een SaaS omgeving worden de servers en databases door meerdere klanten gebruikt en zijn niet toegankelijk voor deze klanten. Een SaaS leverancier hanteert één beveiligingsstrategie voor data met verschillende eigenaren. (Chung, 2008) Een overzicht van de verschillen in applicatiebeheer bij SaaS en applicatie outsourcing is te zien in Figuur 9. Toegankelijkheid Bij het vergelijken van de toegankelijkheid van applicaties in een SaaS omgeving en applicaties in een traditionele applicatie outsourcing omgeving zijn er twee significante toegangsgebieden: toegankelijkheid van de data en de toegankelijkheid van de applicatie.

22

In een SaaS omgeving wordt de data die hoort bij de software bij de SaaS leverancier voor verschillende klanten centraal opgeslagen en beheerd. Bij applicatie outsourcing wordt de data ook bij de outsourcing leverancier opgeslagen, maar veelal op een eigen fysieke database server (‘dedicated database server’). In het vorige hoofdstuk zijn reeds de meest voorkomende data architecturen van SaaS besproken, geïsoleerde databases, geïsoleerde schema’s en gedeelde schema’s. In SaaS omgevingen wordt de data van verschillende klanten logisch gescheiden in plaats van fysiek gescheiden zoals bij applicatie outsourcing (Chung, 2008). Een ander verschil tussen de SaaS omgeving en traditionele applicatie outsourcings omgeving met betrekking tot toegankelijkheid is de toegang tot de applicatie. In een SaaS omgeving is de applicatie een web applicatie en hebben de gebruikers via het internet toegang tot de applicatie. In de traditionele applicatie outsourcings omgeving is de applicatie een client-server applicatie en hebben de gebruikers via het intranet toegang tot de applicatie. Een overzicht van de verschillen in beveiliging bij SaaS en applicatie outsourcing is te zien in Figuur 9.

5.2

Verschillen tussen SaaS en Application Service Provider (ASP)

In de vorige paragraaf zijn de verschillen tussen SaaS en traditionele applicatie outsourcing beschreven. Uit de vele verschillen kunnen wij stellen dat SaaS tot een nieuwere generatie van applicatie outsourcing behoort. In het hoofdstuk over de ontwikkeling van SaaS werd Application Service Provider (ASP) reeds genoemd. In de praktijk worden SaaS en ASP soms als elkaars synoniemen gebruikt. Beide modellen hebben als uitgangspunt het aanbieden van software via het internet. Ondanks deze overeenkomst hebben SaaS en ASP ook enkele duidelijke verschillen. In deze paragraaf is eerst een definitie gegeven van ASP, vervolgens bespreken wij enkele significante verschillen tussen SaaS en ASP. Op verscheidene gebieden zijn er verschillen op te merken tussen SaaS en ASP, vanuit een technologie architectuur perspectief, vanuit een klant perspectief, in de data architectuur en ook in de focus van de dienstverlening. In deze scriptie baseren wij ons op de definitie van ASP van Gartner: Application Service Providing (ASP) is het leveren van applicatiefunctionaliteit en verwante diensten over een netwerk aan een veelvoud van klanten, gebruikmakend van het pay-as-yougo betalingsmodel (Gartner, 2000). SaaS en ASP hebben beiden als uitgangspunt het aanbieden van software via het internet. Hierbij is het verschil dat SaaS applicaties specifiek worden gebouwd als web applicaties, terwijl bij ASP het vaak traditionele software pakketten zijn die beschikbaar worden gemaakt via het internet (Nitu, 2009; Sääksjärvi et al, 2005). Vanuit een leveranciers technologie architectuur perspectief is er een significant verschil tussen SaaS en ASP: bij SaaS wordt er een middenlaag toegevoegd tussen de gebruiker en server applicaties, deze middenlaag wordt gebruikt voor gebruiker customisatie, schaalbaarheid en multi-user efficiency. SaaS software is een geïntegreerd product dat gedeeld wordt door veel verschillende afnemers tegelijkertijd, terwijl ASP software vaak één afnemer heeft. ASP leveranciers beheren voornamelijk veel aparte klant-specifieke applicaties (Nitu, 2009; Sääksjärvi et al, 2005).

23

Liao geeft in zijn artikel nog een belangrijk verschil aan vanuit een klanten perspectief tussen SaaS en ASP. SaaS klanten stemmen hun IT services af op het publieke platform dat wordt aangeboden door SaaS leveranciers. ASP is in die zin beter te vergelijken met de traditionele applicatie outsourcing, klanten beschikken over hun eigen servers en hun eigen applicaties en besteden deze uit aan de ASP leverancier (Liao, 2008). De focus van de modellen is af te leiden uit de naamgeving van SaaS en ASP. Bij SaaS, Software as a Service, wordt de nadruk gelegd op de dienstverlening, terwijl bij Application Service Provider, de nadruk wordt gelegd op de applicatie (Liao, 2008).

24

6 Risico’s voor SaaS leveranciers In voorgaande hoofdstukken zijn de kenmerken van SaaS en verschillen met de traditionelere applicatie outsourcing diensten geïdentificeerd en toegelicht. Hieruit blijkt dat er wezenlijke verschillen zijn tussen SaaS en de traditionele vorm van outsourcing. Daarnaast blijkt dat de huidige raamwerken voor het verkrijgen van zekerheid bij een SaaS leverancier zich nog niet specifiek richten op de risico’s die van toepassing zijn bij SaaS omgevingen. In dit hoofdstuk zijn risico’s afgeleid, gebaseerd op de geïdentificeerde verschillen zoals vermeld in de literatuur. Per verschil zijn de risico’s geïdentificeerd zoals ze in de literatuur benoemd worden. De risico’s zijn ingedeeld in twee categorieën, namelijk business en IT risico’s. IT risico is hier gedefinieerd als: Het risico dat bedrijfsprocessen en informatievoorziening onvoldoende integer, niet continue of onvoldoende beveiligd worden ondersteund door IT. Bedrijfsrisico is gedefinieerd als: Het risico dat de SaaS leverancier zijn ondernemingsdoelstellingen niet bereikt. Daarnaast zijn enkel de risico’s die op toepassing zijn voor de SaaS leverancier (t.o.v. de klant) geïdentificeerd.

6.1

Applicatie eigenschappen SaaS

Een eigenschap (en verschil met traditionele outsourcing applicaties) van SaaS applicaties is dat deze aangeboden worden volgens het ‘multi-tenant’ model en dat deze schaalbaar zijn. Hoewel het een voordeel biedt voor de SaaS leverancier om vanuit een centrale locatie aan meer klanten een applicatie aan te bieden, zitten hier ook risico’s aan. De SaaS leverancier krijgt te maken met complexiteit- en capaciteitsproblemen met betrekking tot zijn infrastructuur (Manford, 2008). Indien er in een korte periode veel nieuwe gebruikers van de SaaS applicatie bij komen, kan de leverancier te maken hebben met technische capaciteitsproblemen zoals: te weinig processorcapaciteit, te weinig netwerkbandbreedte en te weinig opslagcapaciteit. Deze capaciteitsbeperkingen kunnen al snel leiden tot performance problemen, waardoor afnemers niet meer hun data kunnen benaderen of het langer duurt om hun data te benaderen (Chong, 2006). Daarnaast is er een ander organisatorisch risico op het gebied van capaciteitsproblemen, namelijk het risico van onvoldoende personeel op de beheerafdeling. De SaaS leverancier moet in kunnen spelen op de snelle veranderingen en eisen van de IT-omgeving, indien dit niet gebeurd kan deze leverancier te maken krijgen met te weinig of juist te veel personeel op de beheerafdeling. Bovenstaande risico’s kunnen leiden tot het tijdelijk of voor een langere duur niet beschikbaar zijn van de SaaS applicatie (Manford, 2008).

6.2

Leveringsmodel bij SaaS

Het leveringsmodel van SaaS is gebasseerd op betalen-per-gebruik of een abonnementsconstructie (subscription). Bij gebruik van dit model hoeven de afnemers van een SaaS applicatie geen licentiekosten te betalen (voor de aanschaf), dit houdt wel in dat de SaaS leverancier aanvankelijk een hogere investering moet doen dan bij traditionele applicatieoutsourcing. Volgens Vidyanand Choudhary (2007), zijn de traditionele software 25

ontwikkelaars gericht op het snel terugverdienen van hun investering door een eenmalige hoge contributie van de klant te vragen, terwijl SaaS leveranciers een applicatie ontwikkelen waarvan de kosten op lange termijn door een continue langdurige contributie worden terugverdiend. Hierdoor is er een risico verbonden aan dit leveringsmodel voor de leverancier; indien er niet voldoende afnemers zijn kan dit leiden tot het niet terugverdienen van de investeringskosten (Vroom, 2007). Ook hoeven de afnemers zich niet voor lange termijn te verbinden aan de SaaS leverancier, ze kunnen bij het betalen naar gebruik model, op elk moment de overeenkomst met de SaaS leverancier beëindigen. De SaaS leverancier heeft hierdoor minder zekerheid dat de investeringskosten terug zullen worden verdient.

6.3

Applicatiebeheer

Op het gebied van applicatiebeheer is uit het verschil met traditionele outsourcing gebleken dat de SaaS leverancier verantwoordelijk is voor software ontwikkeling, het (technisch) beheer van de applicatie én infrastructuur. Alle afnemers kunnen gebruik maken van één applicatie en vaak dezelfde fysieke infrastructuur. Elke afnemer heeft zijn eigen soort bedrijfsprocessen, cultuur en regelgevingen. Dit heeft als gevolg dat de functionaliteiten van een SaaS applicatie vaak specifiek op de wensen van de afnemer moeten kunnen worden aangepast (Sun et. al, 2008). Deze wensen stroken vaak niet met het SaaS concept, dat juist een standaardisatie van functionaliteit aanbiedt. Indien SaaS leveranciers niet de juiste mate van customisatie (aanpassing van code) en configuratie (aanpassing van parameters) vinden, lopen ze het risico dat de beoogde afnemers de SaaS diensten niet afnemen (Sun et. al, 2008). Naast bovenstaand bedrijfsrisico, zijn ook een aantal IT-risico’s op het gebied van wijzigingsbeheer gebonden. Als een bepaalde afnemer wijzigingen doorvoert zoals de customisatie van de code of rechtstreekse wijzigingen in de database aanbrengt, ontstaat het risico dat deze wijzigingen onterecht ook worden doorgevoerd op de data van andere afnemers (Chung, 2009). Deze wijzigingen kunnen leiden tot verlies van data of (tijdelijk) niet beschikbaar zijn van de SaaS applicatie, de leverancier kan in dit geval aansprakelijk worden gesteld. Een ander IT-risico op het gebied van wijzigingsbeheer heeft te maken met integratie tussen SaaS applicaties en andere applicaties van de afnemer. Een onderzoeksrapport van AMR heeft uitgewezen dat 70% van de 639 SaaS (toekomstige) afnemers, verwachten dat de SaaS applicatie geïntegreerd kan worden met de bestaande applicaties en andere SaaS applicaties (AMR, 2005). Maar dit is tegelijkertijd ook een van de redenen waarom organisaties geen SaaS diensten afnemen; onderzoek van Forrester in 2008 heeft uitgewezen dat 25% van de mogelijke SaaS afnemers geen SaaS dienst afneemt vanwege integratieproblemen (zie Figuur 10). Afnemers van SaaS diensten verwachten en vereisen integreerbaarheid, maar zien dat hier ook risico’s aan verbonden zijn. Een afnemer van SaaS diensten neemt een SaaS applicatie af om een bepaald bedrijfsproces te ondersteunen, vaak staat dit bedrijfsproces niet op zichzelf en is er data uitwisseling nodig met een andere applicatie van de afnemer. Er bestaan geen algemene richtlijnen of “best practices” voor het ontwikkelen van SaaS applicaties of gebruik van protocollen waardoor, in tegenstelling tot de verwachtingen van de afnemers, de integratie tussen SaaS applicaties en andere applicaties moeilijk uitvoerbaar is. Een andere belangrijke factor bij de integratie tussen SaaS en andere applicaties is de mate van complexiteit van de SaaS applicatie (Guo, 2009). Hoe complexer een SaaS applicatie is (zoals een ERP pakket met veel 26

functionaliteiten), hoe meer moeite een afnemer en SaaS leverancier moeten doen om de integratie tot stand te brengen. Deze integraties leiden vaak tot wijzigingen aan de SaaS applicatie, waardoor de leverancier verscheidene versies van de applicatiecode bij moet houden per afnemer. Daarnaast kunnen interfaces en verscheidene connecties ervoor zorgen dat de IT omgeving moeilijker beheerbaar wordt. Bijvoorbeeld het beheer van wijzigingen en opsporen van incidenten kan veel tijd in beslag nemen waardoor de voordelen SaaS niet benut kunnen worden.

Figuur 10: Redenen om geen SaaS te implementeren

6.4

Toegankelijkheid

Op het gebied van toegankelijkheid zijn in het voorgaande hoofdstuk op de volgende gebieden verschillen met traditionele applicatie outsourcing geïdentificeerd: toegang tot de webapplicatie via het internet en de toegang tot data (dataopslag). Deze toegangseigenschappen leiden tot zorgen en kritische vragen bij afnemers met betrekking tot de informatiebeveiliging. Zorgen over de beveiliging van SaaS diensten is de belangrijkste reden, naast de kosten, waarom bedrijven (nog) niet op SaaS willen overstappen. Dit blijkt uit een onderzoek van Forrester Research onder 352 onderzochte bedrijven, zie Figuur 10. Deze zorgen werden in 2005 en begin 2006 bevestigd, toen een aantal SaaS applicaties van leverancier Salesforce.com niet meer beschikbaar waren en de toegang tot de applicaties voor afnemers werd geblokkeerd (Kaplan, 2007). SaaS applicaties zijn webapplicaties en moeten via het internet benaderd worden, dit houdt in dat de informatie van afnemers beschikbaar wordt gesteld via het publieke internet. Indien onvoldoende beveiligingsmaatregelen getroffen worden bestaat het risico op verlies, misbruik of diefstal van bedrijfsdata van afnemers. Hiervoor zijn verscheidene oorzaken 27

denkbaar zoals fouten in de beveiliging, denial of service aanvallen en malware installaties. De constante beschikbaarheid van de SaaS applicatie via het internet, vergroot het risico op aanvallen en misbruik aanzienlijk (Liao, 2008). Ook kan de leverancier het vertrouwen van al zijn klanten kwijtraken aangezien een beveiligingslek een grote impact kan hebben op alle opgeslagen data. Indien data van verscheidene afnemers centraal in een database is opgeslagen, zoals dit vaak het geval is bij SaaS applicaties, bestaat er een risico dat ongeautoriseerde personen (bv. hackers) erin slagen om al deze data in één keer te stelen. Dit zou een impact op de betrouwbaarheid en integriteit kunnen hebben op de data van duizenden gebruikers (Deyo, 2008). Naast deze IT risico’s zijn er ook risico’s op juridisch vlak; bij SaaS neemt de leverancier meer verantwoordelijkheid dan bij traditionele applicatie outsourcing. De SaaS leverancier kan aangeklaagd worden indien gegevens van een klant openbaar worden gemaakt. Een ander IT risico dat volgt uit de toegang tot SaaS applicaties via het internet is de afhankelijkheid van het internet. Bij traditionelere applicatie outsourcing kon de applicatie van een leverancier via een intern netwerk benaderd worden. Bij SaaS is de leverancier afhankelijk van het internet; het risico is aanwezig dat door een storing bij de internet provider (van de SaaS leverancier) de SaaS applicatie onbeschikbaar wordt. De toegankelijkheid van data is afhankelijk van de manier waarop data is opgeslagen en daarmee de data architectuur. In voorgaand hoofdstuk zijn de verschillende data architecturen van SaaS applicaties toegelicht. Een risico bij geïsoleerde databases per afnemer is dat deze manier van opslag hoge kosten aan beheer, aanschaf van hardware en backup van data met zich mee brengt (Chong, 2006). Daarom wordt data van afnemers in SaaS omgevingen vaak logisch gescheiden (geïsoleerde en gedeelde schema’s) in plaats van fysiek gescheiden (geïsoleerde databases). Het gebruik van logisch gescheiden databases (geïsoleerde en gedeelde schema’s) brengt lagere kosten met zich mee, maar de SaaS leverancier krijgt wel met hogere beveiligingsrisico’s te maken. Aangezien data van verscheidene afnemers in één database is opgeslagen bestaat het risico, bij onvoldoende scheidingen van data, dat afnemers data van elkaar kunnen inzien of wijzigen. Hiermee is de juistheid en volledigheid van data niet gewaarborgd. In Figuur 11 is een mapping opgenomen tussen de verschillen en de risico’s zoals besproken in dit hoofdstuk. Verschil SaaS t.o.v. traditioneel applicatie outsourcing

Risico beschrijving

IT of Business risico

Applicatie Eigenschappen Webapplicatie, toegankelijk via het internet

•

Risico geïdentificeerd bij categorie toegankelijkheid.

One-to-many (‘multitenant’) software architectuur

•

Onvoldoende capaciteit organisatie (onvoldoende beheerpersoneel) Onvoldoende capaciteit infrastructuur (te weinig processorcapaciteit, te weinig netwerkbandbreedte en te weinig opslagcapaciteit)

•

28

N.V.T.

•

Business risico

•

IT risico

Leveringsmodel Licentiemodel / Betalingsmodel

• • •

• • •

Business risico Business risico Business risico

Onvoldoende customisatie en configuratie, • daardoor geen afnemers van de SaaS dienst Wijzigingen aan de SaaS code of database voor • een afnemer heeft invloed op de applicatie / database van andere SaaS afnemers

Business risico

Te hoge investeringskosten Niet terugverdienen van investeringskosten Geen zekerheid over inkomsten over lange periode

Applicatie beheer SaaS leverancier voert • software ontwikkeling, het (technisch) beheer van de • applicatie én infrastructuur uit Flexibiliteit m.b.t. integratie met andere applicaties

• •

IT risico

•

IT risico

•

IT risico

Bij onvoldoende scheiding van data, is de juistheid en volledigheid van data niet gewaarborgd

•

IT risico

•

IT risico

Bij onvoldoende beveiligingsmaatregelen bestaat het risico op verlies, misbruik of diefstal van bedrijfsdata van afnemers. Vergroot risico dat ongeautoriseerde personen (bv. hackers) erin slagen om alle bedrijfskritische klantdata in één keer gestolen wordt. Bij een storing bij de internet provider wordt de SaaS applicatie onbeschikbaar of zijn er performance issues. Imagoschade, het vertrouwen van alle afnemers in een keer kwijtraken

•

IT risico

•

IT risico

•

IT risico

•

Business risico

Integratieprobelemen tussen SaaS en andere software Onbeheersbaarheid van IT omgeving, door veel verschillende versies van de applicatiecode en interfaces

Toegankelijkheid Eén database voor meerdere afnemers

Webapplicatie, toegankelijk via het internet

•

• •

• •

Figuur 11: Risico identificatie

29

7 Maatregelen voor SaaS leveranciers Uit tal van literatuuronderzoeken zoals in het vorige hoofdstuk beschreven is gebleken dat er zowel specifieke IT gerelateerde risico’s alsook bedrijfsrisico’s van toepassing zijn op SaaS diensten. Aangezien de focus van IT-audits en reviews op IT gerelateerde risico’s ligt, kunnen toegespitste maatregelen een handvat bieden om een uitspraak te doen over de automatiseringsomgeving van SaaS leveranciers. Uit literatuuronderzoek is gebleken dat er onvoldoende maatregelen voor SaaS leveranciers te herleiden zijn naar de geïdentificeerde IT risico’s uit het voorgaande hoofdstuk. Om voor elk IT-risico een maatregel te beschrijven zijn, naast de literatuurstudie twee diepte-interviews (van elk een uur) met twee Deloitte Consulting SaaS experts georganiseerd. Deze experts hebben jarenlange ervaring opgedaan op het gebied van SaaS implementaties met betrekking tot SaaS software van Oracle Ondemand en Salesforce.com. Aan beide SaaS experts is gevraagd om aan de hand van de geïdentificeerde IT-risico’s, waar nog geen wetenschappelijke literatuur voor aanwezig is, bijpassende maatregelen voor te leggen. Uit combinatie van literatuuronderzoek en de diepteinterviews is een overzicht van IT risico’s en maatregelen opgesteld (zie Figuur 12). Belangrijk is om hierbij te vermelden dat de lijst van maatregelen niet uitputtend is en mogelijk niet alle IT-risico’s volledig worden afdekt. De impact van de geïdentificeerde ITrisico’s kan per SaaS leverancier verschillen, het doel is dus niet om een volledige set van maatregelen te weergeven, maar om een richtlijn te geven voor het mitigeren van de reeds geïdentificeerde risico’s. Daarnaast is het niet het doel van dit onderzoek om alle mogelijke maatregelen voor SaaS leveranciers op te stellen, maar om maatregelen op te stellen die uit de verschillen met traditioneel applicatie outsourcing komen. IT Risico beschrijving

Maatregel

Bron

Applicatie Eigenschappen Onvoldoende capaciteit infrastructuur

•

Het implementeren van een passend capaciteitsplanning proces.

Literatuur

Leveringsmodel NVT – geen IT-risico Applicatie beheer •

• •

Wijzigingen aan de SaaS • code of database voor een afnemer heeft invloed op de applicatie / database van • andere SaaS afnemers Integratieprobelemen tussen SaaS en andere software • Onbeheersbaarheid van IT omgeving, door veel verschillende versies van de applicatiecode en interfaces

Het afstemmen van de wijzigingsbeheer procedure op de SaaS applicatie architectuur – en de data architectuur. Het opstellen van een rechtenstructuur voor het beheren van de SaaS applicatie en de SaaS database. Het opstellen van een configuratie en customisatie strategie.

Toegankelijkheid

30

Literatuur en interviews

•

• • •

Bij onvoldoende scheiding van data, is de juistheid en volledigheid van data niet gewaarborgd. Risico op verlies, misbruik of diefstal van bedrijfsdata van afnemers. Vergroot risico alle bedrijfskritische klantdata in één keer gestolen wordt. Bij een storing bij de internet provider wordt de SaaS applicatie onbeschikbaar of zijn er performance issues.

•

•

• • •

• •

•

• •

Het opstellen van een informatiebeveiligingsbeleid, waarin onder andere scheiding van verantwoordelijkheden van medewerkers ten aanzien van de verscheidene afnemers, nondisclosure agreements en screenings is opgenomen. Het opstellen van SLA’s met afnemers, waarbij geen services worden gegarandeerd waarop de SaaS leverancier beperkte invloed kan uitoefenen. Het toepassen van beveiligingsmetrieken om een bepaalde mate van beveiliging te kunnen garanderen. Het periodiek laten uitvoeren van een security assessment door een derde partij. Het vroegtijdig implementeren en reviewen van beveiliginsmaatregelen in elke fase van het softwareontwikkelings traject van SaaS applicaties. Het inrichten van een Identity & access Management systeem. Het uitvoeren van additionele beveiligingstests om data beveiliging te garanderen en te voorkomen dat er 'breaches' ontstaan specifiek gericht op SaaS applicaties en de SaaS databases. Het implementeren van sterke encryptie technieken en een streng autorisatie beleid, waarbij wordt voorkomen dat gebruikers van de ene afnemer toegang hebben tot data van de andere afnemers. Het periodiek elektronisch monitoren en preventief beheren van de SaaS infrastructuur. Het opstellen van SLA’s met (meerdere) service providers waarin voldoende beschikbaarheid, informatiebeveiliging en privacy wordt gegarandeerd.

Literatuur en interviews

Figuur 12: IT-Risico's en maatregelen

7.1

Applicatie Eigenschappen

Uit de risico-identificatie is gebleken dat het aanbieden van SaaS diensten tot onvoldoende capaciteit in de infrastructuur kan leiden. Dit risico kan grotendeels gemitigeerd worden door een adequaat capaciteitsplanning proces in te richten. De maatregel die de SaaS leverancier zou kunnen treffen is de capaciteit van zijn technische infrastructuur in termen van het aantal gelijktijdige gebruikers, processor gebruik en (pieken in het) netwerkgebruik in kaart te brengen. Hieraan zou het minimum aan benodigde resources (hardware, software tools) beschikbaar gesteld moeten worden. Een methode die gebruikt kan worden bij het plannen 31

van SaaS capaciteit is Transaction Cost Analysis, kortweg TCA (Devlin, 2009). TCA biedt een model waarmee het gebruik van de infrastructuur gemeten kan worden en de capaciteit voorspeld kan worden.

7.2

Applicatie beheer

In de SaaS omgeving zijn er twee belangrijke IT risico’s onderkend met betrekking tot applicatie beheer. Ten eerste het risico dat wijzigingen aan de SaaS applicatie code of een rechtstreekse wijziging in de database onterecht worden doorgevoerd op de data van andere afnemers. Uit het diepte interview met de SaaS experts kwam naar voren dat het in een SaaS omgeving belangrijk is dat de wijzigingsbeheer procedure is afgestemd op de SaaS applicatie architectuur en de bijbehorende data architectuur. Alvorens wijzigingen aan de SaaS applicatie code worden doorgevoerd, dienen deze getest te worden en dient de impact op applicatie functionaliteiten en data voor de verschillende klanten onderzocht te worden. Daarnaast is het belangrijk dat de SaaS leverancier een rechtenstructuur heeft opgesteld voor het beheren van de applicaties en databases. Ten tweede bestaat het risico dat de IT omgeving onbeheersbaar wordt door de verschillende versies van de applicatiecode en interfaces per afnemer. Deze verschillende versies ontstaan bij het integreren van de SaaS applicatie met applicaties van de afnemers. In het onderzoek van Sun et. Al (Sun et. Al, 2008) wordt voor dit risico de maatregel genoemd dat SaaS leveranciers voor het beheersen van de configuraties en customizations een strategie dienen op te stellen. In deze strategie wordt de aanpak met betrekking tot configuraties en customizations bepaald.

7.3

Toegankelijkheid

Op het gebied van toegankelijkheid zijn de IT-risico’s geïdentificeerd zoals beschreven in Figuur 12. Deze risico’s hebben betrekking op de toegang tot de webapplicatie, toegang tot data (dataopslag) en toegang via het internet. Vanuit bovenstaande risico’s zijn specifieke beveiligingsmaatregelen te herleiden naar de applicatie, data en het netwerk. Onderstaand zijn de maatregelen verdeeld in een algemene categorie en in specifieke categorieën (applicatie, data en netwerk). 7.3.1 Algemene maatregelen Een tal van beveiligingsmaatregelen die kunnen worden toegepast bij traditionele applicatie outsourcing zijn terug te vinden in de huidige wetenschappelijke literatuur en er zijn standaarden uitgebracht zoals de Code van Informatiebeveiliging (NEN ISO 27001 en 27002). Deze literatuur en de standaarden geven handreikingen voor de implementatie van informatiebeveiligingsmaatregelen. SaaS diensten verschillen wezenlijk van traditioneel outsourcing en de beschikbare standaarden zijn niet specifiek op SaaS diensten gericht. Er zou daarom aandacht moeten worden geschonken aan een aantal algemene beveiligingsmaatregelen welke invloed hebben op de gehele SaaS IT-omgeving. Volgens de “Security Guidance” zoals opgesteld door de Cloud Security Alliance (CSA, 2009) dienen SaaS leveranciers hoge beveiligingseisen te stellen aan hun afnemers middels 32

een algemeen informatiebeveiligingsbeleid. Zolang de beveiligingsmaatregelen weinig impact op het gebruikersgemak van de afnemers hebben, dienen deze eisen te worden uitgewerkt in baselines en volgens deze baselines te worden geïmplementeerd. Het informatiebeveilingsbeleid zou ook aandachten moeten schenken aan de scheiding van verantwoordelijkheden van medewerkers (zoals beheerders) ten aanzien van de verscheidene afnemers, non-disclosure agreements en screenings van werknemers. Bovenstaande informatiebeveiligingsbeleid, beveiligingseisen en verantwoordelijkheden dienen te worden opgenomen in service level agreements (kortweg SLA’s) met afnemers. Wel moeten SaaS leveranciers extra aandacht schenken bij het opstellen van SLA’s, specifiek bij het garanderen van bepaalde service levels. Volgens Kaplan (Kaplan, 2007) willen afnemers dat een SaaS leverancier de beschikbaarheid, beveiliging en privacy garandeert van hun data. Maar volgens het onderzoek van Devlin (Devlin, 2009) is gebleken dat de SaaS leverancier beperkte invloed heeft op de beschikbaarheid van de applicatie aangezien de SaaS leverancier geen invloed heeft op de performance van het internet. SaaS leveranciers dienen dus uiterst voorzichtig het service level te definiëren. Een maatregel die leveranicers kunnen nemen om een bepaalde mate van beveiliging te kunnen garanderen is het toepassen van beveiligings metrieken zoals de dekking van geïnstalleerde patches en aantal aanwezige kwetsbaarheden. Om de kwetsbaarheden van de applicatie en netwerk inzichtelijk te brengen, dienen SaaS leveranicers een security assessent te laten uitvoeren door een derde partij. Volgens de “Security Guidance” van CSA (CSA,2009) is het cruciaal voor een SaaS leverancier om periodiek een security assessment uit te voeren. 7.3.2 Toegankelijkheid applicatie Naast algemene informatiebeveiligingsmaatregelen dienen SaaS leveranciers allereerst op applicatieniveau maatregelen te nemen om de risico’s in verband met de juistheid en volledigheid van afnemerdata te waarborgen. Gezien de hoge risico’s met betrekking tot informatiebeveiliging bij SaaS, zou het implementeren van beveiligingsmaatregelen al bij de ontwikkeling van SaaS applicaties moeten plaatsvinden. Informatiebeveiliging zou een onderdeel moeten worden van het softwareontwikkelingtraject. Dit houdt in dat de richtlijnen voor het ontwikkelen van applicaties, de architectuur en assessment tools, aangepast moeten worden aan de vereiste beveiligingsmaatregelen. SaaS leveranciers zouden ook bij elke fase tijdens de ontwikkeling een review moeten uitvoeren op de beoogde beveiligingsmaatregelen. Aan de hand hiervan zouden de geïdentificeerde kwetsbaarheden in de beveiliging tijdens het ontwikkelen en testen opgelost moeten worden (Rane, 2010; CSA, 2009). Na de software ontwikkeling fase zou ook het toegangsbeheer tot de applicatie ingeregeld moeten worden. Een maatregel om controle over de toegang tot de applicatie te hebben, is het inrichten van een Identity & Access Management (kortweg IAM) systeem. Een IAM biedt functies zoals een gecentraliseerd gebruikersbeheer (inclusief functiescheidingen) en autenthicatie tot de SaaS applicatie. Een IAM geeft een leverancier de mogelijkheid om vanaf een centraal punt de toegang voor de afnemers te regelen en scheiding tussen verschillende afnemers in te richten (Rane, 2010; CSA, 2009).

33

7.3.3 Toegankelijkheid data In deze scriptie zijn de data architecturen in een SaaS omgeving en de bijbehorende risico’s reeds toegelicht. Samenvattend wordt data van verschillende afnemers in een SaaS omgeving in één database opgeslagen, waardoor bij onvoldoende scheiding van de data het risico bestaat dat de juistheid en volledigheid van deze data niet kan worden gewaarborgd. Deze risico’s kunnen gemitigeerd worden door maatregelen te implementeren, zoals het uitvoeren van additionele beveiligingstests om data beveiliging te garanderen en om te voorkomen dat er ‘breaches’ ontstaan door kwetsbaarheden in de applicatie of ongeautoriseerde gebruikers. Andere mitigerende maatregelen kunnen zijn het gebruik van sterke encryptie technieken voor data beveiliging en een streng autorisatie beleid voor de toegang tot data. Deze beveiligingstests dienen zodanig geïmplementeerd te worden dat er voorkomen wordt dat er ongeautoriseerde toegang plaats vindt door gebruikers van de ene afnemer bij data van de andere afnemers. Hierbij dient de database voldoende beveiligd te zijn en dient de applicatie data segregatie te ondersteunen (Rane, 2010). 7.3.4 Toegankelijkheid netwerk SaaS applicaties zijn toegankelijk via het internet en ook de informatie van de afnemers wordt via het internet beschikbaar gesteld, de risico’s die hiermee gepaard gaan zijn in het vorige hoofdstuk beschreven. Samenvattend zijn de belangrijkste risico’s; het risico op verlies, misbruik of diefstal van bedrijfsdata van afnemers en het risico dat een SaaS applicatie onbeschikbaar wordt door een storing bij de internet provider. In (Rane, 2010) worden maatregelen beschreven om externe aanvallen, ‘breaches’ en data verlies over het internet tegen te gaan, zoals het uitvoeren van host scanning, netwerk penetratie tests, firewall tests, router tests en het uitvoeren van pakket analyses. Daarnaast wordt het gebruik van sterke netwerk verkeer encryptie technieken zoals ‘Secure Socket layer’ (SSL) en de ‘Transport Layer Security (TSL)’aanbevolen. De SaaS infrastructuur moet doorlopend elektronisch worden gemonitored en preventief worden beheerd (Chung, 2009). Risico’s als gevolg van storingen op het internet zijn te onvoorspelbaar voor het treffen van goede preventieve maatregelen. Voor de SaaS leverancier is het van belang dat alle mogelijke knelpunten en beperkingen in kaart worden gebracht, zodat er in geval van storingen de juiste maatregelen genomen kunnen worden. Veel risico’s zijn te voorspellen door te letten op de signalen uit de monitoring. Op het moment dat zich een incident voordoet, moet er snel een analyse gemaakt kunnen worden van de oorzaak. Daarnaast dient de SaaS leverancier duidelijke afspraken te maken met de internet provider over verantwoordelijkheden en taken in geval van storingen. (Chung, 2009) De SaaS leverancier dient SLA’s op te stellen met de internet provider waarin voldoende beschikbaarheid, informatiebeveiliging en privacy wordt gegarandeerd.

34

8 Conclusie literatuuronderzoek en conceptueel risico raamwerk In dit hoofdstuk wordt antwoord gegeven op de gestelde onderzoeksvragen. Het doel van dit onderzoek was om een conceptueel risico raamwerk van risico’s en maatregelen samen te stellen. Om dit raamwerk op te bouwen is er gebruik gemaakt van een risico methodiek van Deloitte. Er is eerst een verschillenanalyse uitgevoerd waarbij de kenmerken van SaaS zijn vergeleken met de kenmerken van traditioneel applicatie outsourcing. Uit deze analyse is naar voren gekomen dat er 10 belangrijke verschillen te vinden zijn die in vier categorieën ingedeeld kunnen worden: applicatie eigenschappen, leveringsmodellen, applicatiebeheer en toegankelijkheid. Het aantal verschillen en de verscheidenheid van deze verschillen duidt erop dat SaaS wezenlijk anders is dan de traditionelere vormen van applicatie outsourcing. Dit overzicht van verschillen gaf antwoord op deelvraag 1: Wat zijn de verschillen tussen SaaS en andere applicatie outsourcing diensten? Uit deze verschillen zijn vervolgens bedrijfsrisico’s en IT-risico’s geïdentificeerd en gegroepeerd per categorie. Uit de risico identificatie blijkt dat voornamelijk op het gebied van toegankelijkheid en (wijzigingen)beheer IT-risico’s liggen waar extra aandacht aan dient te worden besteed bij SaaS omgevingen. Hiermee is deelvraag 2 beantwoordt: Welke IT risico’s zijn specifiek voor SaaS? Uit de geïdentificeerde IT-risico is inzicht gegeven in passende maatregelen voor SaaS omgevingen. Het overzicht van maatregelen is niet uitputtend, maar bevat enkel specifieke maatregelen voor SaaS. Hiermee is antwoord gegeven op deelvraag 3: Welke maatregelen zijn er om de IT risico’s bij SaaS te mitigeren? Ten slotte zijn de verschillen, risico’s en beheersmaatregelen aan elkaar gekoppeld om tot een conceptueel risico raamwerk te komen (zie Bijlage 2 Conceptueel risico raamwerk). Dit raamwerk kan worden gebruikt als een startpunt bij de risicoanalyse in de planningsfase van reviews of IT-audits. Het uitvoeren van een risicoanalyse is een belangrijke randvoorwaarde om de specifieke risico’s die gepaard gaan met het aanbieden van een SaaS dienst te mitigeren. Hiermee is een deel van de onderzoeksvraag beantwoord: 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? Het uitgevoerde literatuuronderzoek is verkennend, daarnaast is ook bevestigend onderzoek nodig om het conceptuele risico raamwerk te valideren en uit te breiden, hiermee wordt in hoofdstuk 8 middels een praktijkcasus aandacht op gericht. Hiermee kan ook de onderzoeksvraag volledig worden beantwoord.

35

9 Praktijkcasus: Toetsing en aanvulling conceptueel risico raamwerk Het doel van de praktijkcasus is om het conceptueel risico raamwerk uit ons literatuuronderzoek te toetsen aan een praktijksituatie en aan te vullen met risico’s en maatregelen uit deze specifieke praktijksituatie. Hierbij hebben wij vastgesteld of de IT risico’s die in de literatuur worden genoemd, in de dagelijkse praktijk ook als risico worden geïdentificeerd en welke maatregelen al dan niet worden getroffen om deze risico’s te beperken. In de praktijkcasus hebben wij ons alleen gericht op de IT risico’s. In de literatuur hebben wij in de categorie ‘Leveringsmodel’ geen IT-risico’s geïdentificeerd, slechts bedrijfsrisico’s. Deze categorie wordt om die reden niet uitgewerkt in de praktijkcasus. Aangezien deze praktijkcasus zich richt op één Nederlandse SaaS leverancier houden wij er rekening mee dat niet alle risico’s in deze specifieke praktijksituatie gelden. De risico’s en maatregelen uit het initiële conceptueel risico raamwerk zijn daarom ook ongewijzigd. Wij hebben slechts risico’s en maatregelen toegevoegd als deze niet reeds voorkwamen in het raamwerk.

9.1

Praktijksituatie : SaaS leverancier X

De naam van de SaaS leverancier in deze casus is geanonimiseerd vanwege de gevoeligheid van de verstrekte informatie, er is daarom “SaaS X” in plaats van de naam van de leverancier gebruikt. SaaS X is een innovatieve IT- dienstverlener die zich richt op SaaS applicaties bij financiële , zorg - en onderwijs instellingen. Het gebruik van deze applicaties wordt als service door SaaS X aan klanten aangeboden. De klanten gebruiken de functionaliteit van de applicatie via een web browser waarbij SaaS X verantwoordelijk is voor hosting-, beheer- en onderhoud. De hosting werkzaamheden zijn door SaaS X uitbesteed aan externe leveranciers.

9.2

Interviews

Tijdens de interviews hebben wij de risico’s uit het conceptueel risico raamwerk voorgelegd aan de geïnterviewde personen. Wij hebben open vragen gesteld aan de medewerkers van SaaS X om te voorkomen dat wij de antwoorden te veel zouden beïnvloeden (zie bijlage 1 voor de gestelde vragen). Indien de risico’s werden bevestigd hebben wij gevraagd of zij maatregelen hanteren om de risico’s te beperken. Daarnaast hebben wij de maatregelen uit het conceptueel risico raamwerk aan hen voorgelegd. In dezelfde structuur wordt de praktijkcasus in onderstaande paragraaf behandeld.

36

9.3

Risico’s en maatregelen in de praktijk

In deze paragraaf beschrijven wij de resultaten van de praktijkcasus. Per IT-risico wordt aangegeven of het risico wel of niet door SaaS X is bevestigd. Indien het IT-risico niet door SaaS X is bevestigd, wordt dit kort uitgelegd. In het geval dat het IT-risico wel door SaaS X is bevestigd, worden ook de door SaaS X getroffen maatregelen beschreven. Daarnaast hebben wij de maatregelen globaal vergeleken met de maatregelen uit het conceptueel risico raamwerk. Figuur 13 geeft een overzicht van de IT-risico’s die wel of niet door SaaS X zijn bevestigd en een overzicht van de maatregelen die zij getroffen hebben om de erkende risico’s te beperken. Een totaaloverzicht van het conceptueel risico raamwerk aangevuld met de IT-risico’s en maatregelen uit de praktijkcasus, hebben wij opgenomen in Bijlage 2 Conceptueel risico raamwerk. Verschil SaaS t.o.v. traditioneel applicatie outsourcing

IT risico in de literatuur

Risico’s bevestigd door SaaS X ( Ѵ /Χ)

Maatregelen SaaS X

Applicatie Eigenschappen Webapplicatie, • toegankelijk via het internet One-to-many (‘multi-tenant’) software architectuur

•

Risico geïdentificeerd bij categorie toegankelijkheid. Onvoldoende capaciteit infrastructuur (te weinig processorcapaciteit, te weinig netwerkbandbreedte en te weinig opslagcapaciteit)

N.V.T.

Ѵ

•

• •

Leveringsmodel

37

Periodiek worden er door de SaaS leverancier per SaaS applicatie analyses uitgevoerd voor de benodigde infrastructuur capaciteit. Maandelijks vindt er een review plaats van de infrastructuur belasting. De SaaS leverancier voorziet dat er voldoende service managers beschikbaar zijn ter ondersteuning van klanten, tevens stellen zij documentatie beschikbaar waarmee service managers elkaars taken kunnen overnemen.

Licentiemodel / Betalingsmodel

•

Geen IT risico geïdentificeerd.

Applicatie beheer SaaS leverancier • voert software ontwikkeling, het (technisch) beheer van de applicatie én infrastructuur uit

Wijzigingen aan de SaaS code of database voor een afnemer heeft invloed op de applicatie / database van andere SaaS afnemers

Ѵ

•

•

Flexibiliteit m.b.t. integratie met andere applicaties

• •

Integratieproblemen tussen SaaS en andere software Onbeheersbaarheid van IT omgeving, door veel verschillende versies van de applicatiecode en interfaces

Ѵ

De SaaS leverancier hanteert twee wijzigingsbeheer procedures één generiek voor alle afnemers en één specifiek voor een bepaalde afnemer De SaaS applicatie is uitgerust met een groot aantal parameter instelmogelijkheden, waardoor het toevoegen van functionaliteit niet altijd tot een wijziging in de SaaS code hoeft te leiden

•

Geen passende maatregel

Voor het inloggen op de SaaS applicatie wordt een juiste login naam en wachtwoord combinatie vereist en een geldig certificaat. Er worden periodiek kwetsbaarheids en penetratie tests uitgevoerd zoals bijvoorbeeld SQL search op velden die daarvoor niet bevoegd zijn. Beheerders voeren account checks uit op de database. Data architectuur wordt

Χ

Toegankelijkheid Eén database voor meerdere afnemers

•

Webapplicatie, • toegankelijk via het internet •

Bij onvoldoende scheiding van data, is de juistheid en volledigheid van data niet gewaarborgd.

Ѵ

•

Bij onvoldoende beveiligingsmaatregelen bestaat het risico op verlies, misbruik of diefstal van bedrijfsdata van afnemers. Vergroot risico dat ongeautoriseerde personen (bv. hackers) erin slagen om alle

Ѵ

•

38

Ѵ

• •

•

bedrijfskritische klantdata in één keer gestolen wordt. Bij een storing bij de internet provider wordt de SaaS applicatie onbeschikbaar of zijn er performance issues.

• Ѵ

afgestemd op de geldende beveiligingseisen in een bedrijfssegment. Maandelijks vindt er een security overleg plaats, waarin het security beleid wordt geëvalueerd; Risico’s, mogelijke oplossingen en verbeterpunten worden voorgelegd aan het management- en directie team.

Figuur 13: Overzicht risico’s en maatregelen uit het conceptueel risico raamwerk getoetst op een praktijksituatie

Applicatie eigenschappen Risico: Onvoldoende capaciteit infrastructuur SaaS X heeft dit risico bevestigd. SaaS X heeft een aantal maatregelen getroffen om de capaciteit van de infrastructuur te monitoren. De applicaties van SaaS X zijn voornamelijk toegespitst op gebruik bij financiële instellingen, zorginstellingen en onderwijsinstellingen. Periodiek worden er per SaaS applicatie in een specifiek bedrijfssegment analyses uitgevoerd om inzicht te krijgen in de benodigde capaciteit van de technische infrastructuur. Op basis van deze analyses wordt bepaald of er voor een bepaalde applicatie in een bepaalde periode extra capaciteit (bijv. processor rekenkracht) ingeschakeld dient te worden of dat er juist minder capaciteit nodig is. Daarnaast wordt er bij SaaS X maandelijks een review uitgevoerd op de belasting van de infrastructuur. Voor het ondersteunen van afnemers bij problemen, waaronder infrastructuur capaciteitsproblemen, heeft SaaS X met de afnemers afspraken gemaakt over de verantwoordelijkheden van de service desk. De afnemers zijn zelf verantwoordelijk voor de eerstelijns service desk. Indien de vragen niet door de eerste lijn afgehandeld kunnen worden, worden de vragen doorgezet naar de tweedelijns service desk waar SaaS X verantwoordelijk voor is. SaaS X zorgt ervoor dat er altijd voldoende service managers beschikbaar zijn ter ondersteuning van de afnemers. Ook is er documentatie beschikbaar waarmee service managers elkaars taken kunnen overnemen. In het conceptueel risico raamwerk wordt voor dit risico de volgende maatregel genoemd: Het implementeren van een passend capaciteitsplanning proces. De maatregelen die bij SaaS X worden genoemd zijn voorbeelden van activiteiten die in een capaciteitsplanning proces opgenomen zouden kunnen worden.

39

Applicatiebeheer Risico: Wijzigingen aan de SaaS code of database voor een afnemer heeft invloed op de applicatie / database van andere SaaS afnemers SaaS X heeft dit risico bevestigd. SaaS X biedt verschillende SaaS applicaties aan met verschillende applicatie en data architecturen. De keuze voor de applicatie architectuur en data architectuur is afhankelijk van het bedrijfssegment waarin de applicatie wordt gebruikt en de beveiligingseisen die aan de applicatie worden gesteld. De beveiligingseisen bij financiële instellingen zijn bijvoorbeeld strenger dan bij onderwijsinstellingen. Applicaties van SaaS X die door financiële instellingen worden gebruikt, beschikken over een eigen virtueel platform met een eigen geïsoleerde database. Bij SaaS applicaties voor onderwijsinstellingen worden zowel de database als segmenten gedeeld, waardoor elke afnemer beschikt over een eigen ID in de database. Voor het beperken van het risico heeft SaaS X verschillende maatregelen getroffen. SaaS X hanteert twee verschillende wijzigingsprocedures één generieke wijzigingsprocedure (die overkoepelend is voor alle applicaties) en één wijzigingsprocedure specifiek gericht op de SaaS applicatie van een bepaalde afnemer in een bepaald bedrijfsegment. Daarnaast zijn SaaS X applicaties zodanig ontwikkeld dat zij beschikken over vele parameter instelmogelijkheden. Hierdoor kunnen bepaalde functionaliteiten worden toegevoegd, zonder dat er een wijziging in de programmacode noodzakelijk is. In het conceptueel risico raamwerk wordt voor dit risico onder andere de maatregel genoemd: het afstemmen van de wijzigingsbeheer procedure op de SaaS applicatie architectuur en de data architectuur. SaaS X heeft deze maatregel uitgewerkt door twee verschillende wijzigingsbeheer maatregelen te hanteren, één generieke wijzigingsbeheer procedure (voor het proces toepasbaar op alle applicaties) en een specifieke wijzigingsbeheer procedure die van toepassing is op de SaaS applicatie van een bepaalde afnemer. Risico: Integratieproblemen tussen SaaS en andere software SaaS X heeft dit risico bevestigd. SaaS X heeft bevestigd dat het risico aanwezig is dat er integratieproblemen optreden tussen SaaS en software van andere leveranciers. Zoals reeds eerder vermeld levert SaaS X diensten aan financiële, onderwijs- en zorg instellingen. De SaaS applicaties dienen vaak te communiceren met applicaties van derde partijen specifiek voor deze bedrijfssegmenten. Om de SaaS applicaties te integreren met deze derde partijen applicaties maakt SaaS X gebruik van interfaces die zij zelf ontwikkelen. Echter heeft SaaS X geen inzicht in de programmacode van applicaties van derde partijen. Als de code van deze applicaties wordt gewijzigd door een derde partij, zodanig dat de communicatie tussen de interface en de applicaties van de derde partij anders zou moeten plaatsvinden, wordt SaaS X of diens afnemer hiervan vaak niet op de hoogte gesteld. De afhankelijkheid van de derde partijen wordt door SaaS X gezien als een groot aandachtspunt. SaaS X heeft voor dit risico geen passende maatregel.

40

Risico: Onbeheersbaarheid van IT omgeving, door veel verschillende versies van de applicatiecode en interfaces SaaS X heeft dit risico niet bevestigd. SaaS X heeft tijdens de interviews het risico niet bevestigd dat verschillende versies van de applicatiecode en interfaces kunnen leiden tot een onbeheersbare IT omgeving. Ten tijde van het onderzoek had SaaS X geen afnemers die onafhankelijk van elkaar het gebruik van één SaaS applicatie op één platform als dienst afnamen. De afnemers die het gebruik van één SaaS applicatie op één platform als dienst afnamen, waren onderdeel van een overkoepelende coöperatie of stichting. Wijzigingen aan de SaaS applicatie worden in deze situatie door één gezamenlijk aanspreekpunt van de afnemers met SaaS X afgestemd. De situatie dat verschillende afnemers verschillende versies van de SaaS applicatie vereisen of verschillende versies van interfaces tussen de SaaS applicatie en applicaties van derde partijen kwam op dat moment bij SaaS X niet voor. Toegankelijkheid Risico: Bij onvoldoende scheiding van data, is de juistheid en volledigheid van data niet gewaarborgd. Risico: Bij onvoldoende beveiligingsmaatregelen bestaat het risico op verlies, misbruik of diefstal van bedrijfsdata van afnemers. Risico: Vergroot risico dat ongeautoriseerde personen (bv. hackers) erin slagen om alle bedrijfskritische klantdata in één keer gestolen wordt. SaaS X heeft bovenstaande risico’s bevestigd. Wij hebben tijdens het interview met SaaS X de risico’s die betrekking hebben op de toegankelijkheid van data gezamenlijk aan hen voorgelegd. SaaS X heeft bevestigd dat deze risico’s aanwezig zijn, echter geven de medewerkers van SaaS X aan dat een slecht applicatie ontwerp een hoger risico veroorzaakt met betrekking tot de juistheid en volledigheid van de data. Voor het beveiligen van de SaaS applicatie wordt er bij het inloggen een juiste combinatie van een gebruikersnaam en wachtwoord vereist en een geldig certificaat. Daarnaast worden er periodiek kwetsbaarheids en penetratie tests uitgevoerd zoals bijvoorbeeld SQL search op velden die daarvoor niet bevoegd zijn om ongeautoriseerde toegang tot de database te voorkomen. Ook voeren database beheerders periodiek account check’s uit op de database om ongeautoriseerde toegang te voorkomen. Een algemene maatregel die SaaS X hanteert om bovenstaande risico’s te beperken is dat zij maandelijks een security overleg hebben, waarin het security beleid wordt geëvalueerd. Tijdens dit overleg worden risico’s geïdentificeerd. Ook worden mogelijke oplossingen en verbeterpunten voorgelegd aan het management- en het directie team. Een aantal maatregelen die SaaS X hanteert om toegang tot data te beveiligen kunnen gerelateerd worden aan maatregelen uit het conceptueel risico raamwerk. In het conceptueel risico raamwerk wordt onder andere het uitvoeren van additionele beveiligingstests specifiek gericht op SaaS applicaties en de SaaS databases als maatregel genoemd. SaaS X voert additionele beveiligingstests uit om data te beveiligen, zoals kwetsbaarheids tests en penetratie tests en ook worden er periodiek account checks op de database uitgevoerd.

41

Risico: Bij een storing bij de internet provider wordt de SaaS applicatie onbeschikbaar of zijn er performance issues SaaS X heeft dit risico bevestigd. Om het risico te beperken dat de SaaS applicatie onbeschikbaar wordt of performance issues vertoont hanteert SaaS X een aantal maatregelen. Allereerst heeft SaaS X om de beschikbaarheid van de applicaties te waarborgen contracten met twee verschillende internet service providers. In het geval dat er een storing optreedt bij de ene provider kan dit worden opgevangen door de andere provider. Daarnaast heeft SaaS X ook contracten (SLA’s) met afnemers, waarin is vastgelegd dat de afnemer verantwoordelijk is voor de internetverbinding tussen de SaaS applicatie en zijn eigen IT omgeving. In het conceptueel risico raamwerk wordt voor dit risico onder andere de maatregel genoemd om SLA’s met (meerdere) service providers op te stellen waarin voldoende beschikbaarheid, informatiebeveiliging en privacy wordt gegarandeerd. SaaS X heeft met twee service providers contracten afgesloten om dit risico te beperken.

9.4

Conclusie uit praktijkcasus

In de praktijkcasus hebben wij één SaaS leverancier onderzocht. Uit interviews is gebleken dat zij een soortgelijke definitie van SaaS hanteren als in dit onderzoek wordt bestudeerd. De meeste risico’s zoals gedefinieerd tijdens de literatuurstudie worden onderkend door SaaS X. SaaS X heeft geen additionele IT risico’s genoemd. We zien net als bij het literatuuronderzoek dat het verschil op basis van het leveringsmodel niet leidt tot IT-risico’s. Een verklaring hiervoor kan zijn dat het leveringsmodel voornamelijk te maken heeft met betaling van de afnemer en inkomsten voor de leverancier waar met name bedrijfsrisico’s aan verbonden zijn. Tevens concluderen wij uit de praktijkcasus dat de door ons gedefinieerde maatregelen voor SaaS leveranciers grotendeels zijn terug te vinden in de onderzochte praktijksituatie. Hierbij zijn de maatregelen uit de literatuur vaak op een abstracter niveau geformuleerd, terwijl de maatregelen uit de praktijkcasus een specifiekere invulling geven. Het overzicht van de bevestigde risico’s en de maatregelen is te zien in Figuur 13. Hiermee is ook het conceptuele risico raamwerk aangevuld, zoals afgebeeld in bijlage 2.

42

Hoofdconclusie, beperkingen en vervolgonderzoek

9.5

Hoofdconclusie

In deze scriptie is onderzoek gedaan naar de IT-risico’s en maatregelen bij SaaS leveranciers. De deelvragen behorende bij de hoofdvraag zijn reeds beantwoord in de conclusie van de literatuurstudie (zie hoofdstuk 8). De onderstaande onderzoeksvraag wordt beantwoord in deze hoofdconclusie: 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? Er zijn 10 kenmerkende verschillen tussen SaaS en andere applicatie outsourcing diensten, welke, volgens dit onderzoek, in te delen zijn in 4 categorieën: applicatie eigenschappen, leveringsmodel, applicatiebeheer en toegankelijkheid. Deze verschillen leiden tot additionele risico’s in vergelijking tot traditionelere vormen van applicatie outsourcing. Op basis van de verschillen in de genoemde categorieën zijn IT risico’s in de literatuur middels een systematische risico analyse geïdentificeerd. Te zien is dat de risico’s voornamelijk liggen op het vlak van applicatiebeheer en toegankelijkheid. Voornamelijk de eigenschappen multi tenancy (meer afnemers van één applicatie), toegankelijkheid via het internet en gedeelde databases zorgen ervoor dat de gerelateerde IT risico’s een hoge impact hebben op alle data van de afnemers. Passende maatregelen zijn daarom zowel uit de literatuur als praktijkcasus gehaald. Hiermee is een conceptueel risico raamwerk samengesteld (zie bijlage 2) en de onderzoeksvraag beantwoord. Uit literatuuronderzoek is gebleken dat een gedegen risico analyse nodig is bij aanvang van audits en reviews op SaaS leveranciers. Het conceptuele risico raamwerk kan tijdens reviews of IT-audits bij SaaS leveranciers als een startpunt gebruikt worden bij de risico analyse. Op basis van de situatie en eigenschappen van de SaaS leverancier kunnen IT-auditors IT risico’s die van toepassing zijn op die SaaS leverancier terugvinden in het conceptuele risico raamwerk. De bijbehorende maatregelen kunnen een richting geven voor het opzetten van specifieke beheersmaatregelen en het opstellen van een normenkader. Naast IT-auditors kunnen ook SaaS leveranicers gebruik maken van het conceptuele raamwerk om hun IT risico’s in kaart te brengen. Middels de uitgevoerde analyse in dit onderzoek kunnen zij ook additionele risico’s, die specifiek zijn voor hun bedrijfsprocessen identificeren.

9.6

Beperkingen en vervolgonderzoek

Het opgestelde risico raamwerk voor SaaS omgevingen is een conceptueel raamwerk, wij bevelen daarom aan om vervolgonderzoek hierop te doen. Hoewel de IT risico’s in het raamwerk gevalideerd zijn bij een SaaS leverancier, kunnen we nog geen uitspraak over de generalisatie van deze risico’s en maatregelen doen. Middels een kwantitative risico analyse zou onderzoek kunnen worden gedaan om de risico’s en maatregelen te bevestigen bij meerdere SaaS leveranciers. Daarnaast is dit onderzoek beperkt tot de eerste 4 stappen van het Deloitte risico raamwerk (Risk Intelligent Enterprise). De laatste twee stappen, waarin het ontwerpen, implementeren, 43

testen en monitoren van beheersmaatregelen wordt uitgevoerd komen niet aan bod in dit onderzoek. Vervolgonderzoek is daarom nodig om SaaS specifieke beheersmaatregelen te identificeren.

9.7 Reflectie Tijdens het ‘brainstormen’ over een scriptie onderwerp werd het ons al vrij snel duidelijk dat onze interesse lag op het gebied van IT outsourcingdiensten en met name het aanbieden van outsourcingdiensten via het internet. Vanwege voorspellingen in de media over het toenemende gebruik van SaaS in de komende jaren hebben wij besloten om de risico’s die SaaS diensten met zich meebrengen nader te onderzoeken. Hierbij hebben wij ons gericht op de aanwezige risico’s voor SaaS leveranciers. In ons dagelijkse werk als IT-auditor voeren wij ook audits uit bij leveranciers van outsourcingdiensten. Het is daarom mogelijk dat wij in de toekomst meer met SaaS leveranciers te maken zullen krijgen, voornamelijk in het kader van IT audits. Daarbij is het belangrijk dat wij inzicht hebben in de risico’s van SaaS omgevingen en hoe deze uiteindelijk geaudit dienen te worden. Het resultaat van ons onderzoek is een conceptueel risico raamwerk, waarin IT-risico’s en maatregelen specifiek voor SaaS leveranciers zijn vastgelegd. In de literatuur wordt er meer onderzoek gedaan naar risico’s in SaaS omgevingen vanuit een afnemers perspectief. Ons onderzoek levert een bijdrage door meer inzicht te geven in risico’s voor SaaS leveranciers. We hebben het gevoel dat middels dit onderzoek ons kennisniveau ten aanzien van SaaS, risicomanagement en IT-auditing is toegenomen.

44

10 Literatuurlijst AMR Research Report: Software as a Service: Managing Buyer Expectations as We Pass the Tipping Point from Novelty to Necessity, 2005 Chong F., Carraro G., and Wolter R., “Multi-tenant data architecture,” http://msdn.microsoft.com/en-us/library/aa479086.aspx, Juni 2006, geraadpleegd op 1 Juli 2010. Chung M., ‘Informatiebeveiliging versus SaaS’, Compact, 2009 Cloud Security Alliance (CSA), : Security Guidance for Critical Areas of Focus in Cloud Computing v2.1, 2009, geraadpleegd op 27 augustus 2010: http://www.cloudsecurityalliance.org/guidance/csaguide.pdf Deloitte, Losing Ground: 2009 TMT Global Services Security Survey, Deloitte Touche Tohmatsu, DTT Technology, Media and Telecommunications Industry Group, 2009a Deloitte, Risk Intelligence in a Downturn: Balancing Risk and Reward in Volatile Times. Risk Intelligence Series., 14, 1-16, 2009b Dubey A., Wagle D.: Delivering software as a service, The McKinsey Quarterly, mei 2007, p. 1-12. Devlin C., SaaS Capacity Planning: Transaction Cost Analysis Revisited, 2009, geraadpleegd op 27 Augustus 2010: http://msdn.microsoft.com/en-us/architecture/cc261632.aspx Deyo, J, Software as a Service(SaaS): A look at the migration of applications to the web, 2008 D. Fishteyn, "Deploying Software as a Service (SaaS)," WebApps, Inc., geraadpleegd op 1 maart 2010: http:/www.saas.com Gartner’s Dataquest Forecasts Worldwide ASP Market to Surpass $25 billion in 2004, August 9, 2000 Gartner Research, Gartner Says Worldwide SaaS Revenue in the Enterprise Application Markets Will Grow 27 Per Cent in 2008, 22 oktober, 2008. Geraadpleegd op 27 november, 2009: http://www.gartner.com/it/page.jsp?id=783212 Gartner Research, SAS 70 Is Not Proof of Security, Continuity or Privacy Compliance, juni 2010. Greschler, D.; Mangan, T., Networking lessons in delivering ‘Software as a Service’ - Part I. Int. J. Network Mgmt 12, 2002.

45

Guo P., A Survey of Software as a Service Delivery Paradigm, Seminar on Internetworking 2009-04-27 ISACA, IT Standards, Guidelines, and Tools and Techniques for Audit and Assurance and Control Professionals, 16 Augustus 2010a ISACA, Cloud Computing Management Audit/Assurance Program, Augustus 2010b, geraadpleegd op 26 september 2010: http://www.isaca.org

Kaplan J.M., SaaS: Friend or foe? In Business Communications Review, pages 48–53, juni 2007. Kouwenberg F., Burgering R., SaaS toegepast op IT Service en Asset Management Tooling, Best Practice Magazine, 2008 Liao H.C Tao C.Q., “An anatomy to SaaS business mode based on Internet,” in Int. Conf. on Management of e-Commerce and e-Government, 2008. ICMECG’08, Jiangxi,China, Oct. 17–19, 2008, pp. 215–220. Manford, C., The impact of the SaaS model of software delivery. in Mann, S. and Lopez, M. eds. Proceedings of the 21st Annual NACCQ Conference, NACCQ, Auckland, New Zealand, 2008, 283-286. Mell, P., Grance, T., NIST definition of cloud computing, National Institute of Standards and Technology, October 7, 2009 Nitu: Configurability in SaaS (software as a service) applications. In Proc. of the 2nd annual India softw.eng. conf. (ISEC), pages 19–26. ACM, 2009. Overbeek P., Lindgreen E.R. en Spruit M., Informatiebeveiliging onder Controle, Financial Times/Prentice Hall, 2000 (2e druk) Rane, P.. Securing SaaS applications: A cloud security perspective for application providers: Information Systems Security, 2010, geraadpleegd op 15 juli 2010: http://www.infosectoday.com/Articles/Securing_SaaS_Applications.htm Robert P. Desisto and Ben Pring, Essential SaaS Overview and 2009 Guide to SaaS Research, 2009 Sääksjärvi, M., Lassila, A., and Nordström, H., ”Evaluating the Software as a Service Business Model: From CPU Time-Sharing to Online Innovation Sharing”, Proceedings of the IADIS International Conference e-Society 2005, Qawra, Malta, pp. 177-186. SIIA : Software and Information Industry Association (2001), Software as a service: strategic backgrounder.

46

Sun W., Zhang X., Guo C.J., Sun P. and Su H., Software as a Service: Configuration and Customization Perspectives. Congres on Services: Part 2, 2008. SERVICES-2. IEEE pages 18-25, Sept. 2008. Sun W., Zhang K., Chen S., Zhang X. and Liang H. (2007). Software as a Service: An integration perspective. In Service-Oriented Computing – ICSIC 2007 (Krämer, B., Lin, K. and Narasimhan, P. Eds.), September 17 – 20, Vienna, Austria, Springer, 558-569. Vermeulen P. (2006), De Business Case voor Software as a Service, IDC Information and Data, augustus 2006 Vidyanand Choudhary (2007), Software as a Service: Implications for Investment in Software Development, Proceedings of the 40th Hawaii International Conference on System Sciences – 2007 Vroom M. (2007), “SaaS 2007, hype or hot/not?”, Software Developer Network Magazine, april 2007 pag 5-10

47

Bijlage 1: Praktijkscasus vragen Vrije Universiteit Amsterdam IT-Audit Opleiding Software as a Service: Risico’s en maatregelen bij SaaS leveranciers Context Software as a Service is de laatste jaren gegroeid en door verscheidene onderzoeken wordt voorspeld dat het gebruik van SaaS diensten in de komende jaren enorm zal groeien. Applicaties met financiële gegevens worden ook steeds meer als SaaS dienst aangeboden. Deze financiële applicaties behoren vaak tot de scope van financiële reviews, quick scans en IT-audits die uitgevoerd worden in het kader van jaarrekening controles. Daarom zijn de risico’s en maatregelen van belang voor ITauditors. In dit onderzoek zullen wij de verschillen tussen SaaS en andere outsourcing diensten in kaart brengen en de risico’s van SaaS omgevingen identificeren om uiteindelijk een conceptueel kader met maatregelen te presenteren die door IT-auditors gebruikt kunnen worden. Perspectief Het onderzoek richt zich op het perspectief van de IT-auditor op de SaaS leverancier. Hiervoor is gekozen omdat de SaaS diensten draaien op de IT omgeving bij de leverancier. Opgestelde risico’s en maatregelen hebben betrekking op de SaaS leverancier, het perspectief van de klant zal nauwelijks aan bod komen. Het onderzoek Het doel van dit interview is om de geïdentificeerde risico’s en maatregelen uit de literatuurstudie te valideren en aan te vullen met de risico’s in de praktijk. We begrijpen dat de verstrekte informatie gevoelig kan zijn voor de SaaS leverancier en zullen de namen van zijn klanten en de naam van de SaaS leverancier zorgvuldig behandelen en indien gewenst anoniem houden. Onderzoeksvraag Wat zijn de verschillen tussen SaaS en andere outsourcing diensten en welk conceptueel risico raamwerk kan als handvat gebruikt worden om SaaS leveranciers te reviewen?

48

Vragen aan de SaaS leverancier 1.

Welke omschrijving/definitie hanteert jullie organisatie voor Software as a Service?

2.

Welke leveringsmodellen bieden jullie aan? (Multi tenant, Multi vendor, Multi integration)

3.

Welke verschillen zien jullie tussen SaaS en de traditionelere vormen van applicatie outsourcing, zoals applicatie hosting?

4.

Welke (IT en business) risico’s zien jullie als SaaS leverancier die specifiek zijn voor SaaS?

5.

Bespreken/validatie van de opgestelde risico’s. Herkennen jullie de geïdentificeerde risico’s?

6.

Welke bijbehorende maatregelen hebben jullie getroffen om deze risico’s af te dekken?

7.

Hoe zien jullie de ontwikkeling van SaaS naar de toekomst?

49

Bijlage 2 Conceptueel risico raamwerk Het conceptueel risico raamwerk is onderverdeeld in de categorieën ‘Applicatie Eigenschappen’, ‘Applicatie beheer’ en ‘Toegankelijkheid’. In deze categorieën zijn er in de literatuur IT-risico’s geïdentificeerd. In het conceptueel risico raamwerk wordt de herkomst van de IT-risico’s en maatregelen aangeduid door een ‘Χ’ te plaatsen in de kolommen ‘L’ van literatuur en ‘P’ van praktijk. Verschil SaaS t.o.v. traditioneel applicatie outsourcing

IT Risico

L

P

Maatregel

L

P

Applicatie Eigenschappen Webapplicatie, toegankelijk via het internet

Risico geïdentificeerd bij categorie toegankelijkheid.

One-to-many (‘multitenant’) software architectuur

•

Onvoldoende capaciteit infrastructuur (te weinig processorcapaciteit, te weinig netwerkbandbreedte en te weinig opslagcapaciteit)

•

Χ

• • •

Het implementeren van een passend capaciteitsplanning proces Periodiek worden er door de SaaS leverancier per SaaS applicatie analyses uitgevoerd voor de benodigde infrastructuur capaciteit Maandelijks vindt er een review plaats van de infrastructuur belasting De SaaS leverancier voorziet dat er voldoende service managers beschikbaar zijn ter ondersteuning van klanten, tevens stellen zij documentatie beschikbaar waarmee service managers elkaars taken kunnen overnemen

Χ

Het afstemmen van de wijzigingsbeheer procedure op de SaaS applicatie architectuur –en de data architectuur Het opstellen van een rechtenstructuur voor het beheren van

Χ

Χ

Χ Χ

Applicatie beheer SaaS leverancier voert • software ontwikkeling, het (technisch) beheer van de

Wijzigingen aan de SaaS code of database voor een afnemer heeft invloed op de applicatie / database van andere

•

Χ

•

50

Χ

applicatie én infrastructuur uit Flexibiliteit m.b.t. integratie met andere applicaties

SaaS afnemers • •

Integratieprobelemen tussen SaaS en andere software Onbeheersbaarheid van IT omgeving, door veel verschillende versies van de applicatiecode en interfaces

Χ

• •

Χ Χ

•

de SaaS applicatie en de SaaS database Het opstellen van een configuratie en customisatie strategie De SaaS leverancier hanteert twee wijzigingsbeheer procedures één generiek voor alle afnemers en één specifiek voor een bepaalde afnemer De SaaS applicatie is uitgerust met een groot aantal parameter instelmogelijkheden, waardoor het toevoegen van functionaliteit niet altijd tot een wijziging in de SaaS code hoeft te leiden.

Χ Χ Χ

Χ

Toegankelijkheid Eén database voor meerdere afnemers

•

Bij onvoldoende scheiding van data, is de juistheid en volledigheid van data niet gewaarborgd

• Χ •

Webapplicatie, toegankelijk via het internet

• •

•

Bij onvoldoende beveiligingsmaatregelen bestaat het risico op verlies, misbruik of diefstal van bedrijfsdata van afnemers. Vergroot risico dat ongeautoriseerde personen (bv. hackers) erin slagen om alle bedrijfskritische klantdata in één keer gestolen wordt. Bij een storing bij de internet provider wordt de SaaS applicatie onbeschikbaar of zijn er performance issues.

• Χ

• •

Χ • • Χ •

51

Het opstellen van een informatiebeveiligings-beleid, waarin onder andere scheiding van verantwoordelijkheden van medewerkers ten aanzien van de verscheidene afnemers, nondisclosure agreements en screenings is opgenomen. Het opstellen van SLA’s met afnemers, waarbij geen services worden gegarandeerd waarop de SaaS leverancier beperkte invloed kan uitoefenen Het toepassen van beveiligings metrieken om een bepaalde mate van beveiliging te kunnen garanderen Het periodiek laten uitvoeren van een security assessment door een derde partij Het vroegtijdig implementeren en reviewen van beveiliginsmaatregelen in elke fase van het softwareontwikkelings traject van SaaS applicaties Het inrichten van een Identity & Access Management systeem Het uitvoeren van additionele beveiligingstests om data beveiliging te garanderen en te voorkomen dat er 'breaches' ontstaan specifiek gericht op SaaS applicaties en de SaaS databases Het implementeren van sterke encryptie technieken en een

Χ

Χ Χ Χ Χ

Χ Χ

• • • • • • •

52

streng autorisatie beleid, waarbij wordt voorkomen dat gebruikers van de ene afnemer toegang hebben tot data van de andere afnemer. Het periodiek elektronisch monitoren en preventief beheren van de SaaS infrastructuur Het opstellen van SLA’s met (meerdere) service providers waarin voldoende beschikbaarheid, informatiebeveiliging en privacy wordt gegarandeerd. Voor het inloggen op de SaaS applicatie wordt een juiste login naam en wachtwoord combinatie vereist en een geldig certificaat. Er worden kwetsbaarheids en penetratie tests uitgevoerd zoals bijvoorbeeld SQL search op velden die daarvoor niet bevoegd zijn. Beheerders voeren account checks uit op de database. Data architectuur worden afgestemd op de geldende beveiligingseisen in een bedrijfssegment. Maandelijks vindt er een security overleg plaats, waarin het security beleid wordt geëvalueerd; Risico’s, mogelijke oplossingen en verbeterpunten worden voorgelegd aan het management- en directie team.

Χ

Χ Χ

Χ

Χ Χ Χ Χ

53