Meilleures pratiques pour vous aider à respecter la conformité de la norme PCI DSS v4.0 en matière de sécurité des API

Les exigences de la version originale englobent les piliers de sécurité qui sont aussi importants aujourd'hui qu'ils ne l'étaient lors de leur publication en 2006. Par exemple :

• Surveiller et contrôler l'accès à tous les comptes administratifs sur l'ensemble des systèmes informatiques traitant ou stockant les données des titulaires de carte

• Attribuer l'accès aux données du système et des titulaires de carte en fonction des besoins et définir les exigences d'accès par rôle

Le problème, c'est que l'écosystème des menaces actuel est plus complexe qu'il ne l'était en 2006.

Oui, les organisations doivent toujours répondre à la tendance des pirates à cibler des domaines tels que les comptes privilégiés et les utilisateurs disposant d'autorisations excessives. Cependant, les entreprises actuelles doivent également adapter leurs programmes de conformité pour tenir compte des acteurs de la menace qui ciblent fréquemment des milliers d'API hébergées dans des technologies de paiement. Ces pirates savent que les API sont faciles à exploiter et peuvent fournir un moyen efficace de voler les données des titulaires de carte.

Par conséquent, pour se conformer à la norme PCI DSS v4.0, votre organisation doit comprendre et se défendre contre les menaces API. Dans cet article de blog, nous partagerons des analyses sur les risques, les exigences et les moyens de se conformer aux exigences.

Dans l'ensemble, la norme PCI DSS v4.0 est centrée sur quatre objectifs principaux :

1. Continuer à répondre aux besoins de sécurité du secteur des paiements

2. Préconiser la sécurité en tant que processus continu

3. Donner aux entreprises une certaine flexibilité (par exemple, de nouveaux outils, de nouveaux contrôles) dans leur manière de répondre aux exigences

4. Améliorer les méthodes et les processus de validation

La norme PCI DSS v4.0 décrit explicitement les API comme un domaine clé qui nécessite visibilité et protection. C'est là que les quatre objectifs entrent en jeu. Mais le troisième point (la flexibilité d'utiliser de nouveaux outils et de nouveaux contrôles) est particulièrement important, compte tenu des risques uniques que présentent les API. Par exemple :

• Les API se trouvent au cœur de vos produits et services digitaux orientés client. Une entreprise moyenne compte entre 15 000 et 25 000 API, selon sa taille, toutes conçues pour faciliter un échange continu de données. 

• Ces données comprennent des informations sensibles sur les clients. Pour chaque paiement digital, il existe une API en arrière-plan, qui transmet des données entre les applications, les systèmes, les tiers, etc.

• Une seule API compromise peut entraîner le vol de millions d'enregistrements, leur détention contre rançon ou leur publication au vu et au su de tous. Et les API exposées ou mal configurées sont courantes, faciles à compromettre et souvent non protégées, invisibles et non gérées.

Les régulateurs sont conscients du risque pour les API, et votre entreprise doit démontrer qu'elle dispose de la visibilité et des contrôles nécessaires pour empêcher que les données ne soient compromises.

Les données des cartes de paiement sont compromises dans plus d'un tiers (37 %) des violations selon le rapport Data Breach Investigations Report 2023 de Verizon. La norme PCI DSS v4.0 inclut de nouvelles exigences en matière d' authentification multifactorielle et de longueur de mot de passe afin de sécuriser l'élément humain de la surface d'attaque de l'industrie des paiements.

Cependant, il est important de se rappeler que les violations de données ne sont pas toujours dues à des méthodes d'attaque bien médiatisées et centrées sur l'homme, telles que l'hameçonnage des mots de passe des employés.

Par exemple, 18 % des attaques contre les entreprises de commerce électronique impliquent un code malveillant intégré dans les pages web de traitement de carte. Les acteurs malveillants d'aujourd'hui sont de plus en plus sophistiqués et ciblent les composants non humains automatisés de l'environnement informatique, qui ne sont souvent pas sécurisés correctement, comme les API.

78 %  des entreprises ont subi un incident de sécurité lié aux API, selon notre étude. Reconnaissant l'urgence des menaces liées aux API, la norme PCI DSS v4.0 inclut de nouvelles règles, directives et meilleures pratiques en matière de sécurité des API. Découvrons-en davantage en explorant d'abord l'exigence 6.2.3.

L'exigence 6.2.3 est axée sur la nécessité pour les entreprises d'examiner le code de leurs applications personnalisées (c'est-à-dire les applications développées par un fournisseur tiers, mais pas les applications commerciales prêtes à l'emploi standard) afin de s'assurer qu'aucune vulnérabilité n'est introduite dans la production.

Cette exigence offre des conseils pour confirmer que le logiciel d'une entreprise utilise en toute sécurité les fonctions de composants externes (bibliothèques, cadres, API, etc.), ce qui témoigne du rôle clé que jouent les API dans la chaîne d'approvisionnement logicielle dans son ensemble – et des mesures à prendre pour la protéger.

Les API sont devenues la méthode de connectivité et d'échange de données par défaut dans les environnements applicatifs. Dans cette optique, sécuriser les API avec une approche de pré-production (shift-left) et une approche de post-production (shield-right) est essentielle pour garantir la résilience de votre entreprise numérique face aux attaques.

Voici 6  meilleures pratiques en matière de sécurité des API qui vous aideront à respecter la conformité avec l'exigence 6.2.3.

1. Confirmer l'utilisation des composants basés sur l'API et leur posture de sécurité (par exemple, trouver toute erreur de configuration entraînant des vulnérabilités, y compris l'utilisation de chiffrements de cryptage faibles comme indiqué dans la norme)

2. Valider le comportement normal et attendu de l'utilisation de l'API et mettez en place des contrôles pour empêcher les acteurs suspects d'abuser de vos systèmes (par exemple, vérifiez le comportement de l'application pour détecter les vulnérabilités logiques)

3. Détecter les cadres tiers utilisés pour alimenter vos API et déterminer s'ils sont obsolètes et vulnérables

4. Établir un inventaire complet de toutes vos API, y compris les différentes versions des API que vous exécutez, ce qui vous donnera un aperçu des fonctionnalités non documentées potentielles et des portes dérobées que vous devez gérer

5. Valider la sécurité de votre code API et éviter d'intégrer dans la production des vulnérabilités liées aux API

6. Mettre en œuvre les meilleures pratiques de codage sécurisé pour les API, ce qui vous permettra d'adopter une approche programmatique pour fournir du code en toute sécurité et en continu

La norme PCI SSC a également ajouté deux autres sections comprenant la sécurité des API à la norme PCI DSS v4.0. Voici un résumé des deux exigences supplémentaires que vous devrez respecter.

• L'exigence 6.3.2 s'applique à la tenue d'un inventaire des logiciels sur mesure et personnalisés, ainsi que des composants logiciels tiers intégrés dans les logiciels sur mesure et personnalisés, afin de faciliter la gestion des vulnérabilités et des correctifs.

• L'exigence 6.2.2 concerne la formation du personnel de développement logiciel travaillant sur des logiciels sur mesure et personnalisés. Elle stipule que les développeurs doivent être formés au moins une fois tous les 12 mois sur la sécurité pertinente pour leur fonction, y compris la conception de logiciels sécurisés et les techniques de codage sécurisé. Cette formation comprend des outils de test de sécurité et explique comment utiliser ces outils pour détecter les vulnérabilités dans les logiciels.