Continue Compliant Elektronisch Betalingsverkeer

Continue Compliant Elektronisch Betalingsverkeer

Auteur: Studentnr.: Datum:

Drs. Ingrid Terlien CISSP CISM 2030977 20-3-2012

Continue compliant elektronisch betalingsverkeer


INHOUDSOPGAVE 1. INLEIDING ....................................................................3 1.1. AANLEIDING .................................................................................................................. 3 1.2. OPDRACHTFORMULERING .............................................................................................. 4 1.2.1. Probleemstelling ................................................................................................... 4 1.2.2. Centrale vraagstelling .......................................................................................... 5 1.2.3. Deelvragen ........................................................................................................... 5 1.2.4. Scope..................................................................................................................... 5 1.3. AANPAK ONDERZOEK ..................................................................................................... 7 1.4. STRUCTUUR EN OPBOUW ................................................................................................ 7

2. ELEKTRONISCH BETALINGSVERKEER..............9 2.1. 2.2. 2.3. 2.4. 2.5.

ALGEMEEN .................................................................................................................... 9 PROCESSING (AUTORISATIE EN CLEARING) ................................................................... 11 SETTLEMENT................................................................................................................ 12 INFRASTRUCTUUR CLEARINGHUIS................................................................................ 13 TOEKOMSTIGE ONTWIKKELINGEN ................................................................................ 15

3. RICHTLIJNEN BETALINGSVERKEER ................17 3.1. SINGLE EUROPEAN PAYMENT AREA (SEPA) ............................................................... 17 3.2. PAYMENT CARD INDUSTRY – DATA SECURITY STANDARD (PCI-DSS) ........................ 20 3.2.1. Inleiding.............................................................................................................. 20 3.2.2. De standaard ...................................................................................................... 21 3.2.3. Assessment en non-compliance .......................................................................... 30

4. CONTINUE MONITORING, AUDITING & ASSURANCE ...............................................................32 4.1. 4.2. 4.3.

BEGRIPPEN EN SAMENHANG ......................................................................................... 32 FREQUENTIE VAN CONTINUE ........................................................................................ 34 CONTINUE MONITORING PROCES .................................................................................. 35

5. BEVINDINGEN THEORETISCH ONDERZOEK BEHEERSMAATREGELEN .....................................37 5.1. 5.2. 5.3. 5.4.

BEHEERSMAATREGEL: INRICHTING INFRASTRUCTUUR ................................................. 37 BEHEERSMAATREGEL: INRICHTING CONTINUE COMPLIANCE ........................................ 41 BEHEERSMAATREGEL: INRICHTING CONTINUE MONITORING VAN DE TECHNISCHE INFRASTRUCTUUR ........................................................................................................ 43 BEHEERSMAATREGEL: BEWIJSVOERING VOOR AANTONEN CONTINUE COMPLIANCE ..... 46

1


6. BEVINDINGEN EMPIRISCH ONDERZOEK BEHEERSMAATREGELEN .....................................48 6.1. 6.2. 6.3. 6.4. 6.5.

OPZET PRAKTIJKONDERZOEK ....................................................................................... 48 BEHEERSMAATREGEL: INRICHTING INFRASTRUCTUUR ................................................. 49 BEHEERSMAATREGEL: INRICHTING CONTINUE COMPLIANCE ........................................ 50 BEHEERSMAATREGEL: INRICHTING CONTINUE MONITORING VAN DE TECHNISCHE INFRASTRUCTUUR ........................................................................................................ 52 BEHEERSMAATREGEL: BEWIJSVOERING VOOR AANTONEN CONTINUE COMPLIANCE ..... 56

7. VRAAGSTELLING, BEANTWOORDING EN AANBEVELINGEN ....................................................57 7.1. 7.2. 7.3.

DEELVRAGEN EN BEANTWOORDING ............................................................................. 57 CENTRALE VRAAGSTELLING EN BEANTWOORDING ....................................................... 59 AANDACHTSPUNTEN EN AANBEVELINGEN .................................................................... 60

8. PERSOONLIJKE REFLECTIE ................................62 9. DANKWOORD ............................................................63 BIJLAGE...........................................................................64 LITERATUURLIJST ................................................................................................................... 64 VRAGENLIJST .......................................................................................................................... 67

2


1. Inleiding 1.1. Aanleiding Een veilig en betrouwbaar betalingsverkeer draagt bij aan de borging van een stabiel financieel stelsel. Dit betekent dat onder andere laagwaardige betalingen (zoals betalingen in winkels of het overmaken van geld door middel van een betaalopdracht) veilig en zonder verstoringen moeten plaatsvinden. De afhandeling van laagwaardige betalingen wordt door verschillende partijen uitgevoerd. Transacties via gelden betaalautomaten worden door een Processor uitgevoerd. De afhandeling van betalingstransacties via internet worden door de zogenaamde Payment Service Providers verzorgd.

Gezien het grote volume in aantallen transacties en geld, kan het voorkomen dat Processors en Payment Service Providers doelwit worden van frauduleuze of criminele handelingen. Hierbij valt te denken aan ongeoorloofde toegang, het wijzigen, vernietigen of misbruik van gegevens. Het is daarom van groot belang dat de beveiliging van de systemen van een zodanig hoog niveau zijn dat het risico minimaal is.

Naast dat de Processors en Payment Service Providers zelf hoge eisen aan de beveiliging van de systemen stellen, worden stringente eisen vanuit weten regelgeving opgelegd. Een regelgeving waaraan moet worden voldaan is PCI-DSS (Payment Card Industry – Data Security Standard). Deze eis wordt door de creditcard maatschappijen (onder andere Mastercard en Visa) opgelegd. In deze regelgeving worden zowel technische als procedurele eisen opgelegd en deze worden jaarlijks middels een audit getoetst.

Het is vereist dat ten alle tijden kan worden aangetoond dat aan de eisen van PCI-DSS wordt voldaan. Dit houdt in dat niet alleen tijdens een audit moet worden aangetoond dat de organisatie compliant is maar, in tegenstelling tot ISO 27001 en ISAE3402, dient een organisatie zelfs aan te tonen dat zij aan de eisen van PCI-DSS voldeed ten tijde van een ‘data breach’, waarbij inbreuk op de beschikbaarheid, integriteit en/of vertrouwelijkheid plaatsvindt.

3


Indien de organisatie dit niet kan aantonen, zullen sancties worden opgelegd door de Payment Brands. Dit betekent dat een organisatie op een zodanige wijze moet worden ingericht dat continue assurance kan worden afgegeven en dat continue monitoren van de omgeving een minimale vereiste is om te voldoen aan de eisen.

Een van de belangrijkste taken van een Security Officer is de continuïteit (24/7) en de veiligheid op het gebied van betalingen voor de IT infrastructuur te borgen. Hierbij dient de IT infrastructuur op een zodanig manier ingericht te worden dat het zowel continue gemonitord als ge-audit kan worden.

De vraag op welke wijze de IT infrastructuur ingericht moet worden, zodat op een efficiënte en effectieve wijze continue op de verschillende niveaus (operationeel, tactisch en strategisch) gemonitord en geacteerd kan worden bracht mij tot dit onderzoek.

1.2. Opdrachtformulering 1.2.1. Probleemstelling De core business van zowel Processors als Payment Service Providers is het leveren van een betrouwbaar, integer en beschikbaar proces voor het betalingsverkeer waarin zij dient als intermediair. Daarnaast spelen factoren zoals weten regelgeving en concurrentie voor deze organisaties een belangrijke rol.

Het probleem dat hierbij ontstaat is dat enerzijds de organisatie een kwalitatief hoogwaardige dienst moet leveren waarbij de risico’s geminimaliseerd zijn terwijl anderzijds de organisatie competitief moet blijven in de markt. Dit laatste houdt in dat zij de kosten dient te beheersen en haar processen zo efficiënt en effectief mogelijk dient in te richten. Dit kan leiden tot conflicterende belangen binnen de organisatie.

4


1.2.2. Centrale vraagstelling Op basis van de aanleiding en de probleemstelling is de centrale vraagstelling als volgt:

Op welke wijze dienen organisatie en beheer van de IT infrastructuur bij vitaal elektronisch betalingsverkeer ingericht te worden om continue te voldoen aan de regelgeving van PCI-DSS op een continue aantoonbare wijze ?

1.2.3. Deelvragen Om de hoofdvraag te kunnen beantwoorden, is het onderzoek gesplitst in verschillende deelvragen, te weten: 

Op welke wijze is het elektronische betalingsverkeer ingericht en wat is haar dynamiek?



Wat houdt de regelgeving PCI-DSS in en aan welke eisen moeten worden voldaan?



Welke inzichten met betrekking tot continue monitoring en continue audit zijn beschreven in het elektronische betalingsverkeer?



Op welke wijze is de technische infrastructuur bij Processors en Payment Service Providers ingericht?



Voldoet de huidige inrichting aan de regelgeving van PCI-DSS en welke maatregelen worden thans genomen?



Op welke wijze worden maatregelen getroffen om middels bewijsvoering continue aantoonbaar in control te zijn?

1.2.4. Scope De scope van het onderzoek is beperkt tot de technische infrastructuur. De technische infrastructuur wordt gedefinieerd als het geheel van technologische componenten, systeem- en toepassingssoftware, procedures en documentatie die nodig zijn voor het beschikbaar stellen van een of meerdere informatiesystemen (ITIL).

5


De componenten zijn (bron: [34]): 

Verwerkingsapparatuur c.q. infrastructuur verwerkingssystemen De apparatuur en de programmatuur die nodig zijn om de toepassingen te laten functioneren. Dit betreft de hardware, operating system en virtuele machine.



Opslagapparatuur c.q. infrastructuur opslagsystemen De apparatuur en programmatuur die nodig zijn om de gegevensverzamelingen op te slaan, zoals storage (SAN/NAS, e.d.), databases (en het daarbij behorende databasemanagementsysteem) en andere middleware voor de koppeling van verschillende computerplatformen en applicaties.



Communicatie- of netwerkinfrastructuur De communicatieverbindingen tussen verwerkingsapparatuur onderling en tussen verwerkingsapparatuur en opslagapparatuur.



Organisatie-infrastructuur Het beleid, processen, procedures en werkinstructies die nodig zijn voor de inrichting en beheer van de technische infrastructuur.

De scope van het onderzoek beperkt zich tot de technische infrastructuur omdat de configuratie instellingen in deze infrastructuur altijd na ingebruikname kunnen worden gewijzigd door de beheerder. Daarnaast zal alleen ingegaan worden op de security standaard PCI-DSS (Payment Card Industry – Data Security Standard) omdat deze standaard toeziet op het continue compliant zijn. Andere weten regelgeving vallen buiten de scope van het onderzoek.

De informatiesystemen zelf vallen buiten de scope van dit onderzoek. De beweegreden hiervoor is dat bij informatiesystemen de beveiligingseisen tijdens het software ontwikkelingstraject worden geïmplementeerd. Een eenmaal opgeleverd informatiesysteem kan later niet worden gewijzigd doordat de source code is gecompileerd.

6


1.3. Aanpak onderzoek Om antwoord te kunnen krijgen op de deelvragen en de uiteindelijke centrale vraag, is de toegepaste onderzoeksmethode een combinatie van een literatuurstudie en een praktijkstudie.

Op basis van de literatuurstudie wordt nagegaan in hoeverre al onderzoek is gedaan naar het onderwerp continue compliant infrastructuur in het elektronische betalingsverkeer. Met behulp van de literatuur wordt een beeld gevormd op welke wijze een continue compliant technisch infrastructuur zou moeten worden ingericht en welke eisen hieraan gesteld worden. Daarnaast wordt inzicht gegeven in de huidige stand van zaken ten aanzien van continue compliance bij betalingsverwerkers.

De praktijkstudie is uitgevoerd middels een schriftelijke vragenlijst die is uitgestuurd naar twee Processors en drie Payment Service Providers. Tevens hebben diverse expert interviews plaatsgevonden met de PCI-DSS auditor van deze organisaties. Tenslotte is gebruik gemaakt van de eigen opgebouwde kennis en ervaring. Door zowel de input van mensen uit de organisatie als de IT Auditor wordt een beeld verkregen dat verschillende invalshoeken belicht. De resultaten van het praktijkonderzoek in vergelijking met het literatuuronderzoek zullen de input vormen voor de beantwoording van de centrale vraag van dit onderzoek.

1.4. Structuur en opbouw Het document is opgebouwd uit vier delen. De inleiding beschrijft de aanleiding tot het onderzoek, de probleemstelling, de centrale onderzoeksvraag en bijbehorende deelvragen. Tevens wordt de scope gedefinieerd en de wijze waarop het onderzoek is aangepakt.

De hoofdstukken 2, 3 en 4 bestaan uit het literatuuronderzoek waarin de deelvragen worden uitgewerkt. In hoofdstuk 2 wordt de deelvraag “Op welke wijze is het elektronisch betalingsverkeer ingericht en wat is haar dynamiek” beantwoord. In hoofdstuk 3 wordt de regelgevingen die betrekking heeft op het elektronische betalingsverkeer beschreven en zal ingegaan worden op de richtlijn Single European Payment Area (SEPA) en de standaard

7


Payment Card Industry – Data Security Standard (PCI-DSS). Tot slot zal hoofdstuk 4 de inzichten met betrekking tot continue monitoring en continue auditing worden belicht.

In de hoofdstukken 5 en 6 worden de bevindingen van de beheersmaatregelen die genomen moeten worden beschreven. De bevindingen van het theoretische onderzoek zijn in hoofdstuk 5 uitgewerkt en hoofdstuk 6 de bevindingen van het empirisch onderzoek.

Tot slot wordt in hoofdstuk 8 de centrale vraag en deelvragen beantwoord. Tevens worden in dit hoofdstuk aanbevelingen gegeven die van belang zijn voor een goede implementatie van het continue compliance proces.

8


2. Elektronisch betalingsverkeer 2.1. Algemeen De infrastructuur van het betalingsverkeer geeft aan op welke wijze transacties worden verwerkt en verrekend. Er zijn diverse manieren waarop transacties worden verwerkt, maar over het algemeen wordt hetzelfde business model gebruikt. Het business model wordt ook wel het 4-party model genoemd en ziet er als volgt uit:

Betaler

Ontvanger

(kaarthouder)

(Verkoper)

Issuing Bank

Clearing house

Acquiring Bank

Figuur 1: 4-party model In de vier hoeken van het 4-party-model staan de partijen die betrokken zijn bij een transactie, te weten: de betaler, ontvanger, Issuing bank (uitgever van de betaalkaart en bank van de betaler) en de Acquiring bank (bank van de ontvanger). In dit model is een vijfde partij toegevoegd, het Clearinghuis. Dit is een tussenpartij die zorgt dat transacties administratief en financieel worden afgehandeld. De dienst die geleverd wordt door het Clearinghuis is afhankelijk van het type Clearinghuis (zie paragraaf 2.4).

Naast de genoemde partijen, bestaat de infrastructuur tevens uit de volgende elementen: 

Processing (autorisatie en clearing): Processing bestaat uit de deelprocessen autorisatie en clearing. In het autorisatieproces wordt de verificatie en de autorisatie van een transactie uitgevoerd. In het clearingproces worden de transacties tussen een Issuing- en Acquiring bank verzameld, gesorteerd, het te vereffenen bedrag berekend en de informatie hierover uitgewisseld.

9




Settlement (vereffening): Dit houdt in dat de bank het te vereffenen bedrag van haar klant uitvoert. Dit is dus de daadwerkelijke betaling van het over te boeken bedrag van de bank van de betaler naar de bank van de ontvanger.



Betalingsinstrument: Dit is het hulpmiddel waarmee toestemming kan worden verleend om een transactie in te dienen. In dit onderzoek zijn dat de betaalkaarten (debet- en creditkaarten).

Voorbeeld: Transactie met gebruik van een betaalkaart: A. De consument koopt een product bij een winkel. In het geval dat de consument in de winkel zelf is, betaalt de consument aan de kassa (POS-terminal) met de betaalkaart. Het is ook mogelijk dat de consument bijvoorbeeld bij een webwinkel een aankoop verricht. De betaling wordt dan uitgevoerd met behulp van de gegevens van de betaalkaart. B. Het betaalsysteem dat de ontvanger gebruikt is aangesloten bij de Acquiring bank en na invoeren van de gegevens in het betaalsysteem wordt autorisatie aangevraagd. De aanvraag kan lopen via: I. Acquiring bank (in figuur pijl BI) II. Clearinghuis (in figuur pijl BII) C. De autorisatie wordt doorgestuurd naar de Issuing bank. Dit kan via de Acquiring bank (pijl CI) of via het Clearinghuis (pijl CII). D. De Issuing bank controleert of de consument het transactiebedrag van de rekening mag afhalen. Als de het tegoed van de consument toereikend genoeg is om de transactie af te ronden zal de Issuing bank een akkoord geven aan de partij die het autorisatie verzoek heeft gedaan. Dit kan de Acquiring bank (zie pijl DI) van de winkel zijn of het Clearinghuis (pijl DII). E. Het betaalsysteem krijgt via de Acquiring bank (pijl EI) of via het Clearinghuis (pijl EII) door of de betaling akkoord is en afgerond mag worden.

Betaler

Ontvanger

(kaarthouder)

(verkoper) Betaalsysteem POS-terminal Webwinkel

A BII

Issuing Bank

CII DII

Clearing house

CI DI

EII

B I EI Acquiring Bank

10


2.2. Processing (autorisatie en clearing) Processing bestaat uit de deelprocessen autorisatie en clearing. In het autorisatieproces wordt de verificatie en de autorisatie van een transactie uitgevoerd. Via het betaalsysteem wordt bij de bank van de betaler (Issuing bank) geverifieerd of de betaler de transactie mag uitvoeren (authenticatie). Vervolgens wordt geverifieerd of de betaler geautoriseerd is om het bedrag van de rekening af te halen (autorisatie). Indien de betaler voldoet aan de eisen, wordt de transactie door de Issuing bank goedgekeurd.

In het clearingproces worden de transacties tussen de Issuing- en Acquiring banken verzameld, gesorteerd en het te vereffenen bedrag per bank berekend. Het te vereffenen bedrag kan bestaan uit miljoenen individuele transacties per dag en is daarom een geheel geautomatiseerd proces. De transacties kunnen zowel intra bancair als interbancair zijn. Een intra bancaire transactie (ook wel concernverkeer genoemd) betreft een transactie tussen een betaler en een ontvanger van dezelfde bank. Dit proces is niet meer dan een eenvoudig boekhoudkundig proces omdat het alleen een overboeking betreft van de rekening van de betaler naar de rekening van de ontvanger en geen geld wordt overgeboekt naar een andere bank. Bij interbancair betalingsverkeer houden de betaler en de ontvanger een rekening aan bij verschillende banken. In dit geval vindt zowel het boekhoudkundige proces, de boeking van de betaling, als de daadwerkelijke verplaatsing van geld tussen de verschillende banken plaats. Dit laatste kan worden uitgevoerd door een derde partij, ook wel Clearinghuis genoemd.

Om de miljoenen transacties efficiënt en correct te verwerken wordt gebruik gemaakt van het clearingproces. Het clearingproces bestaat uit de volgende activiteiten: 

Het sorteren van betaalinstructies per bank naar de verschillende begunstigde banken en het berekenen van de te vereffenen bedragen;



Het sturen van settlement instructies;



Het sturen van alle relevante informatie over de individuele betalingen en over de te vereffenen bedragen aan de betrokken banken.

11


Het clearingproces is een volledig geautomatiseerd proces. Voor de verschillende typen betalingen zijn verschillende clearing systemen in gebruik. Voor betalingen met betrekking tot betaalkaarten, waar dit onderzoek zich op richt, wordt gebruik gemaakt van het systeem STEP2.

Het clearingproces kan door de bank zelf worden uitgevoerd, maar meestal wordt het uitgevoerd door een Clearinghuis. Een Clearinghuis ontvangt van de aangesloten banken de te verwerken transactiegegevens. Het clearingproces is een administratief proces. De transacties worden boekhoudkundig verwerkt op de rekening van de betaler en ontvanger, maar de daadwerkelijke geldtransactie vindt hier nog niet plaats. Dat wordt pas gerealiseerd in het settlementproces.

2.3. Settlement Het settlementproces is de uiteindelijke verrekening van transacties tussen de betrokken banken en is tevens een volledig geautomatiseerd proces. De settlement vindt plaats bij een centrale bank. De centrale bank debiteert de rekening van de Issuing bank en crediteert de rekening van de Acquiring bank. De settlementprocedure zelf is onafhankelijk van het feit of er één of meerdere transacties tegelijk aan de settlement instructie ten grondslag liggen.

Voorbeeld betalingsverkeer: clearing en settlementproces De laatste stap in het vorige voorbeeld was dat de betaling geautoriseerd was door de Issuing bank (actie D). In het clearingproces (C) worden de volgende stappen uitgevoerd: C1. De Issuing en Acquiring bank sturen de transactiegegevens naar het Clearinghuis. C2. Het Clearinghuis sorteert deze en andere binnenkomende transacties en berekent het te vereffenen bedrag. C3. Het Clearinghuis stuurt de settlementinstructie naar de Settlement Agent C4. Het Clearinghuis stuurt informatie over de individuele betalingen naar de Acquiring bank en settlementinformatie naar de Issuing bank.

12


Het settlementproces(S) voert vervolgens de volgende stap uit: S1. Het settlementsysteem (TARGET2) checkt het saldo op de rekening van de Issuing bank en als dit toereikend is, wordt de rekening gedebiteerd en de rekening van de begunstigde, de Acquiring bank, gecrediteerd. Het sturen van de saldo- en transactie informatie naar de betaler en ontvanger valt buiten het clearing en settlementproces en wordt door de bank zelf uitgevoerd.

Betaler

Ontvanger

(kaarthouder)

(Verkoper)

Issuing Bank

C1

Clearing house

C4

C2 C3

S1

C1

Acquiring Bank

C4 S1

Settlement Agent

2.4. Infrastructuur Clearinghuis Voor de clearing en settlement infrastructuur, ook wel het Clearing & Settlement Mechanism (CSM) genoemd, zijn regels vastgelegd waaraan deze infrastructuur moet voldoen. Er is onderscheid gemaakt tussen de volgende typen clearinghuizen: 

Payment Service Provider Clearinghuis voor transactieverwerking van internet betalingen. Zij biedt de mogelijkheid om betalingen op een webwinkel van een winkelier af te handelen.



Processors Clearinghuis voor alleen debet- en credit cards transacties. De transacties gaan niet rechtstreeks naar de banken, maar moeten eerst worden verstuurd naar de credit card maatschappijen (VISA, Mastercard, etc.). Vervolgens worden de transacties doorgezonden naar een (Pan European) Automated Clearing House (PE-)ACH en de (PE-) ACH stuurt de

13


gegevens door naar het settlementproces. Voor de betalingen worden dezelfde netwerken en apparatuur gebruikt als voor betalingen die via een (PE-)ACH lopen. Processors, die alleen debet en credit kaart transacties afhandelen, hoeven niet te voldoen aan de SEPA (Single European Payment Area)1 richtlijnen, maar wel aan de richtlijnen die voor de debet-/creditcard maatschappijen gelden. Het betreft hier vaak processors die voor een bepaalde keten/branche de clearing verrichten. 

ACH (Automated Clearing House) Dit type Clearinghuis verwerkt alle betalingstransacties, zowel kaart als betalingsopdrachten. De ACH biedt zowel de clearing (zoals een Processor) als de settlement functionaliteit aan. De betalingsopdrachten worden uitgewisseld tussen de verschillende deelnemende partijen middels een elektronisch clearing systeem. Vervolgens worden de opdrachten verzameld en aangeboden aan het settlement systeem om de daadwerkelijke betalingen te verrichten. De clearinghuizen zijn compliant voor één of meerdere SEPA betaalmiddelen. Het gaat hier om commercieel verwerkende partijen die voor de gehele sector (bijvoorbeeld hotels, tankstations, etc.) werken. Voorbeelden zijn First Data Corporation en TSYS.



PE-ACH (Pan European – Automated Clearing House) Dit zijn Clearinghuizen die voldoen aan de SEPA eisen die zijn opgesteld voor het verwerken van Europese betalingen en door het Clearing & Settlement Mechanism. De Clearinghuizen kunnen zowel domestic als cross-border betalingen afhandelen. Dit betekent dat betalingen van alle banken in de eurolanden en in eigen land verwerkt kunnen worden, hetzij indirect via intermediaire banken of direct door middel van koppelingen tussen infrastructuren. Het betreft hier vaak het interbancair betalingsverkeer. Voorbeelden zijn Equens SE (Nederland, Duitsland), VocaLink (Verenigd Koninkrijk), STET (Frankrijk).

Het Multi-CSM model (zie figuur 2), is ontwikkeld door de European Automated Clearing House Association (EACHA), en geeft weer op welke wijze de infrastructuur kan worden ingericht voor het clearing en settlement om operabiliteit te kunnen borgen. In dit model zijn

1

Single European Payment Area. Zie hoofdstuk 3.1

14


de deelnemende CSM’s op elkaar aangesloten, zodat zij naast hun eigen klanten (intra-CSM) ook elkaars klanten (inter-CSM) kunnen bereiken voor het verwerken van transacties. Intra CSM Bank

Bank

Bank

Bank

PE-ACH

Bank

PE-ACH

Bank

ACH

Bank

Inter CSM

ACH

Bank

Figuur 2: Multi-CSM model

2.5. Toekomstige ontwikkelingen Sinds de introductie van de euro is de markt voor het elektronische betalingsverkeer volop in beweging. Diverse ontwikkelingen zijn gaande waardoor de stabiele monopolistisch positie van Clearinghuizen verleden tijd wordt. De belangrijkste ontwikkelingen in de markt voor de betalingsverkeer zijn: 

Groei non-cash payments De trend in de betalingsverkeer is dat cash payments in loop der tijd minimaal zullen worden en de non-cash payments (zoals betaalkaart betalingen, micro betalingen, ewallets) enorm zullen toenemen. De Clearinghuizen zullen zich moeten voorbereiden om de grotere volumes te kunnen verwerken.



Veeleisende klanten Grote corporaties (bijvoorbeeld: IKEA, Shell, Vodafone) verlangen steeds hogere kwaliteit voor concurrerende prijzen. Zij sturen nadrukkelijk op het verlagen van de kosten van hun betalingsverkeer. Daarnaast wordt de verwerking van betalingen soms bij meerdere Clearinghuizen uitgevoerd. Deze ontwikkeling zal leiden tot een consolidatieslag waarbij alle transacties in de toekomst bij slechts één Clearinghuis wordt ondergebracht.



Transparantie markt Op Europees niveau is besloten om te komen tot een gemeenschappelijke, transparante

15


betaalmarkt. Binnen de eurozone kunnen bedrijven voor hun betalingsverkeer diensten afnemen bij vele aanbieders. Sinds de Directive on Payment Services (PSD) van kracht is, is het juridische kader vastgelegd voor interne competitie op de Europese betaalmarkt. 

Standaardisatie Vanuit regelgeving (SEPA) wordt standaardisatie van betalingsverwerking geëist. Deze standaardisatie maakt differentiatie moeilijker, waardoor de concurrentie zich voornamelijk zal richten op prijs, kwaliteit en service niveau. Dit vergt een andere benadering van de markt en een andere manier waarop de business wordt gedreven.



Nieuwe toetreders Door de transparantie van de markt en de standaardisatie zien diverse marktpartijen (ATOS, EDS, IBM etc.) kansen in de markt voor betalingsverkeer. Het betreft grote spelers in de outsourcing-branche. De ervaring die zij hebben in outsourcing en relatiebeheer van grote wereldwijde ondernemingen zetten zij in om de markt open te breken.



Fusies, joint ventures en overnames Door de open markt zullen er zowel veel nieuwe toetreders als fusies, joint ventures en overnames plaatsvinden. Grote partijen proberen in diverse Europese landen marktpositie te verkrijgen.



Wet- en regelgeving Door nieuwe en verscherpte weten regelgeving (SEPA, Basel III, ISEA 3402, PCI-DSS) zullen investeringen moeten worden gedaan om aan deze weten regelgeving te kunnen voldoen. Daarnaast zullen de kosten om compliant te blijven toenemen. Dit maakt het in de toekomst moeilijker om winstgevend te blijven en zal er een efficiency slag moeten plaatsvinden.

Geconcludeerd kan worden dat de wereld van transacties en betalingen heftig in beweging is, dat veroorzaakt wordt door technologische ontwikkelingen, veranderingen in weten regelgeving, invoering van marktwerking, consolidatie, en door het toetreden van nieuwe partijen. Deze dynamiek vormt een bedreiging voor de huidige partijen, maar biedt ook kansen voor nieuwe partijen.

16


3. Richtlijnen betalingsverkeer Er zijn diverse richtlijnen opgesteld voor de infrastructuur van het elektronisch betalingsverkeer. De richtlijnen zijn onder andere de Single European Payment Area (SEPA) en Payment Card Industry – Data Security Standard (PCI-DSS).

De richtlijnen die SEPA voorschrijft, zorgen voor standaardisatie van het Europese betalingsverkeer. De PCI-DSS richtlijnen zorgen voor de beveiliging van het betalingsverkeer van betaalkaarten (zie hoofdstuk 3.2). Voor beide richtlijnen geldt dat clearinghuizen compliant moeten zijn om deze betalingen te mogen verwerken.

3.1. Single European Payment Area (SEPA) De richtlijnen die moeten worden gevolgd om betalingen te kunnen verwerken, zijn vastgelegd in de SEPA (Single European Payment Area) Directive. SEPA is ontstaan na invoering van de euro. De invoering van de euro maakt het mogelijk om met één enkele valuta contante betalingen te verrichten in het gehele eurogebied (nu 17 landen). Naast de standaardisatie van de contante betalingen is door middel van SEPA ook de standaardisatie van het elektronische betalingsverkeer in de eurolanden tot stand gekomen en vastgelegd.

Om ervoor te zorgen dat de standaarden in alle eurolanden worden uitgevoerd is door de Economische Commissie een richtlijn opgesteld die de rechten en plichten heeft vastgelegd voor de gebruiker en aanbieder van betaaldiensten. Deze richtlijn is uitgewerkt in de Payment Service Directive (PSD) en vormt een juridische basis voor SEPA.

Om tot een standaardisatie te komen hebben Europese banken zich verenigd in de European Payment Council (EPC). Het EPC heeft specifieke regelgeving, afspraken en standaarden opgesteld, die geïmplementeerd moeten worden om het Europese betalingsverkeer in euro’s mogelijk te maken.

17


De standaarden hebben betrekking op: 

Verwerking van betalingen tussen banken: -

SEPA Credit Transfer (overboekingen)

-

SEPA Direct Debit (incasso’s)

Dit zijn de zogenaamde rulebooks die beogen: -

Technische standaardisatie: Het realiseren van gestandaardiseerde verwerking van transacties tussen banken onderling;

-

Stroomlijning van verwerkingsprocessen: Meer uniforme interpretatie en werkwijze tussen banken onderling (bijvoorbeeld bij het terugdraaien van betaalopdrachten);

-

Interoperabiliteit: De verwerking van overschrijvingen en incasso’s is bij alle verwerkers in SEPA hetzelfde. Hierdoor zullen banken uit veel meer verwerkers ('Processors') van betalingsverkeer kunnen kiezen dan nu.



Opzet en structuur van de markt: -

SEPA Cards Framework (SCF): Raamwerk voor debet- en creditkaarten waarin vastgesteld is waaraan verschillende uitgevers, systemen en ook banken moeten voldoen.

-

PE-ACH/CSM Framework (Pan European- Automated Clearing House/Clearing & Settlement Mechanism): Raamwerk waarin de regels voor Processoren in het eurogebied zijn vastgelegd. De EBA(European Banking Association) en de EACHA (European Automated Clearing House Association) hebben hiervoor verschillende infrastructuren beschreven. Waarbij de EBA zich voornamelijk richt op de inrichting van PE-ACH, terwijl de EACHA meer gericht is op de operabiliteit van de ACHs.

Het raamwerk beoogt voornamelijk: -

Ontvlechting en verbetering van de governance: De nationale verwerker van betalingen kan niet gelijktijdig ook de productbeheerder zijn.

-

Transparantie: Open en heldere regels voor zowel banken als verwerkers.

18


-

Verbeterde toegang en marktwerking: Door de rollenscheiding en transparantie wordt het makkelijker voor banken en verwerkers om grensoverschrijdend uit te breiden.

-

Interoperabiliteit: De ‘back office’ verwerking is in SEPA overal hetzelfde voor alle transacties en alle verwerkers van betalingsverkeer. Banken zullen hierdoor uit veel meer verwerkers van betalingsverkeer kunnen kiezen en winkeliers uit veel meer leveranciers van betaaldiensten voor kaartbetalingen dan nu het geval is.

De SEPA standaard gaat primair over uniformiteit en organisatie van het betalingsverkeer tussen banken (de ‘back office') in een open Europese markt. Er zijn geen kant-en-klare gezamenlijke producten gemaakt. Het is aan de (individuele) banken om producten te ontwikkelen.

De toezicht op naleving wordt door de Europese Centrale Bank (ECB) uitgevoerd. De ECB volgt de voortgang van SEPA in de eurolanden en daarnaast ziet de ECB toe op de kwaliteit van de implementatie van SEPA. De richtlijnen en de samenhang tussen de verschillende partijen zijn in onderstaand figuur samengevat:

Figuur 3: Richtlijnen en samenhang SEPA Naast de Europese richtlijnen is tevens een begin gemaakt met het opstellen van regels, standaarden, procedures en richtlijnen voor het internationale betalingsverkeer gericht op basis van de ISO 20022 Norm (gelijk aan SEPA). Hiervoor is het International Payment Framework Association (IPFA) opgericht. De IPFA heeft als doel de regels voor het uitwisselen van

19


betalingen in de verschillende valuta tussen de leden (zowel clearinghuizen als aangesloten banken) zoveel mogelijk te standaardiseren. Waardoor de interoperabiliteit kan worden verbeterd en de complexiteit tussen de verschillende clearinghuizen wordt vereenvoudigd.

3.2. Payment Card Industry – Data Security Standard (PCI-DSS) De Payment Card Industry-Data Security Standard (PCI-DSS) is een standaard voor informatie beveiliging voor specifiek betaalkaarten. De standaard is ontwikkeld door de Payment Card Industry Standard Security Council (PCI-SSC).

Deze paragraaf bestaat uit drie onderdelen. De sub-paragraaf Inleiding geeft een overzicht van de standaarden die door de PCI-SSC zijn gedefinieerd. In de daarop volgende sub-paragraaf wordt de Payment Card Industry – Data Security Standard (PCI-DSS) beschreven. De laatste sub-paragraaf gaat dieper in op de wijze waarop een assessment wordt afgenomen en de sancties bij non-compliance.

3.2.1. Inleiding De PCI-SSC is in 2006 opgericht door de grote credit card maatschappijen, te weten: Visa, Mastercard, American Express, Discover Financial Service en JCB International. Elke creditcard maatschappij heeft een eigen security programma met meerdere standaarden en certificeringen. Een aantal van deze security standaarden zijn gebundeld tot uniforme PCI standaarden, met als resultaat een uniforme certificering. Daarnaast dient deze standaard het vertrouwen van de consument om met een creditcard te betalen te borgen, c.q. creditcardfraude te minimaliseren.

De PCI-SSC beheert een set van security standaarden die de beveiliging definieert voor het gehele betalingsproces. Momenteel zijn de volgende standaarden beschikbaar: 

Payment Card Industry - Data Security Standard (PCI-DSS): Alle eisen die gesteld worden aan bedrijven die credit kaart data verwerken, opslaan of verzenden. Deze bedrijven worden acceptanten genoemd en zijn bijvoorbeeld (web)winkels, hotels, tankstations, Payment Service Providers, en banken.

20




Payment Application - Data Security Standard (PA-DSS): Dit is een sub set van de PCI-DSS standaard en heeft betrekking op de eisen die gesteld worden aan het ontwikkelen van software voor beveiligde betalingstoepassingen die een rol spelen in de autorisatie en/of clearing en settlement proces.



PIN Transaction Security (PTS): Dit is een sub set van de PCI-DSS standaard en bevat de eisen die gesteld worden aan POS (Point Of Sale) apparaten, betaalautomaten (ATM) en onbemande PIN-pads.

3.2.2. De standaard De PCI-DSS standaard (bron: [17], [18], [19] en [20]) richt zich op de beveiliging van betaalgegevens (debet- en credit kaart) en omvat een raamwerk dat een robuust en veilig betalingsproces borgt.

Alle systemen (netwerk componenten, servers, applicaties), mensen, processen en technologieën die creditcardgegevens2 verwerken, opslaan of verzenden behoren tot de Cardholder Data Environment (CDE) en vallen onder de scope van PCI-DSS.

Daarnaast zijn alle systemen die direct gebonden zijn aan CDE omgeving van invloed op de beveiliging van de kaarthoudersystemen en vallen derhalve dan ook binnen de scope van PCIDSS. Voor de beveiliging van een betalingsproces zijn zowel preventieve, detective als correctieve eisen gesteld. De eisen zijn grote deels van technische aard, maar omvatten ook organisatorische en procedurele eisen.

De PCI-DSS standaard bestaat uit twaalf hoofdrequirements. Elk requirement is weer opgedeeld in subrequirements. De opzet van de standaard is dat de beveiliging van het 2

Creditkaart gegevens kunnen als volgt worden ingedeeld: Kaarthouder gegevens

Gevoelige authenticatie data

Kaartnummer (Primary Account Number (PAN) ) Tenaamstelling creditkaart Service Code Vervallen

Data op de magneet strip Verificatie codes/waarden PIN

21


betalingsproces gelaagd is door verschillende methodes, ook wel defence in depth genoemd. Hierdoor zal een beveiligingslek in een laag niet direct tot een data breach leiden. De twaalf hoofdrequirements kunnen als volgt schematisch worden weergegeven:

Requirement 12: (Maintain an information Security Policy)

Requirement 5, 6 & 11: (Vulnerability management program)

Requirement 2: (Configuratie management)

Requirement 7,8 & 9: (Implement strong access control measures)

Scope PCI-DSS

Internet Protect transmitted CHD (Requirement 4)

Web/application server

Webapplicatie Auditlog Database Track and monitor all access to network resources and CHD (Requirement 10)

Protect stored CHD (Requirement 3)

Data Install and maintain firewall configuration (Requirement 1)

Protect stored CHD (Requirement 3)

Cardholder Data Environment (CDE)

Figuur 4: Overzicht Requirements PCI-DSS

De eerste stap in het beveiligen van creditkaartgegevens is het beschermen van de data bij de opslag (requirement 3: Protect stored CHD). Beschermingsmethoden zoals encryptie, truncatie3, maskeren4 en hashing5 dienen hiervoor gebruikt te worden. 3

Truncatie: Een methode om een segment van de data permanent onleesbaar te maken door een deel te

4

verwijderen. Denk hierbij bijvoorbeeld aan de middelste 8 cijfers worden vervangen door een ‘x’. Maskeren: Een methode om een segment van data tijdelijk te verbergen wanneer deze wordt

5

weergegeven of afgedrukt. Hashing: Het omzetten van gegevens in een onleesbare string met een vaste lengte dat niet herleidbaar is naar de originele data.

22


Requirement 3: Protect stored CHD Policy:  De bewaartermijn van de data moet tot een minimum worden beperkt. Hierbij dient rekening te worden gehouden met weten regelgeving en de eisen uit de business.  Gevoelige authenticatie data2 mag niet worden bewaard na autorisatie.  Bescherm het kaartnummer als het wordt getoond.  Kaartnummer dient onleesbaar te zijn indien het bewaard wordt. Procedure: Processen en procedures dienen aanwezig te zijn voor:  Het verwijderen van data nadat de bewaartermijn is verstreken.  Key management voor de crypto grafische sleutels. Technisch:  Kaartnummers kunnen onleesbaar worden opgeslagen door gebruik te maken van truncatie3, maskeren4, hashing5 of sterke cryptografie.  Kaarthouder data opslag door middel van applicatie, database (tabel- of kolomlevel6), file of disk encryptie.

De creditkaart gegevens worden van en naar verschillende systemen verzonden. Voor het beveiligen van de gegevens dient ten eerste een veilig netwerk te worden opgezet (Requirement 1: Install and maintain firewall configuration). Dit betekent dat, met behulp van firewalls, het verkeer van onveilige netwerken (internet) naar het eigen netwerk wordt gecontroleerd en eventueel geblokkeerd indien het niet voldoet aan de beveiligingseisen.

Requirement 1: Install and maintain firewall configuration Policy:  Verplicht installatie van een persoonlijke firewall op elk systeem dat door de werknemer wordt gebruikt om toegang te krijgen tot het bedrijfsnetwerk.  Verplicht installatie van een firewall en verbied directe toegang van internet tot kaartgegevens. Procedure: Processen en procedures dienen aanwezig te zijn voor:  Rechtvaardiging van de business voor alle openstaande services, protocollen en poorten.  Testen en goedkeuren van alle wijzigingen van de netwerkverbindingen.  Reviewen van de netwerkverbindingen.  Identity en Access Management van netwerkcomponenten. 6

Kolomlevel encryptie is een database encryptie waarbij één of meerdere specifieke kolommen in de database worden geëncrypt.

23


Technisch:  Implementeer firewalls tussen elke internet verbindingen, De-Militarized Zone (DMZ)7, wireless netwerk en het interne netwerk.  Beperkt de toegang van en naar de CDE omgeving.  Beveilig en synchroniseer router configuratie files.  Interne IP adressen en routing informatie van het interne netwerk mogen niet publiek worden gemaakt (door gebruik te maken van onder andere Netwerk Address Translation (NAT), proxy servers, verwijderen van router informatie).  Actueel netwerk diagram met alle connecties naar de CDE omgeving, inclusief alle wireless connecties.  Plaats systemen die kaartgegevens opslaan in een intern netwerk zone gescheiden van de DMZ en andere onveilige netwerken.  Implementeren van stateful inspection firewall8.

Daarnaast dient het eigen netwerk verdeeld te zijn in verschillende segmenten, waardoor voorkomen kan worden dat bij het compromitteren van één onderdeel van het netwerk het hele netwerk gecompromitteerd wordt. Internet facing applicaties zullen bijvoorbeeld in een DeMilitarized Zone (DMZ) staan, terwijl credit card gegevens weer in een intern CDE segment worden opgeslagen zonder directe toegang tot de onveilige netwerken. Elk segment heeft zijn eigen beveiligingseisen en alleen als voldaan wordt aan de eisen zal verkeer worden toegelaten van het ene segment naar het andere segment. De data die over de onveilige netwerken c.q. internet wordt verstuurd dient beschermd te worden (Requirement 4: Protect transmitted CHD). Beschermingsmethoden zoals die bij requirement 3 worden genoemd kunnen hiervoor gebruikt worden.

Requirement 4: Protect transmitted CHD Policy:  Bescherm kaartnummers als ze via de eindgebruiker worden verstuurd (door middel van web, email, chat, instant messaging, etc.).  Bescherm kaartnummers als ze via (wireless) internet worden verstuurd (door middel van SSL, VPN) Procedure: 7

DMZ is een vorm van segmenteren en wordt gebruikt als ontkoppelpunt voor verkeer tussen een

vertrouwd en een minder vertrouwd netwerk (bron: [33]). DMZ heeft als doel te voorkomen dat bij compromitteren van één onderdeel van het netwerk zich zal verspreiden naar andere onderdelen. 8 Stateful inspection is een filtering mechanisme door de firewall waarbij van al het netwerk verkeer informatie over de sessies en het protocol wordt bijgehouden en daarmee gefundeerde beslissingen neemt over de verkeerstromen(bron: [22] en [23]).

24




Beveiligingsbewustwording: Er dient gezorgd te worden dat medewerkers geen kaartgegevens versturen.

Technisch  Gebruik beveiligingsprotocollen (SSL/TLS, IPSEC, SSH) en sterke encryptie voor de beveiliging van de kaartgegevens voor het transport over open en publieke netwerken9.

In het CDE segment zal naast de beveiliging van de kritische data ook de toegang tot de data (Identity en Access Management) moeten worden beveiligd. Het Identity en Access Management (Requirement 7,8 & 9: Implement strong access control measures) betreft zowel de logische als fysieke toegangsbeveiliging. De systemen en processen voor het Identity en Access Management dienen aanwezig te zijn. De toegang tot kaarthouder data dient gelimiteerd te zijn en alleen toegankelijk op basis need-to-know en de uit te voeren functie.

Requirement 7, 8 & 9: Implement Strong Access Control Measures Policy:  De fysieke en logische toegang tot data en systemen is op basis van minimale toegang, gebaseerd op de principes least privileges en need-to-know (rol gebaseerd toegang).  Bezoekers dienen geregistreerd te zijn en mogen niet onbegeleid toegang hebben tot de beveiligde omgevingen.  Media dient vernietigd te worden indien het niet meer wordt gebruikt. De vernietiging dient zo te worden uitgevoerd dat het niet meer mogelijk is om de data op de media te reconstrueren. Procedure: Processen en procedures dienen aanwezig te zijn voor:  De beperking van de fysieke toegang tot de systemen in de CDE omgeving inclusief netwerken, wireless access points, gateways etc.  Identity en Access Management, waarbij speciale aandacht op: - Gedocumenteerde goedkeuring voor alle accounts met speciale rechten. - Verifieer de gebruiker bij een password reset. - Controle op toegang, wijziging en verwijdering van account en toegang. - Onmiddellijke intrekking van rechten bij uitdiensttreding. - Accounts voor de leverancier staan altijd uitgeschakeld en mogen alleen worden ingeschakeld bij onderhoud. Echter dan dienen ze wel gemonitord te worden. - Verwijder of inactiveer accounts die langer dan 90 dagen niet zijn gebruikt.  Bewaren en vernietigen van media.

9

Open en publieke netwerken zijn bijvoorbeeld het internet, wireless netwerk, mobile netwerk.

25


Technisch:  Alle systemen moeten gebruik maken van toegangscontrole.  De toegang tot de systemen wordt toegekend aan individuen, niet aan groepen.  Elke gebruiker heeft een eigen unieke account (de verstrekte toegang moet herleidbaar zijn naar één persoon).  Authenticatie van alle gebruikers gaat op basis van two-factor: dat je iets weet (wachtwoord), en dat je iets hebt (smartcard, token) of dat je iets bent (biometrie).  Indien gebruik wordt gemaakt van remote toegang, zal de authenticatie methode tenminste two-factor moeten zijn.  Alle wachtwoorden dienen versleuteld(sterke versleuteling) te zijn tijdens transport en opslag.  Wachtwoorden dienen te voldoen aan de minimaal opgestelde eisen.  Weiger de toegang als meer dan 6 pogingen zijn gedaan om in te loggen door het account te blokkeren.  Fysieke toegang: - gebruik video camera’s en/of controle mechanismes om de toegang te registreren.

Door alle activiteiten die betrekking hebben op de toegang van de kritische data te loggen (Requirement 10: Track and monitor all acces to network resources and CHD) kan inzicht worden gekregen in welke activiteiten in de CDE omgeving, door wie en op welk moment, zijn uitgevoerd (de audittrail van de uitgevoerde activiteiten). PCI-DSS verplicht dat tenminste alle toegang tot de credit kaart data moet worden gelogd en dat de activiteiten terug te herleiden moeten zijn naar een individu.

Daarnaast dient de audittrail dagelijks gecontroleerd te worden. Het is hierdoor mogelijk om het compromitteren van data in een zo vroeg mogelijk stadium te ontdekken en de impact te minimaliseren.

Requirement 10: Track and monitor all access to network resources and CHD Policy:  De bewaartermijn van de audittrail dient tenminste een jaar beschikbaar te zijn, waarbij ten minste 3 maanden direct online beschikbaar. Hiernaast dient rekening te worden gehouden met weten regelgeving en de eisen van de business. Procedure: Processen en procedures dienen aanwezig te zijn voor:  Het samenvoegen van logging betreffende de toegang tot alle systemen.  Het monitoren van alle toegang tot de netwerk resources en CDE omgeving.

26


Technisch:  Alle systemen dienen een audittrail te genereren waarin wordt vermeld wie welke actie op welk tijdstip uitvoerde.  Gebruik tijd synchronisatie op alle systemen om de klokken en tijden te synchroniseren.  Beveilig de audittrail zodat deze niet ongeautoriseerd gewijzigd kan worden. Dit is te realiseren door beperkte toegang, file-integrity monitoring10 en centralisering van de logging.

Voor alle systemen die in de scope van PCI zijn, dient het configuratie management (requirement 2: Configuration management) te zijn ingericht. Deze eis zorgt ervoor dat een systeem gehardened11 wordt en op een gestandaardiseerde wijze in productie wordt gebracht.

Requirement 2: Configuration management Policy:  Alle systemen dienen volgens een vaste beschreven wijze te zijn ingericht. Procedure: Processen en procedures dienen aanwezig te zijn voor:  Configuratie management. Technisch:  Configuratiestandaard die voldoet aan de industrie standaard en waarbij het systeem is gehardened11.  Wijzig de systeem instellingen die door de leverancier default zijn gezet, zoals account, wachtwoorden, netwerk management protocollen, wireless instellingen.  Implementeer een primaire functie per server.  Zorg dat alleen de noodzakelijke services en protocollen worden aangezet.  Verwijder alle onnodige functionaliteit en functionaliteit die niet gebruikt wordt.  Encrypt alle non-console beheerderstoegang middels sterke cryptologie (SSH, VPN of SSL/TLS).

Om kwetsbaarheden in zowel de CDE omgeving als alle direct verbonden systemen te voorkomen en tijdig te detecteren c.q. acties te ondernemen, worden eisen gesteld aan het vulnerability management proces. Onder vulnerability management wordt verstaan alle processen die ervoor zorgen dat kwetsbaarheden tijdig worden ontdekt en opgelost. Gedacht

10

11

File-integrity monitoring is het proces dat ongeautoriseerde wijzigingen in system settings en files detecteert. Systeem hardening: een stapsgewijs proces van veilig configureren van systemen en het treffen van maatregelen om de betrouwbaarheid van het systeem te borgen en het systeem te beschermen tegen onbevoegde toegang.

27


kan worden aan een antivirus beleid (Requirement 5), het patch management, change management proces (Requirement 6) en het periodiek testen van security en processen door middel van interne/externe vulnerability en penetratie testen (Requirement 11). Het vulnerability management proces zal borgen dat systemen na in productie name continue betrouwbaar en veilig zijn.

Requirement 5 & 6: Maintain a Vulnerability Management Program Policy:  Antivirus software dient te worden geïnstalleerd op alle systemen en deze moet actief en up-todate te zijn. Procedure: Processen en procedures dienen aanwezig te zijn voor:  Patchen, het identificeren en bepalen van de risico’s voor nieuw ontdekte kwetsbaarheden.  Software ontwikkeling en het reviewen van de software code voordat het in productie gaat.  Change control en fall-back procedures. Technisch:  Antivirus: - Implementeer antivirus software op alle systemen en zorg dat updates automatisch worden geïnstalleerd en periodieke scans worden uitgevoerd. - Antivirus moet alle bekende typen malicious software kunnen detecteren, verwijderen en beschermen. - Antivirus software genereert logging en wordt bewaard volgens de bewaartermijn.  Patchen: - Installeer de nieuwste beveiligingspatches van de leverancier zodat alle systemen beschermd zijn tegen bekende kwetsbaarheden. - Kritische security patches dienen binnen 30 dagen na release van de leverancier te zijn geïnstalleerd.  Software ontwikkeling: - Ontwikkeling van software gebaseerd op industrie standaarden en secure coding richtlijnen (bijvoorbeeld OWASP).  Change control: - Gescheiden Ontwikkel-, Test-, Acceptatie- en Productie omgeving. - Productie data wordt niet gebruikt voor test doeleinden. - Verwijderen van test data en test accounts voordat systeem in productie wordt gebracht.

28


Requirement 11: Regular test security systems and processes Policy:  Alle productie en acceptatie systemen moeten regelmatig getest worden. Procedure: Processen en procedures dienen aanwezig te zijn voor:  Het detecteren en identificeren van wireless access points.  Het uitvoeren van interne en externe vulnerability scans12.  Het uitvoeren van interne en externe penetratie testen13.  Intrusion detection en/of intrusion protection systemen14.  File-integrity monitoring10. Technisch:  Implementeren van Intrusion detection en/of intrusion protection systemen  Implementeren van File Integrity Monitoring  Implementeren van Vulnerability scanning

Alle bovenstaande beschreven requirements zijn voornamelijk technisch en procedureel. Echter om beveiliging goed in te bedden, zal dit vanuit de organisatie moeten worden vastgelegd in het beleid en worden uitgedragen zodat elke medewerker bewust wordt van het gebruik van kritische data en de verantwoordelijkheden die hierbij horen. De laatste requirement van PCI-DSS, Requirement 12, stelt de eis dat een beveiligingspolicy aanwezig is en deze ook wordt uitgedragen.

Requirement 12: Maintain an information security policy Policy:  Aanwezigheid van een informatie security policy.  Gebruik van kritieke technologieën, zoals remote toegang, wireless, verwijderbare media, laptop, e-mail, internet etc.  De informatie beveiligingsverantwoordelijkheden zijn beschreven.  De verantwoordelijkheden van elk medewerker staan beschreven. 12

Vulnerability scan is het identificeren van potentiele kwetsbaarheden in netwerk-apparaten, servers en

applicaties. De externe scan identificeert de risico’s vanuit het internet. De interne scan zal vanuit het interne netwerk controleren op kwetsbaarheden. 13 Penetratie test tracht aan de hand van de resultaten van de vulnerability scan de geïdentificeerde kwetsbaarheden uit te buiten en daarmee de netwerk-apparaten, servers en applicaties te compromitteren. 14 Intrusion detection systeem is een geautomatiseerd systeem dat ongeautoriseerde toegang tot een informatiesysteem of netwerkt detecteert. Intrusion prevention systeem is een intrusion detection systeem die daarnaast in staat is om actief inbraken die gedetecteerd worden, te blokkeren en daardoor te voorkomen.

29




Outsourcen.

Procedure: Processen en procedures dienen aanwezig te zijn voor:  Het opstellen, publiceren, onderhouden en verspreiden van de informatie security policy, waarin onder andere de PCI-DSS requirements zijn ondergebracht.  Risico analyse.  Dagelijkse procedures bij alle teams die de informatie security policy borgt.  Gebruik van technologieën.  Security awareness trainingen.  Screening van (toekomstig) personeel.  Het managen van Service providers.  Incident response. Technisch:  -

3.2.3. Assessment en non-compliance De PCI-DSS standaard is een norm die opgelegd is door de PCI Council. De PCI Council eist van de aangesloten organisaties (winkelier, Acquiring bank, Issuing bank en Clearinghuis) dat een PCI-DSS assessment plaatsvindt. Het type assessment is afhankelijk van uitgever van de kaart en de hoeveelheid transacties die worden verwerkt. In onderstaande tabel worden de voorwaarden weergegeven.

Type

Aantal transacties per jaar >6.000.000

Verplichte Assessment

2

>1.000.000 – <6.000.000

 

3

>20.000 - <1.000.000

 

4

<20.000



1

 

Jaarlijkse onsite assessment & Per kwartaal externe vulnerability scan Self-assessment & Per kwartaal externe vulnerability scan Self-assessment & Per kwartaal externe vulnerability scan Optioneel self-assessment

30


Indien niet wordt voldaan aan de assessment eisen, zal de organisatie een boete worden opgelegd. Het bedrag is afhankelijk van uitgever van de kaart, het type organisatie en hoe vaak de overtreding plaatsvindt.

In het geval van een breach wordt eerst bepaald of de PCI-DSS regelgeving is nageleefd. De getroffen organisatie moet kunnen aantonen dat op het moment van de breach de organisatie compliant was. De organisatie dient het bewijs van compliance aan te leveren over de periode voor de compromittering. Indien aangetoond kan worden dat de organisatie compliant was tijdens deze periode, zal de aangesloten organisatie geen sancties opgelegd krijgen en worden de kosten die voortvloeien uit de breach genomen door de creditcardmaatschappijen. In het geval dat niet aangetoond kan worden dat de aangesloten organisatie compliant was, zullen sancties worden opgelegd. Bijvoorbeeld voor een type 1 organisaties kunnen deze sancties zijn: 

Boete van $5 per gecompromitteerd kaartnummer;



Compromis honorarium van $100.00 per incident;



Aansprakelijkheid voor alle fraude verliezen van gecompromitteerde rekeningnummers;



Aansprakelijkheid voor de kosten van her-uitgifte van de kaart;



Restricties of permanent verbod voor aansluiting van de organisatie op netwerken van de PCI Council members (American Express, Discover, JCB, MasterCard en Visa).

31


4. Continue monitoring, auditing & assurance In de literatuur (bron: [27], [28], [30] en [31]) is veel geschreven over continue monitoring/auditing. De invoering hiervan blijkt in de praktijk nog minimaal te zijn. Uit het onderzoek van KMPG (bron: [27]) blijkt dat slechts drie procent van de ondervraagde organisaties uit diverse sectoren continue monitoring/auditing geïmplementeerd hebben.

Uit ervaringen in de financiële sector blijkt dat veel initiatieven worden genomen om zowel continue monitoring als continue auditing te implementeren. Echter dit zijn vaak initiatieven die uitsluitend technisch gedreven zijn en worden organisatorische en procedurele eisen, die gesteld worden door weten regelgeving, achterwege gelaten. Hierdoor zijn de processen voor het continue monitoring en continue auditing veelal slecht geïmplementeerd.

In de eerste paragraaf worden de definities van de concepten continue monitoring, continue auditing en continue assurance beschreven. Daarnaast wordt in deze paragraaf weergegeven wat de samenhang is tussen de verschillende concepten. In paragraaf Frequentie van continue wordt de definitie van continue beschreven en welke factoren bepalend zijn voor de frequentie van continue. Het continue monitoring proces is van primair belang voor het continue compliant houden van de technische infrastructuur. In de laatste paragraaf wordt dit proces beschreven.

4.1. Begrippen en samenhang In de literatuur (bron: [27], [28], [30] en [31]) wordt voor de beheersing van de bedrijfsprocessen vaak over een drietal concepten gesproken die nauw verbonden zijn met elkaar. Deze concepten zijn: continue monitoring, continue auditing en continue assurance.

Continue monitoring is een techniek en werkwijze om frequent/continue vast te stellen of de IT-systemen, processen en procedures functioneren zoals ze gedefinieerd zijn in de beheersingsmaatregelen. Het doel van continue monitoring is het snel en tijdig inzicht krijgen in afwijkingen en non compliance.

32


Continue auditing richt zich op frequente /continue controle activiteiten om bewijslast en indicatoren uit IT-systemen, processen en beheersingsmaatregelen te verkrijgen, met als doel sneller en tijdig inzicht te krijgen in de risico’s en controles.

Het verschil tussen deze twee concepten zit voornamelijk in de laag van de organisatie waarop de controle wordt uitgevoerd en daarbij de detaillering van de controle. Continue monitoring is voornamelijk een operationele aangelegenheid en een verantwoordelijkheid van management. Terwijl continue auditing juist op tactisch niveau wordt uitgevoerd door de interne audit afdeling. De processen zijn nauw met elkaar verbonden, omdat de mate waarop de continue monitoring is ingericht invloed heeft op de inspanning die nodig is voor het continue auditen om tot dezelfde mate van continue zekerheid te komen. De inspanning die moet worden geleverd door de audit afdeling is sterk afhankelijk van de mate waarop het continue monitoringsproces is ingericht en de bewijslast die hieruit al beschikbaar is. Dit is visueel weergegeven in onderstaand figuur.

Hoge mate van Continue Monitoring Minder werkzaamheden

Weinig continue monitoring

Significante hoeveelheid werkzaamheden

Figuur 5: Spanningsveld continue monitoring  continue auditing Continue Assurance geeft op een continue basis zekerheid over de beheersing van risico’s en de werking van de beheersingsmaatregelen. Assurance wordt afgegeven door de interne audit afdeling. Continue Assurance kan verkregen worden door continue monitoring en/of continue auditing in te richten, de mogelijke inrichtingen zijn: 

Continue auditing: De interne audit afdeling zal continue gedetailleerde testen moeten uitvoeren om te bepalen of het bestaan en de werking van de beheersingsmaatregelen voldoen.

33




Continue monitoring: Het management zorgt ervoor dat de beheersingsmaatregelen continue worden gemonitord en de afwijkingen worden gemanaged. Bewijslast van het continue monitoring proces wordt opgeslagen en de resultaten zijn geschikt voor het continue auditing proces. De interne audit afdeling zal periodiek audits uitvoeren om te bepalen of vertrouwd kan worden op het continue monitoring proces. Daarnaast zal de interne audit afdeling de gedetecteerde afwijkingen uit het continue monitoring proces en de reactie van het management hierop reviewen.



Continue monitoring & Continue auditing: De resultaten van het continue monitoring proces dienen beschikbaar te zijn voor het continue auditing proces. Echter de interne audit afdeling zal steekproefsgewijs de beheersingsmaatregelen auditen. De werkzaamheden voor de interne audit afdeling zal aanzienlijk afnemen in vergelijking met de andere twee inrichtingen.

Bovengenoemde inrichtingen kunnen visueel als volgt worden weergegeven: Continuous Assurance

Audit

Results

Management

Audit testing of CM

Continuous Monitoring & Contintue auditing Continuous Monitoring

Continuous Auditing Activities, transactions and Events Business Systems & processes

Figuur 6: Continue monitoring, auditing & assurance

4.2. Frequentie van continue De definitie van continue in het Nederlandse woordenboek wordt anders geïnterpreteerd dan continue in het continue monitoring/auditing proces. In het woordenboek wordt continue gedefinieerd als onafgebroken, ononderbroken in de tijd, volgorde, inhoud of omvang. In het

34


continue monitoring/auditing proces wordt het woord continue vertaald als met een bepaalde frequentie, waarbij de frequentie afhankelijk is van bepaalde factoren, te weten: 

De classificatie van het bedrijfsproces/activiteit;



De impact van een foutieve waarde;



Aantal personen dat paramaters kan aanpassen;



De verplichtingen voortkomend uit de weten regelgeving;



De effectiviteit en efficiency.

De frequentie van monitoring wordt meestal gezamenlijk door het management en de interne audit afdeling bepaald. Aan de hand van de factoren en de risico’s wordt de frequentie vastgesteld.

4.3. Continue monitoring proces Het proces om continue monitoring in te richten kan afgeleid worden uit het Risk Management Framework zoals beschreven is NIST (SP 800-37). Dit proces heet de Security Life Cycle en bestaat uit de volgende stappen: 

Classificeer het information Systeem In dit proces wordt het systeem geclassificeerd op basis van de Beschikbaarheid, Integriteit en Vertrouwelijkheid (BIV). De classificatie wordt op basis van de architectuur en de impact van de business bepaald.



Selecteer de security controles Aan de hand van de classificatie wordt de security baseline vastgesteld die voldoet aan het beleid van de organisatie. In een security baseline wordt aangegeven welke maatregelen worden genomen om te voldoen aan de eisen die gesteld worden door de architectuur en business op basis van de classificatie van het informatie



Implementeer de security controles

35




Audit de security controles Bepaal de effectiviteit van de controles, zoals: zijn de controles correct geïmplementeerd, werken ze zoals ze bedoeld zijn en voldoet de controle aan de gestelde eisen.



Goedkeuring informatie systeem Bepaal de organisatorische en operationele risico’s na de genomen security controles. Als deze geaccepteerd worden, kunnen de genomen security controles worden goedgekeurd.



Monitor de security controles Operationeel wordt continue gecontroleerd of de security controles nog werken zoals deze oorspronkelijk opgezet en geïmplementeerd zijn. Op tactisch niveau wordt periodiek en na wijziging bepaald of de geïmplementeerde security controles nog voldoende het risico afdekken en voldoen aan de classificatie van het informatie systeem.

ARCHITECTUUR.

BUSINESS Wet- en regelgeving, policy, strategie, missie, doelen etc

1. CLASSIFICEER Informatie Systeem

6. MONITOR Security Controles

2. SELECTEER Security controles

5. GOEDKEURING Informatie Systeem

3. IMPLEMENTEER Security controles

4. AUDIT Security controles

Figuur 7: Continue monitoring proces

36


5. Bevindingen theoretisch onderzoek beheersmaatregelen In dit hoofdstuk worden de beheersmaatregelen beschreven die de inrichting van een continue compliant infrastructuur kunnen borgen. De beheersmaatregelen zijn bepaald op basis van de literatuur. In het volgende hoofdstuk wordt de theorie gevalideerd met de praktijk.

5.1. Beheersmaatregel: Inrichting infrastructuur De technische infrastructuur wordt gedefinieerd als het geheel van technologische componenten, systeem- en toepassingssoftware, procedures en documentatie die nodig zijn voor het beschikbaar stellen van een of meerdere informatiesystemen (ITIL). De componenten zijn (bron: [34]): 

Verwerkingsapparatuur c.q. infrastructuur verwerkingssystemen De apparatuur en de programmatuur die nodig zijn om de toepassingen te laten functioneren. Dit betreft de hardware, operating system en virtuele machine.



Opslagapparatuur c.q. infrastructuur opslagsystemen De apparatuur en programmatuur die nodig zijn om de gegevensverzamelingen op te slaan, zoals storage (SAN/NAS, e.d.), databases (en het daarbij behorende databasemanagementsysteem) en andere middleware voor de koppeling van verschillende computerplatformen en applicaties.



Communicatie- of netwerkinfrastructuur De communicatieverbindingen tussen verwerkingsapparatuur onderling en tussen verwerkingsapparatuur en opslagapparatuur.



Organisatie-infrastructuur Het beleid, processen, procedures en werkinstructies die nodig zijn voor de inrichting en beheer van de technische infrastructuur.

37


De inrichting van de componenten van de technische infrastructuur is afhankelijk van de classificatie van de data en de daarbij behorende beveiligingseisen. Als eerste dient de infrastructuur van de verwerkings- en opslagsystemen te worden ingericht. Dit is gebaseerd op de architectuur van de netwerk infrastructuur en de eisen van weten regelgeving.

Voor de inrichting van het netwerk (bron: [36] en [17]) kan gebruik gemaakt worden van zowel zonering als segmentering. Bij zonering wordt door het netwerk de data beveiligd middels verschillende lagen van bescherming, die zowel netwerk- als logische beveiligingsmaatregelen bevatten. De verschillende zones zijn gebaseerd op de classificatie van de vertrouwelijkheid en integriteit van data.

Het is noodzakelijk dat de data eerst geclassificeerd dient te worden op basis van het beleid van de organisatie. Aan de hand van de classificatie van de data kan bepaald worden in welke zone de data geplaatst dient te worden. Data met het classificatie label “vertrouwelijk”, dit is de daadwerkelijke business data, wordt in de kern - de data zone - geplaatst. Het is alleen mogelijk deze data te benaderen via de applicatie zone. De applicatie zone is lager geclassificeerd, meestal met het classificatie label “intern”. In deze zone bevinden zich onder andere de interne data en applicaties. De laagste geclassificeerde zone, gelabeld “publiek”, wordt de presentatie zone genoemd. Hierin staan de webservers die de buitenwereld toegang geven tot het bedrijfsnetwerk.

Het netwerk is dus verdeeld in drie zones. Tussen deze zones zitten firewalls om deze te beschermen. Binnen een zone is vrij verkeer toegestaan Door de firewalls is het niet mogelijk om direct toegang te krijgen tot een zone die niet direct aan de eigen zone grenst. De externe zone kan alleen toegang krijgen tot het bedrijfsnetwerk via de presentatie zone. Het is dus niet mogelijk om via de externe zone direct toegang te krijgen naar de diepere zones (applicatie en data zone). Zie grijze pijlen in figuur 8.

38


Externe zone Presentatie zone Applicatie zone Data zone Database Appli c

e r ve File S

ation

r

DMZ

Internet

Figuur 8: Zone model

Naast het gebruik van het zone model wordt het netwerk vaak gesegmenteerd. Een segment is een verfijning van het zone model en beschermt een specifieke groep van data over zones heen. Een segment kan gezien worden als een aparte netwerk omgeving in het gehele netwerk. Indien in een zone een specifieke groep van data wordt gecreëerd, wordt dit een intern segment genoemd (zie figuur 9).

Externe zone Presentatie zone Applicatie zone Data zone e gm Se

nt

Intern segment

Figuur 9: Segmentatie

39


Het segment wordt meestal gescheiden door firewalls. Het is ook mogelijk om te scheiden door middel van routers en strikte Access Lists, maar voor consistentie, eenduidigheid en robuustheid gaat de voorkeur uit naar firewalls.

Vanuit het PCI-DSS oogpunt is het van belang dat de kaarthouder data beschermd wordt. De technische infrastructuur waarop kaarthouder data wordt verwerkt, opgeslagen of verzonden wordt vaak door middel van een segment gescheiden van andere business processen.

De componenten van de technische infrastructuur, te weten de infrastructuur verwerkingssystemen en de infrastructuur opslagsystemen, dienen te worden geplaatst in het segment en de zones zoals bepaald is in de classificatie, waardoor een PCI segment ontstaat.

Voor de inrichting van de organisatorische infrastructuur dient niet alleen de architectuur (zoals hierboven beschreven), maar ook het beleid (zie paragraaf 4.3 ´Selecteer de security controles´) als input gebruikt te worden. In het beleid zullen de weten regelgevingen, zoals de eisen van PCI-DSS, ISEA 3402, DNB, geïntegreerd moeten zijn. Gezien het beleid de eisen slechts generiek beschrijft, dienen deze eisen te worden uitgewerkt in een security baseline. Een security baseline geeft per classificatie niveau aan welke eisen en controles minimaal gesteld worden aan de beveiliging om te voldoen aan het beleid. Voor de uiteindelijke inrichting van de componenten van de technische infrastructuur is de configuratiestandaard de basis. De configuratiestandaard is gebaseerd op de security baseline, de best practices en de hardening.

Om een component van de technische infrastructuur te kunnen implementeren dient een installatiehandleiding beschikbaar te zijn. Een installatiehandleiding is een vertaling van de configuratiestandaard naar de daadwerkelijke instellingen van het component inclusief de best practices en hardening.

Om van de inrichting naar de implementatie en vervolgens beheer te gaan, dienen de ITIL processen, zoals change-/releasemanagement, configuratie management, Identity & Access

40


Management ingericht te zijn. Hiervoor zullen zowel de proces/procedure beschrijvingen als de werkinstructies aanwezig moeten zijn.

Bij een dergelijke inrichting, zoals hiervoor beschreven, wordt een technische infrastructuur neergezet die is opgezet volgens de architectuur en het beleid van de organisatie en behouden wordt door gebruik te maken van de ITIL processen.

5.2. Beheersmaatregel: Inrichting continue compliance Zodra continue assurance moet worden afgeven, dient een continue compliance proces te worden ingericht. De wijze waarop compliance verankerd wordt in de organisatie is van strategisch belang. Dit betekent dat de doelstelling van compliance en de wijze waarop de compliance organisatie wordt vormgegeven, door de top van de organisatie moet worden gedragen. Deze “Tone at the top” is van essentieel belang om het bewustzijn van de rest van de organisatie te bewerkstelligen en ervoor te zorgen dat ook zij zich binden aan de vastgelegde verantwoordelijkheden.

Voor de inrichting van het continue compliance proces zullen tenminste de volgende bedrijfsonderdelen betrokken moeten zijn: het bestuur, de business units, de compliance organisatie en de audit organisatie. Voor elk bedrijfsonderdeel zal de kwaliteitscirkel van Deming15 moeten worden ingericht.

Om efficiëntie en effectiviteit te bewerkstelligen wordt het bedrijfsonderdeel compliance vaak geïntegreerd in de normale bedrijfsvoering en wordt dit belegd in de business units en het audit onderdeel. Naast de borging van de kwaliteitscirkel van Deming per bedrijfsonderdeel, is het van belang dat de kwaliteitscirkel van Deming ook op organisatorisch niveau geborgd wordt (zie figuur 10).

15

De kwaliteitscirkel van Deming is een hulpmiddel voor kwaliteitsmanagement en ontwikkeld door William Edwards Deming. De cirkel beschrijft vier activiteiten die op alle verbeteringen in organisaties van toepassing zijn. De vier activiteiten zorgen voor een betere kwaliteit. Het cyclische karakter garandeert dat de kwaliteitsverbetering continue onder de aandacht is. De vier activiteiten van Deming zijn: Plan, Do, Check en Act.

41


Bestuur

Business Unit Compliance

Compliance

Audit Compliance

Figuur 10: Organisatorische inrichting continue compliance proces

Het bedrijfsonderdeel Bestuur is verantwoordelijk voor de borging van weten regelgeving in het beleid. Een continu proces zal moeten zekerstellen dat gewijzigde weten regelgeving wordt opgenomen in het beleid en maatregelen worden genomen. Voor de business units zal het continue monitoring proces volgens het Security Life Cycle (paragraaf 4.3) moeten worden ingericht. Monitoring van de gang van zaken met betrekking tot compliance is essentieel om (tijdig) compliance problemen te kunnen signaleren. De informatiebronnen die hiervoor gebruikt worden, zijn de bewijslast en incidenten. Aan de hand van de informatiebronnen wordt informatie verstrekt over de werking van de maatregelen en kan leiden tot noodzakelijke bijsturing.

Het bedrijfsonderdeel Audit zal het continue auditing proces borgen waarmee inzicht gegeven kan worden in: 

De beheersing en verankering van de compliance op strategisch niveau. Hieronder valt tevens de verankering van compliance binnen de gehele organisatie.



De resultaten en de uitvoering van compliance onderzoeken en audits op basis van de resultaten uit het continue monitoring proces.

Het is van belang dat op elk bedrijfsonderdeel en organisatorisch niveau de kwaliteitscirkel van Deming wordt nageleefd. Pas dan zal efficiency en effectiviteit worden verkregen uit het continue compliance proces. Indien dit niet geborgd is kan geen inzicht worden verkregen in de beheersing en verankering van de compliance op strategisch niveau en kan geen continue assurance worden afgegeven.

42


5.3. Beheersmaatregel: Inrichting continue monitoring van de technische infrastructuur Voor het inrichten van continue monitoring voor de technische infrastructuur componenten zouden per component de volgende stappen uitgevoerd moeten worden (bron: [33]): 

Bepaal de aard van de belangrijkste controles die moeten worden gemonitord

Voor continue monitoring zijn generiek voor PCI-DSS de volgende controles met betrekking tot de technische infrastructuur componenten belangrijk: Netwerk Management:  Zijn de netwerk diagrammen up-to-date.  Configuratiestandaarden van firewall en routers geïmplementeerd.  Review regels op de firewall, routers conform de ontwerp inrichting netwerk. Configuratie management:  Zijn de instellingen op de technische infrastructuur componenten conform de configuratiestandaard.  Is onnodig of ongebruikte functionaliteit uitgezet op de technische infrastructuur component.  Worden de bewaartermijn logging en data gehandhaafd. Identity & Access Management:  Zijn de rollen matrices up-to-date.  Zijn de autorisatie matrices up-to-date.  Wordt er geen gebruik gemaakt van groeps- of generieke accounts. Vulnerability en patch Management:  Is antivirus software op elk system beschikbaar, up-to-date en actief.  Zijn patches op tijd geïnstalleerd.  Worden nieuwe kwetsbaarheden gedetecteerd. Log, monitoring & alerting:  Wordt voor alle technische infrastructuur componenten de logging verzameld.  Kan logging niet worden onbevoegd worden gewijzigd.  Activiteiten waarop minimaal gemonitord/alert wordt. Het Security Information en Event Monitoring (SIEM).

43




Bepaal of een specifieke controle al dan niet wordt gemonitord Voor het dagelijks beheer worden veel controles al door de beheerder uitgevoerd. Bepaald dient te worden wat het verschil met de huidige controle is en welke controles eventueel moeten worden uitgebreid.



Bepaal de informatiebronnen die nodig zijn Bepaal aan de hand van de controle welke informatiebronnen geraadpleegd moeten worden om de controle te kunnen uitvoeren.



Bepaal welke bewijslast nodig is als output voor de controle. Bepaal welke bewijslast nodig is om aan te kunnen tonen dat voldaan wordt aan de eisen die opgesteld zijn. Daarnaast dient de bewijslast tenminste 1 jaar beschikbaar te zijn en de bewijslast mag niet gemanipuleerd kunnen worden.



Bepaal de frequentie van de controle De frequentie van controlemomenten is afhankelijk van verschillende factoren. Naast de factoren die genoemd zijn in paragraaf 4.2, is het raadzaam om tenminste twee keer zo zoveel als de weten regelgeving voorschrijft te controleren. Bij non-compliance kan dan nog tijdig gecorrigeerd worden, zodat op de wettelijke tijdstippen compliance kan worden aangetoond. Indien de gestelde eisen vaak non-compliant zijn, dient de controlefrequentie te worden aangescherpt zodat sneller ingegrepen kan worden. De laatste factor is de gemiddelde tijd, manuren, die nodig zijn om de controle uit te voeren. Handmatige controles zijn soms tijdrovend en daardoor kostbaar voor de organisatie. Indien de handmatige controles niet geautomatiseerd kunnen worden, kan ervoor gekozen worden om de controle minder vaak uit te voeren.



Bepaal de haalbaarheid van het gebruik van de geautomatiseerde tools In deze stap zal bepaald worden of de controle geautomatiseerd kan worden, door middel van scripting of tooling. Daarnaast kan het mogelijk zijn om één type tooling voor verschillende technisch infrastructuur componenten in te zetten. Het is niet altijd mogelijk om controles te automatiseren.

44




Bepaal welke rol de controle moet uitvoeren Bepaal aan de hand van functiescheiding welke rol de controle uitvoert om het tegengestelde belang, zoals beschreven is door Starreveld, te borgen.

Er zijn verschillende manieren om een controle uit te voeren. Generiek kunnen vier controles gedefinieerd worden: 

IT-inherente controles IT-inherente controles zijn door de leverancier ontworpen en ingebouwd. Ze kunnen niet gemakkelijk worden gewijzigd na de implementatie van het systeem.



IT-configureerbare controles Dit worden vaak de configuratie settings genoemd en zijn door de gebruiker te wijzigen en/of uit te schakelen zonder dat wijzigingen in de programmatuur nodig zijn.



Handmatige controle met gebruik van IT Dit zijn handmatige controles die met behulp van informatie verkregen uit een IT – toepassing worden uitgevoerd.



Handmatige controle

De verschillende controles hebben effect op de betrouwbaarheid van compliance en de effectiviteit van het proces. Handmatige controles zijn vaak tijdrovender dan controles die automatisch uitgevoerd worden. Daarnaast is de betrouwbaarheid bij het handmatig uitvoeren van een controle ook minder. Organisaties dienen een kosten/baten analyse te maken van de verschillende wijzen waarop een controle kan worden uitgevoerd. Hierbij dient rekening gehouden te worden met factoren zoals de frequentie van de controle, betrouwbaarheid, kosten tooling en de kans op non-compliance indien geen controle wordt uitgevoerd.

45


5.4. Beheersmaatregel: Bewijsvoering voor aantonen continue compliance Teneinde continue compliance te kunnen aantonen, dienen de opzet, bestaan en werking van het proces te zijn gedocumenteerd en dient de bewijslast beschikbaar te zijn. Voor dit onderdeel is voornamelijk gekeken naar de bewijsvoering waaruit blijkt dat aan alle eisen (die vanuit weten regelgeving worden gesteld) wordt voldaan. De bewijsvoering van het continue compliance proces is een onderdeel van de eisen die worden gesteld en daarom niet specifiek genoemd in het onderzoek.

De bewijsvoering van het continue compliance proces omvat: 

De bewijslast van de opzet;



De bewijslast van de compliance-eisen;



Borging van de processen en de opvolging van non-compliance problemen.

De documentatie met betrekking tot de processen, procedures, werkinstructies, installatiehandleidingen, configuratiestandaarden dient beschikbaar en up-to-date te zijn. Dit is de generieke bewijslast die nodig is voor het aantonen van compliance en niet specifiek hoeft te worden uitgebreid voor PCI-DSS.

De bewijslast die nodig is om aan te tonen dat voldaan wordt aan de gestelde eisen, dient te worden gespecificeerd. Het continue monitoring proces controleert specifiek hierop en de bewijslast hiervan dient te worden verzameld. De bewijslast kan in de tooling worden bewaard, maar het is ook mogelijk om rapportages, schermprintjes, email e.d. als bewijslast te gebruiken.

Als laatste dient bewijslast te worden verzameld dat de processen worden gevolgd. Hierbij kan bijvoorbeeld een lijst worden bijgehouden met daarin de dagelijkse taken die voor het uitvoeren van de processen zijn beschreven. In de lijst zijn de taken gedefinieerd en de medewerker die een taak heeft uitgevoerd tekent deze lijst af. Bij afwijkingen of non-

46


compliance kan bijvoorbeeld in de lijst tevens het incident of change nummer worden toegevoegd.

Een aandachtspunt bij de bewijslast zijn de bewaartermijnen. De bewaartermijn van de bewijslast is afhankelijk van de weten regelgeving en de eisen die gesteld worden vanuit de business. De weten regelgeving of business eisen die de langste termijn voorschrijft moet worden gevolgd. Het is mogelijk dat delen van de bewijslast al eerder kunnen worden vernietigd. Dit dient in het beleid te worden vastgelegd, zodat op een eenduidige wijze de bewijslast wordt bewaard.

47


6. Bevindingen empirisch onderzoek beheersmaatregelen In de voorgaande hoofdstukken is op basis van literatuuronderzoek inzicht gegeven in de regelgeving en de processen met betrekking tot continue compliance. In hoofdstuk 5 zijn beheersmaatregelen beschreven die de inrichting van een continue compliant infrastructuur kunnen borgen. Om de theorie te valideren met de praktijk is een vragenlijst opgesteld, die bij een vijftal Processors c.q. Payment Service Providers is uitgezet. Daarnaast hebben diverse expert interviews plaatsgevonden met de assessor die de Processors/Payment Service Providers heeft geaudit.

In paragraaf 6.1 zal worden beschreven op welke wijze het onderzoek is opgezet en uitgevoerd. In de daarop volgende paragrafen worden de resultaten van het onderzoek per beheersmaatregel beschreven.

6.1. Opzet praktijkonderzoek Zoals in de inleiding is aangegeven is het praktijkonderzoek beperkt tot een schriftelijke vragenlijst (zie Bijlage-Vragenlijst) en diverse expert interviews met de assessor (QSA). De vragenlijst is opgestuurd naar een vijftal Processors/Payment Service Providers. Zowel de Processors als de Payment Service Providers zijn gevestigd in Europa en moeten voldoen aan de regelgeving van PCI-DSS. Gezien de gevoeligheid van de informatie is geheimhouding aan de deelnemende organisaties toegezegd.

De vragenlijst beslaat drie onderzoeksgebieden. Allereerst wordt getracht uit te zoeken op welke wijze de processor zijn processen heeft ingericht om compliance te kunnen bewijzen, monitoren en auditen.

Het tweede onderzoeksgebied betreft de wijze waarop continue monitoring is ingericht en wordt gemonitord. Onderzocht is of er gebruik wordt gemaakt van één tool of dat verschillende soorten tooling ingezet zijn en of deze tooling specifiek is aangeschaft of al binnen de organisatie aanwezig was.

48


Het laatste onderzoeksgebied betreft de wijze waarop de bewijslast wordt opgehaald en bewaard.

6.2. Beheersmaatregel: Inrichting infrastructuur Alle ondervraagde processors c.q. service providers hebben de technische infrastructuur ingericht op de wijze waarop de netwerk zone model en segmentering is beschreven. PCI-DSS kent specifieke eisen ten opzichte van de inrichting van de technische infrastructuur. De ondervraagde partijen hebben voor PCI-DSS een specifiek segment ingericht die hieraan voldoet. Naast de specifieke beveiligingsmaatregelen die genomen moeten worden, wordt vaak ook gekozen om een segment in te richten voor de kaarthouder data omgeving en daarmee de scope voor het assessment te beperken.

De eisen van PCI-DSS zijn bij alle ondervraagde partijen in het beleid van de organisatie opgenomen. Geen enkele partij maakt gebruik van security baselines. De vertaling van het beleid naar de configuratiestandaard c.q. installatiehandleiding is uitgevoerd. Bij kleine partijen is slechts één document aanwezig dat zowel de configuratiestandaard als de installatiehandleiding bevat. De best practices en de hardening zijn hierin ook verwerkt.

Nadeel van het niet opnemen van de weten regelgeving in het beleid is dat binnen de organisatie onduidelijkheden kunnen ontstaan over de specifieke verantwoordelijkheden en eisen. Beveiligingsmaatregelen worden genomen op basis van continue re-engineering en kan de security niet op een eenduidige wijze worden geïmplementeerd.

Processen zoals configuratie management, change management, patch management, Identityen Access management zijn bij alle organisaties aanwezig. Afhankelijk van de volwassenheid van de organisatie worden de procedures gevolgd.

Over het algemeen kan worden geconcludeerd dat alle ondervraagde organisaties op een min of meer gelijke wijze zijn ingericht. De organisatorische infrastructuur, de ITIL processen, is echter verschillend en afhankelijk van de volwassenheid en omvang van de organisatie.

49


6.3. Beheersmaatregel: Inrichting continue compliance De inrichting van het continue compliance proces is afhankelijk van de omvang van de organisatie en de volwassenheid van het proces. De bevindingen zijn onderverdeeld in kleineen grote organisaties.

Kleine organisaties In de kleinere organisaties is het interne beheersingssysteem voornamelijk verankerd in de informele organisatie. Hierdoor is er geen specifiek continue compliance proces ingericht. De mechanismen van intern beheer zijn ook in mindere mate beschreven en de opvolging wordt vaak geborgd door de bedrijfscultuur.

Het beleid bij deze organisaties is meestal summier beschreven en hierin wordt slechts benoemd dat voldaan moet worden bepaalde weten regelgeving. Gezien de geringe omvang van de organisatie stelt het management de medewerkers verantwoordelijk voor de implementatie en uitvoering van de regelgeving. Adviseurs worden hierbij eventueel aangetrokken om de beheersmaatregelen initieel goed in te richten.

Het continue monitoring proces is in alle onderzochte kleine organisaties zwak ingericht. Het monitoren van de technische infrastructuur componenten gaat deels middels tooling, maar grotendeels handmatig. Het voordeel bij kleinere organisaties is dat de verantwoordelijkheid voor een bepaald technisch infrastructuur component, bij een beperkt aantal medewerkers ligt die precies op eenzelfde wijze de beheerwerkzaamheden uitvoeren. Hierdoor is de kans op afwijkingen minimaal en is de sociale controle tussen medewerkers onderling een stuk groter. De kennis van de gehele technische infrastructuur is vaak bij alle medewerkers bekend, waardoor bij incidenten sneller de oorzaak wordt gevonden. Processen, procedures en werkinstructies zijn vaak nauwelijks beschreven. Vanuit PCI-DSS oogpunt is dit minder van belang, omdat de bewijslast van de werking voldoende genoeg is om compliance aan te tonen. Echter voor ISO 27001/27002 en ISAE 3402 certificering zijn deze beschrijvingen noodzakelijk.

50


De kleinere organisaties die onderzocht zijn hebben geen interne audit afdeling. Het continue monitoring proces en eventueel aanwezige taaklijsten zorgen voor de borging van de weten regelgeving. Tijdens de inrichting van het continue monitoring proces wordt over het algemeen extern advies gevraagd van een onafhankelijke auditor, om te bepalen of de juiste beheersingsmaatregelen worden genomen. Het continue compliance proces krijgt het grootste deel van de input van het continue monitoring proces. In kleine organisaties hangt de keuze van de uitvoering van de compliance activiteiten versus de operationele activiteiten af van de prioriteiten die de medewerker zelf hieraan stelt. Security awareness van de medewerker is daarom een belangrijke factor voor de uitvoering van de activiteiten en het slagen van het proces. Daarnaast zal de security kennis van de medewerker mede een factor zijn voor het continue verbeteren van het continue monitoring proces zijn.

Grote organisaties In alle grote ondervraagde organisaties is op de verschillende bedrijfsonderdelen het continue compliance proces ingericht. In alle ondervraagde organisaties is de borging van de weten regelgeving in het beleid opgenomen. Daarnaast vindt jaarlijkse een review van het beleid plaats. In de praktijk betekent de review slechts check of wijzigingen in de weten regelgeving zijn geïmplementeerd. Het toetsen van het beleid aan de huidige ontwikkelingen met betrekking tot security en het mogelijk implementeren in de praktijk valt niet binnen de scope.

Het beleid is in alle gevallen niet vertaald naar een security baseline, wat betekent dat de business units zowel het beleid als de weten regelgeving moeten interpreteren. Het continue monitoring proces is bij alle partijen goed ingeregeld. De eisen die vanuit PCIDSS worden gesteld, worden periodiek gecontroleerd c.q. uitgevoerd. Bewijslast wordt hierbij centraal bewaard (zie paragraaf 5.3). Uit het onderzoek kwam naar voren dat bij één organisatie de volwassenheid van het continue monitoring proces hoog is. De vertaling van de weten regelgeving naar het beleid was echter niet goed geregeld. Echter vanuit PCI-DSS regelgeving zijn alle eisen vertaald naar specifieke maatregelen voor elk technisch infrastructuur component. Daarnaast was een beschrijving aanwezig waarin staat op welke wijze de maatregel wordt geïmplementeerd, beheerd en gemonitord. Het monitoren gebeurde middels een dashboard, dat gerapporteerd wordt aan de business unit en de security organisatie. Steekproefsgewijs wordt in deze organisatie door de Security Officer van de

51


business unit getoetst of de maatregelen goed zijn geïmplementeerd en wordt de bewijslast getoetst op de kwaliteit en compliance. Het continue monitoring is beter geborgd in de organisatie omdat verschillende rollen in de organisatie verantwoordelijk zijn voor dit proces.

Uit het onderzoek is gebleken dat de Interne Audit afdeling beperkt wordt betrokken bij de PCI-DSS audit, maar wel bijvoorbeeld bij de ISO 27001/27002, ISAE 304. De oorzaak is niet door de ondervraagde partijen aangeven.

De inrichting van de continue auditing proces is bij geen enkele organisatie aanwezig. Een ander opvallend resultaat is dat de bewijslast uit het continue monitoring proces soms alleen voor PCI-DSS wordt verkregen en bewaard. Bewijslast die nodig is voor ISO 27001/27002 en andere audits worden apart opgevraagd en via andere bronnen opgeleverd.

Geconcludeerd kan worden dat grote organisaties qua het continue compliance proces een stap verder zijn dan kleinere organisaties. In alle organisaties zie je de volwassenheid van de onderdelen van continue compliance proces niet gelijk zijn. Elke organisatie heeft een andere focus gehad op het continue compliance proces en zijn daardoor op verschillende onderdelen volwassen. Het continue auditing proces is in geen enkele organisatie aanwezig. Juist de integratie van het de continue monitoring proces en continue auditing proces zal de effectiviteit en efficiency in het continue compliance proces sterk verbeteren.

6.4. Beheersmaatregel: Inrichting continue monitoring van de technische infrastructuur Voor de inrichting van continue monitoring van de technische infrastructuur componenten zijn bij de ondervraagde organisaties een diversiteit aan controles ingericht. De bestaande controles zijn uitgebreid en nieuwe controles zijn toegevoegd aan de dagelijkse operatie. Bij grotere organisaties is hier specifieke tooling voor aangeschaft, kleinere organisaties hebben vaak de bestaande tooling aangevuld met scripts en handmatige controles.

52


De belangrijkste aandachtspunten met betrekking tot de PCI-DSS controles zijn de volgende: 

Configuratie management: Het controleren van de configuratie wordt op veel verschillende manieren uitgevoerd. Uit het praktijkonderzoek blijkt dat de handmatige controle met of zonder gebruik van scripts het meest voorkomt. Scripts zijn vaak het resultaat van een efficiëntie slag op de handmatige controles omdat de controles veel tijd in beslag nemen en de bewijslast expliciet moet worden gegenereerd.

Organisaties maken tevens gebruik van de bestaande tooling. De tooling werd voorheen alleen gebruikt voor monitoring van de performance en is inmiddels uitgebreid met compliance monitoring. Grotere organisaties controleren de configuratie vaak met behulp van File Integrity Monitoring tooling.

Kortom, er bestaan veel verschillende manieren om de configuratie te controleren. Vaak wordt voor elk technisch infrastructuur component aparte tooling ingezet en is er nauwelijks synergie in de tool voor het beheer van de verschillende technische infrastructuur componenten. De File Integrity Monitoring tooling maakt dit wel mogelijk, maar de kosten van aanschaf en inrichting zijn van dien aard, dat kleinere organisaties de aanschaf uitstellen. Daarnaast is File Integrity Monitoring nog niet geschikt om de gehele configuratie te controleren. 

Identity & Access Management: Het continue monitoren van het Identity & Access Management is afhankelijk van de grootte en volwassenheid van de organisatie. In geen enkele organisatie is Role Based Access Control ingevoerd. Daarnaast wordt er niet automatisch geprovisioned waardoor er geen dagelijkse synchronisatie plaatsvindt met de SOLL positie.

In de ondervraagde grote organisaties worden maandelijks de autorisatiematrices (SOLL posities) vergeleken met de werkelijkheid en worden de autorisatiematrices ter goedkeuring aangeboden aan de verantwoordelijke functionaris. In de ondervraagde kleinere organisaties wordt deze controle wel uitgevoerd, maar minder vaak en handmatig.

53


De controle van de Identity & Access management is als het handmatig wordt uitgevoerd een tijdrovende activiteit. Afhankelijk van functiewijzigingen, uit- en indiensttredingen kan ingeschat worden wat de frequentie van het continue monitoring proces zal zijn. 

Vulnerability en patch management: PCI-DSS stelt strikte eisen met betrekking tot vulnerability management. Ten eerste is het verplicht dat organisaties antivirus software op alle systemen heeft draaien. Ten tweede moet tenminste vier keer per jaar een externe vulnerability scan worden uitgevoerd en het resultaat van de scan moet compliant zijn en goedgekeurd worden door een geaccrediteerde partij. Als laatste dient jaarlijks een penetratie test te worden uitgevoerd en resultaten dienen te worden belegd in de organisatie. Bij alle organisaties zijn deze aspecten van vulnerability management standaard ingericht.

Daarnaast dient de organisatie interne vulnerability scans uit te voeren bij een wijziging van een systeem dat binnen de scope van PCI-DSS valt. Indien uit deze scan kwetsbaarheden worden gedetecteerd, dienen deze geregistreerd en opgelost te worden volgens het vulnerability proces. In alle onderzochte organisaties wordt voor het continue monitoring proces periodiek, meestal maandelijks, een interne vulnerability scan uitgevoerd. Kwetsbaarheden kunnen dan snel worden gedetecteerd en aan de hand van de risico analyse kan de kwetsbaarheid worden opgelost binnen de gestelde termijn.

Het continue monitoring van het patch management heeft voornamelijk betrekking op het uitkomen van nieuwe patches door de leverancier en het uitvoeren van de patch binnen de gestelde termijn. PCI-DSS stelt de eis dat een kritische security patch binnen 30 dagen na het uitbrengen geïnstalleerd dient te worden. Regelmatig, dit is meestal dagelijks, dient gecontroleerd te worden of nieuwe patches zijn uitgebracht. In grote organisaties mag de periode, waarop de controle plaats vind, niet te lang zijn. De patch cyclus is vaak langer dan drie weken en waardoor de gestelde termijn van PCI-DSS van 30 dagen slecht haalbaar zal zijn.

54


In alle organisaties wordt dagelijks gemonitord of er nieuwe patches zijn uitgekomen. Vaak geeft de leverancier op de website de mogelijkheid om RSS-feed aan te zetten. Als een update plaatsvindt, wordt automatisch een mail naar de organisatie gestuurd. Anders dient handmatig elke dag de website van de leverancier gecontroleerd te worden op nieuwe patches. 

Log & Monitoring: Uit het onderzoek is gebleken dat voor de logging, grote organisaties gebruik maken van een centraal logging systeem. Dit systeem collecteert de logging van alle technische infrastructuur componenten en slaat deze op in een centrale database. Voor de kleinere organisaties wordt de logging vaak decentraal opgeslagen. Controles met betrekking tot de volledigheid en integriteit van de logging worden bij alle organisaties uitgevoerd. Dagelijks vindt controle plaats op de volledigheid van opgehaalde loggings.

Het gebruik van een centrale logging systeem zou er toe moeten leiden dat ook SIEM (Security Information en Event Monitoring) is ingericht. Echter de uiteindelijke analyse en correlatie op de logbestanden staat nog in de kinderschoenen en is heel summier ingericht en wordt ook slechts beperkt uitgevoerd bij de grotere organisaties . Bij kleine organisaties is de inrichting beter geregeld.

Uit bovenstaande blijkt dat voor de meeste controles de bestaande tooling gebruikt wordt, welke is aangevuld met scripts en handmatige controles. Echter voor het Security Information en Event Monitoring (SIEM) en vulnerability scanning is nieuwe tooling aangeschaft. Voor wat betreft SIEM is slechts het ophalen van de logging geïmplementeerd welke wel enkele rapportages kan genereren maar nog niet in staat is een analyse of correlatierapportage op te leveren. Met betrekking tot vulnerability management zijn zowel het proces als de scanning geïmplementeerd.

Een andere bevinding is dat er nog geen generieke tooling beschikbaar is voor het monitoren van de algehele technische infrastructuur. De beschikbare tooling kan vaak slechts één technisch infrastructuur component monitoren. Hierdoor zal voor de diverse technische infrastructuur componenten veel verschillende tooling nodig zijn. De kosten voor tooling zijn

55


hierdoor hoog en daarnaast is veel verschillende expertise nodig voor het beheer en gebruik van de tooling.

6.5. Beheersmaatregel: Bewijsvoering voor aantonen continue compliance De bewijslast wordt in de praktijk zowel centraal als decentraal bewaard. In de meeste ondervraagde organisaties, zowel de kleine als grote, wordt de bewijslast decentraal bij het team bewaard. In dit geval blijft de bewijslast voornamelijk in de tooling die gebruikt wordt voor het continue monitoren. Bij één grote organisatie wordt centraal een lijst bijgehouden welke bewijslast voor welke PCI-DSS requirement gebruikt wordt en op welke wijze deze bewijslast verkregen kan worden.

Voor een audit of interne controle moet eerst alle bewijslast worden verzameld hetgeen een tijdrovende activiteit is. Daarnaast is het niet voor alle tooling mogelijk om de bewijslast minimaal één jaar te bewaren en zal tevens de back-up moeten worden geraadpleegd.

Een van de ondervraagde organisatie heeft voor de technische infrastructuur de bewijslast centraal opgeslagen. In het continue monitoring proces wordt middels workflows de bewijslast over de afgelopen periode opgevraagd bij de verschillende technische infrastructuur componenten. De bewijslast wordt automatisch per PCI-DSS requirement of groep van requirements opgeslagen en wordt voor elk technische infrastructuur component verzameld. Daarnaast is centraal een koppeling gelegd naar alle documentatie betreffende de processen, werkinstructies, installatiehandleidingen, configuratiestandaarden etc. Bij een audit of interne controle dient alleen de centrale plek te worden geraadpleegd.

56


7. Vraagstelling, beantwoording en aanbevelingen De centrale vraagstelling zoals geformuleerd in hoofdstuk 1.2.2 is als volgt:

Op welke wijze dienen organisatie en beheer van de technische IT infrastructuur bij vitaal elektronisch betalingsverkeer ingericht te worden om continue te voldoen aan de regelgeving van PCI-DSS op een continue aantoonbare wijze?

In dit hoofdstuk worden de centrale vraag en de deelvragen beantwoord op basis van de literatuurstudie en het praktijkonderzoek en zullen een aantal aandachtspunten en aanbevelingen worden gegeven

7.1. Deelvragen en beantwoording Voor de beantwoording van de centrale onderzoeksvraag, worden eerst de afzonderlijke deelvragen beantwoord welke gesteld waren voor het praktijkonderzoek.

Deelvraag: Op welke wijze is de technische infrastructuur bij Processors en Payment Service Providers ingericht?

De inrichting van de organisatie en het beheer van de technische IT infrastructuur in het elektronische betalingsverkeer is gebaseerd op verschillende beveiligingseisen, die tezamen zorgen voor een “defence in depth” van de technische infrastructuur. De inrichting van de netwerkinfrastructuur is een van de belangrijkste beveiligingseisen. De meest voorkomende manier waarop het netwerkinfrastructuur is ingericht, is op basis van een zone model en segmentering. Hierdoor is het elektronische betalingsverkeer al op netwerkgebied afgescheiden van de rest van omgevingen die de organisatie bedient.

Daarnaast dient elke server slechts één functie uit te voeren, waardoor een scheiding bestaat tussen de data, applicatie en webserver. Elke functie heeft zijn eigen beveiligingseisen en door slechts een functie per server in te richten ontstaan er geen conflicterende beveiligingseisen.

57


Het beveiligingsniveau is mede afhankelijk van de dataclassificatie. Per dataclassificatie worden verschillende beveiligingseisen gesteld aan de technische infrastructuur.

Tevens dient de technische infrastructuur in overeenstemming te zijn met het beleid van de organisatie. Voorwaarde is dat weten regelgeving geïntegreerd is met het beleid.

Deelvraag: Voldoet de huidige inrichting aan de regelgeving van PCI en welke maatregelen worden thans genomen?

De inrichting van een continue compliance proces blijkt niet daadwerkelijk nodig te zijn om te voldoen aan de regelgeving van PCI-DSS. Het continue monitoring proces is wel één van de vereisten en wordt getoetst tijdens een audit. De inrichting van het continue monitoring proces van de technische infrastructuur zorgt dat continue voldaan wordt aan de regelgeving van PCIDSS. In de ondervraagde organisaties worden alleen maatregelen getroffen om het continue monitoring proces te optimaliseren omdat zij allen al PCI-DSS compliant zijn.

De investeringen die nodig zijn om het continue compliance proces te implementeren, worden vanwege de economische slechte tijd nog uitgesteld. Echter de business case voor deze investeringen kan gunstig uitvallen. De investeringen die zijn gedaan bij het continue monitoring proces zullen extra rendement gaan opleveren bij het inrichten van het continue compliance proces.

Deelvraag: Op welke wijze worden maatregelen getroffen om continue aantoonbaar middels bewijsvoering in control te zijn?

Om continue Assurance af te kunnen geven, zal de inrichting van een continue compliance proces van groot belang zijn. Het continue compliance proces bevat de essentiële onderdelen continue monitoring en continue auditing. In de literatuur is over deze twee onderwerpen veel geschreven en krijgt men de indruk dat het gehele continue compliance proces al deel uitmaakt van menig organisatie. Uit het praktijkonderzoek blijkt echter dat het continue compliance

58


proces nog in de kinderschoenen staat. Kleine organisaties hebben zich voornamelijk gericht op het continue monitoring proces. Grote organisaties hebben verschillende stappen gemaakt om onderdelen te installeren, maar in nog geen enkel onderzochte organisatie is het continue compliance proces in zijn geheel geïmplementeerd.

De getroffen maatregelen om continue aantoonbaar middels bewijsvoering in controle te zijn, zijn met name te vinden in het continue monitoring proces op zowel het proces- als technisch niveau. Daarnaast zijn maatregelen getroffen om de bewijsvoering te borgen. De bewijslast wordt voornamelijk decentraal of in de tooling opgeslagen.

De meeste tooling voor het continue monitoring proces is vaak voor slechts één specifiek infrastructuur component geschikt. Er is nauwelijks tooling beschikbaar die generiek kan worden ingezet voor alle infrastructuur componenten. De tooling voor Security Information en Event Monitoring (SIEM) en vulnerability scanning zijn daarentegen wel generiek. De inrichting van SIEM is vaak beperkt. Het ophalen van de logging is wel geïmplementeerd, echter events worden minimaal gemonitord. Desondanks is dit samen met de getroffen maatregelen voor PCI-DSS voldoende om continue aantoonbaar in control te zijn.

7.2. Centrale vraagstelling en beantwoording In antwoord op de centrale vraag kan worden gesteld dat de technische IT infrastructuur voor het elektronische betalingsverkeer ingericht dient te zijn volgens het zone model en segmentering. Daarnaast zullen door middel van de dataclassificatie en het beleid, de overige beveiligingseisen vastgesteld worden.

Een organisatie die voldoet aan PCI-DSS dient te allen tijde te kunnen aantonen dat voldaan wordt aan de regelgeving van PCI-DSS. Om continue Assurance te kunnen afgeven, zal de inrichting van een continue compliance proces van groot belang zijn, maar is niet verplicht voor PCI-DSS.

59


Wel verplicht is dat het continue monitoring proces en de daarbij behorende bewijsvoering op orde is zodat de organisatie in geval zij wordt gecompromitteerd, kan aantonen dat zij voldeed aan de eisen van PCI-DSS.

7.3. Aandachtspunten en aanbevelingen Uit de interviews met de assessor (QSA) en mijn eigen bevindingen uit de praktijk zijn diverse aandachtspunten naar voren gekomen die van belang zijn voor een goede implementatie van het continue compliance proces en de borging van dit proces. De aandachtspunten en mijn aanbevelingen zijn: 

Continue betrokkenheid van het management, ook na een assessment Tijdens het implementatie traject om compliant te worden is er over het algemeen voldoende aandacht vanuit het management. Na de certificering is het echter van groot belang dat de focus op compliance aanwezig blijft bij het management. In de praktijk blijkt dat de aandacht na certificering veelal verslapt, waardoor er een risico ontstaat dat de procedures niet of niet tijdig worden uitgevoerd en daardoor het doorlopende bewijs en documentatie uitblijft.



Multidisciplinaire aanpak Het is aan te raden om tijdens het inrichten van het continue compliance-, monitor en audit proces de expertise van de verschillende partijen (security, beheer en audit) in te zetten. Elke partij stelt zijn eigen vereisten welke volgen uit de weten regelgeving. Door gebruik te maken van de verschillende expertises zullen alleen de noodzakelijke controles worden uitgevoerd en bewijslast worden verkregen.



Implementeer voor investeringen in tooling Indien nog geen continue monitoring proces is ingericht, implementeer deze dan met de beschikbare tooling aangevuld met handmatige controles en scripts. In de praktijk komt het regelmatig voor dat voor elke technische infrastructuur component nieuwe tooling wordt aangeschaft. De kans bestaat verschillende soorten tooling worden aangeschaft met dezelfde functionaliteit. Door eerst gebruik te maken van de beschikbare middelen kan

60


achteraf beter geïnventariseerd worden welke requirements gesteld worden aan de gehele technische infrastructuur. 

Effectiviteit en efficiency worden pas zichtbaar na implementatie van het gehele continue compliance proces Uit de praktijk blijkt dat het inrichten van het continue compliance proces, de daarbij behorende extra uit te voeren controles en de te verzamelen bewijslast, vaak als een tijdrovende activiteit wordt ervaren. Dit komt meestal omdat voorheen controles niet werden uitgevoerd en de bewijslast niet werd veilig gesteld. Pas na in gebruik name van het proces en enige verbeteringen op de controles zal de effectiviteit en efficiency in de beheerorganisatie merkbaar zijn. De extra controles maken de technische infrastructuur robuuster en vermindert het aantal storingen. Tijdens de audits zal de inzet van de beheerorganisatie minder nodig zijn daar al bewijslast beschikbaar is.

61


8. Persoonlijke reflectie Terugkijkend op het doorlopen van het scriptietraject; het was een leerzame periode en een goede aanvulling op de EDP-Audit opleiding.

Tijdens de aanvang van mijn vorige werkzaamheden als Security Officer, was ik verrast dat het continue compliance proces nog in haar kinderschoenen stond. Mijn nieuwsgierigheid werd hierdoor gewekt en was ik geïnteresseerd in hoe andere organisaties dit hadden ingericht. Voornoemde is de reden voor de keuze van het onderwerp van deze scriptie.

Tijdens het literatuuronderzoek viel mij op dat er al veel geschreven is over continue assurance, continue monitoring en continue auditing. Uit het praktijkonderzoek kon ik echter opmaken dat ook in andere organisaties het continue compliance proces nog in ontwikkeling is. In de loop der tijd heb ik echter wel het continue compliance proces voor de technische infrastructuur op verschillende lagen van de organisatie zien ontwikkelen en tevens de problematiek kunnen aanschouwen.

Kortom, het uitvoeren van dit onderzoeken en het schrijven van deze scriptie was een interessant proces dat deels parallel liep aan de ontwikkelingen binnen mijn organisatie en mij inzicht heeft gegeven op welke wijze organisaties continue compliance borgen.

62


9. Dankwoord Voor het tot stand komen van deze scriptie wil ik de volgende mensen bedanken voor hun input, advies en tijd: 

Rene Matthijsse: Mijn scriptiebegeleider die mij het hele jaar heeft ondersteund en exact wist hoe hij mij gedurende slechte tijden kon motiveren om door te gaan met mijn scriptie. Daarnaast dank voor het reviewen van mijn scriptie en het geven van de opbouwende kritiek.



Richard van Oeffel: De PCI-DSS assessor die mij heeft ondersteund in het vinden van het bewijs voor mijn centrale vraagstelling. Daarbij heeft Richard mij de mogelijkheid gegeven om in contact te komen bij verschillende Processors en Payment Service Providers.



Alle Security Officers van de Processors en Payment Service Providers: Zij hebben mij geholpen om mijn beeld te kunnen bepalen. Dit deden ze door mij een kijkje in de keuken van hun organisatie te geven en openheid te geven over de implementatie van het continue compliant proces.

63


Bijlage Literatuurlijst [1]

Een introductie van SEPA, juli 2009, (http://www.ecb.europa.eu/paym/sepa/html/index.en.html)

[2]

Programmaplan SEPA NL: Nederland als deel van de Single Euro(pean) Payments are, (http://www.sepanl.nl/scrivo/asset.php?id=62372)

[3]

Payment Service Provider (http://en.wikipedia.org/wiki/Payment_service_provider)

[4]

Algemene opleiding bankbedrijf, april 2001/2008

[5]

Opleiding Nederlands en Europees betalingsverkeer (interne cursus Equens SE 2009)

[6]

SEPA betalingsverkeer (interne cursus Equens SE 2011)

[7]

Alumnicongres Geeft elektronisch betalen vertrouwen (11 november 2009)

[8]

Banken profiteren van meer concurrentie bij clearing, auteur:P. van Andel, oktober 2009 (http://www.enigma-payments.nl/nl/publications/205-brv.html)

[9]

Banks preparing for SEPA, version 2.0, oktober 2006 (https://www.ebaportal.eu/_Download/EBA%20Insight/EBA061001_Banks_Preparing_ for_SEPA.pdf)

[10] Merchant account basics – A compilation of Braintree blogs posted (Braintree) (http://www.braintreepayments.com/assets-1571f1fc86/assets/307/MerchantAccount.pdf) [11] Het gemeenschappelijk eurobetaingsgebied (SEPA) – een geïntegreerde retailbetalingsmarkt (http://www.ecb.int/pub/pdf/other/sepa_brochure_2009nl.pdf) [12] Impact paper toward PE-ACH (http://docs.google.com/viewer?a=v&q=cache:DpxdehoWQkJ:https://www.ebaclearing.eu/Repository.aspx%3FID%3De51a1de8-ac6943ea-a87d-bc02aba7b00a+IMPACT+PAPER+TOWARDS+%E2%80%9CPEACH&hl=nl&gl=nl&pid=bl&srcid=ADGEESg7uzjNLAEDHemWcGRSSNZCA_g1Yh 6GBjaBZGM5F0Lvue6Bl8B2xHm34JTLuX8l03jg79QuBsFTYAUfQ0p1aR1EGRV2N y83yfFvlSvL4Yq7bx8PuOhhTLuSqjkzjGDB_k1l8ZGD&sig=AHIEtbTl5LBcthd_FcJol ActjbNJqLzX1g) [13] The Payment system, ECB 2010 (http://www.ecb.int/pub/pdf/other/paymentsystem200909en.pdf)

64


[14] The international Payment Framework Association is Formed (http://www.internationalpaymentsframework.org/docs/IPFAArticleFormationofIPFA.p df) [15] EACHA Interoperability Framework (v5.0) (http://www.eacha.org/downloads/EACHA_Framework_5_0.pdf) [16] PE-ACH/CSM Framework(https://www.ebaportal.eu/_Download/2006-00401_PEACH_Framework.pdf) [17] PCI DSS (PCI Data Security Standard) – PCI DSS v2.0, date issued:10/28/2010, https://www.pcisecuritystandards.org/security_standards/documents.php [18] PCI DSS – Glossary v2.0, date issued:10/28/2010, https://www.pcisecuritystandards.org/security_standards/documents.php [19] PCI DSS – Navigating the PCI DSS v2.0, date issued: 10/28/2010, https://www.pcisecuritystandards.org/security_standards/documents.php [20] PCI DSS – Quick Reference Guide v2.0, date issued: 01/10/2010, https://www.pcisecuritystandards.org/security_standards/documents.php [21] Qualified Security Assessor (QSA) Training (oktober 2008) [22] Continuous auditing: Implication for assurance, monitoring and risk assessment, auteur: E. Graig (http://www.acl.com/pdfs/GTAG_ContinuousAuditing-05.pdf) [23] Firewalls, auteur: Drs.ing.R.Pluis MBA MBI CISSP, date issued:2005 [24] NIST SP 800-137 [25] NIST SP 800-39 [26] Whitepaper(quest software) Collecting compliance evidence: The role of event logs, auteur: J. Grettenberger, November 2009 [27] Continuous Auditing en continuous monitoring: levert het de beloofde voordelen op (http://www.kpmg.com/NL/nl/IssuesAndInsights/ArticlesPublications/Documents/PDF/ Risk%20and%20Compliance/Continuous_Auditing_Continuous_Monitoring1.pdf) [28] Continuous monitoring and auditing: what is the difference, auteur:J.verver (http://www.protiviti.cn/en-US/Insights/Browse-by-Content/FeaturedArticles/Pages/Continuous-Monitoring-and-Auditing.aspx) [29] White paper (Tripwire) Five challenges to continuous PCI DSS Compliance

65


[30] Information security continuous monitoring (ongoing monitoring in support of organizational risk management), Auteur: L. Arnold Johnson, December 2010 (http://csrc.nist.gov/groups/SMA/forum/documents/Forum-121410-ContinuousMonitoring-AJohnson.pdf) [31] IT audit and assurance guideline: G42 Continuous Assurance (ISACA), maart 2010 [32] Monitoring processes and internal control adequacy: Continuous monitoring within a Microsoft access database, auteur: M. Brewster, G. Gal, S. Rosen, A. Zubenko,2007 (ISACA) [33] Monitoring internal control systems and IT – A primer for business executives, managers and auditors on how to embrace and advance best practices (ISACA), ISBN: 978-1-60420-110-9, druk:2010 [34] ICT-Strategie en –organisatie: in theorie en praktijk, auteur: prof. Drs. J.A. Oosterhaven, tweede herziende druk(2007) [35] Inrichten en beheersen van organisaties, auteur: Drs. R.M.J. Christiaanse RA, J.C. van Praat RE RA, eerste druk, eerste oplage (2005) [36] Secure Network zones, auteur: P. Wimmer (ISSE-2009) (http://www.atsec.com/downloads/pdf/ISSE_2009-Secure_network_zonesPeter_Wimmer.pdf )

66


Vragenlijst 1. What are the components of the infrastructure to be continuously monitoring? You can fill in the table below, complement if components type are not present. Enter your answer in the table in the Annex 2. Describe which department responsible is for what component of the infrastructure (organisation chart or RACI). You could give your answer in the table in the Annex. Please could you give a copy of the organisation chart. 3. In what way are the rules and regulations (ISO 27001/27002, PCI-DSS, ISAE 3402, COBOL, ITIL e.g) embedded in the security policy or framework of the organisation?

4. The card brands require being continuously compliant. How is the infrastructure designed for this (framework, principles and processes)?

5. Are the measures taken to continuously monitor, the same for each infrastructure component or has each infrastructural component a specific implementation and its own tooling?

6. Could you give per infrastructure component what tool is used? Please use the table in the annex and complement the column “Used Tooling”. 7. Is the continuous monitoring process (and possible compliance process) efficiently organized and why? What kind of improvements would you like to make?

8. How is the continuous monitoring process guaranteed in the organisation (tasks and responsibilities)? Is the continuous monitoring process being controlled and improved?

67


9. How is the alignment of continuous monitoring process with the continuous auditing process (internal / external audit and the relation between other (security) departments)?

10. How is the evidence collected (central / decentralise) and do you use specific tooling for it? Please use the table in the annex and complement the column “Evidence collected through”. 11. Is the continuous auditing process (and possible compliance process) efficiently organized and why? What kind of improvements would you like to make?

12. How is the continuous auditing process guaranteed in the organisation (tasks and responsibilities)? Is the continuous auditing process being controlled and improved?

13. Do you have a framework for the compliance process, were the continuous monitoring and continuous auditing process are merged. Or are this separate processes that share information?

14. Is the design of the continuous monitoring process (framework, principles, processes and/or tooling) also suitable for other parts of the organisation? Which part of the organisation makes use this process (in percentage)

15. Do you have any other comments or remarks which are not mentioned in the questions before?

68


Question 1 Infrastructure type Network Components

Operating system

Virtual machine Storage

Middleware

Component Firewall

Brand/Version

Amount (estimation)

Question 2 Responsible Department

Question 6 Used tooling

Question 10 Evidence collected through

Accountable: <department> Responsible: <department>

Routers e.g. Windows HPNS Mainframe e.g. VMWare e.g. SAN /NAS /DASD e.g. SQL Oracle Websphere Etc.

69

Continue Compliant Elektronisch Betalingsverkeer

Recommend Documents