API bancaires ouvertes dans le cadre de psD2 : comment atténuer les risques

Frederik Mennes, mai 14, 2018

Ces dernières années, l'open banking a reçu beaucoup d'attention dans le secteur des services financiers. L'ouverture bancaire signifie que les banques ouvrent leurs systèmes à des fournisseurs de services financiers tiers autorisés, de sorte que ces sociétés peuvent initier et traiter les paiements et les transactions financières à la demande des clients de la banque.

L'open banking promet de débloquer l'innovation qui améliorera profondément l'expérience bancaire et introduira de nouveaux services financiers. Par exemple, les fournisseurs tiers (TPP) peuvent fournir des applications qui permettent aux consommateurs de consulter plusieurs comptes bancaires à partir d'une seule application, ou des applications qui facilitent le partage de données par les entreprises avec leurs comptables.

Dans le cadre de LA DSP2, les banques doivent offrir une interface permettant aux TPP de communiquer avec elles. De cette façon, si le consommateur veut utiliser des fournisseurs de services financiers autres que la banque, ces fournisseurs peuvent accéder aux systèmes de la banque et servir les clients de la banque via l'interface de communication ouverte.

Ce n'est pas sans risque. Selon McKinsey - Company, « la plupart des banques déclarent qu'elles ne s'attendent pas à ce que la sécurité devienne un problème dans le cadre de la DSP2; toutefois, ils reconnaissent également qu'ils doivent investir dans la gestion de la fraude. Les banques sont responsables de l'atténuation du risque de fraude et devront mettre en œuvre des contrôles avancés, y compris des analyses avancées (par exemple, pour valider l'origine des appels entrants vers l'API) et des outils solides pour détecter les attaques frauduleuses. L'enquête [McKinsey Global Payments Practice PSD2 Survey 2017] a indiqué que le risque de fraude découlant de l'accès de tiers aux comptes est une préoccupation sérieuse et que la préventionde la fraude est une priorité absolue.

Risques pour les banques

L'introduction d'API ouvertes rend les banques dépendantes de la sécurité des TPP à l'aide de ces API. Les scénarios de menace possibles comprennent :

  • Une violation de données lors d'un PTP expose les clients de la banque
    • Les TPP stockeront les données financières des consommateurs. Si un PTP est violé, cela pourrait exposer les données des clients de la banque, ce qui pourrait à son tour affecter la réputation de la banque. À la lumière du Règlement général européen sur la protection des données (RGP), les banques doivent s'assurer que les TPP mettent en œuvre des mesures techniques et organisationnelles appropriées pour protéger les données des clients.
  • Demandes frauduleuses d'un PTP compromis
    • Si un PTP est piraté, cela pourrait entraîner des demandes frauduleuses d'informations sur les clients d'une banque - ou des demandes de paiement frauduleuses du PTP à la banque. Un tel incident pourrait se produire par le biais de vulnérabilités dans l'application mobile ou l'application Web du PTP. Étant donné que les banques sont la première partie à être tenue responsable des transactions financières non autorisées à partir du compte bancaire d'un utilisateur, une violation de sécurité lors d'un PTP peut avoir de graves conséquences pour les banques.
  • Demandes frauduleuses des employés du PTP
    • Un employé mécontent d'un PTP pourrait émettre des demandes frauduleuses d'information sur les clients d'une banque ou déclencher des paiements frauduleux.
Missing élément de média.

Les banques devraient adopter un certain nombre de mesures techniques et de sécurité organisationnelle pour faire face à ces menaces et à d'autres. Dans le contexte de l'open banking, les banques peuvent atténuer les risques de multiples façons :

1. Utiliser l'analyse des risques de transaction
Les banques peuvent utiliser l'analyse des risques de transaction pour :

  • Détecter les transactions frauduleuses et le comportement des utilisateurs. Les Normes techniques réglementaires PSD2 (SRT) exigent que les fournisseurs de services de paiement (PSP), y compris les banques, effectuent une analyse des risques de toutes les transactions financières qu'ils traitent. De cette façon, les PSP peuvent détecter la fraude de paiement, telle que la fraude de carte-non-présente.
  • Détecter les incidents de sécurité dans les TPP. L'analyse des risques de transaction peut être utilisée pour détecter un comportement anormal dans les demandes provenant des TPP, identifier les transactions suspectes provenant des TPP, détecter des séquences atypiques d'appels API, et tout cela en temps réel.
  • Détecter les vulnérabilités d'implémentation aPI. Les faiblesses dans la mise en œuvre des API peuvent donner lieu à des transactions frauduleuses et à un comportement inhabituel des utilisateurs, qui peuvent être détectés à l'aide d'une surveillance avancée de la fraude.

2. Choisissez le bon modèle d'authentification
L'authentification forte du client est essentielle, qu'il s'agisse d'authentificationà deux facteurs, d'authentification multifacteur,d'authentification biométriqueou autre. Cependant, différents modèles d'authentification ont chacun leurs propres caractéristiques et implications de sécurité. Pour la banque, il est généralement préférable d'utiliser un modèle qui place le processus d'authentification avec la banque elle-même ou avec un fournisseur de sécurité externe. Cela signifie que la banque continuera à communiquer directement avec l'utilisateur au lieu de par le biais du PTP. Ce faisant, plus d'informations deviennent disponibles à la banque pour l'analyse des risques de transaction, y compris la preuve d'événements d'authentification, ce qui est pertinent pour le traitement des litiges concernant la responsabilité d'une transaction frauduleuse.

3. Protéger le canal de communication avec les TPP
Les banques doivent protéger l'échange de données avec leurs TPP. Pensez à l'authentification mutuelle entre une banque et le TPP en utilisant, par exemple, les protocoles SSL/TSL.

4. Demander des rapports indépendants d'audit de sécurité des TPP
La Commission européenne a anticipé les risques pour la sécurité dans le cadre de la PSD2 et exige donc que les PSP et les TPP gèrent les risques opérationnels et de sécurité. Plus précisément, l'article 95(1) du PSD2 exige que les PSP établissent un cadre assidu avec des mesures d'atténuation appropriées pour gérer les risques opérationnels et de sécurité liés aux services financiers qu'ils fournissent. La mise en place, la mise en œuvre et le suivi des mesures de sécurité devraient couvrir les éléments suivants :

  • Gouvernance, y compris le cadre de gestion des risques opérationnels et de sécurité, les modèles de gestion et de contrôle des risques et l'externalisation
  • Évaluation des risques, y compris l'identification, la classification et l'évaluation des risques des fonctions, des processus et des actifs
  • Protection de l'intégrité des données, des systèmes et de la confidentialité, de la sécurité physique et du contrôle des actifs
  • Surveillance, détection et signalement des incidents de sécurité
  • Gestion de la continuité des activités, y compris l'essai des plans de continuité des activités, la gestion des incidents et la communication de crise
  • Test indépendant des mesures de sécurité

Les banques devraient demander que les TPP fournissent des rapports indépendants de tests de sécurité afin de vérifier la maturité de leurs pratiques de sécurité.

5. Éviter les failles de sécurité dans la mise en œuvre de l'API
Pour vous protéger contre les attaques par injection, assurez-vous que quequel que soit le format de données que l'API utilise, le composant logiciel API qui analyse les structures de données est durci contre les attaques. En outre, les banques devraient protéger l'assainissement des intrants pour empêcher l'injection de toutes les formes. L'analyse et les tests de sécurité devraient couvrir toutes les API et les outils afin que les banques puissent les découvrir et les analyser efficacement.

Open Banking API et Comment les protéger

Les API ouvertes exigées par PSD2 mèneront sans aucun doute à de nouveaux services et applications bancaires innovants. Dans le même temps, cependant, les banques doivent empêcher les criminels d'accéder aux données et aux transactions des clients. Les banques et les TPP doivent donc être conscientes des risques et offrir une protection suffisante. Pour en savoir plus, téléchargez ce livre blanc :

API bancaires ouvertes dans le cadre de la directive DSP2 : menaces et solutions pour la sécurité

Ce blog a été inspiré par un article de Frederik Mennes qui est apparu pour la première fois sur Techzine.

Frederik dirige le Security Competence Center de OneSpan, où il est responsable des aspects de sécurité des produits et de l'infrastructure de OneSpan. Il possède une connaissance approfondie des technologies d'authentification, de gestion des identités, de réglementation et de sécurité pour les applications cloud et mobiles.