‘Voldoen of voldaan?’ - vurore.nl · Level 1‐strategie ... • Afstemming tijdens...

VRIJE UNIVERSITEIT AMSTERDAM

‘Voldoen of voldaan?’ Succesvolle invoering van PCI‐DSS

Daniel van Burk & Wouter Beens

Maart 2009

Groep 917 Scriptie in het kader van de postdoctorale opleiding IT Auditing. VU Coach: Robin Knip RE CISA Bedrijfscoach: Johan Sturm RE

Succesvolle invoering van PCI‐DSS

Pagina 2 van 43

Voorwoord Dit onderzoeksverslag over de invoering van de Payment Card Industry Data Security Standard (PCI‐DSS) is geschreven in het kader van het onderzoek ter afsluiting van de driejarige postdoctorale IT‐Audit opleiding aan de Vrije Universiteit te Amsterdam. Dit verslag is primair bedoeld voor de directe afstudeerbegeleiders en beoordelaars. Daarnaast is het verslag raadpleegbaar voor andere studenten van de IT‐Audit opleiding aan de Vrije Universiteit te Amsterdam. De keuze voor het onderwerp is gebaseerd op onze interesse in (IT) compliance gecombineerd met het feit dat wij beiden vanuit Atos Consulting een project hebben uitgevoerd binnen een payment service provider, waarbij PCI‐DSS een belangrijk onderdeel vormde. In dit onderzoek hebben wij een analyse gemaakt van inzichten uit de theorie en die geconfronteerd met inzichten uit praktijkinterviews. Dit heeft voor ons tot interessante nieuwe inzichten geleid. Wij willen een aantal mensen bedanken. Ten eerste onze scriptiebegeleiders, de heer Robin Knip namens de Vrije Universiteit en de heer Johan Sturm vanuit Atos Consulting. We waarderen hun in‐spanningen om ons dicht bij de centrale vraagstelling te houden. Daarnaast zijn de geïnterviewden voor deze scriptie van grote waarde geweest. Zonder het ‘kijkje in de keuken’ dat zij ons hebben ge‐geven had deze scriptie niet in deze vorm tot stand kunnen komen. Daniel van Burk & Wouter Beens Amsterdam, maart 2009


Pagina 3 van 43

Samenvatting In een wereld waarin credit card gegevens steeds vaker worden opgeslagen en getransporteerd in omgevingen die aan Internet zijn gekoppeld (o.a. als gevolg van e‐commerce) is het risico waaraan de credit card maatschappijen zijn blootgesteld de laatste jaren flink toegenomen. Om hieraan het hoofd te bieden hebben de grote credit card maatschappijen gezamenlijk de Payment Card Industry Data Security Standard (PCI‐DSS) uitgevaardigd. Doelstelling van deze scriptie is om vanuit het per‐spectief van de organisaties die PCI‐DSS moeten invoeren (de auditees) inzicht te verschaffen in de strategische keuzes die zij kunnen maken voor een succesvolle invoering van PCI‐DSS. In de scriptie hebben wij de volgende centrale vraagstelling onderzocht:

“Welke strategieën voor succesvolle invoering van PCI‐DSS zijn te onderscheiden?” Aan de hand van de criteria die zijn geformuleerd voor succesvolle invoering van PCI‐DSS hebben we onderzocht welke keuzes en overwegingen relevant zijn. Waar mogelijk hebben we aangegeven wel‐ke alternatieven de voorkeur genieten. Deze analyse hebben we gedaan aan de hand van de fasen die worden doorlopen bij de invoering. We hebben deze fasen gekozen omdat deze de stappen weergeven die nodig zijn om te komen tot het aantoonbaar voldoen aan de eisen uit PCI‐DSS: van het identificeren van de eisen waaraan de organisatie moet voldoen tot aan het afleggen van ver‐antwoording over de mate waarin men voldoet aan die eisen. Deze analyse heeft tot een tweetal mogelijke strategieën voor de invoering geleid, die zijn gekoppeld aan een tweetal voor PCI‐DSS relevante typen organisaties (de zogeheten merchant levels):

Level 1‐strategie ‘Geïntegreerde invoering van PCI‐DSS gericht

op toegevoegde waarde’

Level 4‐strategie ‘Stand‐alone invoering van PCI‐DSS gericht op

certificering’ • Actief monitoren van ontwikkelingen (wil

zo vroeg mogelijk op de hoogte zijn voor strategische afstemming)

• Voldoen aan de standaard • Veel aandacht voor alignment met ande‐

re initiatieven en strategie • Invloed proberen uit te oefenen op de

deadline • Intern opbouwen van kennis, wel inscha‐

kelen QSA • Vertalen van eisen vanuit een risico‐

analyse • Gaps bepalen a.d.h.v. een pre‐audit • Geïntegreerde impact analyse uitvoeren • Scope beperking toepassen • Risk based prioriteitstelling • Standaardisering van systemen en pro‐

cessen • Geïntegreerde projectopzet • Afstemming tijdens implementatie • Bewijs verzamelen centraal monitoren, in

de uitvoering vastleggen

• Niet actief monitoren van ontwikkelingen (wordt door de acquirer op de hoogte ge‐steld)

• Voldoen aan de standaard • Geen alignment nodig

• Invloed proberen uit te oefenen op de

deadline • Extern inhuren van kennis

• Vertalen van eisen vanuit de baseline

• Gaps bepalen a.d.h.v. een quick‐scan • Stand‐alone impact analyse uitvoeren • Scope beperkingen toepassen • Control based prioriteitstelling • Geen standaardisering van systemen en

processen • Stand‐alone projectopzet • Afstemming tijdens implementatie • Bewijs verzamelen en monitoren in één

functie


Pagina 4 van 43




certificering’ • Actief naar buiten brengen van de certifi‐

cering • Security breaches rapporteren

• Niet actief naar buiten brengen van de certificering

• Security breaches rapporteren In de praktijk zal het aantal mogelijke strategieën niet tot deze twee beperkt zijn, maar zal door combinaties van gekozen alternatieven een grotere diversiteit aan strategieën mogelijk zijn. Het is aan de organisaties die aan PCI‐DSS moeten voldoen om zelf een strategie te formuleren door het maken van keuzes in de diverse fasen van de invoering. Daarbij is het mogelijk om één van de twee door ons geformuleerde strategieën als vertrekpunt te nemen.


Pagina 5 van 43

Inhoudsopgave Voorwoord .............................................................................................................................................. 2 Samenvatting........................................................................................................................................... 3 Inhoudsopgave ........................................................................................................................................ 5 Inleiding ................................................................................................................................................... 6 Relevantie en doelstelling ................................................................................................................... 6 Centrale vraagstelling.......................................................................................................................... 6 Deelvragen .......................................................................................................................................... 7 Onderzoeksopzet................................................................................................................................. 7

1. Payment Card Industry Data Security Standard............................................................................ 10 1.1. Ontstaan van PCI‐DSS .......................................................................................................... 10 1.2. Het doel van PCI‐DSS............................................................................................................ 10 1.3. De kenmerken van PCI‐DSS.................................................................................................. 11 1.4. Belanghebbenden ................................................................................................................ 12

2. Keuzes en overwegingen tijdens de fasen van de invoering......................................................... 13 2.1. Kennisname van de (wijzigingen op) de standaard ............................................................. 13 2.2. Strategische besluitvorming ................................................................................................ 14 2.3. Interpretatie van de eisen.................................................................................................... 19 2.4. Gap en impact analyse......................................................................................................... 21 2.5. Planvorming ......................................................................................................................... 23 2.6. Implementatie en inbedding ............................................................................................... 25 2.7. Certificering en rapportage.................................................................................................. 26

3. Vaststellen van het succes van de invoering................................................................................. 29 4. Conclusies en aanbevelingen ........................................................................................................ 34 4.1. Beperkingen en aanbevelingen tot nader onderzoek ......................................................... 34

Literatuuroverzicht................................................................................................................................ 35 Bijlage 1 ‐ Compliance eisen.................................................................................................................. 37 Bijlage 2 ‐ Non‐compliance op PCI‐DSS eisen........................................................................................ 38 Bijlage 3 ‐ Report on Compliance eisen................................................................................................. 39 Bijlage 4 ‐ Kosten van PCI‐DSS............................................................................................................... 40 Bijlage 5 ‐ Relatie tot andere bestaande wet‐ en regelgeving en standaarden .................................... 41


Pagina 6 van 43

Inleiding Credit card maatschappijen lopen risico in geval van misbruik van credit card gegevens aangezien zij eventuele schade, die klanten (kaarthouders) lijden als gevolg van misbruik, moeten vergoeden. In een wereld waarin credit card gegevens steeds vaker worden opgeslagen en getransporteerd in om‐gevingen die aan Internet zijn gekoppeld (o.a. als gevolg van e‐commerce) is het risico waaraan de credit card maatschappijen zijn blootgesteld de laatste jaren flink toegenomen. Om hieraan het hoofd te bieden hebben een aantal credit card maatschappijen de krachten gebundeld in het Pay‐ment Card Industry Security Standards Council (vanaf hier PCI SSC). In 2005 is door MasterCard en VISA de Payment Card Industry Data Security Standard uitgevaardigd.

Relevantie en doelstelling De laatste jaren is er steeds meer aandacht voor het implementeren van beheersmaatregelen op basis van een risico inventarisatie. Daarnaast komen er meer eisen vanuit externe wet‐ en regelge‐ving en sector specifieke reguleringen. Binnen organisaties worden pogingen ondernomen om op efficiënte wijze om te gaan met implementatie en evaluatie van beheersmaatregelen evenals de verantwoording over de werking van de beheersmaatregelen naar externe partijen. Doelstelling van deze scriptie is om vanuit het perspectief van de organisaties die PCI‐DSS moeten invoeren (de auditees) inzicht te verschaffen in de strategische keuzes die zij kunnen maken voor een succesvolle invoering van PCI‐DSS.

Centrale vraagstelling In de scriptie zullen wij de volgende centrale vraagstelling onderzoeken:

“Welke strategieën voor succesvolle invoering van PCI‐DSS zijn te onderscheiden?” Onder invoeringsstrategieën verstaan wij het geheel aan keuzes en overwegingen die voor organisa‐ties richtingbepalend zijn voor de vraag of en vooral hoe de invoering van PCI‐DSS plaatsvindt binnen de organisatie. Onder invoering wordt verstaan de cyclus die wordt doorlopen vanaf het identificeren van de eisen waaraan de organisatie moet voldoen tot aan het afleggen van verantwoording over de mate waarin men voldoet aan die eisen. In het kader van deze scriptie zal niet worden ingegaan op de technische aspecten van implementatie van maatregelen. Voor de beantwoording van de vraagstelling hebben wij een aantal criteria gedefinieerd dat gehan‐teerd wordt voor de mate van succes van de invoering:

• Op basis van de genomen acties is er geen reden voor een boete vanuit de credit card maat‐schappij(en);

• In geval van fraude is er op basis van de genomen acties geen reden voor een verschuiving van de aansprakelijkheid van de credit card maatschappij(en) naar de merchant/service provider;

• De invoering leidt tot een certificering door een QSA danwel een Report on Compliance (af‐hankelijk van het level van de organisatie) naar de credit card maatschappij(en);

• De beveiliging met betrekking tot opslag en transport van kaarthoudergegevens wordt ver‐hoogd tot het door de organisatie gewenste niveau (als dit voor de invoering van PCI‐DSS nog niet het geval was);

• De mate waarin de invoering recht doet aan de organisatiestrategie (in het algemeen en meer in het bijzonder ten aanzien van de gekozen compliance strategie).


Pagina 7 van 43

Onder succesvol wordt niet verstaan dat er nooit meer een security breach met betrekking tot kaart‐houdergegevens zal optreden.

Deelvragen Om deze vraagstelling meer efficiënt en sturend te maken is uit de centrale vraagstelling een aantal deelvragen afgeleid. De deelvragen zijn tevens richtinggevend voor de beantwoording van de centra‐le vraagstelling: De Payment Card Industry Data Security Standard (PCI‐DSS) • Wat is PCI‐DSS (ontstaan, doel, kenmerken)? • Wat is de impact van PCI‐DSS (op marktomgeving, belanghebbenden)? • Wat is de mogelijke overlap van PCI‐DSS met andere wet‐ & regelgeving en standaarden? • Wat zijn de audit aspecten PCI‐DSS (objecten, scope, bewijslast, uitvoering en certificering)? Keuzes en overwegingen bij invoering en aanpak wet‐ & regelgeving en standaarden • Uit welke fasen bestaat het invoeringstraject van wet‐ & regelgeving en standaarden? • Welke keuzes moeten of kunnen tijdens deze fasen worden gemaakt? • Welke overwegingen spelen een rol bij het maken van de keuzes? • Op welke wijze is vast te stellen of de gemaakte keuzes een bijdrage hebben geleverd aan de suc‐

cesvolle invoering van PCI‐DSS? PCI‐DSS in de praktijk • Hoe gaan bedrijven in de huidige praktijk om met invoering van PCI‐DSS?

Onderzoeksopzet In onderstaande figuur is de opzet van het onderzoek schematisch weergegeven.

Schrijftraject

Onderzoekstraject

Ontwerpen onderzoeks‐ traject

Ontwerpen onderzoeks‐ traject

Analyse onderzoeks‐materiaal

Analyse onderzoeks‐materiaal

Verzamelen praktijk‐gegevens

Verzamelen praktijk‐gegevens

Analyse praktijk‐gegevens

Analyse praktijk‐gegevens

Verzamelen onderzoeks‐materiaal

Verzamelen onderzoeks‐materiaal

Koppeling maken theorie en praktijk

Koppeling maken theorie en praktijk

Concept strategieën Concept

strategieën

Eind‐rapportage (scriptie) opleveren

Eind‐rapportage (scriptie) opleveren

Figuur 1 ‐ Onderzoeksopzet Het onderzoek vond plaats in de periode september 2008 tot maart 2009. Voor de beantwoording van de deelvragen en de uiteindelijke centrale vraagstelling is gebruik gemaakt van literatuuronder‐zoek en interviews met ervaringsdeskundigen. Op basis van de uitkomsten van het onderzoek en de inzichten die daaruit naar voren kwamen hebben wij ervoor gekozen de deelvragen en het onder‐zoeksmodel ten aanzien van het originele onderzoeksvoorstel op onderdelen aan te passen. Dit heeft te maken met een aantal originele deelvragen die in de uiteindelijke beantwoording van de centrale vraagstelling niet meer hun oorspronkelijk veronderstelde relevantie hadden.


Pagina 8 van 43

In onderstaande figuur staat op hoofdlijnen het inhoudelijke onderzoeksmodel weergegeven.

PCI‐DSS achtergrondPCI‐DSS

achtergrond

Bestaande theorie

Bestaande theorie

Praktijk invoeringPCI‐DSS

Praktijk invoeringPCI‐DSS

Strategieën voor succesvolle

invoering PCI‐DSS

Strategieën voor succesvolle

invoering PCI‐DSS

Invoering van externe

standaarden

Invoering van externe

standaarden

Beheersing regelgevingBeheersing regelgeving

Figuur 2 ‐ Onderzoeksmodel scriptie Voor de analyse van mogelijke strategieën hebben we 3 mogelijke invalshoeken overwogen: 1. Redenerend vanuit compliance strategieën; 2. Redenerend vanuit de fasen van de invoering; 3. Redenerend vanuit de maatregelen die nodig zijn om te voldoen aan PCI‐DSS. Invalshoek 1 bleek meer van toepassing op de wijze waarop een organisatie omgaat met het geheel aan eisen vanuit regelgeving en heeft daardoor een te hoog abstractieniveau om specifiek voor de invoering van PCI‐DSS de centrale vraagstelling te beantwoorden. Invalshoek 3 heeft juist weer een te laag abstractieniveau om keuzes en overwegingen te koppelen aan de gestelde criteria voor suc‐cesvolle invoering. Invalshoek 2 biedt de mogelijkheid om de keuzes en overwegingen voor de gehele invoeringscyclus voor een standaard specifiek te kunnen koppelen aan PCI‐DSS, gekoppeld aan alle criteria voor succesvolle invoering van PCI‐DSS.

Literatuur Voor de achtergrond en kenmerken van PCI‐DSS, invoering van standaarden en beheersing van re‐gelgeving is naast de standaard zelf ook gekeken naar literatuur en artikelen uit de media. De litera‐tuur is verkregen via een literatuuronderzoek, waar onder andere gezocht is in: • Wetenschappelijke literatuur; • Artikelen in wetenschappelijke tijdschriften; • Artikelen in vakbladen; • Nieuwsberichten. Veel informatie m.b.t. de achtergrond van PCI‐DSS, standaarden en regelgeving was te vinden via internet (nieuwsberichten, opinieartikelen, officiële informatie over PCI‐DSS en studies van het IT Compliance Institute, ISACA en Forrester). ScienceDirect en de catalogus van de VU (Picarta) leverden artikelen over PCI‐DSS in vakbladen op. Beheersing van regelgeving was vooral terug te vinden in artikelen in wetenschappelijke tijdschriften en enkele (wetenschappelijke) boeken. Interviews Informatie over de implementatie van PCI‐DSS in de praktijk is verkregen door een zevental kwalita‐tieve interviews bij organisaties (payment service providers, issuing / acquiring banks & merchants) die de PCI‐DSS richtlijnen aan het invoeren zijn of deze al hebben ingevoerd. In de interviews behan‐delen we een vast aantal onderwerpen rondom de invoering van PCI‐DSS: besluitvorming & overwe‐gingen, moment & factoren bij invoering, beïnvloeding, gerelateerde standaarden/regelgeving, om‐gaan met wijzigingen en auditaspecten van PCI‐DSS.


Pagina 9 van 43

De respondenten zijn allen actief op de Nederlandse markt. Onder de respondenten zijn twee grote merchants, twee payment service providers, en twee banken. Daarnaast is met één van de respon‐denten (lid van PCI SSC) ook een aantal vragen rondom het PCI SSC doorgenomen en hebben we met een toezichthouder op het betalingsverkeer (De Nederlandsche Bank) gesproken. Opbouw van de scriptie Na deze inleiding zal in hoofdstuk 1 PCI‐DSS worden toegelicht om de nodige context te geven als basis voor de verdere analyse van de invoeringsfasen. In hoofdstuk 2 zullen we per fase van de invoe‐ring de keuzes en overwegingen analyseren die kunnen bijdragen aan de succesvolle invoering. Bij deze analyse zullen we inzichten uit theorie en praktijk meenemen en waar relevant met elkaar con‐fronteren. Na de bespreking van de fasen proberen we in hoofdstuk 3 vast te stellen welke strategie‐en kunnen leiden tot een succesvolle invoering. We ronden af met conclusies en aanbevelingen op basis van de analyse uit de eerdere hoofdstukken.


Pagina 10 van 43

1. Payment Card Industry Data Security Standard In dit hoofdstuk zal nader worden ingegaan op het ontstaan, doel, kenmerken en belanghebbenden van PCI‐DSS. Ten eerste om daarmee het onderwerp van de nodige context te voorzien. Daarnaast dient de informatie in dit hoofdstuk als basis voor de analyse die in het volgende hoofdstuk wordt gemaakt.

1.1. Ontstaan van PCIDSS De aanleiding voor het ontstaan van PCI‐DSS is een aantal security breaches in de afgelopen jaren bij organisaties in Amerika, waarbij door diverse betrokken partijen aanzienlijke schade is geleden. Daar‐bij zijn op grote schaal credit card gegevens ontvreemd, waarmee vervolgens fraude is gepleegd. De omvang van fraude met credit cards is zeer aanzienlijk1 en de trend lijkt dat vooral fraude met op illegale en digitale wijze verkregen credit card gegevens blijft stijgen. Het Amerikaanse congres heeft naar aanleiding van de fraudes gedreigd met ingrijpen d.m.v. het uitvaardigen van wetgeving. De credit card maatschappijen en de payments branche hebben, om dit te voorkomen, besloten om te komen tot een gezamenlijke standaard voor informatiebeveiliging van credit card gegevens (Mes‐smer, 2007; Meadowcroft, 2008; Messmer, 2009; Hines, 2008: 47). PCI‐DSS is in 2005 ontstaan vanuit de afzonderlijke credit card security programma’s van de Master‐Card en VISA. In 2006 is het PCI Security Standards Council (PCI SSC) opgericht door een vijftal grote credit card maatschappijen (American Express, Discover Financial Services, JCB, MasterCard World‐wide en Visa International). De verantwoordelijkheid voor PCI‐DSS is in 2006 ook overgegaan naar het PCI SSC, in dat jaar is ook de herziene versie uitgekomen. Inmiddels is in oktober 2008 de derde versie (1.2) gepubliceerd (Drew & Nair, 2008; Schwartz, 2007:7; Sussman, 2008:3). Ondanks de ge‐zamenlijke standaard voor informatiebeveiliging hebben de afzonderlijke maatschappijen nog wel elk hun eigen compliance programma (Bednarz, 2006; Morse & Raval, 2008). In Nederland wordt relatief weinig (t.o.v. VS) met credit cards betaald. Wel is het zo dat ook Neder‐landse merchants in toenemende mate te maken krijgen met fraude, waarvoor zij zelf verantwoorde‐lijk worden gesteld indien ze onvoldoende maatregelen hebben getroffen (Werf, 2009). Ook werd vorig jaar in het programma Zembla aandacht besteed aan Nederlandse credit card gegevens die te koop waren in Rusland (Van Kemenade, 2008).

1.2. Het doel van PCIDSS Het grootste risico voor credit card gegevens is de constant veranderende wijze van uitbuiten van zowel de technische als administratieve kwetsbaarheden in informatiesystemen die credit card gege‐vens opslaan, verwerken en transporteren. PCI‐DSS adresseert die kwetsbaarheden, in het bijzonder degenen die invloed hebben op de vertrouwelijke kaarthoudergegevens, en definieert een aantal minimale maatregelen die organisaties moeten nemen om de risico’s voortvloeiend uit de kwets‐baarheden in de beveiliging te minimaliseren (ITCI, 2007). Het doel van de standaard is dan ook om huidige en toekomstige beveiligingsrisico’s die in de pay‐ment industrie ontstaan te mitigeren en daarbij tevens een breed gedragen toepassing van informa‐tiebeveiliging op betaalsystemen te faciliteren (Schwartz, 2007:7).

1 Uit een onderzoek van Symantec blijkt dat er wereldwijd jaarlijks honderden miljoenen omgaan in de handel in gestolen credit card gegevens, waarbij de waarde op de kaarten in de miljarden loopt (Andriessen, 2008; Ringelestijn, 2008; Van Dijk, 2008).


Pagina 11 van 43

1.3. De kenmerken van PCIDSS Compliance met PCI‐DSS is een verplichting die voortvloeit uit het werken met één van de payment schemes van de bij het PCI SSC aangesloten credit card maatschappijen en wordt afgedwongen via contractuele bepalingen tussen merchants, acquirers, service providers en credit card maatschappij‐en (Morse & Raval, 2008). De verschillende credit card maatschappijen vereisen allen PCI‐DSS compliance, maar het aantonen van naleving en eventuele consequenties van non‐compliance verschillen per credit card maatschap‐pij. Dit zorgt voor onduidelijkheden (Morse & Raval, 2008:551, Bednarz, 2006). PCI‐DSS is een ‘rule‐based’ standaard met strikte eisen en beperkte ruimte voor interpretatie van de partij die de standaard toepast. Dit in tegenstelling tot bijvoorbeeld een standaard als ISO 27001 (Code voor Informatiebeveiliging) die meer is gericht op doelstellingen (‘principle‐based’). PCI‐DSS is neergezet als een baseline voor security, wat inhoudt dat het de organisatie niet ontslaat van de verantwoordelijkheid om een eigen security beleid te voeren gebaseerd op risico management. In PCI‐DSS zijn onder andere baselines voor beleid, procedures en technische eisen voor systeem‐componenten (o.a. applicaties, servers en netwerken) opgenomen. PCI‐DSS is van toepassing als er een PAN (Primary Account Number) wordt opgeslagen, verwerkt of getransporteerd2. De eisen zijn van toepassing op alle systeemcomponenten die tot de omgeving met de kaarthoudergegevens be‐horen of die hierop zijn aangesloten en richten zich voornamelijk op het kwaliteitsaspect “vertrouwe‐lijkheid” (PCI SSC, 2008; Schwartz, 2007:7). De beveiliging van de kaarthouder gegevens is onderverdeeld in zes domeinen en twaalf high level eisen. De twaalf eisen zijn weer onderverdeeld in detail vereisten. De tabel hieronder geeft een over‐zicht:

Domein Vereiste Een veilig netwerk opbouwen en onderhouden

1e vereiste: een firewallconfiguratie installeren en onderhouden om kaarthoudergegevens te beschermen 2e vereiste: geen fabrieksstandaarden voor systeemwachtwoorden en andere beveiligingsparameters gebruiken

Kaarthoudergegevens bescher‐men

3e vereiste: opgeslagen kaarthoudergegevens beschermen 4e vereiste: de overdracht van kaarthoudergegevens via openbare netwerken coderen

Een kwetsbaarheidsbeheerpro‐gramma onderhouden

5e vereiste: antivirussoftware gebruiken en regelmatig bijwerken 6e vereiste: veilige systemen en toepassingen ontwikkelen en onderhouden

Krachtige maatregelen voor toegangscontrole implemente‐ren

7e vereiste: de toegang tot kaarthoudergegevens beperken op basis van zakelijke need‐to‐know 8e vereiste: een unieke ID toewijzen aan iedere persoon met computertoegang 9e vereiste: de fysieke toegang tot Kaarthoudergegevens beperken

Netwerken regelmatig controle‐ren en testen

10e vereiste: alle toegang tot netwerkbronnen en kaarthoudergegevens bijhou‐den en bewaken 11e vereiste: beveiligingssystemen en ‐processen regelmatig testen

Een informatiebeveiligingsbeleid handhaven

12e vereiste: een beleid handhaven dat op informatiebeveiliging is gericht

Tabel 1 ‐ PCI‐DSS domeinen en eisen (PCI SSC, 2008)

2 De zogenaamde “gevoelige verificatiegegevens” zoals de volledige magneetstrip, PIN en CVC2/CVVV2/CID mogen onder geen voorwaarde worden opgeslagen.


Pagina 12 van 43

1.4. Belanghebbenden Ten aanzien van PCI‐DSS is er een aantal belanghebbenden met ieder hun eigen rol. In onderstaande tabel staan ze weergegeven:

Belanghebbende Rol Credit card maatschap‐pijen

• Gezamenlijk besturen van het PCI SSC • Penetratie van PCI‐DSS stimuleren richting acquiring3 en issuing4 banken die

hun card schemes voeren • Stellen merchants direct verantwoordelijk voor het naleven van PCI‐DSS (Ame‐

rican Express & Discover) • Stellen de acquirers verantwoordelijk voor het toezien dat op hun systemen

aangesloten merchants PCI‐DSS compliant zijn (Visa en MasterCard) PCI Security Standards Council (PCI SSC)

Namens de credit card maatschappijen: • Beheren van de PCI standaards5 • Accreditatie van QSA’s en ASV’s

Acquiring & Issuing ban‐ken

• PCI‐DSS compliant zijn • Erop toezien dat aangesloten merchants, waarvoor zij acquiring activiteiten

uitvoeren, dit ook zijn • Maken gebruik van service providers (bijvoorbeeld netwerkleveranciers en

processors) die de technische afhandeling van de transacties verzorgen Service Providers • PCI‐DSS compliant zijn Merchants • PCI‐DSS compliant zijn Quailified Security Asses‐sors (QSA’s)

• Adviseren de banken, processors en merchants bij inrichting van de eisen van PCI‐DSS

• Voeren de audits uit • Bieden resultaten van de audits ter goedkeuring aan de credit card maat‐

schappijen van het specifieke scheme aan, zodat de PCI‐DSS certificering kan worden afgegeven

Approved Scanning Ven‐dors (ASV’s)

• Voeren minimaal ieder kwartaal intrusion en vulnerability scans uit op net‐werken en applicaties van partijen die aan PCI‐DSS moeten voldoen

Tabel 2 ‐ Belanghebbenden van PCI‐DSS In Nederland is een belangrijke partij in het toezicht (oversight) op het betalingsverkeer De Neder‐landsche Bank. Vanuit die rol volgen zij de ontwikkelingen op het gebied van PCI‐DSS, maar hebben daar geen directe relatie mee. Wel kunnen zij besluiten om voor specifieke onderdelen te steunen op een PCI‐DSS certificering van een organisatie.

3 Acquiring: het accepteren en verwerken van credit card transacties voor het card scheme waar de merchant is aangesloten door een bank of processor. 4 Issuing: het verwerken van aanvragen en uitgeven van credit cards aan kaarthouders 5 Naast PCI‐DSS zijn er nog een aantal andere standaarden zoals de PA‐DSS voor payment applicaties en de PCI‐PED voor PIN Entry Devices


Pagina 13 van 43

2. Keuzes en overwegingen tijdens de fasen van de invoering

In het vorige hoofdstuk is ingegaan op de kenmerken van PCI‐DSS zelf. In dit hoofdstuk gaan we na‐der in op de keuzes en overwegingen die relevant zijn voor de succesvolle invoering van PCI‐DSS. Deze analyse doen we aan de hand van de fasen die worden doorlopen bij de invoering, waarbij we bondig bij elke fase aangeven welke invloed de uitvoering van de fase kan hebben op een succesvolle invoering. We hebben deze fasen gekozen omdat deze de stappen weergeven die nodig zijn om te komen tot het aantoonbaar voldoen aan de eisen uit PCI‐DSS: van het identificeren van de eisen waaraan de organisatie moet voldoen tot aan het afleggen van verantwoording over de mate waarin men voldoet aan die eisen. Per fase behandelen we enkel voor het succes van de invoering relevante keuzes en overwegingen. De keuzes per fase zijn voortgekomen uit de inzichten uit theorie, praktijk en eigen analyse, gerela‐teerd aan de criteria voor succesvolle invoering (zie Inleiding). Daarnaast is vanuit de criteria voor succesvolle invoering een check gedaan op eventuele ontbrekende keuzes. De fasen die we voor de invoering onderscheiden zijn de volgende:

1. Kennisname

van de standaard

1. Kennisname

van de standaard

2. Strategische besluit‐vorming

2. Strategische besluit‐vorming

3. Interpretatie van de eisen

3. Interpretatie van de eisen

6. Certificering

en rapportage

6. Certificering

en rapportage

4. Gap en impact analyse

4. Gap en impact analyse

6. Implemen‐tatie en inbedding

6. Implemen‐tatie en inbedding

5. Planvorming

5. Planvorming

Wijzigingen op de standaard

Bevindingen

Figuur 3 ‐ Fasen tijdens de invoering

2.1. Kennisname van de (wijzigingen op) de standaard Het compliant worden aan eisen vanuit wet‐ & regelgeving en standaarden start met de kennis van het bestaan van de eisen (en wijzigingen daarvan) en indien van toepassing de verplichting om eraan te voldoen. Van PCI‐DSS zijn sinds de introductie in 2005 twee nieuwe versies geïntroduceerd en daarbij zijn diverse ondersteunende documenten gepubliceerd. In deze fase analyseren we de me‐chanismen die organisaties aan kunnen wenden om op de hoogte te raken van nieuwe eisen en wij‐zigingen van bestaande. De snelheid waarmee men kennis neemt van de eisen bepaalt de tijd en ruimte die een organisatie heeft om te kiezen voor een invoering die is afgestemd op de organisatie‐strategie. Het stelt de organisatie in staat om tijdig aan PCI‐DSS te voldoen en voorkomt daarmee boetes voor non‐compliance en aansprakelijkheid (bij fraude) in geval van non‐compliance. Tijdens deze fase komt het management van de organisatie voor de volgende keuze te staan: • Wel of niet actief monitoren van ontwikkelingen (ten aanzien van PCI‐DSS);


Pagina 14 van 43

Wel of niet actief monitoren van ontwikkelingen Het actief monitoren van ontwikkelingen is bepalend voor de snelheid waarmee men op de hoogte raakt van nieuwe eisen en wijzigingen daarop. Bij niet actief monitoren geeft de organisatie het initi‐atief bij het op de hoogte raken uit handen. Het opmerken van nieuwe ontwikkelingen ten aanzien van wet‐ & regelgeving en standaarden kan op een aantal verschillende wijzen (Van Zoest, 2007: 52): • Via de organisatie die de standaard uitvaardigt; • Via brancheverenigingen; • Via publicaties in media; • Via kennisevenementen (congressen, seminars, etc.); • Via informele contacten. Een overweging bij actieve monitoring is de plaats in de organisatie waar dit belegd is. Onze ervaring is dat onderstaande afdelingen een optie zijn: • Bij de juridische afdeling; • Bij risk management, compliance & security afdelingen; • Bij de lijnorganisatie die uiteindelijk verantwoordelijk is voor naleving van eisen. Bij de respondenten zijn we alle drie de genoemde varianten tegengekomen. Ten aanzien van PCI‐DSS kan worden aangehaakt op activiteiten die al plaatsvinden voor het bijhouden van de protocol‐len van de card schemes (dit geldt met name voor service providers). In de praktijk zien we een grote variatie in de wijze waarop en de snelheid waarmee organisaties op de hoogte zijn gebracht (zie ook paragraaf 1.4 Belanghebbenden): • Enkele partijen waren al op de hoogte voordat zij formeel in kennis werden gesteld, door actieve

monitoring of kennisuitwisseling met andere organisaties. Anderen wisten het vanaf de formele kennisgeving;

• Waar de één rond 2005 al op de hoogte was gesteld was een ander rond die tijd enkel informeel op de hoogte en werd pas rond 2007 officieel geïnformeerd.

Alle respondenten geven aan dat zij de eisen uit nieuwe versies van de standaard willen implemente‐ren zodra deze bekend zijn. Het is opvallend dat voor een aantal respondenten geldt dat zij min of meer per toeval geconfronteerd zijn met de laatste nieuwe versie (1.2) van PCI‐DSS. Organisaties die het eerste op de hoogte waren van de standaard hebben meer tijd gehad en ge‐bruikt voor de invoering. Wij zijn van mening dat een mechanisme voor actieve monitoring op veran‐derende eisen uit wet‐ & regelgeving en standaarden de mogelijkheid vergroot op een tijdige certifi‐cering en daarmee de kans op boetes en aansprakelijkstelling verkleint.

2.2. Strategische besluitvorming Door strategische besluitvorming wordt richting gegeven aan de manier waarop de organisatie invul‐ling geeft aan de invoering van PCI‐DSS. PCI‐DSS legt eisen op aan de organisatie (met mogelijk aan‐zienlijke consequenties) en men zal aan alle eisen moeten voldoen om te kunnen certificeren. De organisatie zal afwegingen moeten maken die uitwijzen of en hoe de invoering van PCI‐DSS zodanig kan worden vormgegeven dat de wijze van invoering aansluit op de organisatiestrategie. Het mana‐gement stelt kaders voor verdere invoering en zorgt voor afstemming met reeds gemaakte keuzes t.a.v. technologie, compliance en informatiebeveiliging. Tevens wordt in deze fase helder wat de ambitie is ten aanzien van de invoering en in welke mate de organisatie zich aan de invoering com‐mitteert. We gaan eerst in op een tweetal invalshoeken voor de positionering van de organisatie ten opzichte van de standaard. Die positionering vormt een vertrekpunt voor de te maken keuzes in deze fase.


Pagina 15 van 43

Positionering ten opzichte van de standaard Van belang voor de positionering van de organisatie ten opzichte van PCI‐DSS zijn enerzijds de ver‐wachte voordelen van de invoering van de standaard en anderzijds de gevolgen van non‐compliance. Het verwachte voordeel voor de organisatie is een afweging van een aantal mogelijke voor‐ en nade‐len, waarvan onderstaand een aantal voorbeelden is gegeven:

Voordelen Nadelen • Toename beveiligingsniveau • Vertrouwen in de organisatie • Concurrentiepositie (‘first mover

advantage’, toenemende klantvraag, ‘license to operate’)

• Lagere verwerkingskosten voor transacties van acquirers en mer‐chants die PCI‐DSS compliant zijn6;

• Afname fraude • Aansluiting op technologische ver‐

nieuwing

• ‘Audit burden’ • Eisen kunnen leiden tot andere in‐

richting van systemen dan gewenst cq. tot hoge kosten (upgrade van in‐frastructuur, assessment kosten en onderhouden van compliance)

• Systeemaanpassingen die de norma‐le operatie kunnen verstoren

• Kosten van het invoeringsproject • Kosten van onderhoud van de certi‐

ficering Tabel 3 ‐ Voor & nadelen van invoering Bij PCI‐DSS zijn er in het geval van non‐compliance verschillende mogelijke gevolgen: • Boetes in het geval van security incidenten vanuit de credit card maatschappijen7 aan de acquirers; • Boetes (maandelijks oplopend) vanuit de credit card maatschappijen naar acquiring banken voor

non‐compliant merchants (die dit op hun beurt weer doorberekenen naar de merchants); • Boetes (maandelijks) voor het opslaan van verboden credit card gegevens door de credit card

maatschappijen (Messmer, 2007: 2); • Aansprakelijkstelling van merchants en acquirers voor de directe schade (zoals het vervangen van

credit cards, schadeloos stellen van slachtoffers van fraude); • Aansprakelijkstelling van acquirers en merchants voor maatschappelijke schade (zoals inbreuk op

de privacy van kaarthouders) (Morse & Raval, 2008: 541); • Intrekking van de mogelijkheid om transacties van het card scheme te verwerken (acquirer) of

betalingen te accepteren (merchant) (Meadowcroft, 2008; Adler & Swanson, 2007); • Imagoschade bij organisaties met een beveiliging/fraude incident, wat de continuïteit van de orga‐

nisatie in gevaar kan brengen (PaySquare, 2009);

6 VISA biedt lagere verwerkingskosten voor banken die zorgen dat de op hun aangesloten acquirers PCI‐DSS compliant zijn, die deze korting ook weer kunnen doorrekenen aan hun merchants. Andere maatschappijen gaan dit voorbeeld ook toepassen (Schwartz, 2007). 7 PCI‐DSS is geen wetgeving en wordt door de credit card maatschappijen geregeld in de contracten met de acquirers. De credit card maatschappijen hebben meestal geen directe relatie met de merchants en stellen daarom de acquirers aansprakelijk voor het hebben van PCI‐compliant merchants.


Pagina 16 van 43

Wanneer we deze twee factoren tegen elkaar afzetten ontstaan vier mogelijke invalshoeken die stu‐rend kunnen zijn voor de strategische keuzes die de organisatie in deze fase maakt.

• Snelheid geboden

• Kosten zo laag mogelijk

• Voldoen wanneer het echt moet



• Kosten mogen hoger uitvallen wanneer de baten mee stijgen

• Realisatie van baten belangrijker dan snelheid van implementatie




• Voldoen wanneer het echt moet




• Realisatie van baten belangrijker dan snelheid van implementatie


Gevolgen van non‐compliance

Verwachtevoordelen

Groot

Hoog

LaagKlein

Figuur 4 ‐ Invalshoeken voor strategische keuzes Organisatieniveau dat betrokken is bij de besluitvorming en invoering van PCI‐DSS Voor het waarborgen van een goede invoering en het maken van de juiste keuzes is het van belang dat zowel de business als IT betrokken is bij besluitvorming. PCI‐DSS is een standaard voor informa‐tiebeveiliging en veel van de eisen zijn van technische aard, de invoering ervan is echter niet alleen een IT aangelegenheid. Voor een goede alignment van de invoering met de business en haar doel‐stellingen is het van belang dat zowel business‐ als IT management betrokken zijn bij de besluitvor‐ming. Dit is ook van belang voor de noodzakelijke toezegging van resources in de fase “planvorming”. Bij de meeste geïnterviewde organisaties is zowel business als IT management betrokken bij de be‐sluitvorming. In deze fase komt het management voor de volgende keuzes te staan: • Wel of niet voldoen aan de standaard • Alignment met andere initiatieven/strategie (t.a.v. business‐IT alignment, technologie, complian‐

ce en informatiebeveiliging) • Moment van invoering van en voldoen aan de standaard • Wel of niet proberen invloed uit te oefenen (om compliance aan de standaard meer in lijn met

eigen organisatiedoelstellingen te krijgen)

Wel of niet voldoen aan de standaard Een van de eerste vragen die de organisatie zich kan stellen is of het accepteren van credit cards met inbegrip van de PCI‐DSS eisen (en de consequenties daarvan) nog past binnen de organisatiestrate‐gie. Voor organisaties waarbij de afhankelijkheid van credit cards als betaalmiddel laag is en de kos‐ten om aan PCI‐DSS te voldoen hoog zijn kan het een overweging zijn om te stoppen met het accep‐teren van credit cards. Zeker in Nederland, waar het gebruik van credit cards relatief laag is, kan dit voor organisaties een reële overweging zijn. Op die manier wordt voorkomen dat er boetes en aan‐sprakelijkheidstelling plaatsvinden. Alle respondenten hebben ervoor gekozen om te voldoen aan de standaard. Gezien de centrale vraagstelling van de scriptie gaan we alleen verder op de keuze om credit cards te blijven accepteren en te voldoen aan de standaard.


Pagina 17 van 43

Alignment met andere initiatieven/strategie De besluitvormingsfase is een geschikt moment om de gehele PCI‐DSS invoering in lijn te brengen met de organisatiestrategie en geplande activiteiten: • In het kader van business‐IT alignment is het logisch de strategie voor de beheersing van regelge‐ving in het IT domein op de business strategie af te stemmen (Henderson & Venkatraman, 1999). Kiest een organisatie er in de markt voor om een ‘early mover’ te zijn, dan lijkt het logisch om ook te anticiperen op nieuwe eisen, zeker wanneer daar een (tijdelijk) competitief voordeel mee te behalen is.

• In een recent onderzoek naar het behalen van een competitief voordeel uit opgelegde aanpassin‐gen in informatiesystemen wordt gesteld dat organisaties die de aanpassingen kunnen combine‐ren met aanpassingen die reeds gepland stonden in het voordeel zijn ten opzichte van concurren‐ten. Onder andere omdat de kans dat ze hiermee in lijn met de bedrijfsstrategie handelen groter is (Krell & Matook, 2009: 4‐5).

• Op het gebied van beveiliging kan aangehaakt worden op eventueel reeds toegepast beveiligings‐standaarden (zie ook paragraaf 2.5 Planvorming) waarbij tot een geïntegreerde en samenhangen‐de set van beveiligingsmaatregelen gekomen kan worden.

• Met betrekking tot compliance is het raadzaam om te kijken hoe de keuzes voor het moment van invoering en het wel of niet proberen invloed uit te oefenen passen in de eventuele overall com‐pliance strategie die de organisatie hanteert. Op die manier kan gebruik gemaakt worden van reeds bestaande mechanismen voor invoering van standaarden en bestaande platfor‐men/overlegstructuren voor beïnvloeding.

Op deze wijze kan men voorkomen dat er onder hoge tijdsdruk ingegrepen moet worden op reeds ingeslagen paden en worden dubbele kosten en besluiten vermeden die niet leiden tot toegevoegde waarde. Moment van invoering van en voldoen aan de standaard In lijn met de organisatiestrategie moet ook bepaald worden welk moment de organisatie kiest om te starten met de invoering en op welk moment ze compliant wil zijn aan de standaard. Organisaties die voorop willen lopen met ontwikkelingen zullen meer gebaat zijn bij snelle invoering. Organisaties die het laagste kostenniveau nastreven willen gebruik kunnen maken van ervaring die andere organisa‐ties hebben opgedaan met de invoering van de standaard. Organisaties worden geconfronteerd met eisen van externe partijen waaraan voldaan moet worden. Weidenbaum (1980) betoogt dat er drie generieke reacties zijn op deze eisen, te weten passief reageren, positief anticiperen en beleid beïn‐vloeden. Hierbij worden ondernemingen door toenemende regelgeving gemotiveerd om van een passief reagerende naar een beleid beïnvloedende reactie op te schuiven. Vanagas & Žirgutiene (2005) nemen een soortgelijke verschuiving waar van een reactieve naar een proactieve benadering van compliance (zie figuur 5).

Figuur 5 ‐ Compliance Paradigm Shift (Vanagas & Žirgutiene, 2005) Het lange termijn competitief voordeel (sustainable competitive advantage) neemt toe bij respectie‐velijk een reactieve, anticiperende en proactieve strategie (Oliver & Holzinger, 2007: 33).


Pagina 18 van 43

• Bij proactief reageren heeft de eigen organisatie het initiatief en kan het PCI‐DSS ook actief inzet‐ten als instrument voor informatiebeveiliging en marketing (commercieel gebruik maken van vroege certificering) en is er ook tijd om de invoering handig en beheerst te plannen en in lijn met andere noodzakelijke wijzigingen (vervanging applicaties etc.) te laten verlopen;

• Bij tijdige reactie zijn deze voordelen in mindere mate aanwezig aangezien het voordeel van de beschikbare tijd er dan minder is en het inzetten van certificering als marketing instrument ver‐minderde uitwerking heeft. Daarnaast ligt het initiatief op dat moment bij de partij die PCI‐DSS vereist, hoewel er nog voldoende tijd is voor een geleidelijke invoering;

• Bij reactief reageren ligt de termijn waarop men compliant moet zijn in de nabije toekomst en zal de invoering onder zwaardere druk plaatsvinden. Er is dan geen tijd meer om de invoering in lijn met andere keuzes van de organisatie te plannen. Daar staat tegenover dat het wachten met de invoering als voordeel kan bieden dat men kan leren van de ervaring van anderen. Later versche‐nen verduidelijking van de richtlijnen kunnen bij latere invoering in een keer worden meegeno‐men.

Naast de positionering (in termen van verwacht voordeel van invoering en gevolgen van non‐compliance) van de organisatie ten opzichte van de standaard zijn er nog een aantal factoren, die de keuze voor het moment van invoeren en compliant worden beïnvloeden: • Maatschappelijke verantwoordelijkheid (vanwege mogelijke effecten van security breaches op

andere partijen in het maatschappelijk verkeer); • Ontstaan van kritieke massa (als steeds meer concurrenten voldoen wordt het een nadeel als je

niet voldoet); • Toenemende druk van card schemes; • Reeds aanwezige niveau van beveiliging; • Vermijden van investeringen in legacy technologie (applicaties, systemen en netwerken) wan‐

neer deze voor vervanging gepland staat. De reactie van de respondenten op PCI‐DSS verschilde per organisatie. De partijen die proactief rea‐geerden (verplichting was nog niet opgelegd) deden dat vooral om zeker te stellen dat de gevolgen van non‐compliance werden beperkt door implementatie van de maatregelen. Bij de partijen die tijdig reageerden waren de vrees voor boetes en reputatieschade bij non‐compliance en de toename van de informatiebeveiliging de belangrijkste redenen. Bij partijen die reactief reageerden werd in de ene organisatie de noodzaak niet gezien aangezien het beveiligingsniveau al voldoende werd geacht. Daar is na een aantal jaren pas besloten om PCI‐DSS in te voeren vanuit een commercieel oogpunt (toenemende vraag van klanten om PCI‐DSS compliance, waardoor het op termijn een disqualifier kon worden in bid trajecten, helemaal als concurrerende bedrijven wel compliant zijn). Deze laatste overweging was voor de andere organisatie die zich reactief opstelde ten aanzien van PCI‐DSS ook doorslaggevend om met PCI‐DSS aan de slag gegaan. Bij de partijen die zich reactief opstellen zien we dat de invoering meer problemen (te weinig tijd voor goede studies naar oplossingen, de noodzaak voor tijdelijke compenserende maatregelen om security breaches en aansprakelijkstelling te voor‐komen) oplevert dan bij de partijen die dat proactief of tijdig doen. Deze hebben wel voldoende tijd om voorbereidingen te treffen en in een keer de juiste maatregelen te implementeren. Uit oogpunt van het tijdig certificeren (en daarmee de kans op boetes en aansprakelijkstelling ver‐kleinen) en de verhoging van het beveiligingsniveau zijn wij van mening dat een proactieve aanpak de meeste voordelen biedt. Wel of niet proberen invloed uit te oefenen Beïnvloedingsstrategieën worden gedefinieerd als acties voor het vergaren van steun voor de belan‐gen van de onderneming (Shaffer, 1995; Oliver & Holzinger, 2007). Concurrentie vindt niet alleen plaats in de markt maar ook in de politieke arena. Organisaties kunnen concurrentievoordeel beha‐


Pagina 19 van 43

len door zich actief in deze politieke arena te bewegen en daar te pogen regelgeving naar hun hand te zetten (Henisz & Zelner, 2003). Voor PCI‐DSS kan worden gepoogd invloed uit te oefenen op de inhoud (eisen) en opzet (rule‐based) van de standaard en op de deadline voor het voldoen aan de standaard om dit beter te laten aansluiten op de eigen doelstellingen en keuzes van de organisatie. Invloed proberen uit te oefenen op de inhoud kan, zeker gezien het rule‐based karakter van PCI‐DSS, van belang zijn om (fundamentele) wijzigingen in de opzet van PCI‐DSS geaccepteerd te krijgen door de credit card maatschappijen. Hiervoor is het dan wel noodzakelijk coalities te vormen (bijvoorbeeld middels een branchevereniging) (Van Zoest, 2007). Een aantal respondenten heeft bij latere versies via het PCI SSC geprobeerd invloed uit te oefenen middels reviews op de voorstellen. Daarbij wordt wel een aantal zaken opgemerkt: • PCI SSC luistert naar de (invloedrijke) partijen in de markt; • De werkelijke invloed wordt als beperkt ervaren en de discussie blijft soms erg theoretisch. Ten aanzien van de deadline van het voldoen aan de standaard hebben op twee na alle responden‐ten geprobeerd invloed uit te oefenen op de invoering van de standaard. Er is vooral met de credit card maatschappijen gesproken om tot overeenstemming te komen over een voor beide partijen acceptabel moment van compliance. Slechts één van de respondenten maakt actief gebruik van coalities met andere partijen die eenzelf‐de belang hebben. Eén andere partij heeft een poging hiertoe ondernomen, die gestrand is als gevolg van concurrentieoverwegingen. Gezien de beperkte invloed die in de praktijk mogelijk lijkt, is het voor individuele partijen naar onze mening weinig zinvol om te kiezen voor beïnvloeding op de inhoud van de standaard. Enkel wanneer gebruik gemaakt wordt van coalities voor het bereiken van kritieke massa vinden wij beïnvloeding ten aanzien van de inhoud een zinvolle keuze. Met betrekking tot het moment van compliant worden vinden wij het raadzaam om hierover met de organisatie die de compliance vereist in overleg te tre‐den, hierdoor is de kans groter dat het moment van invoering aan te sluiten is op de plan‐ning/strategie van de eigen organisatie. Het vergroot de kans op certificering aangezien er meer tijd is om een beheerste invoering te doorlopen.

2.3. Interpretatie van de eisen De juiste interpretatie van de eisen leidt tot snellere certificering aangezien er ten tijde van de audit geen misverstanden meer bestaan over de vraag of nu wel op de juiste manier aan de eisen uit de PCI‐DSS is voldaan. Het lijkt enerzijds makkelijk dat de PCI‐DSS een rule‐based opzet kent, dit laat onverlet dat er nog steeds een goed begrip vereist is van wat er nu precies wordt gevraagd en op welke onderdelen het nu wel en niet van toepassing is op de eigen organisatie8. De interpretatie vormt één van de moeilijkste onderdelen bij het invoeren van wet‐ en regelgeving en standaarden.

8 Bij PCI‐DSS wordt de interpretatie bemoeilijkt door de opzet van PCI‐DSS zelf. Morse & Raval (2008) zetten uiteen dat de eisen onderling verschillen in aard, scope en detailniveau. Enkele eisen zijn sterk voorschrijvend (firewall configuratie, data encryptie), terwijl andere ruimte laten voor eigen invulling (‘business need to know’). Daarnaast zijn de structuur en volgorde van de eisen weinig logisch. De eis die de toon zou moeten zetten voor de hele standaard (het hebben en onderhouden van een informatiebeveiligingsbeleid) is de laatste eis van de standaard, terwijl deze als eerste verwacht zou mogen worden.


Pagina 20 van 43

Tijdens deze fase staat het management voor de volgende keuzes: • Intern opbouwen van de benodigde kennis of naar behoefte extern inhuren;

• Ambitieniveau bij de vertaling van eisen naar de eigen organisatie. Intern opbouwen van de benodigde kennis of naar behoefte extern inhuren Door wijzigingen op de standaard, het uitkomen van aanvullende documentatie en door wijzigingen in de processen en systemen in de organisatie is interpretatie van de eisen geen eenmalige exercitie. Voor een goede interpretatie is specialistische kennis vereist op diverse terreinen (over de standaard zelf en de toelichting daarop maar ook over mogelijke maatregelen in systemen en processen die aan de eisen voldoen). De organisatie kan ervoor kiezen om deze kennis tijdelijk van buiten de organisa‐tie te betrekken door inhuren van externen (QSA’s, juristen, consultants) die zich in de specifieke aandachtsgebieden hebben gespecialiseerd. Het alternatief is om de kennis intern op te bouwen. Aanvullend kan men in beide situaties gebruik maken van kennis in branche‐ en vakverenigingen en afstemming met de toezichthouder/de partij die de eisen oplegt. Het voordeel van extern inhuren is de flexibilisering van de kosten en de toegang tot up‐to‐date spe‐cialistische kennis in de markt. Het voordeel van het intern opbouwen van de kennis is dat deze per‐manent beschikbaar is en deze kennis snel in kan zetten in geval van wijzigingen. Ondanks het feit dat de PCI‐DSS een rule‐based standaard is, bieden de eisen in de PCI‐DSS nog aan‐leiding tot interpretatie. Op dit vlak zijn er grote overeenkomsten tussen de diverse respondenten. Ten eerste hebben, op één na, alle geïnterviewden een QSA in de hand genomen om te ondersteu‐nen bij de interpretatie van de standaard. In een aantal gevallen heeft deze QSA ook geholpen in de contacten met credit card maatschappijen om onduidelijkheden of standpunten van de organisatie ten aanzien van de interpretatie van de standaard af te stemmen. Ten tweede bleek de interpretatie van de standaard in de meeste gevallen een lastige exercitie, vooral het bepalen van de scope (is‐suing/acquiring, services, systemen, geografisch) was daarbij lastig. Door enkele van de responden‐ten wordt als reden de inconsistente terminologie in de standaard gegeven. Ook het statement op hoofdlijnen dat de eisen van toepassing zijn op alles wat met payments te maken heeft leidt tot veel discussie. Het is van belang om te voorkomen dat ten tijde van de certificering tekortkomingen met een grote impact (bijvoorbeeld investering in een webapplicatie die niet voldoen aan de OWASP eisen) naar voren komen als gevolg van een verkeerde of ongelukkige interpretatie van de standaard. Daarom vinden wij het verstandig om in een vroeg stadium een adviseur aan te stellen die over voldoende kennis beschikt om een goede interpretatie te maken. Het is vervolgens afhankelijk van de grootte van de organisatie of het haalbaar is om deze kennis intern te borgen. Ambitieniveau bij de vertaling van eisen naar de eigen organisatie De keuze voor het ambitieniveau bij de vertaling van de eisen naar de eigen organisatie is van invloed op de vraag of de invoering tot een verhoging van het beveiligingsniveau gaat leiden. Bij de interpre‐tatie van de eisen heeft de organisatie de keuze om: • Vast te houden aan de baseline positie die door PCI‐DSS wordt gegeven (leidt tot minimale maat‐

regelen); • De interpretatie uit te voeren in het licht van de risico’s die daadwerkelijk worden gelopen en

waar nodig zichzelf hogere eisen te stellen dan strikt genomen vanuit PCI‐DSS gezien noodzake‐lijk zijn (kan leiden tot zwaardere maatregelen).

Hanteren van de baseline draagt bij aan het snel gecertificeerd raken van de organisatie. De interpre‐tatie vanuit de daadwerkelijke risico’s draagt bij aan minimaliseren van de kans op security inciden‐ten. Bij de ondervraagde organisaties zagen we zowel de keuze om dicht bij de baseline te blijven om de kosten te beperken en vanwege het commerciële belang van certificering als organisaties die de eisen interpreteerden vanuit hun eigen beveiligingsrisico’s om daarmee het niveau van informatie‐


Pagina 21 van 43

beveiliging te verhogen. Onze voorkeur is dat organisaties vooral redeneren vanuit de daadwerkelijke risico’s omdat dit het meest bijdraagt aan een verbetering van het beveiligingsniveau.

2.4. Gap en impact analyse Het adequaat uitvoeren van de gap en impact analyse is van belang voor tijdige certificering tegen de eisen van PCI‐DSS. PCI‐DSS certificering vergt invulling van alle eisen. Helder krijgen waar nog niet wordt voldaan aan de eisen en wat nodig is om een plan op te stellen dat invulling geeft aan het daadwerkelijk oplossen van de gaps. Een reële inschatting van de impact betekent dat de organisatie later in het traject niet voor verrassingen komt te staan die de certificering in de weg staan. Scope vaststellen Een belangrijk en lastig onderdeel bij het bepalen van de scope is het in kaart brengen van de gehele betaalomgeving en het inventariseren van systeemcomponenten9 waar kaarthoudergegevens wor‐den opgeslagen, verwerkt en getransporteerd, inclusief maatregelen voor informatiebeveiliging. Uit onderzoek blijkt dat veel organisaties niet goed weten waar de kaarthoudergegevens allemaal wor‐den gebruikt. Daarnaast blijkt dat ook regelmatig nog verboden gegevens worden opgeslagen zoals de CVV2 en PIN (Carr, 2008; Paysquare, 2009; Drew & Nair, 2008). De respondenten hebben allen de scope in kaart gebracht, waarbij één partij aangaf dat het veel moeite had met de afbakening daarvan. Tijdens deze fase komt het management van de organisatie voor de volgende keuze te staan: • Diepgang van de gap analyse; • Stand‐alone of geïntegreerde impact analyse. Diepgang van de gap analyse De keuze voor de diepgang van de analyse is een afweging tussen de snelheid waarmee de gap ana‐lyse kan worden gemaakt en de zekerheid die de uitkomsten van de analyse bieden. Voor de gap analyse kan men, naast de standaard zelf, gebruik maken van de PCI‐DSS Security Audit Procedures. Daarin zijn de test procedures helder beschreven, ze geven houvast voor het vaststellen van de gaps. Bij het uitvoeren van de gap analyse kan de organisatie overwegen om: • Een pre‐audit uit te (laten) voeren; • Een beperkte gap analyse uit te voeren o.b.v. documentatie; • Een quick‐scan uit te voeren bijvoorbeeld o.b.v. het eigen control framework. Een overweging hierbij is de complexiteit van de betaalomgeving, met name ten aanzien van de sys‐teemcomponenten en de mate waarin men de documentatie op orde heeft. Het voordeel van een pre‐audit op de omgeving is dat men inzicht krijgt in alle tekortkomingen in de actuele situatie voor beleid, procedures en systeemcomponenten. Het nadeel is dat het relatief veel tijd in beslag neemt en kostbaar is. De pre‐audit draagt bij aan het voorkomen van tekortkomingen die pas tijdens de certificering worden opgemerkt, met name binnen een grote en complexe betaal‐omgeving. Deze pre‐audit kan ook in latere fasen nog ingezet worden om een goed inzicht te krijgen in de kans op succes bij de formele audit en een goed inzicht in de openstaande gaps. Het uitvoeren van een pre‐audit, door personen vanuit de eigen organisatie (bijvoorbeeld internal audit) heeft als bijkomend voordeel dat zij inzicht krijgen in de audit vereisten, maar biedt minder zekerheid over de uitkomsten. Er kan met behulp van een QSA ook een pre‐audit worden uitgevoerd, dit is vanuit een kostenoverweging minder voordelig. Wel is het zo dat hierdoor een redelijke zekerheid is dat de maatregelen ‘audit proof’ zijn als ze akkoord worden bevonden.

9 Systeemcomponenten zijn volgens PCI‐DSS “alle netwerkcomponenten, servers en toepassingen die tot de omgeving met de kaarthoudergegevens behoren of hierop zijn aangesloten”.


Pagina 22 van 43

Het voordeel van een beperkte gap analyse (middels het raadplegen van documentatie van beleid, procedures en systeemcomponenten) is dat men snel in redelijk detail inzicht krijgt in tekortkomin‐gen. Nadeel is dat het geen zekerheid verschaft over de actuele situatie, dit hoeft echter bij minder grote en complexe omgevingen niet te leiden tot grote verassingen (omdat beter ingeschat kan wor‐den in hoeverre de documentatie de actuele situatie weerspiegelt). Een organisatie kan er voor kiezen om een quick‐scan te doen op basis van de beschreven maatrege‐len in het eigen control framework (waarin voor de organisatie relevante eisen en geïmplementeerde maatregelen zijn opgenomen). Dit levert met een beperkte inspanning een redelijke indicatie van de tekortkomingen op, maar geen zekerheid over specifieke actuele maatregelen in systeemcomponen‐ten. In weinig complexe omgevingen kan dit bijdragen aan een korte doorlooptijd naar certificering. Het levert bovendien inzicht op in de relatie tot het gewenste niveau van informatiebeveiliging dat de organisatie zelf heeft. De diepgang van de gap analyse is door de respondenten op verschillende wijzen opgepakt. Er is een redelijk gelijke verdeling over de drie genoemde alternatieven. In de praktijk zien we geen directe relatie tussen de grootte en complexiteit van de omgeving en de gekozen diepgang van de gap analy‐se. Interessant is dat alle organisaties (intern beleid op basis van) ISO 27001 noemen als framework waartegen de eisen van PCI‐DSS tegen zijn afgezet. De gap analyse die is uitgevoerd als gevolg van wijzigingen in de standaard verschilt tussen de respondenten. De ene partij voert een gap analyse uit op de eigen situatie ten aanzien van de nieuwe versie van de standaard terwijl de andere partij wacht op de eerstvolgende audit om op die manier de gaps te vernemen en te gaan verhelpen (soms met behulp van een QSA). Argument voor respondenten voor het inschakelen van de QSA is dat hierdoor meteen door een onafhankelijke deskundige partij werd gekeken naar de tekortkomingen vanuit een audit perspectief. Wij raden aan om bij grote en complexe omgevingen gebruik te maken van een daadwerkelijke pre‐audit. Met een pre‐audit voorkomt men dat oplossingen niet aan de eisen voldoen. Ook kunnen in een vroeg stadium gaps opgespoord worden die met prioriteit kunnen worden verholpen zodat de kans op boetes en fraude afneemt. Voor de minder grote en complexe omgevingen volstaat wat ons betreft een gap analyse of quick‐scan aangezien daar het risico op grote tekortkomingen die men niet inzichtelijk krijgt/heeft veel lager is (voorwaarde is wel dat de documentatie en het eventuele framework waartegen men PCI‐DSS afzet de actuele maatregelen weergeven). Stand‐alone of geïntegreerde impact analyse De keuze tussen stand‐alone of geïntegreerd uitvoeren van de impact analyse is van invloed op de snelheid waarmee de impact analyse kan worden uitgevoerd en de mogelijkheden die kunnen wor‐den geïdentificeerd om aan te sluiten op reeds lopende of te starten projecten (bijvoorbeeld vervan‐ging van een applicatie omdat deze encryptie niet ondersteunt, maar die vanuit de normale life‐cycle ook al bijna aan vervanging toe was). Als op basis van de analyse duidelijk is wat de tekortkomingen zijn van de huidige getroffen maatregelen kan men de impact bepalen die het wegwerken van de tekortkomingen met zich mee brengt. De impact is afhankelijk van het niveau van reeds geïmple‐menteerde maatregelen bij de organisatie, de mate waarin dit gedocumenteerd is en van de vraag of de maatregelen voldoende dekkend zijn ten opzichte van de PCI‐DSS eisen. Er zijn in de praktijk ech‐ter maar weinig organisaties die zonder enige te verhelpen tekortkomingen meteen compliant zijn. Ter indicatie, veel PCI projecten duren gemiddeld tussen de 12 en 18 maanden (ITCI, 2007; Schwartz, 2007). De kosten worden geraamd tussen $ 2 miljoen ‐ $ 10 miljoen verspreid over 2 jaar (Thompson, 2007).


Pagina 23 van 43

2.5. Planvorming De haalbaarheid van de invoering, en daarmee ook van de certificering, wordt voor een belangrijk deel bepaald tijdens de planvorming. Door de eigenschap dat PCI‐DSS zich specifiek richt op kaart‐houdergegevens kan gericht te werk worden gegaan om de activiteiten zo te focussen dat die activi‐teiten worden ondernomen die direct bijdragen aan enerzijds certificering en anderzijds de aanslui‐ting op reeds gemaakte keuzes in het kader van de organisatiestrategie. Tijdens deze fase komt het management van de organisatie voor de volgende keuzes te staan: • Wel of geen scopebeperking toepassen; • Control based of Risk based; • Wel of niet standaardiseren van systemen en processen; • Wel of niet continuous monitoring invoeren; • Wijze van projectopzet. Wel of geen scopebeperking toepassen Scopebeperking verlaagt het risico dat tijdens een security breach kaarthoudergegevens worden ontvreemd en daarmee de kans op fraude. Het verlaagt tevens de impact in termen van activiteiten die moeten worden uitgevoerd om PCI‐DSS gecertificeerd te worden (en te blijven), met name omdat het aantal systeemcomponenten in scope voor PCI‐DSS wordt verkleind. Hieronder enkele maatrege‐len om de scope beperken: • Niet (meer) opslaan van PAN gegevens: Kaartgegevens worden alleen geslagen indien dat een

valide business reden heeft (Adler & Swanson, 2007: 2). Een voorbeeld is dat veel credit card ge‐gevens onnodig worden gebruikt in bijvoorbeeld CRM‐achtige omgevingen of als primaire sleutel in databases.

• Gedeeltelijk maskeren van PAN gegevens: Vaak is het niet nodig om het gehele PAN nummer te gebruiken, de persoonlijke gegevens van de kaarthouder i.c.m. een gedeeltelijk afgeschermde PAN is al voldoende (IT Compliance Institute, 2007).

• Netwerksegmentatie: Een beproefde methode voor scopebeperking is door netwerksegmentatie toe te passen (afscheiden van het netwerk en de servers die kaartgegevens bevatten van de rest van het netwerk). Dit heeft de nodige impact op het ontwerp van het netwerk, maar levert later veel voordeel op doordat het aantal systeemcomponenten dat moet voldoen aan PCI‐DSS gere‐duceerd wordt.

• Outsourcing: Door het outsourcen van (delen van) de systemen en processen waarin kaarthou‐dergegevens worden behandeld kan de hoeveelheid werk die nodig is om compliant te worden voor de organisatie zelf verminderen. Of het ook tot lagere kosten leidt is afhankelijk van de vraag of de service provider reeds over PCI‐DSS compliant systemen en processen beschikt waar gebruik van gemaakt kan worden. Outsourcing levert geen vrijwaring van de aansprakelijkheid op.

De keuze om geen scope beperkende maatregelen te plannen is te overwegen als de voordelen niet opwegen tegen de investeringen van de scope beperkende maatregelen. Twee organisaties gaven aan actief de scope te beperken door te kijken naar mogelijkheden van netwerksegmentatie, vermijden van opslag van kaarthoudergegevens en het gedeeltelijk maskeren van de PAN. Wij raden aan om de mogelijkheden van scopebeperking te onderzoeken, om op die manier bewust te kiezen om de impact van de (her)certificering te beperken en om de kans op frau‐de te beperken in geval van een security breach. Control based of Risk based De toename van het beveiligingsniveau kan eerder worden bereikt wanneer de gaps met de hoogste risico’s als eerste worden opgelost. Qua volgorde van implementeren van maatregelen geeft PCI‐DSS daarentegen een handreiking die uitgaat van een fasering op basis van implementatie van controls


Pagina 24 van 43

die niet specifiek recht doet aan de risico’s die de organisatie loopt. Voor gaps moet de organisatie een duidelijk plan opstellen dat beschrijft hoe compliance zal worden bereikt. Dit plan wordt door de QSA en/of de acquirer van de organisatie gemonitored (Drew & Nair, 2008). Voor het bepalen van de prioriteiten van het oplossen van de gaps bestaat een tweetal mogelijke invalshoeken: • Control based aanpak: Hier kan gebruik gemaakt worden van de PCI‐DSS Prioritized Approach

van het PCI SSC (PCI SSC, 2009). Op basis van een zestal door PCI SSC gedefinieerde milestones is een volgorde aangegeven van welke eisen voor welke milestone op orde moet zijn.

• Risk based aanpak: Prioriteiten worden bepaald op basis van één van de volgende criteria (af‐hankelijk van waar voor de organisatie de grootste risico’s in zijn gelegen): • Systemen/processen met de grootste aantallen kaarthoudergegevens; • Systemen/processen met de meeste gaps en/of kwetsbaarheden (Drew & Nair, 2008); • Classificering van gaps uit een impact analyse/pre‐audit (bijvoorbeeld het onderscheid tussen

door de QSA aangemerkte ‘red alerts’, ‘warnings’ en ‘informationals’) Naast de prioriteiten kan voor de volgorde van implementatie ook worden gekeken naar logische momenten voor implementatie o.b.v. bijv. nieuwe releases van systemen. Twee partijen hebben een risico‐analyse uitgevoerd t.b.v. prioriteitstelling. Eén partij heeft op basis van de risico’s gekozen om op korte termijn alleen de hoge risico’s af te dekken. Bij een andere respondent was sprake van een groot upgrade programma, waarbij compliant zijn aan PCI‐DSS en nodige vervanging van legacy ge‐zamenlijk de business‐case positief maakten. De risk based aanpak draagt bij aan het verkleinen van de kans op security breaches tijdens de im‐plementatiefase. De control based aanpak doet dat ook, alleen is daar de risico inschatting door het PCI SSC gemaakt o.b.v. ervaringen en eigen afwegingen en niet o.b.v. de specifieke risico’s van de organisatie zelf. Gezien de invloed op het beveiligingsniveau heeft de risk based aanpak onze voor‐keur. Wel of niet standaardiseren van systemen en processen Niet zozeer voor de certificering op korte termijn als wel voor het onderhouden van de certificering is de keuze om wel of niet standaardisatie toe te passen van invloed op het compliant blijven aan de standaard. Minder diversiteit in processen en systemen houdt in dat aanpassingen als gevolg van wijzigingen in de standaard makkelijker zijn door te voeren. Ook is de kans dat een uitzondering aan de aandacht ontsnapt kleiner en daarmee ook de kans op nieuwe gaps. Met betrekking tot de systeemcomponenten mag er gebruik worden gemaakt van een steekproef o.b.v. een representatieve set waarbij ten minste alle type combinaties worden getest (bijvoorbeeld bij meerdere webservers zowel een Unix‐Apache als een HP‐MS‐IIS combinatie testen) (PCI SSC, 2008; ITCI, 2007; Drew & Nair, 2008). Voor de onderhoudbaarheid van de maatregelen raden wij aan om te kiezen voor gestandaardiseerde processen, oplossingen en configuraties, mits hiervoor een positieve business‐case bestaat (investeringen in standaardisatie worden terugverdiend met o.a. verlaging van auditkosten en kosten voor beheer en onderhoud). Wel of niet continuous monitoring invoeren De keuze voor wel of niet invoeren van continuous monitoring is van invloed op de toename van het beveiligingsniveau en op de kans op boetes en aansprakelijkstelling. Hoewel een PCI‐DSS audit een momentopname is, telt voor de vraag of wel of geen boete of aansprakelijkstelling wordt uitgevaar‐digd zwaar of op het moment van een security breach aan de eisen werd voldaan (door de organisa‐tie aan te tonen) zwaarder dan de certificering. Met het oog op continuous monitoring kan men de keuze maken om het testen van de maatregelen voor PCI‐DSS op te nemen in een integraal pro‐gramma waarbij regelmatig de werking van de maatregelen worden getest vanuit de eisen vanuit PCI‐DSS en andere frameworks (bijvoorbeeld ISO 27001 en eisen vanuit klanten i.v.m. SAS 70 voor service providers). Dit levert wat ons betreft de meeste zekerheid over de continue werking van de


Pagina 25 van 43

maatregelen voor de eigen organisatie door het jaar heen. Het voorkomt tevens verrassingen tijdens (her)certificering. Stand‐alone of geïntegreerde projectopzet De keuze voor de opzet van het project is van invloed op de snelheid waarmee een certificering kan worden bereikt en op de mate waarin kan worden aangesloten op de reeds gemaakte keuzes en lopende projecten in het kader van de organisatiestrategie. In dit geval kan het een keuze tussen de twee genoemde belangen zijn, aangezien de keuze voor snelheid veelal ten koste gaat van de moge‐lijkheden om aan te sluiten op lopende activiteiten. Afhankelijk van de keuze van het moment van invoering van en compliance aan de standaard (zie ook paragraaf 2.2), de tijd die men voor de im‐plementatie heeft en de beschikbare resources en kennis kan men kiezen voor: • Een stand‐alone invoering waarbij alle activiteiten binnen een op zichzelf staand PCI‐DSS pro‐gramma worden ingevoerd, zonder aan te sluiten op andere projecten waarmee raakvlakken be‐staan. Dit heeft als voordeel dat de focus binnen het project geheel op de invoering van PCI‐DSS is gericht en niet veel tijd besteed wordt aan afstemming;

• Een geïntegreerde invoering waarbij de verschillende eisen volledig zijn belegd bij de staande or‐ganisatie en applicatieaanpassingen volledig zijn geïntegreerd in het normale change proces. Daarbij is alleen een centrale regie van het PCI‐DSS programma nodig. Dit kan leiden tot een lan‐gere doorlooptijd tot aan certificering maar biedt wel betere aansluiting op de bestaande mecha‐nismen en strategie van de organisatie.

De keuze tussen bovenstaande is een kwestie van het afwegen van het zwaarste belang voor de or‐ganisatie: snelle certificering (zie ook paragraaf 2.2 over het moment van invoering en voldoen) of aansluiting op de organisatiestrategie (zie ook paragraaf 2.2 over alignment van keuzes). Bij de keuze voor de opzet van het project is een overweging of gewerkt wordt in een centraal, de‐centraal of hub‐and‐spoke (centraal deel gecombineerd met decentrale onderdelen) model voor de projectorganisatie. Systemen en processen die verspreid zijn over de organisatie leidt tot verspreide verantwoordelijkheden voor de naleving van de PCI‐DSS eisen. Er moet bewaakt worden dat de di‐verse organisatieonderdelen samen de volledige scope (qua eisen en processen/systemen) afdekken (Zoellick & Frank, 2005). Daarom verdient naar onze mening het hub‐and‐spoke model in veel geval‐len aanbeveling omdat dit de verantwoordelijkheden zo dicht mogelijk bij het object belegt, maar wel centraal het overzicht en de bewaking borgt.

2.6. Implementatie en inbedding Het managen van de verwachtingen van de implementatie en het goed inbedden van de activiteiten die benodigd zijn voor het voldoen aan de eisen van PCI‐DSS zijn van invloed op het behalen van de certificering en de toename van het beveiligingsniveau. Tijdens deze fase komt het management van de organisatie voor de volgende keuzes te staan: • Wel of geen afstemming zoeken met externe partijen tijdens de implementatie; • De verantwoordelijkheid voor het verzamelen van bewijs (centraal vs. uitvoering). Wel of geen afstemming zoeken met externe partijen tijdens de implementatie Tijdens de implementatie kan men kiezen om nauw samen te werken met de QSA en/of de partij die PCI‐DSS compliance vereist. Het voordeel hiervan is dat het goodwill kweekt en dat men ook eventu‐ele oplossingen kan voorleggen en kan laten accorderen voordat men tot implementatie overgaat. Hetzelfde geldt m.b.t. het rapporteren over de voortgang: het tijdig en correct informeren geeft de externe partijen meer vertrouwen, vooral als de implementatie een langere doorlooptijd heeft. Hier‐bij kan men ook afspraken maken over eventuele verantwoordelijkheid in geval van breaches tijdens de implementatie (i.c.m. tijdelijke compenserende maatregelen voor de hoge risico’s). De meeste respondenten geven aan dat de mogelijkheden om compenserende maatregelen te gebruiken zeer


Pagina 26 van 43

beperkt zijn. Dit heeft te maken met de procedure die daarvoor in het leven is geroepen en de eisen die daaraan worden gesteld (de compenserende maatregelen moeten tenminste hetzelfde niveau van informatiebeveiliging waarborgen en moeten uitvoerig worden gedocumenteerd en worden beoordeeld door de QSA), met name sinds de invoering van versie 1.2 van PCI‐DSS. Ten aanzien van inhoudelijke aspecten van de invoering (gekozen oplossingen, compenserende maatregelen, e.d.) wordt vooral met de QSA onderhandeld, die waar nodig weer met de credit card maatschappijen in overleg treedt. Wij raden aan om nauw samen te werken met de QSA’s en de partij die compliance vereist om op die manier de verwachtingen over en weer helder te hebben en zodoende snel tot certificering te kunnen komen. De verantwoordelijkheid voor het verzamelen van bewijs Verzamelen van bewijs kan een tijdrovende bezigheid zijn tijdens een audit. Aangezien de audit jaar‐lijks wordt gehouden en PCI‐DSS audits voor een groot gedeelte steunen op documentatie als bewijs‐last is de keuze voor het beleggen van het verzamelen van de bewijslast van invloed op een vlotte certificering. Men kan kiezen om de verantwoordelijkheid voor het verzamelen van bewijs ten be‐hoeve van audits te beleggen bij: • Een centrale functie zoals een interne audit of compliance afdeling; • Personen in de lijn die verantwoordelijk zijn voor onderhoud van systeemcomponenten (configu‐

ratie van firewalls, verlenen van logische toegang etc.) en de uitvoerende processen. Het voordeel van het eerste alternatief is dat er centraal inzicht is in de uitvoering van de maatrege‐len. De aanwezigheid van het juiste bewijsmateriaal en de borging van de kwaliteit ervan is gewaar‐borgd doordat interne audit of compliance functies bekend zijn met audit procedures. Nadeel is dat het veel tijd kost en vaak achteraf verzameld moet worden. Voordeel van het tweede alternatief is dat de verzameling van het bewijs dicht bij de operatie plaatsvindt, bij de personen die verantwoor‐delijk zijn voor de naleving van de eisen uit PCI‐DSS. De verantwoordelijkheid voor het verzamelen van de bewijslast kan bijdragen aan het strikt naleven van maatregelen. Personen in de operatie hebben echter vaak minder affiniteit met de auditvereisten. Wij raden een combinatie aan waarbij de centrale functie audit of compliance functie toeziet op de kwaliteit en het vastleggen van bewijs (voordeel is onafhankelijkheid van de procesuitvoering, quality assurance en centrale regie) en de personen in de lijn verantwoordelijk zijn voor de uitvoering (ver‐deling van ‘audit burden’ en bewijs wordt direct bij tijdens de operatie vastgelegd). Belangrijk is ook de aandacht voor change management. Bij alle wijzigingen die een implicatie kunnen hebben op de huidige systeemcomponenten of leiden tot een uitbreiding van de PCI‐DSS scope moet goed worden getest of de wijziging ‘audit proof’ is. Tevens moeten wijzigingen goed worden gedocumenteerd.

2.7. Certificering en rapportage Het communiceren met de credit card maatschappijen over onverhoopte security breaches kan de kans op een boete en aansprakelijkstelling verlagen. De wijze waarop met de buitenwereld wordt gecommuniceerd over PCI‐DSS certificering is van invloed op de aansluiting op de organisatiestrate‐gie. Certificering kan voor marketingdoeleinden worden gebruikt als kwaliteitsstempel. Compliance eisen PCI‐DSS maakt onderscheid in het type organisatie en de wijze waarop PCI‐DSS moet worden aange‐toond. Hiervoor zijn verschillende levels gedefinieerd, waarbij ook verschillende eisen10 gelden m.b.t. het aantonen van PCI compliance (ITCI, 2007). Voor level 1 geldt een jaarlijkse on‐site audit door een QSA, voor de andere levels een jaarlijkse self‐assessment met een Self‐Assesment Questionnaire (SAQ). Voor alle levels geldt per kwartaal een netwerk security scan door een ASV (Approved Scan‐ning Vendor) (PCI SSC, 2008). De organisatie moet voorafgaand aan de audit de audit vereisten

10 Zie ‘Bijlage 1 ‐ Compliance eisen’


Pagina 27 van 43

scherp hebben en deze afstemmen met de partij (acquirer of credit card maatschappij) die uiteinde‐lijk PCI‐DSS certificering eist, omdat de credit card maatschappijen ieder nog hun eigen compliance programma hebben. Scoping De audit begint met het vaststellen van het doel van de audit. Vervolgens worden de scope en de systeemcomponenten die tijdens de audit worden getest bepaald. De scope van de audit kan worden vastgesteld o.b.v. de compliance eisen en de bepaalde scope tijdens de voorgaande fasen. Uitvoering van de audit Na de scoping wordt o.b.v. een planning het audit programma door de QSA uitgevoerd. Hiervoor zijn de PCI‐DSS Security Audit Procedures beschikbaar. Om een indicatie te krijgen in de bewijslast van PCI‐DSS hebben we een analyse gemaakt van alle eisen. Deze analyse laat zien dat voor de bewijslast zwaar gesteund wordt op documentatie. Het is voor de uitvoering van de audit van belang dat de juiste documentatie beschikbaar is. Tijdens de audit moeten de juiste personen beschikbaar zijn voor de QSA in geval van vragen/interviews. Zorgdragen voor beschikbaarheid van informatie (via docu‐mentatie en beantwoording van vragen) draagt bij aan een vlotte PCI‐DSS certificering van de organi‐satie. Remediation en rapportage Indien er tijdens de audit tekortkomingen zijn geconstateerd is er een remediation (herstel) periode waarin de auditee de gelegenheid krijgt om de tekortkomingen te verhelpen. Hierna worden de re‐sultaten via een RoC (Report on Compliance11) vastgelegd. De RoC bevat tenminste contactinforma‐tie en rapportage datum, een management samenvatting, beschrijving van de onderzoeksaanpak en scope, de resultaten van de scans per kwartaal12 en de bevindingen en waarnemingen van de audit. De RoC wordt daarna door de QSA aan de credit card maatschappij (of andere partij die PCI‐DSS cer‐tificering vereist) verstuurd die uiteindelijk de aanbeveling over kan nemen en de organisatie certifi‐ceert (PCI SSC, 2008). Ondanks het feit dat PCI‐DSS steeds meer een geaccepteerde standaard is en wordt neergezet als een baseline voor security, zijn er veel organisaties die toch een PCI‐DSS audit niet goed doorlopen. Volgens onderzoek13 van VeriSign (2007) was maar 25% in staat om in een keer succesvol de audit te doorlopen, terwijl de meeste auditees al robuuste beveiligings‐programma’s hadden lopen. Succes‐vol waren vooral Level 2 of kleinere Level 1 service providers. Deze beschikken over het algemeen over kleinere en minder complexe omgevingen. In 79% van de audits was er sprake van non‐compliance omdat kaarthouder gegevens onversleuteld in spreadsheets waren opgeslagen of in on‐beveiligde fysieke apparaten op het bedrijfsnetwerk. 74% slaagt er ook niet in om regelmatig de pro‐cessen en beveiligingssystemen te testen. Bij de meeste organisaties (66%) was er sprake van non‐compliance ten aanzien van meerdere eisen tegelijk. Veel genoemde oplossingen zijn goede segmen‐tatie van netwerken (scope verkleinen), toepassen van encryptie, goed inzicht in de data‐flow (weet waar de gegevens worden opgeslagen) en alleen opslaan van gegevens als dit absoluut noodzakelijk is (Meadowcroft, 2008) (zie ook paragraaf 2.5). De organisaties die een audit moeten doorlopen kun‐nen veel van de bekende en veel voorkomende non‐compliance bevindingen leren. Alle respondenten die reeds een verplichting gecommuniceerd hebben om te voldoen aan PCI‐DSS worden geaudit door een QSA. Dit vindt plaats op basis van onderzoeken door de QSA, intrusion testing op netwerk en website en self‐assessment. Opvallend is dat één respondent aangeeft dat zij wekelijkse intrusion testing laten doen door een extern beveiligingsbedrijf (die geen ApprovedScan‐ 11 Zie ‘Bijlage 3: Report on Compliance eisen’ 12 In geval van hercertificering. 13 Onderzoek o.b.v. 112 audits. Zie ‘Bijlage 2 ‐ Non‐compliance op PCI‐DSS eisen’


Pagina 28 van 43

ning Vendor status heeft), maar dat de QSA hier niet op wil steunen. De QSA vereist dat naast de door het beveiligingsbedrijf uitgevoerde intrusion scans nog steeds eenmaal per kwartaal door een ASV wordt uitgevoerd. Hoewel te verklaren op basis van de ASV status die als eis wordt gesteld, er‐vaart de respondent het als bureaucratisch. Andere partijen (externe accountant, DNB) zijn in voor‐komende gevallen wel bereid te steunen op een PCI‐DSS certificering. Een deel van de respondenten geeft aan dat de eisen van PCI‐DSS opgenomen zijn in de audit plan‐nen van de interne audit dienst. In één geval wordt de interne audit dienst ingeschakeld om kritisch mee te kijken naar de verdeling van de verantwoordelijkheden voor het voldoen aan de eisen binnen de organisatie en of daarbij geen blinde vlekken ontstaan. Tijdens deze fase komt het management van de organisatie voor de volgende keuzes te staan: • Wel of niet rapporteren van security breaches naar alle belanghebbenden; • Wel of niet actief naar buiten communiceren van de certificering. Wel of niet rapporteren van security breaches naar alle belanghebbenden Tijdens de audit en de herstel periode is het van belang om alle betrokken partijen goed op de hoog‐te te houden. Het tijdig rapporteren van security breaches kan leiden tot lagere boetes en tot ver‐minderde aansprakelijkstelling. Wij raden aan om tijdig over security breaches te communiceren met de juiste belanghebbenden, waarbij wel van belang is dat men meteen onderzoek instelt naar de oorzaak van de problemen. Wel of niet actief naar buiten communiceren van de certificering Nadat de organisatie de certificering heeft behaald kan men ervoor kiezen om dit actief in te zetten als marketing instrument als dit past binnen de organisatiestrategie. In het geval van een service provider zien wij het voordeel hiervan in (het is immers een license‐to‐operate), voor een merchant is het minder relevant. Aan het actief communiceren over de certificering kleeft ook het risico dat dit voor hackers juist een aanleiding vormt om een poging te ondernemen de beveiliging te doorbreken.


Pagina 29 van 43

3. Vaststellen van het succes van de invoering In de voorgaande onderdelen is ingegaan op de kenmerken van PCI‐DSS zelf en hebben we voor de verschillende invoeringsfasen in kaart gebracht welke keuzes en overwegingen kunnen bijdragen aan een succesvolle invoering van PCI‐DSS. In dit hoofdstuk zullen we op basis van de analyse in hoofd‐stuk 2 proberen vast te stellen welke strategieën voor een succesvolle invoering van PCI‐DSS zijn te onderscheiden. Op basis van de bestudeerde theorie, de uitkomsten van de interviews en onze eigen analyse zijn we tot onderstaand overzicht gekomen. Het overzicht geeft het geheel aan keuzes tijdens de invoerings‐fasen weer met daarbij in de meeste gevallen een voorkeur voor alternatieven. Tevens geven we aan aan welke criteria voor succesvolle invoering ze bijdragen.

Criterium Keuze14 Alternatieven & voorkeur 1. 2. 3. 4. 5.

• Wel of niet actief monitoren van ontwikkelingen (1) • Wel / niet + + + + +

• Wel of niet voldoen aan de standaard (2) • Wel / niet (afhankelijk van keuze voor credit cards voeren)

+

• Alignment met andere initiatieven/strategie (2) • Wel / niet afstemmen +

• Moment van invoering van en voldoen aan de stan‐daard (2)

• Proactief, tijdig of reactief

+ + + +

• Wel / niet (m.b.t. deadline)

+ + + • Wel of niet proberen invloed uit te oefenen (2)

• Wel / niet (m.b.t. inhoud)

• Intern opbouwen van de benodigde kennis of naar behoefte extern inhuren (3)

• Intern opbouwen / externe inhuur (af‐hankelijke grootte, complexiteit en ken‐nisniveau, combinatie extern halen intern borgen)

+ +

• Ambitieniveau bij de vertaling van eisen naar de eigen organisatie (3)

• Baseline / risicoanaly‐se (afhankelijk snelle certificering en/of strategie)

+ + +

• Diepgang van de gap analyse (4) • Pre‐audit, gap‐analyse of quick‐scan (afhan‐kelijke grootte en complexiteit)

+ + +

• Stand‐alone of geïntegreerde impact analyse (4) • Stand alone / geïnte‐greerd

+

• Wel of geen scope beperking toepassen (5) • Wel / geen + + +

• Control based of Risk based (5) • Control based / Risk based

+ + +

• Wel of geen standaardisering van systemen en pro‐cessen (5)

• Wel / geen (afhanke‐lijk van investeringen vs. ‘audit burden’)

+

• Wel of geen continuous monitoring invoeren (5) • Wel / geen + + + +

14 De cijfers achter de keuzes refereren aan de verschillende fasen van invoering (zie figuur 3 in hoofdstuk 2).


Pagina 30 van 43

Criterium Keuze14 Alternatieven & voorkeur 1. 2. 3. 4. 5.

• Stand‐alone of geïntegreerde projectopzet (5) • Stand‐alone / geïnte‐greerd (afhankelijk van belang snelle cer‐tificering of strategic alignment)

+ +

• Wel of geen afstemming zoeken met externe partij‐en tijdens de implementatie (6)

• Wel / geen + + +

• De verantwoordelijkheid voor het verzamelen van bewijs (6)

• Centraal / uitvoering (voorkeur is een com‐binatie)

+

• Kiezen voor het actief naar buiten brengen van de certificering (7)

• Wel / niet (afhankelijk van marketing strate‐gie. Misschien voor‐deel voor service pro‐vider)

+ +

• Wel of niet rapporteren van security breaches naar alle belanghebbenden (7)

• Wel / niet + +

Tabel 4 ‐ Succescriteria vs. keuzes Als we naar het bovenstaande overzicht kijken dan kan de combinatie van keuzes waar we een voor‐keur hebben aangegeven voor een alternatief worden beschouwd als een mogelijke strategie voor succesvolle invoering. Deze mogelijke strategie is echter nog niet in de context van een organisatie geplaatst. De specifieke omstandigheden en eigenschappen van een organisatie kunnen aanleiding zijn om voor andere alternatieven te kiezen, zowel ten aanzien van de keuzes waar wij geen voorkeur hebben gegeven als voor de keuzes waar we wel een voorkeur hebben uitgesproken. Op basis van kenmerken van organisaties die moeten voldoen aan PCI‐DSS (merchants/service pro‐vider/acquier/issuer, groot/klein) valt een link te leggen met de PCI‐DSS levels15 voor organisaties. Er zijn namelijk verschillende levels voor merchants (gebaseerd op ingeschatte risico’s voor het type transacties, de mate waarin het betaalsysteem wordt blootgesteld aan gevaren en het transactie volume). Voor andere organisaties geldt dit onderscheid in levels niet. Aanhaken bij deze levels biedt een aanknopingspunt om meer specifiek te komen tot enkele mogelijke strategieën voor succesvolle invoering van PCI‐DSS. In het licht van een aantal kenmerkende verschillen tussen met name de level 1 en level 4 organisa‐ties werken we een tweetal strategieën uit die zijn toegespitst op de specifieke situatie. We hebben bewust voor de beide uitersten gekozen om onderscheidende strategieën vast te kunnen stellen. Daarvoor is het nodig om een aantal aannames te doen over de omstandigheden en eigenschappen van deze twee typen organisaties. Level 1 organisatie: grote merchant16 met transport, verwerking en opslag van grote aantallen kaart‐gegevens in een complexe betaalomgeving die is verspreid over verschillende locaties (dus mogelijk grote risico’s). Credit card betalingen vormen een groot aandeel in de business. Er zijn een aantal centrale staf functies (audit, compliance), en er is veel security kennis aanwezig. De (PCI‐DSS) certifi‐cering is voor de organisatie vanuit verschillende invalshoeken van belang, onder andere vanuit toe‐nemend commercieel belang. Het niveau van beveiliging is al goed, ze hebben een eigen control fra‐mework (bijvoorbeeld op basis van ISO27001) geïmplementeerd. Er staan de komende jaren een

15 Zie ‘Bijlage 1 ‐ Compliance eisen’. 16 Deze typering zou ook van toepassing kunnen zijn op een service provider.


Pagina 31 van 43

aantal grote applicatie en technologische vervangingen in de planning die ook invloed hebben op de betaalomgeving. De omgeving is aan verandering onderhevig. Voor dit type organisatie is de meeste toegevoegde waarde te halen uit de goede integratie met de organisatiestrategie en het verhogen van het niveau van beveiliging. Level 4 organisatie: kleine merchant met maar beperkte aantallen credit card transacties die voor‐namelijk worden getransporteerd en maar beperkt worden opgeslagen in de eigen systemen. Stop‐pen met acceptatie van credit cards als betaalmiddel is geen reële mogelijkheid. Er is een beperkte staf aanwezig, er is afgezien van de specifieke kennis van de systemen weinig security kennis. Com‐pliant zijn is voornamelijk van belang omdat het een eis is van de acquirer. Er staan geen ingrijpende initiatieven op de planning die invloed hebben op de betaalomgeving, die ook redelijk stabiel is. Voor dit type organisatie is de meeste toegevoegde waarde te halen uit het certificeren ten aanzien van PCI‐DSS en het voorkomen van boetes en aansprakelijkstelling. Hieronder de voorgestelde strategie voor een succesvolle invoering voor de beschreven typen orga‐nisaties, waarbij de gekozen alternatieven voor elke keuze tegemoet komen aan de relevante om‐standigheden en eigenschappen:




certificering’ • Actief monitoren van ontwikkelingen (wil

zo vroeg mogelijk op de hoogte zijn voor strategische afstemming)

• Voldoen aan de standaard • Veel aandacht voor alignment met ande‐

re initiatieven en strategie • Invloed proberen uit te oefenen op de

deadline • Intern opbouwen van kennis, wel inscha‐

kelen QSA • Vertalen van eisen vanuit een risico‐

analyse • Gaps bepalen a.d.h.v. een pre‐audit • Geïntegreerde impact analyse uitvoeren • Scope beperking toepassen • Risk based prioriteitstelling • Standaardisering van systemen en pro‐

cessen • Geïntegreerde projectopzet • Afstemming tijdens implementatie • Bewijs verzamelen centraal monitoren, in

de uitvoering vastleggen • Actief naar buiten brengen van de certifi‐

cering • Security breaches rapporteren

• Niet actief monitoren van ontwikkelingen (wordt door de acquirer op de hoogte ge‐steld)

• Voldoen aan de standaard • Geen alignment nodig

• Invloed proberen uit te oefenen op de

deadline • Extern inhuren van kennis

• Vertalen van eisen vanuit de baseline

• Gaps bepalen a.d.h.v. een quick‐scan • Stand‐alone impact analyse uitvoeren • Scope beperkingen toepassen • Control based prioriteitstelling • Geen standaardisering van systemen en

processen • Stand‐alone projectopzet • Afstemming tijdens implementatie • Bewijs verzamelen en monitoren in één

functie • Niet actief naar buiten brengen van de

certificering • Security breaches rapporteren

Tabel 5 ‐ Voorkeurstrategieën voor twee typen organisaties Iedere organisatie zal voor zichzelf een strategie moeten bepalen die recht doet aan de specifieke omstandigheden en eigenschappen. Hiervoor kan gebruik gemaakt worden van één van bovenge‐noemde strategieën, maar zullen de alternatieven moeten worden afgewogen op basis van de speci‐


Pagina 32 van 43

fieke situatie. Om te bepalen of de door de organisatie gemaakte keuzes uiteindelijk hebben bijge‐dragen aan een succesvolle invoering van PCI‐DSS kan de organisatie voor zichzelf vaststellen of aan de criteria voor succesvolle invoering is voldaan. In onderstaande tabel hebben wij per criterium aangegeven hoe dit kan worden vastgesteld: Nr. Criterium Wijze van vaststellen 1. Op basis van de genomen acties is er

geen reden voor een boete vanuit de credit card maatschappij(en)

Dit is vast te stellen door bij de juridische of financiële afdeling na te gaan of er boetes zijn ontvangen of melding is gemaakt van non‐compliance issues door de credit card maatschappij die tot een boete kunnen leiden17.

2. In geval van fraude is er op basis van de genomen acties geen reden voor een verschuiving van de aansprakelijk‐heid van de credit card maatschap‐pij(en) naar de merchant/service pro‐vider

Dit is in het geval fraude heeft plaatsgevonden vast te stellen op basis van het al dan niet aansprakelijk gesteld zijn voor geleden schade door de credit card maatschap‐pij. Als zich geen fraude heeft voorgedaan kan een mer‐chant of service provider de voorgestelde maatregelen laten voorleggen aan de credit card maatschappij en deze laten goedkeuren. Door de formele acceptatie neemt de acquirer de verantwoordelijkheid voor het rest risico. Echter ondanks dat men een certificering heeft moet men wel aantonen op het moment van de breach compliant te zijn geweest.

3. De invoering leidt tot een certificering middels een Report on Compliance, al dan niet op basis van een officiële audit (afhankelijk van het level van de organisatie) naar de credit card maat‐schappij(en)

a. Dit is voor level 2, 3 en 4 merchants aantoonbaar als zij middels een geaccepteerde SAQ als compliant wor‐den geaccepteerd door de acquirer, SP of credit card maatschappij;

b. Voor de level 1 merchant is dit aantoonbaar als na het doorlopen van on‐site audit geen bevindingen meer zijn en de aanbeveling van de QSA in de RoC wordt ge‐accepteerd door de acquirer, SP of credit card maat‐schappij;

c. Daarnaast bestaat voor beide partijen de verplichting om de resultaten van de kwartaal netwerk scans te overleggen.

4. De beveiliging met betrekking tot op‐slag en transport van kaarthouderge‐gevens wordt verhoogd tot het door de organisatie gewenste niveau (als dit voor de invoering van PCI‐DSS nog niet het geval was).

Op basis van het door de organisatie vastgestelde beveili‐gingsbeleid en het control framework kan worden vastge‐steld of de invoering van PCI‐DSS heeft bijgedragen aan de toename van het beveiligingsniveau. Mogelijke indicato‐ren hiervoor zijn • een afname van het aantal non‐compliance bevindin‐

gen tijdens een PCI‐DSS audit; • een afname van het aantal security incidenten; • toename security controls (meer servers die volledig

zijn gepatcht, meer gehardende systemen, etc.) 5. De mate waarin de invoering recht

doet aan de organisatiestrategie (in het algemeen en meer in het bijzonder ten aanzien van de gekozen Complian‐ce strategie)

Op basis van de door de organisatie vastgestelde doelen uit de strategie kan worden vastgesteld of de invoering van PCI‐DSS hier consistent mee is. Mogelijke indicatoren hiervoor zijn: • Gelijke richting in ontwikkeling van KPI’s (bijvoorbeeld

kwaliteit omhoog, kosten omlaag); • Gelijke inrichtingsprincipes t.a.v, van Governance;

17 VISA geeft voor gehackte gegevens sowieso een boete ongeacht of men wel of niet PCI‐Compliant is. Master‐card kent de zogenaamde Safe Harbor, waarbij de organisatie die PCI‐Compliant is geen boete krijgt. Overigens wordt bij het opleggen van boetes en liability shifts wel rekening gehouden met de mate waarin de verwerker pro‐actief heeft gehandeld inzake melding en remediation.


Pagina 33 van 43

Nr. Criterium Wijze van vaststellen • Mate van integratie van PCI‐DSS in andere werkzaam‐

heden (bijv. auditplannen); • Dekkingspercentage van maatregelen in het control

framework van de organisatie t.o.v. PCI‐DSS maatrege‐len.

Tabel 6 ‐ Wijze van vaststellen van succes van invoering


Pagina 34 van 43

4. Conclusies en aanbevelingen De centrale vraagstelling van deze scriptie luidt als volgt:

“Welke strategieën voor succesvolle invoering van PCI‐DSS zijn te onderscheiden?” We hebben op basis van inzichten uit de theorie, praktijk en eigen analyse een aantal keuzes en over‐wegingen gegeven met in een aantal gevallen voorkeuren voor alternatieven. Door deze keuzes te relateren aan een tweetal voor PCI‐DSS relevante typen organisaties zijn we gekomen tot een twee‐tal mogelijke strategieën voor de succesvolle invoering van PCI‐DSS. Dit zijn:

• Geïntegreerde invoering van PCI‐DSS gericht op toegevoegde waarde voor level 1 organi‐saties

• Stand‐alone invoering van PCI‐DSS gericht op certificering voor level 4 organisaties In de praktijk zal het aantal mogelijke strategieën niet tot deze twee beperkt zijn, maar zal door combinaties van gekozen alternatieven een grotere diversiteit aan strategieën mogelijk zijn. Het is aan de organisaties die aan PCI‐DSS moeten voldoen om zelf een strategie te formuleren door het maken van keuzes in de diverse fasen van de invoering. Daarbij is het mogelijk om één van de twee door ons geformuleerde strategieën als vertrekpunt te nemen.

4.1. Beperkingen en aanbevelingen tot nader onderzoek Het viel buiten de opzet van dit onderzoek om diepgaand de besluitvorming binnen organisaties te volgen en te meten in hoeverre deze keuzes hebben bijgedragen aan het succes van de invoering. In Nederland zijn de ervaringen met PCI‐DSS ook nog dusdanig beperkt dat het nog niet mogelijk is om op basis van empirisch onderzoek de bijdrage van gemaakte keuzes aan de succesvolle invoering van PCI‐DSS te kunnen vaststellen. Dat neemt niet weg dat het nuttig is om wetenschappelijk onderzoek te verrichten naar de succes‐volle invoering van regelgeving. In het literatuuronderzoek hebben wij weinig kunnen vinden over het bewezen succes van bepaalde keuzes. Ook de samenhang tussen diverse keuzes zou daarbij on‐derzocht moeten worden om op die manier tot inzicht te komen in werkende combinaties van keu‐zes en daaruit voortvloeiend één of meerdere mogelijke strategieën waarvan het succes is aange‐toond. Dit zou dan breder getrokken kunnen worden dan enkel PCI‐DSS. Dit heeft als voordeel dat breder inzicht ontstaat in de effectiviteit van keuzes en het ook door meer organisaties breder toe‐pasbaar is. Het nadeel zou zijn dat een aantal keuzes dat specifiek geldt voor PCI‐DSS door deze aan‐pak niet wordt meegenomen.


Pagina 35 van 43

Literatuuroverzicht De volgende literatuur is gebruikt tijdens dit onderzoek: • Adler, Ken & Swanson, Dan (2007) IT Audit Checklist Series ‐ PCI ‐ Practical guidance on how to prepare for

successful audits, IT Compliance Institute, 107 p. • Andriessen, V. (25/11/2008) ‘Rekeningfraude miljarden waard’, in: Financieele Dagblad,

http://www.emerce.nl/nieuws.jsp?id=35304 • Bednarz, Ann (09/08/2006) ‘New council takes over development of the PCI data security standard’, in:

Network World, http://www.networkworld.com/news/2006/090806‐credit‐card‐security.html • Carr, Jim (01/05/2008) ‘Report: small merchants biggest threat to credit card fraud’, in: SC Magazine,

http://www.scmagazineus.com/Report‐small‐merchants‐biggest‐threat‐to‐credit‐card‐fraud/article/109595/

• Carr, Jim (31/01/2008) ‘Visa: Most merchants in compliance with PCI security standard’, in: SC Magazine, http://www.scmagazineus.com/Visa‐reports‐progress‐on‐PCI‐DSS‐compliance/article/104439/

• Dijk, Wieland van (24/11/2008) ‘Online creditcardfraude is miljarden waard’, in: NU.nl, http://www.nu.nl/internet/1855280/online‐creditcardfraude‐is‐miljarden‐waard.html

• Drew, Doug & Nair, Sushila (2008) ‘Payment Card Industry Data Security Standard in the Real World’, The Information Systems Control Journal, vol. 5 (2008): p. 49‐52.

• Franken, H., Kaspersen, H. & Wild, H. de (2004) Recht en computer, Deventer: Kluwer • Henderson, J.C. & Venkatraman, N. (1993) ‘Strategic Alignment: Leveraging information technology for

transforming organizations’, IBM Systems Journal, vol. 32(1): p. 472‐488 • Henisz, W.J. & Zelner, B.A. (2003) ‘The strategic organization of political risks and opportunities’, Strategic

Organization, vol. 1(4): p. 451‐460 • Hines (2008) ‘Interview ‐ The PCI SSC's general manager talks about the latest version of PCI DSS and del‐

ves into issues around enforcement’, PC Week, vol. 25 (2008) afl. 30: p. 53‐57. • IT Compliance Institute (2007) Challenges and Opportunities of PCI, IT Compliance Institute, 10 p. • IT Governance UK (2008) ‘Everything you need to know for payment card industry data security standard

(PCI DSS) compliance’, in: IT Governance UK, http://www.itgovernance.co.uk/pci_dss.aspx • Kemenade, L. van (7‐10‐2009) ‘Nederlandse creditcardgegevens te koop in Rusland’, in: Elsevier,

http://www.elsevier.nl/web/Nieuws/Internet‐Gadgets/Nederlandse‐creditcardgegevens‐te‐koop‐in‐Rusland.htm

• Krell, K., & Matook, S. (2009) ’Competitive advantage from mandatory investments: An empirical study’, Journal of Strategic Information Systems

• Meadowcroft, Paul (2008) ‘Card fraud – will PCI‐DSS have the desired impact?’, Card Technology Today, vol. 20 (2008) afl. 3: p. 9‐11.

• Messmer, Ellen (22/01/2009) ‘Heartland breach raises questions about PCI standard's effectiveness’, in: Network World, http://www.networkworld.com/news/2009/012209‐heartland‐breach.html

• Messmer, Ellen (25/01/2007) ‘Credit card industry struggles to enforce security standard’, in: Network World, http://www.networkworld.com/news/2007/012507‐tjx‐standard.html

• Morse, Edward & Raval, Vasant (2008) ‘PCI DSS: Payment card industry data security standards in context’, Computer Law & Security Report, vol. 24 (2008) afl. 6: p. 540‐554.

• N.N. (2007), CobiT 4.1, Rolling Meadows: IT Governance Institute • N.N. (2005), ISO/IEC 27001¸ Geneve: ISO • N.N. (2007), The State Of PCI Compliance, Cambridge: Forrester Research • Oliver, C. & Holzinger, I. (2007) The effectiveness of Strategic Political Management: A Dynamic Capabilities

Framework, Toronto: York University • PaySquare (2009) ‘PCI DSS veilig omgaan met kaartgegeven’, in: PaySquare,

http://www.paysquare.nl/Content.aspx?id=513 • PCI Security Standards Council (11/2007) PCI Security Standards Council Strengthens Data Security, press

release • PCI Security Standards Council (10/2008) Payment Card Industry (PCI) Data Security Standard Require‐

ments and Security Assessment Procedures Version 1.2, PCI Security Standards Council, 72 p. • PCI Security Standards Council (03/2009) The Prioritized Approach to Pursue PCI DSS Compliance, PCI Secu‐

rity Standards Council


Pagina 36 van 43

• Ringelestijn, Tonie van (24/11/2008) ‘Creditcardfraude potentieel goed voor 4 miljard euro', in: WebWe‐reld, http://webwereld.nl/article/view/id/53696

• Schwartz, Mathew (20/03/2007) ‘Beyond SOX and Endpoint Security: Six Emerging Trends in Compliance’, in: Do, Huan (ed.) Best Security, Privacy, and Data Protection Articles of 2007: IT Compliance Institute, p. 6‐8.

• Shaffer, B. (1995) ‘Firm‐level responses to government regulation: theoretical and research approaches’, Journal of Management, Fall 1995

• Sussman, Bruce (2008) ‘Mastering the Payment Card Industry Standard’, Journal of Accountancy, vol. 205 (2008) afl. 1: p. 50‐53.

• Thompson, Tony (2007) PCI Compliance Cost Analysis, Solidcore Systems, Emagined Security & Fortrex, 5 p. • Vanagas, P. & Žirgutiene, S. (2005) TQM paradigm shift in the context of change management, Engineering

Economics, 43(3): 42‐48 • Van Zoest, F. (2007) Strategic Regulatory Management: An exploration of the Dutch banking industry, Rot‐

terdam: Erasmus Universiteit • VeriSign Global Security Consulting Services (2007) Lessons Learned: Top Reasons for PCI Audit Failure and

How To Avoid Them, VeriSign, Inc., 16 p. • Weidenbaum, M.L. (1980) ‘Public policy: no longer a spectator sport for business’, Journal of Business Stra‐

tegy, 3(4): p. 46‐53 • Werf, M. van der (02‐02‐2009) ‘Winkel eist vaker legitimatie ‐ Ondernemers dekken zich in tegen fraude

met creditcard’, in: Algemeen Dagblad • Zoellick, B. & Frank, T. (2005) Governance, Risk Management and Compliance: An operational approach, A

Compliance Consortium Whitepaper


Pagina 37 van 43

Bijlage 1 Compliance eisen Onderstaande tabel geeft een indicatie van de algemeen geaccepteerde indeling qua compliance eisen per (merchant) level. De levels zijn gebaseerd op ingeschatte risico’s voor het type transacties, de mate waarin het betaalsysteem wordt blootgesteld aan gevaren en het transactie volume:

Level Transacties Compliance eisen

Level 1 • Merchants met > 6 mln. transacties per jaar (alle kanalen)

• Alle third party processors (TPP’s) • Alle data storage providers (DSP’s)

voor level 1, 2 en 3 partijen • Alle gecompromitteerde18 mer‐

chants, TTP’s en DSP’s

• Jaarlijkse volledige audit (door een QSA of Internal Audit indien ondertekend door een directielid en vooraf goedgekeurd door de acquirer

• Elk kwartaal een netwerk security scan door een Approved Scanning Vendor (ASV)

Level 2 • Elke merchant met 1 mln. >< 6 mln. transacties per jaar (channel proces‐sing)

• Jaarlijks een Self Assessment Questionnaire

• Elk kwartaal een netwerk security scan door een ASV

Level 3 • Merchants met 20k >< 1 mln. e‐commerce transacties per jaar

• Jaarlijks een Self Assessment Questionnaire

• Elk kwartaal een netwerk security scan door een ASV

Level 4 • Alle andere merchants • Jaarlijks een Self Assessment Questionnaire

• Elk kwartaal een netwerk security scan door een ASV, verplicht of optioneel afhankelijk van de ac‐quirers acceptatie criteria.

Tabel 7 ‐ PCI levels (Drew & Nair, 2008; itgovernance.co.uk, 2008; Adler & Swanson, 2007)

18 Organisaties waar eerder security breaches zijn voorgekomen.


Pagina 38 van 43

Bijlage 2 Noncompliance op PCIDSS eisen Het percentage betreft non‐compliance voor een specifieke vereiste:

Tabel 8 ‐ Non‐compliance op PCI‐DSS eisen (VeriSign, 2007)


Pagina 39 van 43

Bijlage 3 Report on Compliance eisen 1. Contact Information and Report Date

Include contact information for merchant or service provider and assessor Date of report

2. Executive Summary Business description List service providers and other entities with which the company shares cardholder data List processor relationships Describe whether entity is directly connected to payment card company For merchants, POS products used Any wholly‐owned entities that require compliance with the PCI DSS Any international entities that require compliance with the PCI DSS Any wireless LANs and/or wireless POS terminals connected to the cardholder environment

3. Description of Scope of Work and Approach Taken Version of the Security Audit Procedures document used to conduct the assessment Timeframe of assessment Environment on which assessment focused (for example, client’s Internet access points, internal

corporate network, processing points for the payment card company) Any areas excluded from the review Brief description or high‐level drawing of network topology and controls List of individuals interviewed List of documentation reviewed List of hardware and critical (for example, database or encryption) software in use For Managed Service Provider (MSP) reviews, clearly delineate which requirements in this docu‐

ment apply to the MSP (and are included in the review), and which are not included in the review and are the responsibility of the MSP’s customers to include in their reviews. Include information about which of the MSP’s IP addresses are scanned as part of the MSP’s quarterly vulnerability scans, and which IP addresses are the responsibility of the MSP’s customers to include in their own quarterly scans

4. Quarterly Scan Results Summarize the four most recent quarterly scan results in comments at Requirement 11.2 Scan must cover all externally accessible (Internet‐facing) IP addresses in existence at the entity 5. Findings and Observations All assessors must use the following template to provide detailed report descriptions and find‐

ings on each requirement and sub‐requirement Where applicable, document any compensating controls considered to conclude that a control is

in place

(PCI SSC, 2008)


Pagina 40 van 43

Bijlage 4 Kosten van PCIDSS

Tabel 9 ‐ Kosten van PCI‐DSS (Thompson, 2007)


Pagina 41 van 43

Bijlage 5 Relatie tot andere bestaande wet en regelgeving en standaarden Gegeven de klassieke CIA (confidentiality, integrity en availability) doelstellingen van informatiebe‐veiliging, richt PCI‐DSS zich voornamelijk op het kwaliteitsaspect “vertrouwelijkheid”. Vanuit dit licht bezien is er een aantal wetten, regelgevingen en standaarden waar mogelijke overlap dan wel raak‐vlakken mee bestaat. Deze zullen achtereenvolgens kort worden toegelicht waarbij de aandacht met name uitgaat naar de overeenkomsten en verschillen in toepassingsgebied en eisen en de mogelijk‐heden om maatregelen te combineren.

Wet‐ en regelgeving

De Wet Bescherming Persoonsgegevens (Wpb) is de meest voor de hand liggende wetgeving wan‐neer het gaat om een directe relatie met de eisen uit PCI‐DSS. Ten eerste is er een overeenkomst in de reikwijdte in die zin dat credit card gegevens, op basis van het feit dat ze een reële mogelijkheid hebben voor het leggen van een verband met een te identificeren of geïdentificeerde natuurlijke persoon (Franken et al., 2004: 354), onder de Wbp vallen en daarmee ook aan de eisen uit de Wbp moet worden voldaan. Ten tweede hebben zowel de Wbp als PCI‐DSS betrekking op zowel opslag transport als verwerking van gegevens. Ten slotte worden vanuit zowel PCI‐DSS als vanuit de Wpb eisen gesteld aan beveiligingsmaatregelen. Daar dient zich echter ook het eerste verschil aan. Wbp art. 13 vereist: ‘de verantwoordelijke legt passende technische en organisatorische maatregelen ten uitvoer om persoonsgegevens te beveiligen tegen verlies of enige vorm van onrechtmatige verwer‐king’. Daarbij worden in het vervolg van het artikel ook nog nuanceringen gemaakt voor ‘de stand van de techniek en de kosten van de tenuitvoerlegging’. Bovendien moet een en ander worden gere‐lateerd aan ‘de risico’s die de verwerking en de aard van te beschermen gegevens met zich mee‐brengen’. Uit voorgaande formuleringen blijkt het principle‐based karakter van de Wbp, waar PCI‐DSS nadrukkelijk een rule‐based standaard is. Een ander verschil is dat de Wbp meer gericht is op gebruiksregulering (Franken et al., 2004: 380)

Standaarden De eisen uit PCI‐DSS vertonen overlap met een aantal standaarden en frameworks die gebruikt wor‐den voor informatiebeveiliging. Onderzoek van Forrester (2007) wijst uit dat de ISO 27001 de meest gebruikte standaard is in combinatie met PCI‐DSS.

Figuur 6 ‐ Standaarden en frameworks gebruikt in combinatie met PCI‐DSS (Forrester, 2007: 13)


Pagina 42 van 43

Voor de hierboven genoemde standaarden en frameworks geldt dat zij allen generieker zijn dan PCI‐DSS (zowel qua scope als qua diepgang), waarbij de ISO 27001 en Cobit antwoord geven op de vraag wat er aan maatregelen genomen zou moeten zijn, terwijl ITIL veel meer antwoord geeft op de vraag hoe die maatregelen kunnen worden ingevuld op basis van best practices. Hoewel er nog meer standaarden en frameworks zijn die een gedeeltelijke overlap met PCI‐DSS eisen vertonen (denk bijvoorbeeld aan de NIST Special Publication 800‐53), zullen we hierna enkel kort ingaan op de mapping van de eisen uit PCI‐DSS op de processen/onderdelen van de standaarden en frameworks, die uit het onderzoek van Forrester als meest gebruikt in combinatie met PCI‐DSS naar voren zijn gekomen. Op basis van de mapping wordt duidelijk dat er vanuit de ISO 17799 / ISO 27001 verreweg de meeste overlap is met PCI‐DSS, wat ook zou verklaren waarom deze het meest in combinatie met PCI‐DSS wordt gebruikt. CobiT en ITIL kennen niet de verfijning op het gebied van informatiebeveiliging die de ISO 17799 / ISO 27001 heeft. ISO 17799 / ISO 27001 De eisen uit PCI‐DSS hebben betrekking op de volgende control objectives uit de ISO 17799 / ISO 27001:

• Information Security Policy

• Internal Organisation

• Responsibility for Assets

• Termination or Change of Employment

• Secure Areas

• Equipment Security

• Operational Procedures and Responsibili‐ties

• Third Party Service Delivery Management

• System planning and acceptance

• Protection against malicious and mobile code

• Network security management

• Media handling

• Exchange of information

• Monitoring

• Business requirement for access control

• User access management

• Network access control

• Operating system access control

• Application and information access con‐trol

• Mobile computing and teleworking

• Security requirements of information sys‐tems

• Cryptographic controls

• Security in development and support pro‐cesses

• Technical Vulnerability Management

CobiT De eisen uit PCI‐DSS hebben vooral betrekking op de volgende CobiT (v4.1) processen:

• AI6: Manage Changes

• AI7: Install and Accredit Solutions and Changes

• DS5: Ensure Systems Security

• DS11: Manage Data

• DS12: Manage the Physical Environment ITIL De eisen uit PCI‐DSS hebben vooral betrekking op de volgende ITIL (v3) processen:


Pagina 43 van 43

• Information Security Management

• Service Asset & Configuration Manage‐ment

• Access Management

• Release Management

• Deployment Management

• Service Validation & Service Testing

• Change Management

‘Voldoen of voldaan?’ - vurore.nl · Level 1‐strategie ... • Afstemming tijdens...

Documents

Transcript of ‘Voldoen of voldaan?’ - vurore.nl · Level 1‐strategie ... • Afstemming tijdens...