Intégrez la sécurité des API à la conformité réglementaire : Six exemples à suivre
Q : Pourquoi les entreprises se voient-elles infliger des amendes pour des incidents liés à la sécurité des API ?
R : Parce que les régulateurs commencent à se rendre compte de ce que les attaquants savent déjà : Les API exposées ou mal configurées sont courantes, faciles à compromettre et souvent non protégées.
Il suffit d'une API vulnérable
Chaque fois qu'un client, un partenaire ou un fournisseur entre en contact avec votre entreprise par voie digitale, une API facilite en coulisses l'échange rapide de données, souvent sensibles. Les attaquants d'aujourd'hui savent qu'ils ne sont plus obligés de mettre en œuvre des stratagèmes complexes en plusieurs étapes pour voler vos données. Ils peuvent en effet contourner l'intermédiaire, par exemple, vos applications, et cibler directement vos API.
Est-il important qu'un document réglementaire de 200 pages mentionne explicitement, sous-entende subtilement ou indique vaguement que la sécurité des API est essentielle ? Pas vraiment. Parce qu'une violation de données en est une, quelle que soit la manière dont elle a été exécutée ou l'endroit où elle l'a été. Il suffit d'une API vulnérable pour que vos données soient compromises, volées ou publiées au vu et au su de tout le monde.
Les violations de données se produisent pendant que vous ne faites rien
La sécurité des API peut-elle attendre que vous donniez la priorité aux menaces que vos régulateurs pointent du doigt, comme les ransomwares ? Malheureusement, non. Les API sont toujours plus nombreuses et plus dangereuses, à mesure que les entreprises déploient de nouveaux produits et services digitaux.
76 % des organisations que nous avons interrogées ont connu un incident de sécurité lié aux API, et la plupart d'entre elles n'ont pas mis en place les contrôles ou les outils nécessaires pour y mettre fin. Pendant ce temps, le coût moyen d'une violation de données augmente de 12,6 % (pour atteindre 5,05 millions de dollars) en cas de non-conformité extrême de l'entreprise.
Si vous adoptez une approche proactive pour identifier chaque API, évaluer les risques qu'elles présentent et les protéger contre les violations, vous protégerez vos données contre les répercussions que les autorités de régulation tentent d'éviter. »
Quel est l'impact sur votre programme de conformité ?
Si vous adoptez une approche proactive de la détection de chaque API, de l'évaluation des risques et de la protection contre les violations, vous protégerez vos données contre les répercussions que les autorités de réglementation tentent d'éviter.
Dans cet article de blog, nous présentons un aperçu des six réglementations et directives qui indiquent un besoin de protection des API, et nous mettons en évidence des exemples clés de moyens de s'y conformer.
6 règlements et cadres clés
1. La norme de sécurité de l'industrie des cartes de paiement (PCI DSS) version 4.0
PCI DSS est devenue une norme mondiale de protection des données de paiement. Si votre entreprise accepte les principales cartes de crédit et traite, stocke ou transmet électroniquement les données des titulaires de cartes, vous devez vous mettre en conformité.
L'exigence 6.2.3 de la norme PCI DSS 4.0 est axée sur la nécessité pour les entreprises d'examiner le code de leurs applications personnalisées afin de s'assurer qu'aucune vulnérabilité n'est introduite dans la production. Spécifique aux API, 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.).
Une façon parmi d'autres de se conformer à cette exigence : Validez 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).
2. Le Règlement général sur la protection des données (RGPD)
RGPD est une législation de l'Union européenne qui vise à renforcer et à unifier la protection des données pour les individus au sein de l'Union européenne. Cependant, le RGPD ne se limite pas aux entreprises basées dans l'UE ; toute entreprise offrant des biens de consommation ou des services dans l'Union européenne doit s'y conformer.
L'article 25 du RGPD est fondé sur le principe du moindre privilège, exigeant des entreprises qu'elles mettent en œuvre « des mesures techniques et organisationnelles pour garantir que, par défaut, seules les données à caractère personnel qui sont nécessaires pour chaque finalité spécifique [...] sont traitées ». De leur côté, les développeurs d'API doivent mettre en œuvre des contrôles d'authentification et d'autorisation des utilisateurs afin de protéger les données sensibles qui transitent par leurs API.
Il s'agit là d'un excellent exemple de la manière dont la sécurité des API s'intègre dans les programmes de sécurité et de conformité à grande échelle de votre entreprise. Les concepts tels que le moindre privilège ne s'appliquent pas uniquement à nous, les humains ; les API doivent également bénéficier d'un accès suffisant pour accomplir leur travail.
3. Le Règlement sur la résilience opérationnelle digitale (DORA)
Au total, plus de 22 000 institutions financières et fournisseurs de services informatiques de l'Union européenne sont concernés par les exigences du règlement DORA, qui visent à aider les entreprises à résister aux cyberattaques et à s'en remettre.
Comment la sécurité des API s'inscrit-elle dans le règlement DORA ? Examinons le contenu de l'article 3 du règlement DORA , qui exige des entreprises qu'elles utilisent des solutions et des processus TIC qui :
réduisent au minimum les risques liés aux données, les accès non autorisés et les défauts techniques
empêchent l'indisponibilité des données, la perte de données et les atteintes à l'intégrité et à la confidentialité
assurent la sécurité du transfert des données
L'objectif principal des API étant de transférer des données, il est essentiel de tester régulièrement vos API pour détecter les vulnérabilités, notamment l'absence de contrôles d'authentification et l'exposition involontaire à l'internet public. En appliquant une approche « shift-left » au test des API, vous pouvez empêcher les vulnérabilités d'atteindre la production.
4. La Loi HIPAA (Health Insurance and Portability and Accountability Act)
HIPAA vise à protéger la confidentialité des données et les règles de sécurité pour sauvegarder les informations de santé protégées (PHI) dans les dossiers de santé électroniques et les systèmes informatiques de santé. Tout prestataire de soins de santé, administrateur de régime ou centre d'échange américain qui stocke ou transmet électroniquement des IPS doit se conformer à la loi HIPAA.
La règle de confidentialité de l'HIPAA précise que les entités concernées « doivent développer et mettre en œuvre des politiques et des procédures qui limitent l'accès et l'utilisation des informations de santé protégées en fonction des rôles spécifiques des membres de leur personnel ».
Par conséquent, les développeurs d'API d'une organisation doivent intégrer des mesures de protection techniques telles que l'authentification, des identifiants d'utilisateur uniques et des contrôles d'accès basés sur les rôles afin de garantir la mise en place d'un moindre privilège.
5. Directive sur la sécurité des réseaux et des systèmes d'information (NIS2)
L'Union européenne a adopté la version 2.0 de la directive NIS en janvier 2023, qui s'appuie sur les directives de la version originale pour sécuriser l'infrastructure informatique et signaler les incidents.
À noter, NIS2 met l'accent sur la sécurisation des chaînes d'approvisionnement : Les entreprises doivent désormais évaluer les risques et sécuriser leurs chaînes d'approvisionnement informatiques et les relations avec les fournisseurs tiers.
Étant donné que les API sont souvent utilisées pour intégrer des services externes, des fournisseurs de logiciels aux fournisseurs de services cloud, il est essentiel d'assurer leur sécurité pour montrer aux régulateurs que votre organisation protège les données de ses clients et la chaîne d'approvisionnement dans son ensemble contre les attaques.
6. Conseil fédéral d'examen des institutions financières (FFIEC)
Le FFIEC élabore des recommandations et des normes à l'intention des régulateurs fédéraux chargés de superviser le secteur financier américain. Il s'agit notamment de la Réserve fédérale et de la FDIC. La mission du conseil est de protéger les utilisateurs et les investisseurs contre les fraudes, les abus et les fautes professionnelles.
L'examen des directives du FFIEC révèle clairement comment la sécurisation des API peut aider les entreprises à protéger les utilisateurs de la fraude et de l'usurpation d'identité. Par exemple, le FFIEC recommande aux entreprises de dresser un inventaire de tous les systèmes d'information, y compris les API, qui nécessitent une authentification et des contrôles d'accès.
L'autorisation est également essentielle : Le FFIEC recommande la mise en œuvre d'une sécurité à plusieurs niveaux ; par exemple, des activités de surveillance, de journalisation et de reporting afin d'identifier et de suivre les accès non autorisés aux API.
Sécuriser les API, c'est aussi renforcer la confiance
Les six réglementations et directives évoquées dans ce billet de blog ont un point commun : la protection des données que d'autres vous ont confiées.
Comme vous le savez, les enjeux d'une violation de données d'API ne se limitent pas à des amendes. Votre réputation et la confiance de vos clients, de vos employés et des autorités de régulation qui couvrent votre secteur sont en jeu. Les régulateurs ont besoin de savoir que vous appliquez la bonne combinaison de personnes, de processus et d'outils pour empêcher que des attaques de ce type ne se produisent.
En savoir plus
Souhaitez-vous mieux comprendre les exigences relatives à l'API pour les six réglementations abordées dans cet article ?