Integriteit en vertrouwelijkheid. van creditcard gegevens: De toegevoegde waarde van het Payment Card Industry (PCI)

Transcriptie

1 Postgraduate Opleiding ITACA Integriteit en vertrouwelijkheid van creditcard gegevens: De toegevoegde waarde van het Payment Card Industry (PCI) Data Security Standards (DSS) framework Auteur adres Chris van Aken

2 Auteur Ing. Chris van Aken VCP MCP QSA CISA Studentnummer Noordbeek B.V. Rijndijk 209-B 2394 CD Hazerswoude Vrije Universiteit Dr. René Matthijsse RE Praktijkbegeleider Ing. Edward van Egmond RE QSA CISA 2 van 53

3 Inhoudsopgave 1. Inleiding Aanleiding voor het onderzoek Onderzoeksdoelstelling Scope en afbakening van het onderzoeksveld Bijdrage van het onderzoek aan het vakgebied IT-audit Onderzoekaanpak Dankwoord Financieel betalingsverkeer en security Creditcards Geld- en informatiestromen tijdens creditcard transacties Payment Card Industry Data Security Standards (PCI DSS) framework Achtergrondinformatie verschillende frameworks van de PCI Council Compliance Bevindingen van praktijkstudie Casus 1: KB Kookmin Card, Lotte Card, en NH Nonghyup Card Casus 2: Diefstal creditcard gegevens Synthese en conclusies Aanbevelingen Beantwoording van de onderzoeksvragen Beantwoording deelvragen Beantwoorden centrale vraagstelling Conclusie Bijlagen Bronliteratuur van 53

4 1. Inleiding Dit onderzoek wordt verricht in opdracht van de Vrije Universiteit te Amsterdam, ter afsluiting van de Postgraduate IT Audit Opleiding. Het onderzoeksonderwerp betreft de Payment Card Industry - Data Security Standards versie 3.0 (PCI DSS 3.0) en hoe dit framework bijdraagt aan het borgen van de integriteit en vertrouwelijkheid van creditcard gegevens Aanleiding voor het onderzoek Tijdens het verwerken van creditcard transacties worden vertrouwelijke gegevens gelezen, opgeslagen en verstuurd. Tegenwoordig vinden dergelijke transacties in toenemende mate plaats via een onveilig medium, namelijk het internet. Om de integriteit en vertrouwelijkheid van creditcard transacties te borgen is het van belang dat op een gelaagde wijze veiligheidsmaatregelen worden getroffen om de kans op een zogenaamde data breach te verminderen. Hiervoor is het framework PCI DSS opgezet als een normenkader, dat door een gecertificeerde IT-auditor moet worden getoetst. De maatregelen vanuit PCI DSS zijn niet uitsluitend technisch van aard, maar ook organisatorisch, fysiek, procedureel en procesmatig 1. Vanuit mijn technische achtergrond ben ik zeer geïnteresseerd in informatiebeveiliging. Derhalve neem ik voortdurend kennis van de laatste ontwikkelingen op het gebied van beveiligingsincidenten en nieuwe methoden en technieken om zulke incidenten te voorkomen. Daarbij analyseer ik vooral de oorzaken van succesvolle aanvallen waarbij creditcard gegevens zijn ontvreemd, en beschouw daarbij hoe zo een aanval had kunnen worden voorkomen Onderzoeksdoelstelling Als een organisatie creditcard gegevens van een van de vijf grootste Amerikaanse creditcard maatschappijen opslaat, verwerkt of verstuurt, dient deze organisatie zich te conformeren aan het PCI DSS normenkader om de integriteit en vertrouwelijkheid van de creditcard gegevens en de gelieerde omgeving te borgen 2. Als casuïstiek neem ik twee incidenten die recentelijk hebben plaatsgevonden en analyseer of compliance met PCI DSS deze inbreuken had kunnen voorkomen 3. 1 PCI Council, (2013). PCI_DSS_v3; 2 PCI Council, (2013). 3 Verizon Enterprise, (2013). Data breach investigations report 2013; 4 van 53

5 1.3. Scope en afbakening van het onderzoeksveld Dagelijks worden miljoenen financiële transacties verwerkt. Binnen het huidige tijdsbestek van een afstudeerscriptie is het niet mogelijk om alle typen van aanvallen op creditcard gegevens te analyseren. Ik heb het als een handicap ervaren dat inhoudelijk diepgaande documentatie omtrent deze onderwerpen slechts beperkt beschikbaar zijn op openbare media wegens hun gevoeligheid. Daarom is dit onderzoek beperkt tot een tweetal grootschalige incidenten waarbij creditcard gegevens zijn ontvreemd. Bij de analyse wordt versie 3.0 van PCI DSS gebruikt, wat op moment van schrijven de meest recente revisie is van dit framework 4. Vraagstelling De centrale vraagstelling is: Hoe draagt het PCI DSS normenkader bij aan het borgen van de integriteit en de vertrouwelijkheid van creditcard gegevens? Deze onderzoeksvraag is gesplitst in een drietal deelvragen, namelijk: 1. Wat is de intentie van de opstellers van het framework PCI DSS versie 3.0 en welke bedreigingen vormen een gevaar voor de vertrouwelijkheid van creditcard gegevens? 2. Welke maatregelen dragen bij aan risicobeheersing van creditcard transacties? Deze twee deelvragen zijn inventariserend en analyserend van aard. De achtergrond van PCI DSS wordt in kaart gebracht, evenals de door PCI geformuleerde requirements en hun doelstellingen. 3. Wat zijn de onderliggende oorzaken van de in praktijkstudie beschouwde inbraken, en had compliance met PCI DSS deze inbraken kunnen voorkomen? De derde deelvraag is analyserend en beschouwend van aard, waarbij de casussen KB Kookmin Card, Lotte Card en NH Nonghyup Card en Target worden geëvalueerd. Deze analyse en beschouwing leidt tot het formuleren van enkele aanbevelingen Bijdrage van het onderzoek aan het vakgebied IT-audit De maatschappij heeft belang bij een ongestoorde en soepele verwerking van grote volumes aan financiële transacties via creditcards, zodat burgers gemakkelijk goederen en diensten kunnen afnemen en kunnen afrekenen. Hierbij is vertrouwen in de verwerking van deze transacties essentieel, zowel voor de koper als de verkoper. 4 PCI Council, (2013). PCI_DSS_v3_05Nov13_Final, van 53

6 Dit vertrouwen moet worden geleverd door de IT-auditor, die in dit kader een belangrijke maatschappelijke functie vervult. Het onderzoek verschaft deze IT auditor inzicht in de doelstellingen van PCI DSS, in de kwetsbaarheden van sommige organisaties bij de verwerking van creditcard gegevens, en daarmee het nut van het nastreven van compliance met PCI DSS Onderzoekaanpak De onderzoeksvragen worden beantwoord via twee studies, namelijk een literatuurstudie gevolgd door een praktijkstudie. PCI DSS wordt geanalyseerd als onderdeel van de literatuurstudie. Hierbij wordt aangegeven hoe creditcard transacties verlopen, welke partijen hierbij zijn betrokken en hoe het framework creditcard gegevens beschermt tegen criminele activiteiten. Bij de praktijkstudie worden twee incidenten besproken waarbij creditcard gegevens zijn ontvreemd. Aan de hand van publiekelijk beschikbare documentatie worden de oorzaken van beide inbraken gereconstrueerd, waarbij vooral wordt geanalyseerd welke maatregelen ontbraken om deze inbraken te voorkomen. Bij dit onderzoek heb ik gebruik gemaakt van mijn kennis en ervaring als Qualified Security Assessor (QSA). Een QSA is een IT-auditor welke bevoegd is om een omgeving te toetsen en te beoordelen op veiligheid specifiek ten aanzien van creditcard gegevens Dankwoord Graag spreek ik enkele woorden van dank uit voor mijn twee begeleiders, namelijk Dr. René Matthijsse RE en Ing. Edward van Egmond RE QSA CISA, die mij hebben geholpen de rode lijn van het verhaal stevig vast te houden. Zonder hun bijsturing en coaching was het moeilijk geweest om het huidige resultaat te bereiken. En natuurlijk een bedankje aan mijn lieve echtgenote Diana die mij de ruimte heeft gegeven om vele uren in de avonden en weekends achter de computer te zitten om literatuur te verzamelen en die om te zetten in een gestructureerde analyse. Zowel Diana als ik zijn verbaasd hoe gigantisch veel uren nodig zijn om op zich eenvoudige vragen en antwoorden op een academisch verantwoorde wijze te onderbouwen, dusdanig dat deze teksten door mijn kwaliteitsbewuste begeleiders geschikt worden geacht om deze voor te leggen aan de Examencommissie van de Opleiding. Daarnaast mijn dank aan mijn collega s Keith, Stef en Dennis bij Noordbeek, die vanuit hun eigen ervaringen met PCI DSS kritisch hebben meegekeken naar mijn analyses en op een gepaste wijze commentaar hebben geleverd op eerdere concept versies. Dit heeft het schrijfproces niet echt versneld, maar de kwaliteit van de scriptie wel op een hoger niveau gebracht. 6 van 53

7 2. Financieel betalingsverkeer en security Het framework PCI Data Security Standards (PCI DSS) is opgesteld om de veiligheid van creditcard gegevens te bevorderen. Dit framework bestaat uit een twaalftal organisatorische, technische, procedurele en procesmatige normen waar een organisatie aan dient te voldoen alvorens deze creditcard gegevens mag verwerken 5. PCI DSS is opgesteld door de Payment Card Industry (PCI) Council. De PCI Council is een samenwerkingsverband tussen de vijf grootste creditcard maatschappijen, te weten: American Express, Discover Financial Services, JCB International, MasterCard Worldwide en Visa Incorporated. Dit samenwerkingsverband is opgericht in In dit hoofdstuk worden de creditcard als betaalmiddel en de afhandeling van de bijbehorende transactie besproken. Het gaat hierbij om de geld- en informatiestromen, soorten transacties en de gelieerde processen. Vervolgens wordt het framework inhoudelijk besproken Creditcards Een creditcard is een betaalpas, uitgegeven aan consumenten om financiële transacties mee te voltooien. Creditcards bieden de consument de mogelijkheid om vooraf diensten of goederen te verkrijgen welke pas achteraf hoeven te worden betaald. De uitgevende bank staat garant voor een bepaald bedrag, afhankelijk van de vooraf gedefinieerde limiet. Deze limiet is afhankelijk van de kredietwaardigheid van de consument. Transacties met creditcards kunnen worden uitgevoerd ongeacht of de betaler wel of niet fysiek aanwezig is in een winkel 7. In het geval dat een betaler aanwezig is in een winkel, kan deze de pas fysiek gebruiken om een transactie te voltooien. De betaler hoeft enkel de creditcard te overhandigen en de kassabon te ondertekenen om de transactie goed te keuren. Het is ook mogelijk om transacties te voltooien zonder dat de betaler fysiek aanwezig hoeft te zijn. Hiervoor zijn wel echter aanvullende gegevens benodigd om te verifieren dat de betaler daadwerkelijk in het bezit is van een legitieme creditcard en is geautoriseerd om deze kaart daadwerkelijk te gebruiken. In het kader van het onderzoek is het van belang vast te stellen welke gegevens een creditcard bevat en waarvoor deze nodig zijn. 5 PCI Council, (2013). PCI_DSS_v3; 6 PCI Council, (2013). 7 Merchant Account Forum, (2011). 7 van 53

8 Per onderstaande paragraaf wordt steeds een van deze gegevens behandeld. Daarbij wordt gerefereerd naar de volgende afbeelding: Primary Account Number (PAN) data De PAN data bevindt zich aan de voorzijde van een creditcard. Dit unieke nummer identificeert de uitgever van de pas en het accountnummer van de consument. Het eerste cijfer van de PAN reeks geeft aan vanuit welk type bedrijf de kaart afkomstig is. Dit wordt ook wel de Major Industry Identifier (MII) genoemd 8 : MII Type of Industry 0 ISO/TC 68 and other future industry assignments 1 Airlines 2 Airlines and other future industry assignments 3 Travel and entertainment and banking/financial 4 Banking and financial 5 Banking and financial 6 Merchandising and banking/financial 7 Petroleum and other future industry assignments 8 Healthcare, telecommunications and other future industry assignments 9 National assignment American Express en JCB vallen onder categorie 3 Travel and entertainment and banking/financial. VISA en Mastercard zijn in categorie 5 Banking and financial gepositioneerd. Discover is ondergebracht in categorie 6 Merchandising and banking/financial. 8 Addison, D., (2011). 8 van 53

9 Expiration date De expiration date geeft de uiterste maand en jaar aan dat de creditcard kan worden gebruikt om transacties te voltooien. Na de aangegeven datum verloopt de creditcard en daarmee ook de mogelijkheid om de verificatiecodes van de kaart te gebruiken voor het bevestigen van financiële transacties. Card Security Code Creditcards bevatten een aparte niet-elektronische code om het eigenaarschap van de creditcard te kunnen bewijzen. De creditcard maatschappijen hebben ieder eigen terminologie voor de Card Security Code (CSC), maar hiermee wordt hetzelfde aangeduid. Andere benamingen die door verschillende creditcard maatschappijen worden gebruikt zijn onder andere: Card Verification Data (CVD); Card verification number (CVN); Card Verification Value (CVV or CVV2); Card Verification Value Code (CVVC); Card Verification Code (CVC or CVC2); Verification Code (V-code or V code); Card Code Verification (CCV); Signature Panel Code (SPC) 9. De CSC is een controlegetal dat op een cryptografische wijze is samengesteld aan de hand van informatie die is opgeslagen op de creditcard. Deze controle wordt ten tijde van een Card Not Present (CNP) transactie uitgevoerd. CNP transacties zijn transacties die plaatsvinden zonder dat de kaart daadwerkelijk wordt gelezen via een Point of Sales (POS) terminal. Een voorbeeld hiervan is het betalen van een online aankoop via internet of het betalen per telefoon of door middel van een fax. Track data Creditcards zijn voorzien van een magnetische laag. Deze laag bevat drie verschillende gegevensverzamelingen die ieder een track worden genoemd. Een kaart bevat maximaal drie tracks. Track 1 bevat gegevens over de betaler, diens rekening en autorisatiegegevens. Welke gegevens exact worden opgeslagen binnen track 1 verschilt per uitgevende maatschappij. Track 2 bevat een verdere specificatie van de gegevens uit track 1. Tijdens transacties worden doorgaans de gegevens vanuit track 1 en track 2 benut. De gegevens in track 3, indien deze wordt gebruikt, bevatten de versleutelde PIN, landcode, type valuta, geautoriseerde bedragen en soortgelijke beperkende gegevens. Track 3 is 9 PCI Council, (2013). 9 van 53

10 echter niet gestandaardiseerd tussen de banken. Bij het bevestigen van transacties wordt doorgaans vooral gebruik gemaakt van de gegevens op Track 1 en Track Type creditcard transacties Een creditcard kan op een tweetal manieren worden gebruikt voor het uitvoeren van een transactie. Dit kan doordat een betaler fysiek aanwezig is bij een transactie of een transactie autoriseert via de autorisatiecodes. Allebei deze typen van transacties worden in de onderstaande paragrafen verder uitgewerkt. Card Present Tijdens een Card Present transactie zijn zowel de betaler als de creditcard aanwezig. De verkopende partij maakt gebruik van een POS terminal om de transactie te verwerken. De POS terminal geeft hierbij aan of de transactie al dan niet is goedgekeurd. De creditcard maatschappijen verzoeken verkopende partijen op te letten of het een legitieme creditcard en transactie betreft. De verschillende maatschappijen hebben diverse fysieke beveiligingsmaatregelen getroffen om de kans op vervalsing te beperken, zoals het gebruik van holografische kenmerken op de creditcard. Ook dient de betaler een handtekening te zetten om de transactie te autoriseren. Deze handtekening wordt door de verkopende partij vergeleken met de handtekening op de creditcard. Creditcard maatschappijen achten frauduleuze Card Present transacties minder waarschijnlijk omdat een kwaadwillende persoonlijk aanwezig dient te zijn met een illegitieme creditcard. Wegens deze verminderde waarschijnlijkheid op compromittering kost de verwerking van Card Present transacties minder dan die van Card Not Present transacties. 11 Card Not Present In het geval dat een betaler producten of diensten aanschaft terwijl hij of zij deze niet persoonlijk afrekent, zal deze zelf een aantal gegevens moeten opgeven zodat de verkopende partij de transactie verder kan verwerken. Het is echter niet nodig om alle Track data op te geven. De betaler dient enkel de gegevens te verstrekken om het eigenaarschap van de creditcard te bevestigen en de desbetreffende transactie te autoriseren. Doordat de betaler niet in staat is om een fysieke handtekening te plaatsen, dienen bepaalde codes te worden doorgegeven waaruit blijkt dat de transactie legitiem is. De benodigde gegevens voor een CNP transactie zijn 12 : PAN data. Dit is nodig om de uitgevende bank en betaler te identificeren; 10 PCI Council, (2013) PaySimple, (2005) PCI Council, (2013) van 53

11 Expiration date. Hiermee kan worden gecontroleerd of het gaat om een geldige creditcard. Ook kan worden getoetst of de CVC code nog geldig is; Card Verification Code (CVC). Hiermee wordt de identiteit van de betaler vastgesteld Geld- en informatiestromen tijdens creditcard transacties Hieronder staat een voorbeeld van een creditcard transactie waarbij de betaler gebruik maakt van een POS terminal. Het proces is identiek aan een CNP transactie. Echter, in het geval van een CNP, levert de betaler zelf de benodigde informatie aan de verkopende partij. Het proces verloopt als volgt: 11 van 53

12 In de bovenstaande afbeelding 13 zijn de partijen aangegeven die zijn betrokken bij de verwerking van een creditcard transactie. De functie en verantwoordelijkheden van de verschillende partijen worden hieronder uitgewerkt. Betrokken partijen De volgende partijen zijn betrokken bij een creditcard transactie 14 : 13 Terlien, I., (2012). Vrije Universiteit Amsterdam: Continue Compliant Elektronisch Betalingsverkeer; 14 Creditcards.com, (2013) van 53

13 Cardholders De cardholder is de consument welke de creditcard gebruikt om een transactie te initieren. Het initiëren van een dergelijke transactie vereist niet per definitie de persoonlijke aanwezigheid van de consument en diens creditcard. Wanneer een aankoop plaatsvindt via het internet, volstaat het om handmatig een aantal controlegegevens in te voeren. 13 van 53

14 Merchants Dit betreft de verkopende partij. Deze partij accepteert creditcard data van de consument om te verifiëren of de transactie kan worden goedgekeurd. Issuer De Issuer betreft de bank van de consument. De consument bezit een rekening met een bepaald saldo. Ten tijde van een transactie controleert de Issuer of het aankoopbedrag binnen het gestelde limiet valt en keurt de transactie, afhankelijk van de uitkomst, wel of niet goed. Acquirer De Acquirer is de bank van de verkopende partij. Evenals de consument is de verkoper ook in het bezit van een rekening. Hierop wordt het geld uiteindelijk gestort. Payment Brand Network Het Payment Brand Network zijn de creditcard maatschappijen VISA, AMEX, JCB, Mastercard en Discover. Afgezien van bovenstaande vier partijen is in de praktijk een vijfde entiteit betrokken bij het verwerken van transacties. Deze entiteit is het Clearing House. Het Clearing House zorgt voor de administratieve afhandeling van transacties, houdt margeverplichtingen bij en zorgt voor levering van stukken nadat de verhandeling van goederen reeds heeft plaatsgevonden. Het uiteindelijke doel van het Clearing House is om het autorisatieproces en clearingproces af te handelen. Autorisatie en clearing Het autorisatieproces bestaat uit het verifiëren en autoriseren van de creditcard transactie. Het betaalsysteem verifieert bij de bank van de klant of de rekeninghouder gemachtigd is om de transactie uit te voeren. Indien dit wordt bevestigd, wordt geverifieerd of het overeengekomen bedrag van de eigen rekening mag worden afgeschreven. Nadat deze twee controles positief worden afgesloten, keurt de issuing bank de transactie goed. Het clearingproces betreft het vereffenen van de verzamelde transacties. Deze vereffening vindt plaats per bank en is een volledig geautomatiseerd proces. Transacties kunnen bij banken onderling plaatsvinden, maar ook intern. Interne transacties betreffen transacties tussen twee partijen die gebruik maken van dezelfde bank. In dergelijke gevallen is de bank geen geld verschuldigd aan andere banken. Het clearingproces is een admini- 14 van 53

15 stratief proces. Boekhoudkundig worden de wijzigingen doorgevoerd, maar de daadwerkelijke overschrijving vindt plaats in het proces voor settlement 15. Settlement Settlement is de uiteindelijke verrekening van transacties tussen de betrokken banken. Dit is een volledig geautomatiseerd proces dat plaats vindt via een centrale bank. De centrale bank debiteert de rekening van de Issuing bank en crediteert de rekening van de Acquiring bank. 15 Terlien, I., (2012). Vrije Universiteit Amsterdam: Continue Compliant Elektronisch Betalingsverkeer; 15 van 53

16 Payment Card Industry Data Security Standards (PCI DSS) framework Om de vertrouwelijkheid en integriteit van creditcard gegevens te borgen, is het van belang om tijdens het gehele proces de gegevens op een gedegen wijze te beveiligen. Het DSS framework richt zich daarom op de volgende twaalf aandachtsgebieden 17 : 16 Terlien, I., (2012). Vrije Universiteit Amsterdam: Continue Compliant Elektronisch Betalingsverkeer; 17 PCI Council, (2013). PCI Data Security Standard v3.0, November van 53

17 Het volledige framework kan worden gevonden op Hieronder volgt per requirement een beknopte samenvatting inzake de aard van de maatregelen en hun beoogde doelen. Requirement 1: Install and maintain firewall configurations Firewalls zijn componenten die netwerkverkeer controleren tussen een vertrouwde interne bron en een onbetrouwbare externe bron, met als doel de interne bronnen te beschermen. Netwerkverkeer welke niet voldoet aan vooraf gedefinieerde criteria wordt geblokkeerd. Ook is het mogelijk om een firewall in te zetten indien een organisatie gevoeligere netwerksegmenten heeft, zoals de Cardholder Data Environment (CDE). In het CDE worden creditcard gegevens verwerkt. Requirement 2: Vendor-supplied defaults IT componenten worden vanuit de fabriek vaak voorzien van standaard inloggegevens. Standaard wachtwoorden van verschillende fabrikanten zijn laagdrempelig verkrijgbaar op openbare media. In het geval dat een dergelijk component in de productieomgeving wordt genomen terwijl het standaard wachtwoord nog in gebruik is, kunnen buitenstaanders op een eenvoudige wijze toegang krijgen tot deze component en zo tot de productieomgeving. 17 van 53

18 Requirement 3: Protect stored cardholder data Organisaties dienen alleen die gegevens op te slaan die daadwerkelijk vereist zijn om de diensten te verlenen. De opgeslagen data dient dusdanig te worden beveiligd dat de gegevens onbruikbaar zijn voor een aanvaller. Beveiligingsmechanismes zoals encryptie, truncation 18, maskeren en hashing 19 zijn cruciaal om de vertrouwelijkheid van creditcard gegevens te kunnen beschermen. Via encryptie worden gegevens versleuteld, waardoor de data niet meer als leesbare tekst beschikbaar is. Om gegevens te kunnen decrypten dient men in bezit te zijn van het algoritme en de sleutel. Truncation houdt in dat bepaalde delen van een PAN niet worden opgeslagen, om het risico van ontvreemding van de volledige PAN data te mitigeren. Hierdoor kan de interne organisatie echter zelf ook niet de volledige PAN achterhalen, mocht hier behoefte toe zijn. Maskeren houdt in dat bepaalde getallen uit het PAN worden weggelaten of worden getoond als 0. De mate waarin maskering dient te worden toegepast is afhankelijk van de aard van de organisatie. Men mag echter maximaal de eerste vier en laatste zes cijfers zichtbaar laten van het PAN. Het liefst wordt ook de zichtbare PAN tot een minimum beperkt. Hashing houdt in dat een bepaalde waarde wordt gegenereerd uit een verzameling van data. Dit vindt plaats aan de hand van een cryptografisch algoritme en wordt gezien als digitale vingerafdruk. De gegenereerde waarde bevat niet meer de gegevens welke gebruikt kunnen worden voor frauduleuze handelingen. Mocht er een inbreuk plaatsvinden waardoor deze aangepaste gegevens zichtbaar worden voor een buitenstaander, dan kunnen deze niet worden gebruikt voor fraude. Requirement 4: Encrypt transmissions Het aftappen van bekabelde verbindingen of het compromitteren van draadloze omgevingen biedt voor kwaadwillenden een kans om netwerkverkeer te onderscheppen en te inspecteren, en zo mogelijk creditcard gegevens te kunnen bemachtigen. Daarom dienen vertrouwelijke gegevens te worden versleuteld bij transmissie. 18 VISA, (2010) Kelley, D., Moyle, E., (2010). PCI-DSS-compliance. 18 van 53

19 Requirement 5: Anti-virus software Malware zoals virussen, wormen en Trojans kunnen op verschillende manieren binnendringen in een organisatie. Mailverkeer, websites, geïnfecteerde bijlagen of zelfs besmette externe opslagmedia zijn enkele voorbeelden hiervan. Door hedendaagse trends zoals Bring Your Own Device (BYOD) worden privé apparaten gekoppeld aan bedrijfsnetwerken. Dit resulteert in een verhoogde kans tot besmetting en vormt derhalve een potentieel gevaar voor de interne organisatie. Om de interne organisatie tegen malware te beschermen, dienen alle relevante systemen te worden voorzien van anti-virus software die voortdurend is voorzien van de nieuwste virusdefinities. Requirement 6: Develop and maintain secure platforms Kwaadwillenden kunnen gebruik maken van kwetsbaarheden binnen informatiesystemen, applicaties of netwerkcomponenten om zichzelf toegang te verschaffen tot de functionaliteit en inhoud van informatiesystemen. Doorgaans worden kwetsbaarheden binnen programmatuur of componenten door de leverancier verholpen middels patches of hotfixes. Alle systemen dienen te zijn voorzien van de laatste beveiligingsupdates. Dit beschermt de interne omgeving tegen kwaadwillenden die de kwetsbaarheden willen exploiteren. Requirement 7: RBAC Het inzien van gevoelige informatie dient uitsluitend mogelijk te zijn voor personeel die hier een gegronde reden toe heeft. De interne organisatie wordt verplicht maatregelen te treffen om de fysieke en logische toegang tot dergelijke gevoelige informatie tot een minimum te beperken. Hierbij wordt bij voorkeur Role Based Access Control (RBAC) gebruikt. Rollen en functies dienen te worden gedefinieerd en goedgekeurd door het management. Vervolgens dienen de rechten en privileges op groepsniveau te worden toegekend aan de medewerkers. Door rechten en privileges centraal toe te kennen en te bewaken, houdt men de rechtenstructuur overzichtelijk, inzichtelijk en beheersbaar. Requirement 8: Unique IDs Medewerkers dienen te beschikken over een uniek en puur persoonlijk account, waarmee kan worden ingelogd. Door een uniek accounts toe te wijzen aan ieder personeelslid kan iedere handeling worden herleid naar de betreffende individuele gebruiker. Het is niet toegestaan om gebruik te maken van accounts die door meerdere personen worden gedeeld, zoals generieke accounts, groepsaccounts of gedeelde accounts. Het gebruik van gedeelde accounts maakt het moeilijk bepaalde handelingen te herleiden naar een individuele gebruiker, mochten er ongewenste handelingen hebben plaatsgevonden. 19 van 53

20 Requirement 9: Physical security Fysieke toegang tot informatiesystemen of opslagmedia biedt gelegenheid voor een kwaadwillende om creditcard gegevens te bemachtigen. Derhalve is het van belang om de fysieke toegang tot dergelijke bronnen voor zowel interne als externe personeelsleden tot het uiterste minimum te beperken. Het toewijzen van toegangsrechten binnen de organisatie dient op eenzelfde wijze als voor requirement 7 te verlopen. Verschillende functieprofielen en rollen hebben behoefte aan verschillende rechten. Het management dient een analyse uit te voeren op de omgeving en specifieke rechten toe te kennen aan de medewerkers op basis van hun rol en functie. Requirement 10: Tracking and monitoring Het vastleggen van geautomatiseerde handelingen en gebruikersactiviteiten zijn van belang om een data breach op te merken, te minimaliseren of te voorkomen. De vastlegging van activiteiten binnen een omgeving biedt de mogelijkheid om afwijkingen te detecteren. Vervolgens kan de organisatie hier actie op ondernemen. Ook zijn logbestanden cruciaal om onderzoek te verrichten nadat een data breach heeft plaatsgevonden. Requirement 11: Test security systems and processes Voortdurend worden nieuwe kwetsbaarheden ontdekt. Fabrikanten brengen steeds nieuwe revisies van programmatuur en informatiesystemen uit om de bij hen bekende kwetsbaarheden te repareren. Deze updates kunnen echter weer nieuwe kwetsbaarheden introduceren. Componenten dienen daarom uitgebreid te worden getest alvorens een nieuwe versie binnen de productieomgeving mag worden geïmplementeerd. Het kan echter voorkomen dat een component een kwetsbaarheid bevat waarvoor de fabrikant nog geen patch heeft uitgebracht. Dergelijke zwakheden kunnen worden geëxploiteerd door kwaadwillenden om de interne omgeving te compromitteren. Daarom dienen bestaande componenten periodiek te worden getest om de veiligheid van de interne omgeving te bewaken. Requirement 12: Information security policy Een helder en duidelijk informatiebeveiligingsbeleid draagt bij aan het informeren van het personeel inzake de beveiligingsverantwoordelijkheden binnen de organisatie en verhoogt de security awareness. Hiermee wordt ook de betrokkenheid van het management benadrukt bij het personeel. Conclusie Requirements Door te conformeren aan bovenstaande twaalf requirements wordt de kans op een data breach beperkt. Indien onverhoopt toch een data breach mocht plaatsvinden, zorgen de 20 van 53

21 maatregelen ervoor dat, tot op zekere hoogte, kan worden nagegaan hoe dit is ontstaan en welke persoon verantwoordelijk kan worden gehouden voor de compromittering. Self Assessment Questionnaire De uitvoering van een complete on-site assessment door een bevoegd QSA, gecombineerd met het opstellen van de daaruit voortvloeiende rapportages, vergt een aanzienlijke hoeveelheid tijd en geld. Het kan voorkomen dat het transactievolume van een winkelier niet toereikend is om de kosten van een dergelijke assessment te rechtvaardigen. De winkeliers worden echter vanuit de PCI Council toch verplicht gesteld zich te conformeren aan het framework. De PCI Council heeft het daarom toegestaan dat, afhankelijk van het aantal transacties gecombineerd met de type dienstverlening van een organisatie, men zelf een versoepelde versie van een assessment uit mag voeren. Een dergelijke organisatie dient jaarlijks een Self Assessment Questionnaire (SAQ) op te stellen en in te dienen. Gezien de verschillende typen dienstverleningen zijn verschillende typen SAQ s opgesteld. Hieronder staat een door de PCI Council beschikbaar gesteld overzicht dat aangeeft welke SAQ van toepassing is op een organisatie 20 : 20 PCI Council, (2013) van 53

22 De PCI Council beboet service providers welke wel creditcard transacties verwerken, maar zich niet conformeren aan PCI DSS. Hierbij twee verschillende types van boetes. De eerste boete betreft het weigeren om te voldoen aan PIC DSS. De tweede boete wordt opgelegd indien een data breach optreedt, ongeacht of de organisatie wel of niet voldoet aan PCI DSS 21. De hoogte van dergelijke boetes zijn: 21 FocusonPCI.com, (2009) van 53

23 2.4. Achtergrondinformatie verschillende frameworks van de PCI Council Er is steeds een keten van partijen betrokken bij het verwerken van een creditcard transactie. Tijdens een dergelijke transactie worden gevoelige gegevens over het netwerk verstuurd. Gezien de kosten van een dedicated leased line is het aantrekkelijker voor organisaties om te kiezen voor een reguliere WAN verbinding. Dit houdt echter in dat gevoelige gegevens over een relatief onveilig medium wordt verstuurd en derhalve additionele bescherming vereisen. Om het gehele transactieproces te beveiligen zijn vanuit de PCI Council meerdere frameworks opgesteld welke zijn toegespitst op verschillende elementen binnen het proces. Op het moment van schrijven zijn de volgende frameworks beschikbaar gesteld 22 : PIN Transaction Security: Dit framework beschrijft de eisen vanuit security management, processing en transmissie van PIN data tijdens betalingen bij Point of Sales (POS) apparaten. Het gaat hierbij om geldautomaten en (on)bemande POS terminals. Payment Card Industry Data Security Standards (PCI DSS): Dit framework beschrijft de eisen waaraan een dienstverlener zich dient te conformeren in het geval deze creditcard gegevens opslaat, verwerkt of verstuurt. 22 PCI Council, (2013) van 53

24 Payment Application Data Security Standards (PA DSS): Dit framework is een deelverzameling van het reguliere PCI DSS en is geënt op de applicaties welke de daadwerkelijke creditcard gegevens verwerken. Het is van belang te toetsen of deze applicaties deugdelijk zijn geïmplementeerd en daadwerkelijk worden bijgewerkt. Hoewel het van cruciaal belang is dat gevoelige data beveiligd wordt verstuurd over het WAN, dient men tevens de interne organisatie dusdanig in te richten dat de kans op compromittering tot een minimum wordt beperkt. Deze normen zijn van toepassing op alle entiteiten binnen het elektronische transactieverkeer, namelijk de merchants, processors, acquirers, issuers en overige service providers. PCI DSS geldt echter enkel als een baseline. Het staat organisaties vrij om deze regels verder uit te breiden mits deze niet conflicteren met de vigerende normatiek van PCI DSS. Het doorvoeren van additionele maatregelen heeft geen verdere consequenties inzake de compliance van het audit object. Lifecycle DSS framework Om organisaties doorlopende bescherming te bieden tegen de meest recente kwetsbaarheden, brengt de PCI Council iedere 36 maanden een nieuwe versie uit van het DSS framework. Indien tussentijds behoefte is aan aanvullende maatregelen, brengt de PCI Council white papers of aanvullende richtlijnen uit. Het uitbrengen van aanvullend materiaal vindt echter alleen plaats wanneer door de praktijk niet langer kan worden gewacht op een nieuwe revisie van het DSS framework. Gedurende deze periode van 36 maanden wordt door de PCI Council stappen ondernomen om nieuwe risico s en kwetsbaarheden in kaart te brengen en te analyseren. Op basis van de bevindingen worden in samenspraak met de stakeholders nieuwe normen opgesteld, of bestaande normen aangepast om de nieuwste gevaren te mitigeren of te vermijden. De levenscyclus van het framework wordt in onderstaande afbeelding verduidelijkt: 24 van 53

25 Zoals bovenstaande afbeelding beschrijft, bestaat de levensloop van het DSS framework uit de volgende acht stappen 23 : Standards Published Het publiceren van een nieuwe standaard vindt plaats in oktober voorafgaand aan het jaar dat de standaard effectief wordt. 23 PCI Council, (2013) van 53

26 Standards Effective Het eerste jaar dat de nieuwste versie van het DSS framework is uitgebracht, staat de PCI Council toe om assessments te verrichten conform de voorlaatste of nieuwste revisie. De reden voor deze flexibiliteit vanuit de PCI Council is om organisaties te ontzien indien deze organisatorische, procedurele of technische maatregelen dient te implementeren om compliant te zijn aan de nieuwe normatiek. De auditee krijgt één jaar respijt om de wijzigingen alsnog door te voeren. Market Implementation Tijdens de fase Market Implementation wordt de auditee in gelegenheid gesteld om de interne organisatie aan te passen, zodat kan worden voldaan aan de aangepaste normatiek. Feedback Begins Stakeholders worden in de gelegenheid gesteld om hun ervaringen met de nieuwste versie van het DSS framework terug te koppelen aan de PCI Council. Tevens wordt gevraagd de visie vanuit de PCI Council kenbaar te maken en verbeteringen voor het komende framework door te voeren. Old standards Retired Op 31 december van het tweede jaar wordt de voorgaande versie van het framework uitgefaseerd. Nieuwe audits dienen enkel plaats te vinden conform de nieuwste versie. Assessments op basis van de voorlaatste versie van het framework worden in dit stadium door de PCI Council niet meer geaccepteerd. Feedback Review Alle feedback van de stakeholders wordt geïnventariseerd en geanalyseerd. Dit vindt plaats tijden het tweede jaar, van april tot en met augustus. De feedback kan doorgaans op drie manieren worden gecategoriseerd: Opheldering: De bewoording van een norm is onduidelijk en dient duidelijker te worden geformuleerd; Benodigde achtergrondinformatie: De auditor begrijpt de achterliggende gedachte van de norm niet en hoopt duidelijkheid hierover te krijgen, zodat gerichter bewijs kan worden opgevraagd; Voorstel tot nieuwe norm: De stakeholder geeft aan dat een nieuwe situatie is voorgekomen welke niet ade- 26 van 53

27 quaat wordt afgedekt binnen het bestaande normenkader. Hierbij kan men een nieuwe norm voorstellen. Draft Revisions Op basis van de bevindingen en analyse van de voorgaande fase wordt een nieuwe conceptversie van het huidige framework opgesteld. Dit concept wordt intern besproken binnen de verschillende werkgroepen van de PCI Council. Dit vindt plaats in november van het tweede jaar tot en met april van het derde jaar. Final Review Gedurende deze laatste fase wordt de nieuwste revisie binnen de PCI Council verspreid en wordt ook het Board of Advisors betrokken. Deze partijen kunnen vervolgens feedback geven. Op basis van deze laatste terugkoppelingen worden de laatste wijzigingen aan het framework doorgevoerd en wordt een beknopte samenvatting van alle wijzigingen verstuurd naar alle stakeholders, waaronder de QSA s. Deze fase vindt plaats van mei tot juli van het derde jaar Compliance Tijdens een DSS audit wordt van de auditor verwacht dat deze de resultaten van de assessment vastlegt conform de regels van de PCI Council. De resultaten volgen uit observaties, interviews, bestuderen van documentatie en het vergaren van samples. Vanuit de PCI Council wordt een van de volgende viertal levels aan organisaties toegewezen 24 : Merchant Level Description Any merchant regardless of acceptance channel processing over 6M Visa transactions per year. Any merchant that Visa, at its sole discretion, determines should meet the Level 1 merchant requirements to minimize risk to the Visa system. Any merchant regardless of acceptance channel processing 1M to 6M Visa transactions per year. Any merchant processing 20,000 to 1M Visa e-commerce transactions per year. Any merchant processing fewer than 20,000 Visa e-commerce transactions per year, and all other merchants regardless of acceptance channel processing up to 1M Visa transactions per year. 24 VISA Inc., (2014) van 53

28 De vastlegging van een assessment is afhankelijk van de opdracht. Hoe groter het aantal verwerkte creditcard transacties, des te uitgebreider dient de assessment te zijn. Een organisatie met grotere hoeveelheden transacties wordt immers een interessanter doel voor kwaadwillenden. De eisen aan de verschillende merchant levels zijn als volgt: Level / Tier1 Merchant Criteria Merchants processing over 6 million Visa transactions annually (all channels) or Global merchants identified as Level 1 by any Visa 1 region Merchants processing 1 million to 6 million Visa transactions annually (all channels). Merchants processing 20,000 to 1 million Visa e-commerce transactions annually. Merchants processing less than 20,000 Visa e-commerce transactions annually and all other merchants processing up to 1 million Visa transactions annually. Validation Requirements Annual Report on Compliance ( ROC ) by Qualified Security Assessor ( QSA ) or Internal Auditor if signed by officer of the company. Quarterly network scan by Approved Scan Vendor ( ASV ) Attestation of Compliance Form. Annual Self-Assessment Questionnaire ( SAQ ). Quarterly network scan by ASV Attestation of Compliance Form. Annual SAQ. Quarterly network scan by ASV Attestation of Compliance Form Annual SAQ recommended. Quarterly network scan by ASV if applicable. Compliance validation requirements set by merchant bank. Een Approved Scan Vendor (ASV) is een organisatie dat vulnerability scans uitvoert op omgevingen van merchants en service providers. Dit brengt eventuele tekortkomingen in de beveiliging aan het licht. Level 1 merchant dienen een volledige assessment door een QSA assessor uit te laten voeren. Het resultaat hiervan is een Report on Compliance (RoC) en Attestation of Compliance (AoC). De overige merchants dienen enkel een Self-Assessment Questionnaire (SAQ) in te dienen. Zowel de RoC, AoC en SAQ worden in onderstaande paragrafen verder uitgediept. Report on Compliance 28 van 53

29 Een ROC bevat, per toepasbare norm, de resultaten van de assessment 25. Dit document wordt beschikbaar gesteld aan de PCI Council en aan de Acquiring bank. Gezien de vertrouwelijke aard van de informatie, wordt dit document niet aan andere partijen ontsloten. Om de andere partijen te kunnen bewijzen dat men in het bezit is van een PCI DSS certificaat, stelt de auditor naast de RoC ook een Attestation of Compliance (AoC) op. Attestation of Compliance Dit document geeft een beknopte en geanonimiseerde samenvatting van de scope van het onderzoek en de resultaten hiervan. Het AoC bevat geen vertrouwelijke informatie en kan derhalve worden ontsloten aan andere partijen. Self-Assessment Questionnaire Indien door een organisatie geen ROC hoeft te worden opgesteld, volstaat het om een SAQ in te dienen. De PCI Council heeft echter verschillende soorten SAQ s uitgebracht afhankelijk van het type dienstverlening. Hieronder volgt een overzicht van de typen SAQ s met een bijbehorende uitleg 26 : SAQ Validation Type 1 A 2 B 3 B 4 C 5 D SAQ Form Description Card-not-present (e-commerce or mail/telephone-order) merchants, all cardholder data functions outsources. Imprint-only merchants with no electronic cardholder data storage Stand-alone dial-up terminal merchants, no electronic cardholder data Merchants with payment application systems connected to the Internet, no electronic cardholder data storage All other merchants (not included in descriptions for SAQs A-C above) and all service providers defined by a payment brand as eligible to complete an SAQ Scan Required? NO NO NO YES YES De interne organisatie dient, al dan niet na afstemming met een QSA, de aard van de dienstverlening te analyseren alvorens een type SAQ wordt geselecteerd en verwerkt. 25 PCI Council, (2013). PCI_DSS_v3_ROC_Reporting_Template.docx 26 PCI Council, (2013) van 53

30 3. Bevindingen van praktijkstudie Het afgelopen jaar zijn verschillende organisaties aangevallen door hackers welke creditcard gegevens hebben ontvreemd. Een tweetal van deze aanvallen worden in de komende paragrafen geanalyseerd. De praktijkstudie verliep onder toezicht van, controle door en overleg met de QSA s binnen Noordbeek. Hierbij werd gebruik gemaakt van publiekelijk beschikbare documentatie De eerste casus betreft de diefstal van circa 104 miljoen creditcard gegevens. Dit vond begin 2014 plaats in Zuid-Korea en had betrekking op 20 miljoen Zuid-Koreaanse burgers. De tweede casus betreft de tweede grootste retailer van Amerika. Ondanks de PCI DSS compliance van deze retailer, zijn de creditcard gegevens van circa 110 miljoen klanten gestolen. Beide casussen worden hieronder uitgediept en geanalyseerd Casus 1: KB Kookmin Card, Lotte Card, en NH Nonghyup Card Aanklagers in Zuid-Korea constateerden op 8 januari 2014 dat de gegevens van circa 104 miljoen creditcards waren ontvreemd, die betrekking hebben op 20 miljoen Zuid- Koreanen 27. Dit bericht bereikte de media op 20 januari Beschrijving van de inbraak De drie grootste creditcardmaatschappijen binnen Zuid-Korea, te weten KB Kookmin Card, Lotte Card en NH Nonghyup Card, beschikken ieder over een eigen database voor hun klantgegevens. Het aanvragen van een creditcard en het, al dan niet technisch, bijwerken en onderhouden van de database vond plaats bij deze maatschappijen. Een IT medewerker van een gezamenlijke onderaannemer, het agentschap Korean Credit Bureau (KCB), heeft de volledige databases met vertrouwelijke informatie over de creditcards gekopieerd 28. In de literatuur is weinig te vinden over de daadwerkelijke gang van zaken. De IT medewerker wordt omschreven als: prosecutors claim that an employee of Korea Credit Bureau, who was ironically responsible for new software development to detect creditcard fraud, 27 BBC, (2014) Panda Security (2014) van 53

31 stole the data in 2012 using a USB device. Wij hebben de indruk dat de IT medewerker op de een of andere wijze toegang had tot de databases waar de desbetreffende data was opgeslagen 29. Deze inbreuk op de vertrouwelijkheid van de klantgegevens heeft ertoe geleidt dat vanuit de financiële toezichthouder aanvullende regelgeving is uitgebracht om dergelijke incidenten in de toekomst te voorkomen. De veronderstelde schade De gestolen data werd door deze IT medewerker doorverkocht aan marketingbedrijven. Nadat de IT medewerker in hechtenis werd genomen, werd door de regering een onderzoek ingesteld naar de omvang en gevolgen van de diefstal. Het onderzoek wees uit dat geen Card Verification Code (CVC) 30 was ontvreemd 31. De CVC is een van de benodigdheden om transacties te kunnen verrichten zonder de fysieke creditcard. Door het ontbreken van de CVC wordt de kans op financiële fraude door de onderzoekers onwaarschijnlijk geacht. Ook hebben de onderzoekers tot 17 januari 2014 geen meldingen, aangiftes of overige gebeurtenissen waargenomen welke voortvloeide uit de diefstal van de gegevens. Analyse: te hoge autorisaties De creditcardmaatschappijen hebben het agentschap Korean Credit Bureau (KCB) toegang verleend tot hun databases 32. De werkzaamheden van dit agentschap betreffen het controleren van de kredietwaardigheid van consumenten. Om deze controle uit te voeren vraagt het agentschap gegevens bij de creditcardmaatschappijen op van de consument in kwestie. Dergelijke controles voorkomen dat consumenten overeenkomsten aangaan waarvan zij de financiële lasten niet kunnen dragen. Vanzelfsprekend dient de toegang tot dergelijke vertrouwelijke informatie zeer strikt te worden beheerst en gecontroleerd. Een derde partij dient enkel toegang te verkrijgen tot informatie welke benodigd is om de overeengekomen werkzaamheden te kunnen verrichten. Om de kredietwaardigheid van consumenten te controleren heeft KCB slechts een beperkt aantal gegevens nodig, zoals het aantal creditcards, de geassocieerde schulden en de inkomsten per consument. Het inzien van informatie zoals CVC s, het volledige Primary Account Number (PAN), de expiratiedata van de creditcards en track data 29 ANO, (2014) Leyden, J., (2014) Databreaches.net, (2014) Financial Services Commission, (2014). T/F Formed to Respond to Personal Information Leaks, _-_TF on Data Leaks. 31 van 53

32 zijn niet relevant voor het onderzoek door KCB. Het ontsluiten van dergelijke informatie kan zelfs als een potentieel gevaar worden gezien. Autorisatiebeheer is een belangrijk middel om toegang te beperken. De creditcardmaatschappijen en het KCB dienen dit contractueel goed te regelen. Wij hebben in de literatuur hier geen verdere informatie over kunnen vinden. Bij het verstrekken van toegang tot vertrouwelijke gegevens aan externen worden normaliter ook contractuele afspraken gemaakt over het bewaken van het gedrag van de betrokken eindgebruikers. Hierbij worden afwijkingen en bijzonderheden gemonitord. Hoewel een eindgebruiker valide redenen kan hebben om gegevens in te kunnen zien, kan het kopiëren van een hele database als afwijkend gedrag worden beschouwd. Door op dergelijke acties te monitoren, is men in staat snel en passend te reageren. Nadat de breuk was gedetecteerd, werd door de hoogste Koreaanse financiële toezichthouder Financial Services Commission (FSC) een Taskforce opgericht 33. De Taskforce kreeg de opdracht om de oorzaak van de breuk te achterhalen. Onderzoek van de Taskforce wees uit dat een medewerker van het KCB vanwege zijn werkzaamheden hoge autorisaties had gekregen binnen de IT omgeving van drie creditcardmaatschappijen. De medewerker in kwestie werd ironisch genoeg ingehuurd om creditcardfraude tegen te gaan 34. Onderzoek van de Taskforce toont aan dat de gegevens binnen de database niet waren versleuteld of gemaskeerd. Hierdoor kon de medewerker alle informatie als clear-tekst inzien. De database werd vervolgens onversleuteld opgeslagen op een extern opslagmedium, namelijk een USB-stick. Dit incident stimuleerde FSC nieuwe richtlijnen uit te vaardigen om de kans op een soortgelijke inbreuk te beperken. Ook werden strengere sancties opgelegd aan instanties waarbij zo een inbreuk plaatsvindt 35. Conclusie PCI DSS bevat diverse maatregelen om de vertrouwelijkheid en integriteit van de creditcard gegevens te borgen. Dit framework geldt echter enkel voor creditcards van de vijf grootste creditcardmaatschappijen van Amerika. De wet- en regelgeving rondom de beveiliging van Zuid-Koreaanse creditcard gegevens vallen onder de verantwoordelijkheid 33 Offshore Publications Limited, (2014) Bloomberg, (2014) million-korean-credit-card-accounts; 35 Financial Services Commission, (2014). Comprehensive Measures to Protect Personal Data in the Financial Sector, _-_Personal_Data_Protection. 32 van 53