La norme PCI-DSS 4.0 sera disponible plus tôt que vous ne le pensez, et c'est l'occasion d'améliorer la cyber-résilience de votre organisation.

Une version de cet article a été publiée sur Boulevard de la sécurité. Elle a été mise à jour et publiée ici.

Au début de l'année, le Conseil des normes de sécurité PCI a dévoilé la version 4.0 de sa norme de sécurité des données de l'industrie des cartes de paiement (PCI DSS). Bien que les organisations ne devront pas être entièrement conformes à la version 4.0 avant mars 2025, cette mise à jour est la plus transformatrice à ce jour et exigera de la plupart des entreprises qu'elles évaluent (et probablement mettent à niveau) des processus de sécurité complexes et des éléments de leur pile technologique. Cela s'ajoute à la mise en œuvre d'une formation de sensibilisation à la sécurité basée sur les rôles et d'une formation régulière au codage sécurisé pour les développeurs.

Il s'agit là d'une occasion en or pour les entreprises du secteur BFSI d'améliorer sérieusement leurs programmes de sécurité et d'entrer dans une nouvelle ère de cyber-résilience axée sur les personnes. 

Quels sont les plus grands défis à relever 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 aux besoins de l'entreprise et aux ressources disponibles, les nouvelles normes PCI DSS couvrent beaucoup de terrain. Toutefois, elles révèlent une évolution marquée vers la flexibilité dans les approches visant à satisfaire aux exigences de sécurité, ce qui est important dans un secteur où les outils, les menaces, la stratégie et les mesures de conformité peuvent changer en un instant.

La norme PCI DSS 4.0 adopte le concept selon lequel il existe de nombreuses façons d'atteindre le même objectif de meilleures pratiques de sécurité étanches. C'est vrai, mais cela semble mieux convenir aux organisations ayant une maturité de sécurité avancée et laisse beaucoup de place à l'erreur, en particulier pour celles qui n'ont pas été réalistes dans leur assessment de leur véritable maturité de sécurité interne. En fin de compte, les entreprises doivent être prêtes à s'engager dans la sécurité comme un processus continu et évolutif, et non comme un exercice ponctuel "à mettre en place et à oublier". Une forte culture de la sécurité est indispensable, avec un engagement à l'échelle de l'organisation en faveur de la sensibilisation à la sécurité. 

Quant aux outils au niveau du code - la cohorte de développement - ils doivent être en mesure de fournir des logiciels conformes et sécurisés dans n'importe quel environnement commercial traitant des actifs et des transactions numériques. 

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

Les développeurs font partie intégrante de l'atteinte d'un état d'excellence en matière de sécurité des logiciels, et cela est particulièrement pertinent pour aller au-delà de la simple conformité symbolique à la norme PCI DSS. Il est essentiel que les développeurs comprennent l'image plus large de PCI DSS 4.0 en termes de ce qu'ils peuvent contrôler et intégrer dans leur approche par défaut de la création d'un logiciel. 

Les changements les plus importants pour l'équipe de développement se situent dans trois domaines clés, qui peuvent être décomposés comme suit :

• Authentification : Un plan viable de contrôle d'accès a toujours été un élément clé de la conformité PCI, mais la version 4.0 donne un coup d'accélérateur qui nécessitera une mise en œuvre minutieuse, tant en interne qu'en externe. L'authentification multifactorielle (MFA) deviendra la norme, tout comme les règles renforcées concernant la complexité des mots de passe et les délais d'attente.
  
  Les problèmes de sécurité liés à l'authentification et au contrôle d'accès étant désormais les plus courants auxquels le développeur moyen est susceptible d'être confronté, il est impératif qu'une formation précise soit mise en place pour l'aider à identifier et à résoudre ces problèmes dans le code réel.
  
  
• Chiffrement et gestion des clés : Nous vivons 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. Ces données de grande valeur étant menacées, le cryptage et des pratiques de cryptographie rigoureuses sont indispensables. Les développeurs doivent s'assurer qu'ils disposent de connaissances actualisées sur les lieux de transmission des informations, sur la manière dont les utilisateurs peuvent y accéder et, même dans le cas où elles se retrouveraient entre de mauvaises mains, s'assurer qu'elles sont illisibles pour les acteurs de la menace.
  
  
• Logiciels malveillants : dans les lignes directrices précédentes, les contrôles de sécurité relatifs à la protection des logiciels contre les codes malveillants étaient appelés "logiciels antivirus", mais cela simplifie à l'excès ce qui devrait être une approche multicouche protégeant contre bien plus que les seuls virus. Les solutions anti-programmes malveillants doivent être appliquées partout où cela est nécessaire, et la journalisation et la surveillance continues sont obligatoires.
  
  Il est également essentiel que les développeurs aient des parcours d'apprentissage qui couvrent l'identification des composants vulnérables, en particulier avec la plupart des bases de code qui reposent au moins en partie sur du code tiers.

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

Comme 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 l'on considère qu'une fois par an est un point de contact suffisant pour la création de logiciels sécurisés, on est loin du compte et il est peu probable que l'on obtienne des logiciels plus sûrs et conformes. 

La formation des développeurs devrait commencer par une formation de base au Top 10 de l'OWASP, ainsi qu'à toutes les autres vulnérabilités qui sont pertinentes pour le langage et critiques pour l'entreprise. Cela devrait faire partie d'un programme continu, dans le but de continuer à développer ces compétences et d'intégrer la sécurité non seulement dans le développement de logiciels dès le départ, mais aussi dans leur état d'esprit et leur approche de leur rôle. En outre, les rôles et les responsabilités doivent être parfaitement clairs pour la cohorte de développeurs et leurs responsables. La sécurité doit être une responsabilité partagée, mais il n'est que juste de documenter les attentes et de s'assurer qu'elles peuvent être satisfaites correctement.

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

‍