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 cyberrésilience de votre organisation

Une version de cet article a été publiée sur Boulevard de sécurité. Il a été mis à jour et diffusé ici.

Plus tôt cette 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). Les entreprises n'auront pas besoin d'être entièrement conformes à la version 4.0 avant mars 2025, mais cette mise à jour est la plus transformatrice à ce jour et obligera la plupart des entreprises à évaluer (et probablement à mettre à niveau) des processus de sécurité complexes et des éléments de leur infrastructure 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.

Cela représente une occasion en or pour les entreprises de l'espace BFSI d'améliorer sérieusement leurs programmes de sécurité, ouvrant ainsi la voie à une nouvelle ère de cyberrésilience axée sur les personnes.

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

Tout comme le programme de sécurité d'une entreprise est complet, avec des complexités propres à ses besoins commerciaux et aux ressources disponibles, les nouvelles normes PCI DSS couvrent de nombreux domaines. Cependant, ils révèlent une évolution marquée vers la flexibilité dans les approches visant à répondre aux exigences de sécurité, et 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 repose sur le concept selon lequel il existe de nombreuses manières d'atteindre le même objectif en matière de bonnes pratiques de sécurité. C'est vrai, mais cela semble mieux adapté 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 évalué de manière réaliste leur véritable maturité en matière de sécurité interne. En fin de compte, les entreprises doivent être prêtes à s'engager dans la sécurité en tant que processus continu et évolutif, et non en tant qu'exercice ponctuel « à repartir et oublier ». Une solide culture de sécurité est indispensable, avec un engagement à l'échelle de l'organisation en faveur de la sensibilisation à la sécurité.

Et ceux qui utilisent des outils au niveau du code, c'est-à-dire la cohorte de développement, doivent être en mesure de fournir des logiciels conformes et sécurisés dans tout environnement commercial gérant 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 dans l'atteinte d'un niveau d'excellence en matière de sécurité logicielle, et cela ne se limite pas à la simple conformité à la norme PCI DSS symbolique. Il est essentiel que les développeurs comprennent la vision globale de la norme PCI DSS 4.0 en termes de ce qu'ils peuvent contrôler et intégrer dans le cadre de leur approche par défaut lors de la conception d'un logiciel.

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

• Authentification : Un plan viable pour le contrôle d'accès a toujours été un élément clé de la conformité PCI, mais la version 4.0 va encore plus loin, d'une manière qui nécessitera une mise en œuvre minutieuse à la fois en interne et en externe. L'authentification multifactorielle (MFA) deviendra la norme, tout comme le renforcement des règles relatives à la complexité des mots de passe et aux 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 problèmes les plus courants auxquels est confronté votre développeur moyen, il est impératif de mettre en place une formation de précision pour l'aider à identifier et à résoudre ces problèmes dans le code réel.
  
  
• Chiffrement et gestion des clés : Nous opérons dans un monde où nous pouvons accéder à certaines de nos informations les plus sensibles via plusieurs points d'accès, tels que nos services bancaires en ligne. Ces données de grande valeur étant menacées, le cryptage et de solides pratiques de cryptographie sont indispensables. Les développeurs doivent s'assurer de disposer de connaissances à jour sur l'endroit où les informations sont transmises, sur la manière dont les utilisateurs peuvent y accéder et, même si elles tombent entre de mauvaises mains, en veillant à ce qu'elles soient illisibles pour les acteurs de la menace.
  
  
• Logiciels malveillants : Dans les directives précédentes, les contrôles de sécurité relatifs à la protection des logiciels contre les codes malveillants étaient qualifiés de « logiciels antivirus », mais cela simplifie à l'extrême ce qui devrait être une approche multicouche protégeant contre bien plus que les seuls virus. Des solutions anti-malware doivent être appliquées chaque fois que cela est nécessaire, et une journalisation et une surveillance continues sont obligatoires.
  
  Il est également essentiel que les développeurs disposent de parcours d'apprentissage qui couvrent l'identification des composants vulnérables, en particulier lorsque la plupart des bases de code s'appuient au moins en partie sur du code tiers.

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

À l'instar des 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 constitue un point de contact suffisant pour la création sécurisée de logiciels, cela est loin d'être suffisant et il est peu probable qu'il aboutisse à des logiciels plus sûrs et conformes.

La formation des développeurs doit commencer par une formation de base dans le Top 10 de l'OWASP, ainsi que par toute autre vulnérabilité pertinente en termes de langage et critique pour l'entreprise. Cela devrait faire partie d'un programme permanent, dans le but de continuer à développer ces compétences et à intégrer la sécurité non seulement dans le développement des logiciels dès le départ, mais également dans leur état d'esprit et leur approche de leur rôle. En outre, les rôles et les responsabilités doivent être clairement définis pour la cohorte de développement et ses responsables. 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.

Compte tenu des délais impartis pour se préparer à la conformité à la norme PCI DSS 4.0, il est possible de réaliser des progrès significatifs en matière d'amélioration de la culture de sécurité à l'échelle de l'entreprise, et c'est un terrain fertile pour former la cohorte de développeurs la plus attentive à la sécurité que vous ayez jamais eue.

‍