GlobalSign Blog

12 apr. 2019

Cyberbeveiliging in partnerschappen tussen financiële instellingen en FinTech-bedrijven

We stellen Jon Scheele aan u voor. Hij werkt als consultant en trainer met financiële instellingen over op API gebaseerde partnerschappen. Hij is gestart met een reeks blog artikelen voor financiële instellingen en FinTech-bedrijven om hen te helpen omgaan met de opkomende technologieën en regelgevende landschap van de EU-markt.

Partnerschappen tussen financiële instellingen (FI) en FinTech-bedrijven (start-ups gebaseerd op financiële technologie) moeten verder gaan dan de waarde propositie voor de klant. Strikte regelgeving, zoals eIDAS voor de beveiliging van elektronische transacties, PCI DSS waarin werd vastgelegd hoe betalingsgegevens kunnen worden verzameld, bewaard en georganiseerd, en GDPR inzake de privacy van klanten, vereist dat cyberbeveiliging wordt geïntegreerd in alle fasen van het traject van de klant.

Om de gegevens en financiële activa van klanten van begin tot einde te beveiligen, moeten alle partnersystemen verificatie en autorisatie, gegevensbeveiliging, systeemintegriteit en proactieve detectie van en reactie op cyberbeveiligingsincidenten omvatten. Aangezien Application Programming Interfaces (API's) cruciaal zijn voor partnerconnectiviteit, is de implementatie van hoogwaardige API-beveiliging een absolute vereiste.

Wie is hier echter verantwoordelijk voor? Of u deze blog nu leest als FI of FinTech-bedrijf, dit is een moeilijke evenwichtsoefening. Laten we van het volgende uitgaan:

De Opportuniteit

Een gezamenlijk rapport van PwC UK en het Open Data Institute voorspelt inkomsten mogelijkheden van £ 7,2 miljard door Open Banking tegen 2022. Dit omvat marginale inkomsten van nieuwe producten en diensten, alsook de bestaande inkomsten van gevestigde exploitanten die in gevaar zijn als ze zich niet aanpassen.

Door API's ter beschikking te stellen van FinTech-partners in hun doelmarktsegmenten, beschikken banken over meer mogelijkheden om contact te leggen met klanten en transacties met hen aan te gaan. Uit een onderzoek bij 39 toonaangevende banken, uitgevoerd door PwC in 2017 in zeventien landen, bleek dat “92 percent van de banken stelde dat partnerschappen met niet-banken zeer belangrijk of belangrijk zullen zijn in de toekomst” en dat “71 percent van de banken akkoord of volledig akkoord gaat dat partners/samenwerking vereist zullen zijn om het tempo van innovatie te kunnen bijhouden”. De respondenten waren van mening dat de FinTech-sector nieuwe technologieën en verbeterde klantenervaringen toegankelijk maakte, terwijl de sterktes van FI's hun beveiligde infrastructuur, bestaande klantenbasis, kennis van klanten en beschikbaarheid van gegevens zijn.

De Risico's

De risico's verdwijnen echter niet, en dat geldt ook voor de verantwoordelijkheid van FI's ten opzichte van toezichthouders en klanten om de gevoelige gegevens en geldmiddelen van klanten te beveiligen. FI's moeten extra waakzaam zijn en bescherming bieden tegen het verlies of de diefstal van klantengegevens, ongeautoriseerde transacties of het risico dat hun systemen of rekeningen worden gebruikt voor het witwassen van geld of schenden van sancties.

Dreigingen

Dreigingen van virussen, malware, man-in-the-middle-, phishing- en denial-of-service (DOS)-aanvallen worden groter wanneer het digitale ecosysteem van FI's wordt uitgebreid met partnersystemen.

Twee recente incidenten wijzen op de toegenomen kwetsbaarheid van klantengegevens bij de partners van FI's:

  • Het gegevenslek bij Ticketmaster UK werden de persoonlijke gegevens en betalingsgegevens van 40.000 klanten openbaar gemaakt. De kwetsbaarheid ontstond toen een stuk JavaScript-code, gecreëerd door de ChatBot-provider van Ticketmaster, Inbenta, werd toegepast op de betalingspagina van Ticketmaster. Hoewel bleek dat hackinggroep Magecart het script van Inbenta infecteerde, zijn het de banken, die de kaarten uitgaven, die moeten omgaan met de getroffen klanten.
  • Het gegevenslek bij de nieuwe digitale vastgoedservice in Australië, PEXA, geeft aan welke verliezen klanten kunnen leiden als partnersystemen van niet-banken worden geïnfecteerd. In dit incident maakte een hacker $ 250.000 van een vastgoedtransactie buit door een e-mail te onderscheppen die werd verzonden naar een overdrachtsagent om het wachtwoord te resetten, zijn eigen gebruikersaccount aan te maken en het geld naar zijn eigen bankrekening over te schrijven. Als reactie implementeerde PEXA meerledige verificatie, bijkomende controles bij het resetten van wachtwoorden en een klantengarantie. De reputatieschade ten gevolge van dit gegevenslek komt helaas op een tijdstip dat PEXA, banken en de overheid het publiek meer vertrouwen willen geven in een nieuw digitaal systeem ter vervanging van een 150 jaar oud proces gebaseerd op papier.

Beheer

Om bescherming te kunnen bieden tegen dreigingen, is een globale aanpak van cyberbeveiliging in het ecosysteem vereist. Deze omvat:

  • validatie van partners voordat deze toegang krijgen tot de productiesystemen van de FI;
  • uitgebreide controle van het API-gebruik door partners;
  • verificatie van de identiteit van partnersystemen;
  • tokenization: gevoelige klantengegevens vervangen door een token of tijdelijke aanduiding. Hierdoor kan de FI de klant koppelen aan zijn 'tokenkluis' zonder de oorspronkelijke gegevens vrij te geven.

De uitdaging voor FI's bij het uitbouwen van een ecosysteem voor partners, is de ontwikkelaars van hun partners leren hoe ze hun API's moeten gebruiken zonder informatie prijs te geven die misbruikt kan worden om het systeem te hacken. Om ontwikkelaars aan te moedigen om API's te testen, publiceren heel wat instellingen portaalsites voor ontwikkelaars, met richtlijnen, voorbeeldcode en een ‘sandbox’ omgeving waarin ontwikkelaars API-aanroepen kunnen simuleren. Hoewel ontwikkelaars in sandboxen makkelijker prototypes kunnen ontwikkelen en testen, zijn er strengere controles nodig om partnertoepassingen toegang te geven tot de productie-API's van FI's. FI's moeten zeker zijn dat de controles van de FI en het FinTech-bedrijf de klantengegevens en productiesystemen beschermen voordat partnertoepassingen toegang krijgen tot de echte productiesystemen van de FI.

Het voordeel van API's is dat ze voor de abstractie van de FI-systemen zorgen. Ze hoeven geen informatie over het onderliggende systeem door te geven (en partners hoeven niet te weten hoe het onderliggende systeem werkt om ermee te kunnen communiceren). Door slechts op één manier toegang te geven tot de systemen van een FI, kunnen de toegang en het gebruik nauwlettend gecontroleerd worden.

Reageren op Incidenten

De verantwoordelijkheid voor API-beveiliging ligt volledig bij de API-provider – de FI zelf. Wanneer deze niet op de hoogte is van de inherente kwetsbaarheden in dergelijke bedrijfsfuncties, kan dat leiden tot omvangrijke verliezen en blootstelling aan gevaren.

De FinTech-partner moet worden geïntegreerd in het SIEM-systeem (Security Incident and Event Management) van de FI. Dit bestaat uit:

  • Processen:
    • Gebruik van API-aanroepen.
    • Per functie/activiteit.
    • Volume.
    • Fouten.
  • Reactie:
    • Volgen.
    • Isoleren/in quarantaine plaatsen/uitschakelen van getroffen delen (API-toegang door een partnersysteem).
  • Melding:
    • Partners.
    • Klanten.
    • Toezichthouders.

Verificatiemethoden

Overschakelen van een traditionele interface (klant – FI) naar een drieledig model (klant – FinTech – FI) vergroot het "aanvalsoppervlak" (meer plaatsen om aan te vallen en gegevens te stelen). Dit vereist een nieuw vertrouwensmodel, waarbij een klant de FI toestemming kan geven om het FinTech-bedrijf toegang te geven tot zijn accountgegevens zonder de aanmeldingsgegevens van de klant bekend te maken. Daarom zijn verdere maatregelen en controles op het vlak van informatiebeveiliging nodig om een klant te beschermen bij het gebruik van tussenliggende FinTech-diensten.

De Europese Bankautoriteit (EBA) heeft richtlijnen opgesteld voor het implementeren van beveiliging volgens de richtlijn betreffende betalingsdiensten (PSD2). Deze vereisen "sterke klantenverificatie" inclusief het gebruik van meerledige verificatie (bv. tweeledige verificatie) op basis van wat de klant heeft (bezit), weet (kennis) of is (inherentie).

Open protocollen zoals OAuth en OpenID Connect zijn de huidige best practice om derden toegang te geven tot accountgegevens en tegelijk de privacy van de aanmeldingsgegevens van de klant te bewaren. Opnieuw verifiëren is ook vereist afhankelijk van de activiteit die wordt opgeroepen, zoals een overboeking van geld of betaling.

De beveiligingsrichtlijnen van de EBA implementeren is een minimum. Bedrijven moeten verder gaan en ervoor zorgen dat hun controles getest zijn en werken zoals verwacht. Beveiliging moet geïntegreerd worden in elke ontwikkelingsstap om misbruik van kwetsbaarheden door hackers, malware en misbruik van API's te voorkomen.

Veilig Groeien

Om partnerschappen tussen FI en FinTech-bedrijven te kunnen ontwikkelen, is een globale aanpak van cyberbeveiliging binnen het ecosysteem vereist. Dit omvat een sterk proces ontwikkelen voor het screenen en introduceren van partners, de beveiligingsprotocollen OAuth2.0 en OpenID Connect toepassen, methodes zoals verificatie op basis van digitale certificaten en tokenization gebruiken, en integratie in de Security Incident and Event Management-processen van de FI.

Deze controles integreren in de vorming en uitbreiding van partnerschappen zorgt ervoor dat FI's, FinTech-bedrijven en hun klanten (veilig) kunnen genieten van de voordelen van partnerschappen.

Deze blog is geschreven voor FinTech-bedrijven en financiële instellingen.

Over de Auteur

Jon Scheele is een consultant en trainer en helpt financiële instellingen en FinTech-bedrijven bij het ontwikkelen van nieuwe waarde proposities voor klanten via API-partnerschappen. Jon traint financiële dienstverleners in de strategie, het ontwerp, de implementatie en het productbeheer van API's in zijn cursus Building Financial Services Open APIs.

Opmerking: dit blogartikel werd geschreven door een externe medewerker om onze lezers een gevarieerder aanbod te geven. De standpunten uiteengezet in dit artikel van een externe medewerker zijn enkel die van de medewerker en komen niet noodzakelijk overeen met die van GlobalSign.

Share this Post