Protéger les API financières et gérer les risques affectant la chaîne logistique

L’adoption d’outils de technologie financière, ou fintech, a atteint un niveau sans précédent, et les consommateurs veulent accéder facilement à leurs finances en mode digital - ils veulent pouvoir transférer de l’argent, contrôler le statut de leurs dossiers d’assurance, et gérer leurs investissements en ligne. D’après une étude sur l’impact de la fintech, 93 % des consommateurs ont indiqué en 2022 retirer de réels avantages de leurs applis fintech, à comparer à 90 % en 2021 et 84 % en 2020 (Plaid). Les institutions financières sont largement désireuses d’offrir des outils développés en interne mais aussi de se connecter à des solutions tierces afin de recruter et de fidéliser leurs clients.

Les écosystèmes financiers sont de plus en plus complexes afin d’offrir ces fonctionnalités, mais malheureusement l’extension de ces supply chains exposent les institutions financières à des risques de failles et de pertes financières. Dans son Data Breach Investigations Report 2022, Verizon estime que les failles dans la chaîne logistique sont responsables de 62 % des incidents d’intrusion dans les systèmes (Verizon). Pourquoi ce type de risque est-il si prévalant et comment les institutions financières peuvent-elles correctement gérer cet important vecteur de risque ?

Pour répondre à cette question, il est important de comprendre comment ces écosystèmes sont construits. Les connexions entre les partenaires au sein de ces écosystèmes sont généralement réalisées par le biais d’API financières, qui permettent de partager facilement des données. Face au développement de ces écosystèmes financiers, les institutions financières ont fait du développement des API une priorité : le pourcentage des banques et institutions de crédit qui ont développé ou investi dans des API est passé de 35 % en 2019 à 47 % en 2021, sachant que 25 % supplémentaires prévoient de se joindre à elles en 2022 (Pyments). Les API sont omniprésentes et se trouvent au cœur des services financiers digitaux d’aujourd’hui. 

Malheureusement, protéger ces API n’est pas aussi simple qu’il n’y paraît : il est facile d’établir un point de terminaison des API, mais bien plus difficile de garantir leur sécurité. La plupart des organisations assument que la sécurité des API est intégrée par le programmeur dans le code qui utilise l’API, alors que les programmeurs s’intéressent beaucoup plus à la livraison de leur code le plus rapidement possible et ont tendance à croire que le fournisseur de la passerelle d’API est responsable de la sécurité. Ce dernier, de son côté, peut fort bien ne fournir que les protections les plus basiques en assumant que l’équipe de sécurité de son client se chargera du reste.

Il en résulte des connexions qui sont faciles à exploiter, et ces problèmes sont encore exacerbés par des processus de développement rapides tels qu’Agile. A noter qu’Agile en tant que tel n’est pas le problème, mais qu’à défaut de disposer d’un processus DevSecOps mature, il peut conduire à un développement accéléré où les exigences de sécurité sont souvent négligées, et les mises à jour des fonctionnalités peuvent rendre l’application globalement moins sécurisée. Les acteurs malveillants ont bien conscience de cette confusion autour de la sécurité des API, et cherchent à exploiter ces vulnérabilités. C’est l’un des facteurs qui contribuent au pourcentage élevé de failles impliquant des partenaires dans la chaîne logistique.

Le fait est que la sécurité des API financières nécessite plusieurs couches pour être vraiment efficace.

Les connexions des API sont classées dans deux catégories : exposées et non exposées. Les API exposées sont ouvertes au public, et donnent facilement accès à une logique business via une interface vers une quelconque tierce partie. Naturellement, même avec une API exposée, l’entreprise peut contrôler ce qu’elle montre et à qui, mais ce type d’API accélère fortement les connexions avec les tierces parties qui composent la chaîne logistique.

De son côté, une API non exposée est une connexion point à point entre deux parties spécifiques. Bien que ce type d’API semble par nature plus sécurisé à première vue, il rend la croissance de l’écosystème plus complexe, et les problèmes de sécurité qui peuvent apparaître ne sont pas si différents. Une organisation qui pense être totalement protégée en utilisant uniquement des API non exposées doit se poser la question suivante : « Souhaitons-nous faire confiance à toutes les organisations auxquelles nous sommes connectés et à chacun de leurs employés, de leurs prestataires et à toutes les autres entreprises auxquelles ils sont connectés ? » Si la réponse à cette question est non, alors éviter les API exposées n’élimine de fait pas le risque.

Voilà pourquoi : dans les deux cas, l’API détient un certificat qui chiffre le canal, et l’organisation et la tierce partie de confiance en question partagent un secret, que tous ceux qui interagissent avec l’API doivent connaître pour interagir avec elle. Malheureusement, à l’instar d’un mot de passe ou d’une question d’authentification basée sur la connaissance, un secret peut être percé. Ce qui rend inadéquat ce premier niveau de sécurité des API est le fait que l’organisation n’a en général aucun contrôle sur les protocoles de sécurité utilisés chez la tierce partie et toutes ses entités connectées. Une faille chez une tierce partie peut engendrer un problème au niveau de l’API chez n’importe quelle organisation connectée.

Par exemple, imaginez qu’une banque a une API connectée à un prestataire de paiements en tierce partie. Maintenant, imaginez que ce prestataire de paiements soit hacké par un cybercriminel cherchant à accéder aux données de la banque. Dans ce cas, le fait que l’API soit exposée ou non exposée n’a pas d’importance : si le hacker a infiltré la tierce partie et connaît le secret partagé, il pourra accéder aux données de la banque par le biais de l’API se faisant passer pour le prestataire de paiements, et accéder à tout ce que la banque a autorisé au prestataire de paiements de voir. Pire, un hackeur expérimenté peut manipuler la connexion de diverses manières une fois l’accès obtenu, par exemple en modifiant des identités au sein de l’API pour pouvoir accéder à d’autres informations ou en injectant des données malveillantes voire des commandes déguisées en paramètres ou en téléchargements de fichiers.

Comme indiqué plus haut, ce type d’attaque est très fréquent. Malheureusement, compte tenu de la nature de la chaîne logistique financière, fonctionner sans connexions au niveau des API n’est pas une option. Les organisations devraient plutôt dépasser la protection de base fournie par le chiffrement du canal et les secrets partagés, pour se protéger contre les risques affectant la chaîne logistique.

Les passerelles API procurent un niveau supérieur de protection pour les API des institutions financières, rendant plus difficile pour un hacker de parvenir à ses fins, bien que la protection qu’elles fournissent reste incomplète. Pourquoi ? Les passerelles ont plusieurs rôles utiles : elles assurent une fonction de gouvernance pour établir des connexions entre les différentes entités et contrôlent de façon centralisée le routage des requêtes des API, l’agrégation des réponses des API et le respect des SLAs. Une passerelle assure des fonctions d’authentification et d’autorisation, contrôle le trafic, stoppe les attaques par déni de service et ajoutent de la télémétrie et des analytics, ce qui aide les organisations à mieux comprendre comment les API sont utilisées. 

Toutefois, les passerelles API n’inspectent pas toutes les données qui passent d’une terminaison à une autre, ce qui est essentiel pour une protection complète des API. Par exemple, imaginez que vous allez à l’aéroport et que vous passez la sécurité. L’agent vérifie la carte d’embarquement et l’identité du passager avant de le laisser passer. Ces activités ressemblent à celles de la configuration de la passerelle API et à l’utilisation d’un secret partagé par le programmeur pour établir la connexion. En assumant que la pièce d’identité et la carte d’embarquement sont légitimes, le passager est-il prêt à embarquer dans l’avion ?

Tous ceux qui ont déjà pris l’avion savent que la réponse est non, bien sûr. Il ne suffit pas d’avoir une pièce d’identité et une carte d’embarquement valides. La sécurité de l’aéroport vérifie aussi les bagages du passager et ce qu’il porte sur lui. Sans ce contrôle, quelqu’un ayant un passeport et une carte d’embarquement valides pourrait tout de même emporter un objet dangereux dans l’avion. C’est la raison pour laquelle les bagages à main de chaque passager sont passés au scanner. L’agent qui vérifie les images a vu des millions de voyageurs. Cet agent est entraîné pour rechercher des anomalies, et les bagages qui posent problème sont identifiés par ces yeux entraînés et peuvent faire l’objet d’un examen plus approfondi.

C’est la raison pour laquelle il est absolument crucial d’examiner les données qui passent entre les terminaisons.

Vous vous souvenez des problèmes évoqués plus haut dans cet article ? Imaginons que le hacker en question a infiltré un tiers de confiance et accédé au secret partagé. Désormais, ce cybercriminel a réussi à s’authentifier sur la passerelle API de la banque en se faisant passer pour un utilisateur autorisé. Ceci peut conduire à une fuite de données, à l’usurpation d’un compte ou même à la possibilité de modifier ou d’effacer des informations que la banque n’a jamais eu l’intention de partager. Le hacker peut sinon essayer d’injecter du code ou des commandes malveillantes dans l’API en les masquant au sein du contenu auquel on fait confiance ou qui est attendu. Il s’agit là de certains des types d’attaques les plus courants lorsqu’un maillon faible dans la chaîne logistique est utilisé pour s’infiltrer dans une institution financière.

Si les seuls contrôles en place sont le secret partagé et la passerelle API, ces types d’attaques pourraient alors passer inaperçus. Si la banque réalise plus tard que ce type d’attaque a eu lieu en analysant les informations depuis les analytics fournis par la passerelle, les dommages seront déjà devenus réalité. Pour répondre à ces menaces en temps réel, l’organisation a besoin d’une solution de sécurité des API qui examine les données qui passent entre les terminaisons, identifie les anomalies en temps réel, alerte l’équipe de sécurité concernée et prend des mesures immédiates.

Les institutions financières exploitent toujours plus les APIs pour construire leurs écosystèmes financiers, mais ne peuvent se fier aveuglément au fait que les programmeurs ont intégré une sécurité forte dans ces connexions. Le fait est que, même si les développeurs ont privilégié la sécurité, il est presque impossible de prendre en compte tous les scénarios potentiels d’attaque dans le code initial. Assumer que les passerelles API offrent une protection adéquate est également une erreur.

Chez Ping Identity, nous comprenons l’importance des API pour le succès de vos projets digitaux, et nous savons que vous devez répondre aux risques posés par la chaîne logistique. Notre solution pour la sécurité et l’intelligence des API financières agit comme le scanner des bagages à l’aéroport dans l’exemple plus haut, en ayant recours au machine learning pour visualiser les données, apprendre ce qui est normal, alerter les équipes de sécurité en cas d’anomalies et de comportements malveillants, et même prendre immédiatement des mesures ciblées en cas d’attaque.

Les API sont l’avenir des services digitaux, et les cybercriminels trouvent en permanence de nouveaux moyens créatifs de les exploiter. Les institutions financières doivent renforcer leurs défenses, et Ping Identity peut les y aider.

Envie d’en savoir plus sur ce sujet ? Découvrez notre livre blanc, Le besoin de sécurité et de gouvernance des API pour en savoir plus.