La norme PCI-DSS 4.0 arrive plus vite que vous ne le pensez ; c'est l'occasion idéale de renforcer la cyberrésilience de votre organisation.

Une version de cet article a été publiée sur Security Boulevard. Il a été mis à jour et syndiqué ici.

Plus tôt cette année, le PCI Security Standards Council a dévoilé la version 4.0 de la norme de sécurité des données de l'industrie des cartes de paiement (PCI DSS). Bien que les organisations n'aient pas l'obligation d'être pleinement conformes à la version 4.0 avant mars 2025, cette mise à jour est la plus transformatrice à ce jour. Elle imposera à la plupart des entreprises d'évaluer (et probablement de mettre à niveau) des processus de sécurité complexes ainsi que certains éléments de leur infrastructure technologique. À cela s'ajoute la mise en place de formations à la sensibilisation à la sécurité basées sur les rôles et d'un enseignement régulier du codage sécurisé pour les développeurs.

Cela représente une occasion en or pour les entreprises du secteur BFSI d'améliorer sérieusement leurs programmes de sécurité, ouvrant ainsi une nouvelle ère de cyber-résilience axée sur l'humain.

Quels sont les plus grands défis pour se préparer à la norme PCI DSS 4.0 ?

Tout comme le programme de sécurité d'une organisation est global, avec des subtilités propres à ses besoins métier et aux ressources disponibles, les nouvelles normes PCI DSS couvrent un large éventail de sujets. Cependant, elles révèlent une évolution marquée vers une plus grande flexibilité dans les approches pour répondre aux exigences de sécurité. Dans un secteur où les outils, les menaces, la stratégie et les mesures de conformité peuvent changer en un instant, cela est significatif.

La norme PCI DSS 4.0 intègre l'idée qu'il existe de nombreuses façons d'atteindre le même objectif : des pratiques de sécurité infaillibles. C'est vrai, mais cette approche semble mieux adaptée aux organisations ayant une maturité de sécurité avancée et laisse une grande place à l'erreur, en particulier pour celles qui n'ont pas été réalistes dans l'évaluation de leur véritable maturité de sécurité interne. En fin de compte, les entreprises doivent être prêtes à considérer la sécurité comme un processus continu et évolutif, et non comme un exercice ponctuel que l'on configure et que l'on oublie. Une culture de sécurité forte est indispensable, avec un engagement envers la sensibilisation à la sécurité à l'échelle de toute l'organisation.

Quant à ceux qui travaillent sur les outils au niveau du code — l'équipe de développement — ils doivent être en mesure de fournir des logiciels conformes et sécurisés dans tout environnement professionnel traitant des actifs et des transactions numériques.

Vos développeurs sont-ils prêts à fournir des logiciels conformes ?

Les développeurs jouent un rôle essentiel pour atteindre l'excellence en matière de sécurité logicielle, et cela va bien au-delà de la simple conformité PCI DSS. Il est crucial que les développeurs comprennent la portée globale de la norme PCI DSS 4.0 en ce qui concerne ce qu'ils peuvent contrôler, et qu'ils l'intègrent par défaut dans leur approche de développement logiciel.

Trois domaines clés représentent les changements les plus pertinents pour l'équipe de développement, et ils peuvent être décomposés comme suit :

• Authentification : Un plan viable pour le contrôle d'accès a toujours été un élément clé de la conformité PCI. Cependant, la version 4.0 renforce cette exigence d'une manière qui nécessitera une mise en œuvre minutieuse, tant en interne qu'en externe. L'authentification multifacteur (MFA) deviendra la norme, tout comme les règles renforcées concernant la complexité des mots de passe et les délais d'expiration.
  
  Les problèmes de sécurité liés à l'authentification et au contrôle d'accès étant désormais les plus courants pour un développeur moyen, il est impératif de déployer une formation précise pour les aider à identifier et à corriger ces problèmes dans le code réel.
  
  
• Chiffrement et gestion des clés : Nous évoluons dans un monde où nous pouvons accéder à certaines de nos informations les plus sensibles via de multiples points d'accès, comme nos services bancaires en ligne. Avec ces données de grande valeur en danger, le chiffrement et des pratiques cryptographiques solides sont indispensables. Les développeurs doivent s'assurer de maintenir à jour leurs connaissances sur les lieux de transmission des informations, sur la manière dont les utilisateurs y accèdent et, même en cas de vol, garantir que ces données restent illisibles pour les acteurs malveillants.
  
  
• Logiciels malveillants : Dans les directives précédentes, les contrôles de sécurité concernant la protection des logiciels contre les codes malveillants étaient regroupés sous le terme « logiciel antivirus ». Cela simplifie à l'excès ce qui devrait être une approche multicouche protégeant contre bien plus que les seuls virus. Des solutions anti-malware doivent être appliquées partout où cela est nécessaire, et la journalisation ainsi que la surveillance continues sont obligatoires.
  
  Il est également essentiel que les développeurs disposent de parcours d'apprentissage couvrant l'identification des composants vulnérables, d'autant plus que la plupart des bases de code reposent au moins en partie sur du code tiers.

Qu'est-ce qui constitue une formation « suffisante » pour les développeurs ?

Comme pour les recommandations précédentes, la norme PCI DSS 4.0 propose que les développeurs soient formés « au moins » une fois par an. Cependant, si cela implique qu'une fois par an suffit pour garantir la création de logiciels sécurisés, c'est loin d'être adéquat et il est peu probable que cela aboutisse à des logiciels plus sûrs et conformes.

La formation des développeurs devrait commencer par une base sur le Top 10 de l'OWASP, ainsi que sur toute autre vulnérabilité pertinente pour le langage utilisé et critique pour l'entreprise. Cela devrait faire partie d'un programme continu, dans l'optique de continuer à développer ces compétences et d'intégrer la sécurité non seulement dans le développement logiciel dès le départ, mais aussi dans leur état d'esprit et leur approche de leur rôle. De plus, les rôles et responsabilités doivent être parfaitement clairs pour l'équipe de développement et ses managers. La sécurité doit être une responsabilité partagée, mais il est juste de documenter les attentes et de s'assurer qu'elles peuvent être satisfaites correctement.

Avec le délai disponible pour se préparer à la conformité PCI DSS 4.0, il est possible de réaliser des progrès significatifs dans l'amélioration de la culture de sécurité à l'échelle de l'organisation. C'est un terrain fertile pour développer l'équipe de développement la plus sensibilisée à la sécurité que vous ayez jamais eue.

‍