Consultant et formateur, Jon Scheele travaille avec les institutions financières sur les partenariats API. Il lance une série d’articles de blog pour aider les institutions financières et les FinTechs à mieux aborder les technologies émergentes et le cadre réglementaire européen. Pour consulter les billets suivants, cliquez sur le lien au bas de cet article.
Les partenariats entre les institutions financières (IF) et les FinTechs (ces start-ups axées sur les technologies qui proposent de nouveaux services financiers) doivent dépasser la simple proposition de valeur au client. Des réglementations strictes comme le Règlement sur l’identification électronique et les services de confiance pour sécuriser les transactions électroniques (eIDAS), la norme de sécurité de l’industrie des cartes de paiement (PCI DSS) qui précise les modalités de saisie, de stockage et d’organisation des données de paiement, et le Règlement général sur la protection des données (RGPD) exigent que des dispositifs de cybersécurité soient intégrés à toutes les étapes du parcours client.
Pour une protection complète des données client et des actifs financiers, des dispositifs de sécurité doivent impérativement être intégrés aux systèmes partenaires — authentification et autorisation, protection des données, intégrité du système, et détection proactive/réponses face aux incidents de cybersécurité. Vu le rôle déterminant que jouent les interfaces de programmation d’applications (API) dans la connectivité interpartenaire, la sécurité des API doit être une priorité absolue.
Qui en a la responsabilité ? Peu importe que vous soyez une institution financière ou une FinTech. L’essentiel est de trouver le bon équilibre. Considérons ce qui suit :
L’opportunité
D’après un rapport conjoint de PwC UK et de l’Open Data Institute, l’Open Banking devrait permettre de générer 7,2 milliards de livres sterling (soit un peu plus de 8 milliards d’euros) de revenus d’ici 2022. Ce chiffre tient compte des revenus supplémentaires engendrés par les nouveaux produits et services, et du risque financier pour les acteurs du marché actuel qui ne parviendraient pas à s’adapter.
L’ouverture des API aux partenaires FinTech sur leurs segments de marché cibles permet aux banques d’accroître leurs capacités à acquérir, interagir et traiter avec leur clientèle. Dans son enquête réalisée en 2017 auprès de 39 grandes banques à travers 17 pays, PwC notait que 92 % des établissements bancaires estimaient qu’à l’avenir, les partenariats avec des établissements non bancaires seraient importants, voire très importants. Cette étude révélait également que, dans le contexte d’innovation actuel, 71 % des banques étaient d’accord ou tout à fait d’accord pour dire que les partenariats et collaborations étaient une condition nécessaire pour rester dans la course. Pour les participants à l’enquête, les FinTechs s’illustrent par leur capacité à introduire de nouvelles technologies et à offrir une expérience client améliorée, tandis que les institutions financières se caractérisent par leur infrastructure sécurisée, leur base de clients bien établie, la connaissance de leurs clients et la disponibilité des données.
Les risques
Mais les risques n’ont pas disparu, pas plus que la responsabilité des institutions financières vis-à-vis des organismes de régulation et de leurs clients — notamment en ce qui concerne la protection des informations sensibles et de l’argent des clients. Ces IF doivent redoubler de vigilance pour se protéger contre la perte ou le vol de données client, mais aussi contre les transactions frauduleuses ou l’utilisation malhonnête de leurs systèmes ou des comptes clients à des fins de blanchiment d’argent ou pour contourner des sanctions.
Les menaces
Virus, logiciels malveillants, attaques de type Man-in-the-Middle ou Déni de Service (DoS), tentatives d’hameçonnage... toutes ces menaces sont amplifiées lors de l’ajout de systèmes partenaires à l’écosystème numérique d’une IF.
Récemment, deux incidents ont mis en évidence la vulnérabilité accrue des données clients en lien avec ces types de partenariats d’IF :
- Suite à la violation de données dont Ticketmaster UK a fait les frais, 40 000 clients du service de billetterie en ligne ont vu leurs données personnelles et de cartes de paiement exposées. La vulnérabilité est apparue lors de l’application d’un morceau de code Javascript, créé par Inbenta — un fournisseur de Ticketmaster — sur la page de paiement de Ticketmaster. Les pirates à l’origine de l’infection du script d’Inbenta appartenaient au groupe Magecart. Il n’en reste pas moins que ce sont les banques émettrices des cartes de paiement qui ont dû gérer les clients affectés.
- Le piratage de PEXA, le nouveau service australien de transactions immobilières numériques, met en lumière ce que les clients peuvent perdre en cas de compromission des systèmes de partenaires en dehors du secteur bancaire. Lors de cet incident, un hacker a détourné 250 000 USD sur le montant d’une transaction immobilière. Le pirate a pour cela intercepté un courriel de réinitialisation de mot de passe adressé à un agent de transfert, avant de créer son propre compte utilisateur et de rediriger les fonds vers son compte bancaire. PEXA réagit en mettant en place l’authentification multifacteurs, des contrôles supplémentaires pour la réinitialisation de mots de passe, et une garantie pour les clients. Les dommages en termes de réputation interviennent cependant au moment où PEXA, les banques et les autorités publiques cherchent à rassurer l’opinion publique sur le remplacement d’un vieux processus papier de 150 ans par un nouveau système numérique.
La gestion
Pour se protéger des menaces, il est essentiel d’aborder la cybersécurité dans une logique d’écosystème. Cela passe notamment par :
- un contrôle des partenaires avant de leur ouvrir l’accès aux systèmes de production des banques ;
- un suivi granulaire de l’utilisation des API par les partenaires ;
- des vérifications d’identité des systèmes partenaires ;
- la tokenisation : c’est-à-dire le remplacement des données client sensibles par un token ou un élément de substitution (placeholder). L’institution financière peut ainsi établir une correspondance avec le client dans son « coffre à tokens » sans exposer les données originales.
Les institutions financières qui prônent la mise en place d’un écosystème de partenaires doivent former les développeurs côté partenaires à l’utilisation de leurs API, sans révéler d’informations susceptibles d’être utilisées à des fins malhonnêtes. Pour encourager les développeurs à tester les API, de nombreux établissements bancaires créent des portails à leur attention avec des guides, des exemples de code et un environnement isolé de type « sandbox » qui leur permet de simuler les appels d’API. Ces sandboxes facilitent certes le développement et les tests de prototypes, mais des contrôles renforcés sont cependant requis pour autoriser une application partenaire à appeler les API des environnements de production de l’IF. Avant d’autoriser les applications partenaires à accéder en direct à leurs systèmes de production, les institutions financières doivent s’assurer que les informations client et les systèmes de production sont correctement protégés grâce aux contrôles qu’elles, et les FinTechs, mettent en place.
L’avantage avec les API, c’est qu’elles mettent une couche d’abstraction au-dessus des systèmes des établissements financiers. Ces établissements n’ont donc pas à révéler d’informations sur leur système sous-jacent (et les partenaires n’ont pas à savoir comment fonctionne ce système pour interagir avec). Le fait de n’octroyer qu’un accès à sens unique aux systèmes des IF permet de surveiller de près les accès et usages.
Réaction en cas d’incident
Le fournisseur de l’API, à savoir l’IF, est responsable à part entière de la sécurité des API. La méconnaissance des vulnérabilités inhérentes à ces fonctions métier peut causer de lourdes pertes et engendrer des risques importants.
Le partenaire FinTech doit être intégré à la gestion des incidents et des événements de sécurité (SIEM) de l’IF, qui comprend :
- Processus :
- Utilisation des appels API.
- Par fonction/activité.
- Volume.
- Erreurs.
- Réponse :
- Observation
- Isolement/Quarantaine/Fermeture des zones affectées (accès à l’API par le système d’un partenaire).
- Notification :
- Partenaires.
- Clients.
- Régulateurs.
Méthodes d’authentification
Le passage d’une interface classique « client-banque » à un modèle tripartite « client-FinTech-Banque » accroît la surface d’attaque (plus de points susceptibles d’être attaqués et piratés). Côté cybersécurité, cette évolution exige un nouveau modèle de confiance : le client donne l’autorisation à sa banque d’accorder à une FinTech l’accès à ses données de compte, sans divulgation de ses identifiants de connexion. La gouvernance et les contrôles de sécurité des informations doivent donc être renforcés pour que les clients soient protégés lorsque l’on fait appel aux services d’intermédiaires des FinTechs.
L’Autorité bancaire européenne (ABE) a défini les orientations pour une mise en œuvre de la sécurité conforme à la directive sur les services de paiement (PSD2). Une « authentification client forte » est exigée, avec un système d’authentification multifactorielle (authentification à deux facteurs, par exemple) basé sur quelque chose que le client possède, une information qu’il connaît ou ce qui lui est inhérent.
Les protocoles ouverts comme OAuth et OpenID Connect correspondent actuellement aux bonnes pratiques lorsque l’on souhaite permettre à un tiers d’accéder aux informations d’un compte tout en préservant la confidentialité des identifiants de connexion du titulaire du compte. En fonction de l’activité invoquée (virements de fonds ou paiements), une nouvelle authentification est également requise.
L’application des consignes de sécurité de l’ABE constitue le minimum. Les entreprises doivent cependant aller un cran plus loin pour s’assurer que les contrôles ont été testés et fonctionnent comme prévu. La sécurité doit être intégrée aux pratiques de développement d’applications pour éviter tout risque d’exploitation des vulnérabilités par des pirates et des logiciels malveillants, ou dans le cadre d’une utilisation abusive des API.
Conditions pour évoluer sans risques
Les politiques de partenariats entre les IF et les FinTechs exigent d’aborder la cybersécurité dans une logique d’écosystème. Cela passe par la mise en place d’un processus rigoureux de sélection et d’intégration des partenaires. D’autres mesures sont également nécessaires comme l’application des protocoles de sécurité OAuth2 et OpenID Connect, le recours à des méthodes d’authentification basée sur les certificats numériques, la tokenisation, et l’intégration avec les processus de gestion des événements et des incidents de sécurité de l’institution financière.
L’intégration de ces contrôles dès la création et le développement des partenariats permettra aux IF, aux FinTechs et à leurs clients de tirer pleinement parti (et en toute sécurité) des avantages de ces partenariats.
Cet article a été rédigé à l’attention des FinTechs et des institutions financières. Retrouvez la suite de notre série dans notre prochain article « PSD2 : Cyber-Implications pour les API FinTech. »
À propos de l’auteur
Consultant et formateur, Jon Scheele aide les institutions financières et les FinTechs à créer de nouvelles propositions de valeur pour leurs clients à l’aide de partenariats axés sur les API. Jon forme des professionnels des services financiers à la stratégie, la conception, la mise en œuvre et la gestion des API dans le cadre de son programme de formation « Building Financial Services Open APIs » (Construire des API ouvertes pour les services financiers).
Note : ce billet de blog a été écrit par un rédacteur externe afin de varier les contenus proposés à nos lecteurs. Les opinions exprimées par l’auteur de cet article sont exclusivement les siennes et ne reflètent pas nécessairement les opinions de GlobalSign.
