La mondialisation de l’économie, l’interopérabilité des échanges, l’augmentation continue du volume des opérations financières, la variété les produits ainsi que le développement des micro-services obligent les banques à repenser leur modèle, leur organisation et leur système d’information, dans un secteur qui, par ailleurs, fait déjà l’objet d’une réglementation très stricte.
Parmi les récentes transpositions, citons la directive (UE) 2015/2366 relative aux services de paiement, dite DSP2, entrée en vigueur le 13 janvier 2018.
Au-delà de la volonté d’harmoniser les règlementations européennes, la DSP2 a pour objectif de créer un véritable écosystème bancaire. Dans cette perspective, il a été prévu :
- De limiter la fraude dans l’e-commerce ;
- De renforcer les droits des consommateurs ;
- D’améliorer le niveau de sécurité des paiements ;
- D’assurer la protection des données ;
- De favoriser l’innovation et l’efficience du marché.
S’agissant des nouvelles exigences de sécurité, en premier lieu, la DSP2 a instauré à compter du 14 septembre 2019, une obligation d’authentification forte pour « la consultation des comptes (suivant leur montant) et les opérations de paiement électronique » (1).
Par ailleurs, en vue de favoriser la compétitivité et la concurrence, le législateur européen a souhaité ouvrir le marché bancaire à de nouveaux acteurs. Ces derniers sont autorisés à accéder aux comptes de paiement des clients et aux informations confidentielles qu’ils contiennent. Ces professionnels sont dénommés “Prestataires de Services de Paiement tiers” (PSP tiers). Ils englobent, d’une part, les Prestataires de Services d’Initiation de Paiement (PSIP) “ qui permettent au client d’initier un paiement à partir de l’un de ses comptes bancaires ”, et, d’autre part, les agrégateurs et Prestataires de Services d’Information sur les Comptes (PSIC) “ qui permettent notamment de consulter sur une seule interface les comptes rattachés à plusieurs établissements bancaires ”.
L’ambition affichée de favoriser “cette collaboration entre les institutions bancaires et les sociétés de technologie financière innovante telles que les Fintechs” (2) n’est pas sans risque à l’heure où les régulateurs ont constaté dans ce secteur, à l’instar de ce que subissent d’autres domaines d’activité, une augmentation majeure du nombre des cyberattaques (3).
Aussi, par sécurité, les banques et les PSP tiers doivent intégrer deux certificats électroniques, et ce, en vue de limiter les risques susceptibles d’apparaître durant leurs échanges.
- L’eDAS Qualified Website Authentication Certificate “qui permet aux serveurs d’un PSP et d’une banque de s’authentifier mutuellement et de maintenir les communications chiffrées”.
- L’eIDAS Qualified electronic Seal Certificate “qui permet aux serveurs d’un PSP et d’une banque de sceller le contenu d’une transaction” (4).
Au cœur de ce nouveau paradigme de l’Open Banking : la technologie de l’Application Programming Interface (API) apparue dans les années 2000 sous l’impulsion de l’américain Roy Fielding (5).
L’API est une interface qui permet à deux programmes informatiques de dialoguer ensemble. Sur un plan technique, les briques de base sont utilisées comme des legos, en tout ou partie, par les développeurs. Suivant leurs besoins, ces derniers intègrent les données et les services proposés par des tiers au sein de leur propre application. (6)
Différents types d’API (7) existent. Celles dites “externes” sont conçues pour s’ouvrir vers l’extérieur en mode partenariat ou public. Afin de pouvoir accéder à la documentation qui explicite leurs différents usages, le développeur doit accepter des conditions générales d’utilisation (CGU) et/ou de vente (CGV).
Rappelons que la plupart des API appartiennent aux GAFAMs (Google, Facebook, Amazon, etc.) qui ont construit le modèle économique de leur plateforme sur la base de cette technologie. Nonobstant les enjeux de souveraineté numérique, il est fort probable que les règles édictées dans lesdites CGU, (auxquelles le développeur consent pour le compte de son employeur), fassent peu cas d’une éventuelle non-conformité au RGPD.
Par ailleurs, depuis le 14 septembre 2019, les API doivent respecter des standards techniques (RTS – Regulary Technical Standards).
Malgré ceux-ci, de nombreuses failles de sécurité (inhérentes “ au triptyque des API qui comporte des enjeux de masse, d’interconnexion et d’interception” (8)) sont révélées par des référentiels internationaux qui publient, chaque année, la typologie des différents types de vulnérabilités.
Parmi les plus représentatives :
- Les vulnérabilités de type Insecure Direct Object Reference (IDOR) permettent d’accéder de manière illégitime à des ressources en dehors du périmètre d’autorisation. L’impact constaté porte sur la donnée.
- Les vulnérabilités de type Server-Side Request Forgery (SSRF) permettent de solliciter des ressources internes en raison d’URLs mal formées transmises par l’utilisateur. L’impact constaté se situe au niveau de l’infrastructure.
Des axes de remédiation existent (9).
Dans la première hypothèse (IDOR), il conviendrait pour le référencement des clients (user id) et celui des accès aux documents (offer id) qui comportent des données confidentielles, d’adopter au sein des API une autre approche que celle des entiers naturels qui peuvent être facilement incrémentés par un attaquant.
La seconde hypothèse (SSRF) révèle la verbosité des API. En effet, il est facile pour un attaquant d’effectuer de nombreuses requêtes afin d’induire l’API en erreur, qui, dans la confusion, “se met à parler” (10) et à communiquer des informations sensibles.
Du fait de la chaîne de responsabilités, l’axe de remédiation proposé est le Développement-Sécurité-Opérations qui privilégie le principe du Security by design.
A titre de propos conclusifs, il est recommandé de ne jamais faire confiance à l’entrée de l’utilisateur (11) et, in fine, de consulter “les modèles de mesure de maturité des API” qui faciliteront la mise en conformité de l’entité.
Alice Louis
Glossaire
▪ Authentification forte : elle repose sur l’utilisation d’au moins deux facteurs indépendants (et ce, afin que la compromission de l’un ne remette pas en question la fiabilité de (des) autre(s)) figurant parmi les suivants :
- “Le facteur connaissance est une information détenue uniquement par l’utilisateur, tel qu’un mot de passe ou un code PIN (un élément que l’utilisateur connaît).
- Le facteur possession est un élément que seul l’utilisateur possède, comme une carte bancaire ou le téléphone mobile sur lequel est envoyé un sms de validation.
- Le facteur inhérence est une donnée biométrique, telle que la reconnaissance vocale ou faciale, les empreintes digitales, etc. (un élément que l’utilisateur est) (12)”.
▪ Bug Bounty : il est né en 1995. Le premier programme de “chasse aux bugs” a été mené par un ingénieur américain Jarrett Ridlingghafer.
Les programmes publics (ouverts à tous et directement organisés par les entreprises) se distinguent des programmes privés gérés par des plateformes de Bug Bounty qui assurent, à l’instar de celle de Yogosha, un rôle d’interface entre les structures et les chasseurs de prime.
Afin de garantir la constitution d’un écosystème de confiance, il est précisé que les compétences des hackers éthiques sont testées en ligne suivant une double notation (celle de la communauté et celle des clients). En outre, leur identité est validée par un tiers de confiance.
▪ Compliance / conformité : la fonction contrôle le risque de sanction judiciaire, administrative ou disciplinaire, de perte financière significative, ou d’atteinte à la réputation, qui naît du non-respect de dispositions propres aux activités bancaires et financières.
A l’instar du délégué à la protection des données à caractère personnel qui doit être “indépendant” et doté de moyens suffisants, le directeur / responsable de la conformité est l’interlocuteur attitré des autorités de supervision” (13).
▪ Ethique : elle est la pensée des principes et des valeurs. L’éthique se distingue du droit (et de la conformité). Néanmoins, elle peut parfois remplir une fonction visant à évaluer la justesse des règles que le droit édicte. En outre, elle peut le préfigurer s’agissant, en particulier, des risques numériques.
▪ Hacker éthique : dénommé aussi chercheur en sécurité ou chasseur de primes. Ce dernier bénéficie d’une protection régie par l’article 47 de la loi n°2016-1321 du 7 octobre 2016 pour une République numérique qui vient compléter l’article L.2321-4 du Code de la défense.
▪ KYC : Know Your Customers. Les obligations de conformité se matérialisent à toutes les étapes suivantes :
- Identification des clients ;
- Contrôle des informations d’identification des clients ;
- Contrôle des clients par rapport aux listes de sanction ;
- Qualification du risque de blanchiment des clients ;
- Consignation des pièces d’identification des clients ;
- Production des preuves des contrôles opérés en cas d’audit du régulateur ;
- Déclaration aux autorités compétentes si soupçon” (14).
▪ Règlementation bancaire : en substance, “les standards internationaux sont posés par le Comité de Bâle qui est chargé de définir les règles prudentielles applicables aux banques. La dernière révision date de décembre 2017 et finalise les réformes engagées après la crise financière de 2008 (Bâle III).
L’ensemble de ces règles sont régulièrement transposées au niveau européen via deux textes : le règlement et de la directive européenne sur les exigences en capital (CRR et CRD). Les travaux se poursuivent avec le paquet législatif sur les paiements (DSP2 et règlement sur les commissions d’interchange carte), la taxe sur les transactions financières, la révision de la directive anti-blanchiment, etc.
Au-delà des normes prudentielles, le Code monétaire et financier définit les modalités et le périmètre de supervision du secteur” depuis la loi du 24 janvier 1984, dite “loi bancaire. (15)
▪ SIEM : Security Information and Event Management ou gestion des informations et des événements d’attaques informatiques, de vulnérabilité et de non-conformité en un seul endroit. Le SIEM est l’outil principal du SOC.
▪ SOC : Security Operations Center. Il s’agit d’une plateforme de supervision et d’administration de la sécurité du système d’information.
Notes
- https://www.oodrive.fr/blog/reglementation/dsp2-la-directive-qui-accompagne-la-mutation-numerique-des-services-de-paiement/
- https://www.oodrive.fr/blog/innovation/certificats-dsp2-la-solution-pour-un-ecosysteme-open-banking-de-confiance/
- http://www.fbf.fr/fr/files/AU8CQN/MEMO_08_DSP2.pdf
- https://www.oodrive.fr/blog/innovation/certificats-dsp2-la-solution-pour-un-ecosysteme-open-banking-de-confiance/
- https://www2.deloitte.com/fr/fr/pages/services-financier/articles/open-banking.html
- Les performances attendues : les API doivent répondre à des problématiques de scalabilité, de la normalisation et de centralisation.
- Elles peuvent être internes. Dans cette hypothèse elles ne sont accessibles qu’aux développeurs de l’entreprise. Certaines sont ouvertes à des partenaires qui signent un contrat.
- Yassir KAZAR.
- Outre les SIEM/SOC.
- Brice AUGRAS.
- Brice AUGRAS : “never trust user input” !
- http://www.fbf.fr/fr/files/AU8CQN/MEMO_08_DSP2.pdf
- https://www.fimarkets.com/pages/fonction_compliance.php
- https://portail.arca.fr/le-kyc-au-sein-des-banques-une-reglementation-strategique-pour-la-relation-client/
- https://www.tresor.economie.gouv.fr/banque-assurance-finance/banques-etablissements-de-credit
