PSD2 biedt volop kansen voor innovatie, mits API’s goed worden beschermd

Open Banking is al jaren een belangrijk thema in de financiële sector. Centraal hierbij staat de Application Programming Interface (API) die andere bedrijven de kans geeft om transactiegegevens van bankklanten te benutten en voor nieuwe apps en diensten te benutten. Maar juist die nieuwe spelers hebben vaak weinig ervaring met het beschermen van API’s. Frederik Mennes van VASCO Data Security legt uit hoe we kunnen voorkomen dat de voordelen van PSD2 omslaan in een vrijspel voor criminelen.

Banken zijn op basis van de Europese PSD2-richtlijn verplicht een interface aan te bieden aan zogeheten derde partijen. Het idee is dat deze Third Party Providers of TPP’s via deze interface toegang krijgen tot de betaalgegevens van bankklanten, als zij hiervoor toestemming geven.

Banken kunnen op twee manieren in deze interface voorzien: via een nieuw ontwikkelde API of via een bestaande interface. Denk hierbij aan een interface die toegang biedt tot internetbankieren of mobiel bankeieren voor klanten van de bank. Kiest men voor een nieuwe API, dan dient deze te voldoen aan ISO 20022.

API’s beschermen

De PSD2-richtlijn stelt strenge eisen ten aanzien van authenticatie als een klant toegang wil tot zijn rekening of een betaling wil uitvoeren. Het is dus erg belangrijk om goed na te denken over de manier waarop authenticatie in een interface voor TPP’s wordt opgenomen.

Een andere eis die PSD2 stelt, is dat het uitwisselen van gegevens tussen de bank en TPP gegarandeerd moet zijn. Dat geldt ook voor de situatie waarbij de klant via een door een TPP ontwikkelde app bankgegevens gebruikt. De bank zal in dat geval deze gegevens moeten verifiëren.

Liever een nieuwe interface

Veel banken lijken er de voorkeur aan te geven om een nieuwe programmeerinterface voor TPP-toepassingen te ontwikkelen. Daarbij moet men een aantal risico’s in ogenschouw nemen en de juiste authenticatiemethode kiezen. Hierbij moet rekening worden gehouden met het type API dat wordt gekozen.

Bij het toepassen van een embedded of ingebouwd model voor authenticatie voert de gebruiker zijn toegangsgegevens in in de TPP-app of op de website van de TPP. Deze info wordt vervolgens voor bevestiging doorgestuurd naar de bank. Deze procedure kan daarmee vatbaar zijn voor phishing- of voor man-in-the-middle-aanvallen. Bovendien kan de end-to-end encryptie van de gegevens tussen gebruiker en bank niet worden gegarandeerd, aangezien er een derde speler meedoet in de overdracht. Banken zijn echter ook in dit soort gevallen aansprakelijk voor schade die een klant oploopt als gevolg van fraude. Daarom is het verstandig als banken kiezen voor authenticatie van de gebruiker zelf. In dat geval kan een crimineel dus niet op het authenticatieproces zelf ingrijpen.

Daarnaast kan gebruik worden gemaakt van de authenticatiediensten van een externe partij. Ook kan de info voor authenticatie ter verificatie worden doorgestuurd naar de bank zelf. In deze  gevallen vult de gebruiker zijn inloggegevens in in de app van de bank of op de website van de bank. Hierdoor blijft de bank dus direct betrokken bij de authenticatie. Hierbij kan ook het bekende 3D Secure-protocol worden toegepast, maar deze heeft als nadeel dat deze procedure een iFrame ofwel pop-up venster opent zonder adresbalk. Het is dan voor de gebruiker erg lastig om vast te stellen wie hem nu precies vraagt om betalingsinformatie in te voeren.

Risico’s door TPP’s

Nu banken verplicht zijn om TPP’s toegang tot rekeninginformatie van klanten te geven, ontstaan drie nieuwe veiligheidsrisico’s:

• Verlies van gebruikersgegevens – Aangezien TPP’s de financiële informatie van klanten opslaan, kunnen kwetsbaarheden in hun applicaties onbedoeld criminelen toegang tot deze gegevens verlenen. Banken moeten dus maatregelen nemen om de gegevens die zij met TPP’s delen te beschermen.
• Frauduleuze handelingen door gecompromitteerde of kwaadwillige TPP’s – Een gehackte of kwaadaardige TPP kan criminelen toegang bieden tot klantgegevens. Maar denk ook aan risico’s als een ontevreden medewerker van een TPP zijn toegang tot deze gegevens misbruikt.
• Inlogproblemen met gecompromitteerde of kwaadwillige TPP’s – Een aanval van criminelen op een TPP kan betekenen dat deze provider een groot aantal ongeldige verzoeken voor authenticatie naar de bank stuurt. Hierop kan de bank reageren door deze bankrekening tijdelijk te blokkeren, met als gevolg dat de klant niet meer bij zijn rekening kan.

Goede bescherming

Gezien de risico’s moeten banken zich goed beschermen. Hierbij kunnen zij van een vijftal mogelijkheden gebruik maken.

Dat is allereerst TRA ofwel Transaction Risk Analysis. Banken zijn verplicht bij elke transactie een risico-analyse te maken. Daarmee kan bijvoorbeeld worden voorkomen dat met een gestolen kredietkaart wordt betaald. Deze analyse bewijst ook goede diensten bij het vaststellen in hoeverre sprake is van ongebruikelijke transacties of ‘vreemde’ oproepen naar de interface van de TPP. Deze analyse vindt in real-time plaats. Interessant genoeg kan TRA ook helpen bij het beoordelen van de kwaliteit van de manier waarop de API is geïmplementeerd. Als frauduleuze transacties of ongewoon gebruikersgedrag vaak voorkomen, wijst dit veelal op zwakke punten in die implementatie.

Een tweede belangrijke optie voor banken is het kiezen van het juiste authenticatiemodel. Zoals eerder aangegeven hebben de diverse autheticatiemodellen ieder hun eigen kenmerken, en daarmee dus gevolgen voor de beveiliging. Voor de bank is het veelal het beste om een model te gebruiken dat het authenticatieproces bij de bank zelf of bij een externe security provider  neerlegt. Hierdoor blijft de bank immers rechtstreeks met de gebruiker communiceren en niet via de TPP. Ook komt op deze manier meer informatie beschikbaar voor een Transaction Risk Analysis.

Een derde punt is dat banken de gegevensuitwisseling met de TPP’s kunnen beschermen. Denk hierbij aan wederzijdse authenticatie tussen bank en TPP door gebruik van bijvoorbeeld SSL/TSL-protocollen. Implementatie van deze protocollen is echter niet eenvoudig. Aan de serverkant komen regelmatig configuratiefouten voor, terwijl ontwikkelaars bij gebruik van deze protocollen certificaten vaak niet op de juiste manier valideren.

Een andere mogelijkheid waarmee banken hun API’s kunnen beschermen, is het aanvragen van een veiligheidsbeoordeling van de TPP. PSD2 bevat gedetailleerde richtlijnen voor het vaststellen, uitvoeren en monitoren van beveiliginsgmaatregelen waaraan TPP’s moeten voldoen.

Een laatste punt: banken kunnen veiligheidsrisico’s bij de implementatie van de API voorkomen. Zo kan men zich tegen injectieaanvallen beschermen door ervoor te zorgen dat de component in de API die voor het parsen van de JSON- of XML-data zorgt goed is beschermd. Ook is het belangrijk dat veel aandacht wordt besteed aan wat wel genoemd wordt ‘input sanitization’.

Innovatie en risico’s

De door PSD2 vereiste programmeerinterfaces gaan ongetwijfeld leiden tot de komst van nieuwe innovatieve diensten en apps. Tegelijkertijd moeten we echter voorkomen dat deze voordelen omslaan in nadelen doordat criminelen toegang krijgen tot gegevens van klanten en transacties. Banken, maar zeker ook Third Party Providers, dienen zich dus heel goed bewust te zijn van de risico’s en ze moeten bovendien voldoende bescherming bieden.

Dit is een ingezonden bijdrage van Frederik Mennes, Senior Manager Market & Security bij VASCO Data Security