La conformité dans les services financiers repose sur la sécurité logicielle

Les institutions de services financiers ont de solides raisons de garantir la sécurité du code logiciel qu'elles utilisent. Une motivation évidente est, bien entendu, la nécessité de protéger leurs données contre les violations, ce qui peut s'avérer coûteux en termes de fuites d'informations personnelles identifiables (PII), de frais de nettoyage, d'amendes, de restitutions et d'atteinte à la réputation de l'organisation. Une autre raison constante est la nécessité de rester en conformité avec un éventail de réglementations sectorielles et gouvernementales.

En raison de la manipulation de volumes importants d'informations sensibles, personnelles et financières, ainsi que de fonds monétaires, les services financiers constituent un secteur hautement réglementé. Selon les services fournis, les entreprises doivent se conformer à un ensemble de règles et d'exigences.

La norme de sécurité des données de l'industrie des cartes de paiement (PCI DSS) est bien connue pour ses règles sur la protection des données des titulaires de cartes, par exemple. Les exigences de la loi Sarbanes-Oxley régissent la gestion des dossiers financiers. Les entreprises opérant à l'international connaissent bien le Digital Operational Resilience Act (DORA), qui est un cadre contraignant de gestion des risques, ainsi que les normes mondiales pour les transferts de fonds établies par la Society for Worldwide Interbank Financial Telecommunication, connue sous le nom de Swift.

Et des lois telles que le California Consumer Privacy Act (CCPA) et le Règlement général sur la protection des données (RGPD) de l'UE fixent des exigences pour la protection de la vie privée et des informations personnelles des clients. Il en existe d'autres, telles que les réglementations établies par l'Office of the Comptroller of the Currency (OCC) aux États-Unis et la Banque centrale européenne (BCE).

Si cela ne suffit pas, la Stratégie nationale de cybersécurité stipule, entre autres, que les éditeurs de logiciels devraient être tenus responsables d'une sécurité logicielle inefficace. De plus, la Cybersecurity and Infrastructure Security Agency (CISA), aux côtés de 17 partenaires américains et internationaux, a publié des conseils sur les principes de conception sécurisée (Secure-By-Design) pour le développement de logiciels.

Un point commun pour les entreprises de services financiers est qu'un code sécurisé est un élément essentiel pour atteindre les objectifs de ces réglementations, ce qui facilite la démonstration de leur conformité. Cela souligne pourquoi les développeurs ont besoin de formation et de montée en compétences pour garantir que la sécurité est appliquée au code dès le début du processus de développement.

Pour illustrer le fonctionnement, examinons la toute dernière version de PCI DSS.

Le codage sécurisé (et la formation des développeurs) est au cœur de PCI DSS 4.0

PCI DSS 4.0, devenue obligatoire depuis le 1er avril 2024, inclut plusieurs mises à jour substantielles par rapport à la version 3.2.1, notamment l'accent mis sur le rôle que jouent les développeurs pour garantir un code logiciel sécurisé.

PCI reconnaît depuis longtemps l'importance des logiciels sécurisés. La version 2.0, publiée en 2017, incluait des conseils aux développeurs sur la sécurisation des transactions sur les appareils mobiles. Les conseils de la version 4.0 mettent désormais l'accent sur l'application des meilleures pratiques de sécurité au développement logiciel et incluent des recommandations spécifiques sur la formation des développeurs.

Les exigences sont souvent formulées de manière générale, bien que les entreprises puissent souhaiter mettre en œuvre une approche plus approfondie.

Par exemple, une exigence de la version 4.0 stipule que les « processus et mécanismes de développement et de maintenance de systèmes et de logiciels sécurisés sont définis et compris ». Un bon moyen de s'en assurer est que les développeurs reçoivent une formation précise sur les langages de programmation et les frameworks qu'ils utilisent afin de combler toute lacune en matière de connaissances.

Une autre exigence stipule que les développeurs travaillant sur des logiciels sur mesure et personnalisés doivent recevoir une formation au moins une fois tous les 12 mois, couvrant :

• La sécurité logicielle pertinente pour leur fonction et leurs langages de développement.
• Les techniques de conception et de codage de logiciels sécurisés.
• La manière d'utiliser les outils de test de sécurité — s'ils sont utilisés — pour détecter les vulnérabilités dans les logiciels.

En réalité, cependant, une fois par an n'est pas suffisant pour traiter les problèmes de sécurité fondamentaux et briser les mauvaises habitudes de codage. La formation doit être continue et mesurée, avec un processus de vérification des compétences pour garantir qu'elle est mise à profit efficacement.

PCI DSS 4.0 inclut plus d'une demi-douzaine d'autres exigences qui traitent de domaines tels que la prévention et l'atténuation de divers types d'attaques, la documentation des composants logiciels tiers, l'identification et la gestion des vulnérabilités, ainsi que d'autres mesures de sécurité. Dans chaque cas, les organisations seraient bien avisées de poursuivre rigoureusement ces mesures. La formation sur les vecteurs d'attaque devrait être fréquente, plutôt qu'annuelle. Les composants tiers, souvent source de vulnérabilités, devraient être soigneusement inventoriés via un programme de nomenclature logicielle (SBOM). Enfin, les organisations doivent s'assurer de définir clairement les rôles pour la gestion des vulnérabilités.

La nouvelle version offre également aux organisations une certaine flexibilité dans le respect de ses exigences, en se concentrant sur les résultats plutôt que sur le simple respect de cases à cocher, tout en ajoutant de nouvelles exigences pour les contrôles d'authentification, la longueur des mots de passe, les comptes partagés et d'autres facteurs.

La conformité commence dès le début du cycle de vie du développement logiciel (SDLC)

Ces réglementations ont toutes en commun de chercher à établir des normes élevées pour la protection des données et des transactions dans le secteur des services financiers. Comme pour la dernière version de la norme PCI DSS, elles insistent de plus en plus sur l'importance d'un code sécurisé dès le début du cycle de vie du développement logiciel (SDLC). La stratégie nationale de cybersécurité et les principes « Secure by Design » de la CISA responsabilisent également les éditeurs de logiciels — avant même la mise sur le marché — obligeant ainsi les entreprises non soumises aux réglementations financières à s'y conformer.

Les organisations doivent combler le fossé entre les équipes DevOps (axées sur la rapidité de développement) et les équipes AppSec (qui s'efforcent d'intégrer la sécurité au processus) en formant les développeurs à faire de la sécurité une composante intrinsèque de leur approche. Cela exige toutefois un ensemble de compétences complexes, que les sessions de formation annuelles ou les programmes éducatifs classiques et statiques ne peuvent offrir. La formation doit être continue, agile, conçue pour impliquer les apprenants avec des scénarios réels et dispensée par petites séquences adaptées à leur emploi du temps.

Les entreprises de services financiers doivent garantir la sécurité pour se protéger contre les violations et se conformer à des réglementations de plus en plus strictes. Le coût de la non-conformité peut être aussi préjudiciable qu'une violation de données, tant en termes d'image de marque que de pertes financières. Le rapport Cost of a Data Breach Report 2023 d'IBM a par exemple révélé que les organisations présentant un niveau élevé de non-conformité ont dû faire face, en moyenne, à des amendes et autres coûts s'élevant à 5,05 millions de dollars, soit un demi-million de dollars de plus que le coût moyen d'une violation de données réelle.

La croissance continue des environnements cloud et des transactions numériques a rendu la sécurité logicielle primordiale dans le secteur des services financiers, un fait reconnu par des réglementations telles que PCI DSS. Le meilleur moyen de garantir la sécurité d'un logiciel est d'adopter un codage sécurisé dès le début du SDLC. Pour y parvenir, il est essentiel de former efficacement les développeurs aux pratiques de codage sécurisé.

Pour un aperçu complet de la manière dont le codage sécurisé peut contribuer au succès, à la sécurité et à la rentabilité des entreprises de services financiers, vous pouvez lire le nouvel e-book de Secure Code Warrior : The ultimate guide to security trends in financial services.

Consultez les pages du blog de Secure Code Warrior pour obtenir plus d'informations sur la cybersécurité, sur l'évolution des menaces, et pour découvrir comment utiliser des technologies et des formations innovantes afin de mieux protéger votre organisation et vos clients.

‍