La conformité à FinServ dépend de la sécurité logicielle
Les institutions de services financiers ont de bonnes raisons de s'assurer que le code logiciel qu'elles utilisent est sécurisé. Une motivation évidente, bien entendu, est la nécessité de protéger leurs données contre une violation, qui peut être coûteuse en termes de fuite d'informations personnelles, de frais de nettoyage, d'amendes et de restitution, et d'atteinte à la réputation d'une organisation. Une autre raison persistante est la nécessité de rester en conformité avec un éventail de réglementations industrielles et gouvernementales.
Parce qu'ils traitent de nombreuses informations sensibles, personnelles et financières, ainsi que l'argent des gens, les services financiers sont un secteur hautement réglementé. En fonction des services qu'elles fournissent, 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 relatives à la protection des données des titulaires de cartes, par exemple. Les exigences de la Loi Sarbanes-Oxely régir la gestion des dossiers financiers. Les entreprises qui opèrent à l'international connaissent bien le Loi sur la résilience opérationnelle numérique (DORA), qui est un cadre de gestion des risques contraignant, et les normes mondiales pour les transferts de fonds établies par le Société pour les télécommunications financières interbancaires mondiales, connu sous le nom de Swift.
Et des lois telles que la Loi californienne sur la confidentialité des consommateurs (CCPA) et celui de l'UE Règlement général sur la protection des données (RGPD) fixe des exigences pour protéger la confidentialité et les informations personnelles des clients. Il en existe d'autres, comme les réglementations établies par l'Office of the Controller of the Currency (OCC) des États-Unis et la Banque centrale européenne (BCE).
Si cela ne suffit pas, Stratégie nationale de cybersécurité stipule notamment que les fabricants de logiciels devraient être tenus responsables de l'inefficacité de la sécurité des logiciels. Et l'Agence de cybersécurité et de sécurité des infrastructures (CISA), aux côtés de 17 partenaires américains et internationaux, a publié des directives sur Sécurisé dès la conception principes pour le développement de logiciels.
Un point commun pour les sociétés de services financiers est que le code sécurisé est un élément essentiel pour atteindre les objectifs de ces réglementations, ce qui peut faciliter la démonstration de leur conformité. Et cela montre pourquoi les développeurs ont besoin de formation et de perfectionnement pour garantir que la sécurité est appliquée au code dès le début du processus de développement.
À titre d'exemple de son fonctionnement, examinons la dernière version de la norme PCI DSS.
Le codage sécurisé (et la formation des développeurs) sont au cœur de la norme PCI DSS 4.0
PCI DSS 4.0, qui est devenue obligatoire le 1er avril 2024, inclut plusieurs mises à jour importantes de la norme PCI DSS 3.2.1, notamment l'accent sur le rôle que jouent les développeurs pour garantir la sécurité du code logiciel.
Dans le passé, PCI a reconnu depuis longtemps l'importance des logiciels sécurisés. La version 2.0, publiée en 2017, comprenait conseils pour les développeurs sur la garantie de transactions sécurisées 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 de logiciels et incluent des conseils spécifiques sur la formation des développeurs.
Les exigences sont souvent énoncé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 les 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 les lacunes en matière de connaissances.
Une autre exigence stipule que les développeurs travaillant sur des logiciels sur mesure doivent suivre une formation au moins une fois tous les 12 mois, portant sur :
- Sécurité logicielle adaptée à leur fonction et à leurs langages de développement.
- Techniques de conception et de codage de logiciels sécurisés.
- Comment utiliser les outils de test de sécurité, s'ils sont utilisés, pour détecter les vulnérabilités des logiciels.
En réalité, une fois par an n'est pas assez fréquente pour résoudre 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 s'assurer qu'elle est utilisée à bon escient.
La norme PCI DSS 4.0 inclut plus d'une demi-douzaine d'autres exigences qui concernent des 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 et d'autres mesures de sécurité. Dans tous les cas, les organisations seraient bien avisées de poursuivre ces mesures de manière approfondie. La formation sur les vecteurs d'attaque devrait être fréquente plutôt qu'annuelle. Les composants tiers, souvent source de vulnérabilités, doivent être soigneusement inventoriés par le biais d'un programme SBOM (Software Bill of Materials). Et les organisations doivent s'assurer de définir clairement les rôles en matière de gestion des vulnérabilités.
La nouvelle version donne également aux organisations une certaine flexibilité pour répondre à leurs exigences, en se concentrant sur les résultats plutôt que sur les 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 au début du SDLC
Le point commun de ces réglementations est qu'elles visent à établir des normes élevées en matière de protection des données et des transactions dans le secteur des services financiers. Et, comme dans le cas de la dernière version de la norme PCI DSS, ils insistent de plus en plus sur l'importance d'un code sécurisé au 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 confient également la responsabilité de la sécurité aux fabricants de logiciels, avant leur expédition, de sorte que même les entreprises qui ne sont pas directement régies par la réglementation des services financiers doivent s'y conformer.
Les entreprises doivent combler le fossé qui existe entre les équipes DevOps (qui se concentrent sur la rapidité du développement) et les équipes AppSec (qui s'empressent d'intégrer la sécurité au processus) en formant les développeurs à intégrer la sécurité à leur approche. Cela nécessite toutefois un ensemble complexe de compétences, qui implique plus que des sessions de formation annuelles ou des programmes éducatifs standard et stagnants. La formation doit être continue et souple, conçue pour impliquer les apprenants dans des scénarios actifs et réels et dispensée en petites périodes adaptées à leurs horaires de travail.
Les sociétés de services financiers doivent garantir la sécurité à la fois pour se protéger contre les violations et pour rester en conformité avec des réglementations de plus en plus strictes. Les coûts liés à la non-conformité peuvent être aussi dommageables qu'une violation en termes d'impact sur la réputation d'une entreprise et de coûts financiers. Les IBM Rapport sur le coût d'une violation de données 2023, par exemple, a constaté que les organisations présentant un niveau élevé de non-conformité étaient confrontées, en moyenne, à des amendes et à d'autres coûts totalisant 5,05 millions de dollars, soit un demi-million de dollars plus supérieur au coût moyen d'une véritable violation de données.
La croissance continue des environnements basés sur le cloud et des transactions numériques a donné une importance capitale à la sécurité des logiciels dans le secteur des services financiers, ce que reconnaissent les réglementations telles que la norme PCI DSS. Le meilleur moyen de garantir la sécurité des logiciels est d'utiliser un codage sécurisé au début du SDLC. Et pour y parvenir, il faut former efficacement les développeurs aux pratiques de codage sécurisées.
Pour un aperçu complet de la manière dont le codage sécurisé peut contribuer à garantir le succès, la sécurité et les bénéfices des sociétés de services financiers, vous pouvez lire le nouveau livre électronique Secure Code Warrior : Le guide ultime des tendances en matière de sécurité dans les services financiers.
Consultez le Secure Code Warrior des pages de blog pour en savoir plus sur la cybersécurité, le paysage des menaces de plus en plus dangereuses, et pour savoir comment vous pouvez utiliser des technologies innovantes et des formations pour mieux protéger votre organisation et vos clients.
Les réglementations régissant le secteur des services financiers, telles que la norme PCI DSS, soulignent l'importance d'un code sécurisé et la nécessité de former les développeurs aux meilleures pratiques en matière de sécurité.
Secure Code Warrior fait du codage sécurisé une expérience positive et engageante pour les développeurs à mesure qu'ils améliorent leurs compétences. Nous guidons chaque codeur le long de son parcours d'apprentissage préféré, afin que les développeurs doués pour la sécurité deviennent les super-héros du quotidien de notre monde connecté.
Secure Code Warrior est là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Réservez une démo
Secure Code Warrior fait du codage sécurisé une expérience positive et engageante pour les développeurs à mesure qu'ils améliorent leurs compétences. Nous guidons chaque codeur le long de son parcours d'apprentissage préféré, afin que les développeurs doués pour la sécurité deviennent les super-héros du quotidien de notre monde connecté.
Cet article a été rédigé par l'équipe d'experts du secteur de Secure Code Warrior, qui s'est engagée à donner aux développeurs les connaissances et les compétences nécessaires pour créer des logiciels sécurisés dès le départ. S'appuyant sur une expertise approfondie en matière de pratiques de codage sécurisé, de tendances du secteur et de connaissances du monde réel.
Les institutions de services financiers ont de bonnes raisons de s'assurer que le code logiciel qu'elles utilisent est sécurisé. Une motivation évidente, bien entendu, est la nécessité de protéger leurs données contre une violation, qui peut être coûteuse en termes de fuite d'informations personnelles, de frais de nettoyage, d'amendes et de restitution, et d'atteinte à la réputation d'une organisation. Une autre raison persistante est la nécessité de rester en conformité avec un éventail de réglementations industrielles et gouvernementales.
Parce qu'ils traitent de nombreuses informations sensibles, personnelles et financières, ainsi que l'argent des gens, les services financiers sont un secteur hautement réglementé. En fonction des services qu'elles fournissent, 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 relatives à la protection des données des titulaires de cartes, par exemple. Les exigences de la Loi Sarbanes-Oxely régir la gestion des dossiers financiers. Les entreprises qui opèrent à l'international connaissent bien le Loi sur la résilience opérationnelle numérique (DORA), qui est un cadre de gestion des risques contraignant, et les normes mondiales pour les transferts de fonds établies par le Société pour les télécommunications financières interbancaires mondiales, connu sous le nom de Swift.
Et des lois telles que la Loi californienne sur la confidentialité des consommateurs (CCPA) et celui de l'UE Règlement général sur la protection des données (RGPD) fixe des exigences pour protéger la confidentialité et les informations personnelles des clients. Il en existe d'autres, comme les réglementations établies par l'Office of the Controller of the Currency (OCC) des États-Unis et la Banque centrale européenne (BCE).
Si cela ne suffit pas, Stratégie nationale de cybersécurité stipule notamment que les fabricants de logiciels devraient être tenus responsables de l'inefficacité de la sécurité des logiciels. Et l'Agence de cybersécurité et de sécurité des infrastructures (CISA), aux côtés de 17 partenaires américains et internationaux, a publié des directives sur Sécurisé dès la conception principes pour le développement de logiciels.
Un point commun pour les sociétés de services financiers est que le code sécurisé est un élément essentiel pour atteindre les objectifs de ces réglementations, ce qui peut faciliter la démonstration de leur conformité. Et cela montre pourquoi les développeurs ont besoin de formation et de perfectionnement pour garantir que la sécurité est appliquée au code dès le début du processus de développement.
À titre d'exemple de son fonctionnement, examinons la dernière version de la norme PCI DSS.
Le codage sécurisé (et la formation des développeurs) sont au cœur de la norme PCI DSS 4.0
PCI DSS 4.0, qui est devenue obligatoire le 1er avril 2024, inclut plusieurs mises à jour importantes de la norme PCI DSS 3.2.1, notamment l'accent sur le rôle que jouent les développeurs pour garantir la sécurité du code logiciel.
Dans le passé, PCI a reconnu depuis longtemps l'importance des logiciels sécurisés. La version 2.0, publiée en 2017, comprenait conseils pour les développeurs sur la garantie de transactions sécurisées 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 de logiciels et incluent des conseils spécifiques sur la formation des développeurs.
Les exigences sont souvent énoncé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 les 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 les lacunes en matière de connaissances.
Une autre exigence stipule que les développeurs travaillant sur des logiciels sur mesure doivent suivre une formation au moins une fois tous les 12 mois, portant sur :
- Sécurité logicielle adaptée à leur fonction et à leurs langages de développement.
- Techniques de conception et de codage de logiciels sécurisés.
- Comment utiliser les outils de test de sécurité, s'ils sont utilisés, pour détecter les vulnérabilités des logiciels.
En réalité, une fois par an n'est pas assez fréquente pour résoudre 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 s'assurer qu'elle est utilisée à bon escient.
La norme PCI DSS 4.0 inclut plus d'une demi-douzaine d'autres exigences qui concernent des 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 et d'autres mesures de sécurité. Dans tous les cas, les organisations seraient bien avisées de poursuivre ces mesures de manière approfondie. La formation sur les vecteurs d'attaque devrait être fréquente plutôt qu'annuelle. Les composants tiers, souvent source de vulnérabilités, doivent être soigneusement inventoriés par le biais d'un programme SBOM (Software Bill of Materials). Et les organisations doivent s'assurer de définir clairement les rôles en matière de gestion des vulnérabilités.
La nouvelle version donne également aux organisations une certaine flexibilité pour répondre à leurs exigences, en se concentrant sur les résultats plutôt que sur les 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 au début du SDLC
Le point commun de ces réglementations est qu'elles visent à établir des normes élevées en matière de protection des données et des transactions dans le secteur des services financiers. Et, comme dans le cas de la dernière version de la norme PCI DSS, ils insistent de plus en plus sur l'importance d'un code sécurisé au 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 confient également la responsabilité de la sécurité aux fabricants de logiciels, avant leur expédition, de sorte que même les entreprises qui ne sont pas directement régies par la réglementation des services financiers doivent s'y conformer.
Les entreprises doivent combler le fossé qui existe entre les équipes DevOps (qui se concentrent sur la rapidité du développement) et les équipes AppSec (qui s'empressent d'intégrer la sécurité au processus) en formant les développeurs à intégrer la sécurité à leur approche. Cela nécessite toutefois un ensemble complexe de compétences, qui implique plus que des sessions de formation annuelles ou des programmes éducatifs standard et stagnants. La formation doit être continue et souple, conçue pour impliquer les apprenants dans des scénarios actifs et réels et dispensée en petites périodes adaptées à leurs horaires de travail.
Les sociétés de services financiers doivent garantir la sécurité à la fois pour se protéger contre les violations et pour rester en conformité avec des réglementations de plus en plus strictes. Les coûts liés à la non-conformité peuvent être aussi dommageables qu'une violation en termes d'impact sur la réputation d'une entreprise et de coûts financiers. Les IBM Rapport sur le coût d'une violation de données 2023, par exemple, a constaté que les organisations présentant un niveau élevé de non-conformité étaient confrontées, en moyenne, à des amendes et à d'autres coûts totalisant 5,05 millions de dollars, soit un demi-million de dollars plus supérieur au coût moyen d'une véritable violation de données.
La croissance continue des environnements basés sur le cloud et des transactions numériques a donné une importance capitale à la sécurité des logiciels dans le secteur des services financiers, ce que reconnaissent les réglementations telles que la norme PCI DSS. Le meilleur moyen de garantir la sécurité des logiciels est d'utiliser un codage sécurisé au début du SDLC. Et pour y parvenir, il faut former efficacement les développeurs aux pratiques de codage sécurisées.
Pour un aperçu complet de la manière dont le codage sécurisé peut contribuer à garantir le succès, la sécurité et les bénéfices des sociétés de services financiers, vous pouvez lire le nouveau livre électronique Secure Code Warrior : Le guide ultime des tendances en matière de sécurité dans les services financiers.
Consultez le Secure Code Warrior des pages de blog pour en savoir plus sur la cybersécurité, le paysage des menaces de plus en plus dangereuses, et pour savoir comment vous pouvez utiliser des technologies innovantes et des formations pour mieux protéger votre organisation et vos clients.
Les institutions de services financiers ont de bonnes raisons de s'assurer que le code logiciel qu'elles utilisent est sécurisé. Une motivation évidente, bien entendu, est la nécessité de protéger leurs données contre une violation, qui peut être coûteuse en termes de fuite d'informations personnelles, de frais de nettoyage, d'amendes et de restitution, et d'atteinte à la réputation d'une organisation. Une autre raison persistante est la nécessité de rester en conformité avec un éventail de réglementations industrielles et gouvernementales.
Parce qu'ils traitent de nombreuses informations sensibles, personnelles et financières, ainsi que l'argent des gens, les services financiers sont un secteur hautement réglementé. En fonction des services qu'elles fournissent, 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 relatives à la protection des données des titulaires de cartes, par exemple. Les exigences de la Loi Sarbanes-Oxely régir la gestion des dossiers financiers. Les entreprises qui opèrent à l'international connaissent bien le Loi sur la résilience opérationnelle numérique (DORA), qui est un cadre de gestion des risques contraignant, et les normes mondiales pour les transferts de fonds établies par le Société pour les télécommunications financières interbancaires mondiales, connu sous le nom de Swift.
Et des lois telles que la Loi californienne sur la confidentialité des consommateurs (CCPA) et celui de l'UE Règlement général sur la protection des données (RGPD) fixe des exigences pour protéger la confidentialité et les informations personnelles des clients. Il en existe d'autres, comme les réglementations établies par l'Office of the Controller of the Currency (OCC) des États-Unis et la Banque centrale européenne (BCE).
Si cela ne suffit pas, Stratégie nationale de cybersécurité stipule notamment que les fabricants de logiciels devraient être tenus responsables de l'inefficacité de la sécurité des logiciels. Et l'Agence de cybersécurité et de sécurité des infrastructures (CISA), aux côtés de 17 partenaires américains et internationaux, a publié des directives sur Sécurisé dès la conception principes pour le développement de logiciels.
Un point commun pour les sociétés de services financiers est que le code sécurisé est un élément essentiel pour atteindre les objectifs de ces réglementations, ce qui peut faciliter la démonstration de leur conformité. Et cela montre pourquoi les développeurs ont besoin de formation et de perfectionnement pour garantir que la sécurité est appliquée au code dès le début du processus de développement.
À titre d'exemple de son fonctionnement, examinons la dernière version de la norme PCI DSS.
Le codage sécurisé (et la formation des développeurs) sont au cœur de la norme PCI DSS 4.0
PCI DSS 4.0, qui est devenue obligatoire le 1er avril 2024, inclut plusieurs mises à jour importantes de la norme PCI DSS 3.2.1, notamment l'accent sur le rôle que jouent les développeurs pour garantir la sécurité du code logiciel.
Dans le passé, PCI a reconnu depuis longtemps l'importance des logiciels sécurisés. La version 2.0, publiée en 2017, comprenait conseils pour les développeurs sur la garantie de transactions sécurisées 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 de logiciels et incluent des conseils spécifiques sur la formation des développeurs.
Les exigences sont souvent énoncé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 les 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 les lacunes en matière de connaissances.
Une autre exigence stipule que les développeurs travaillant sur des logiciels sur mesure doivent suivre une formation au moins une fois tous les 12 mois, portant sur :
- Sécurité logicielle adaptée à leur fonction et à leurs langages de développement.
- Techniques de conception et de codage de logiciels sécurisés.
- Comment utiliser les outils de test de sécurité, s'ils sont utilisés, pour détecter les vulnérabilités des logiciels.
En réalité, une fois par an n'est pas assez fréquente pour résoudre 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 s'assurer qu'elle est utilisée à bon escient.
La norme PCI DSS 4.0 inclut plus d'une demi-douzaine d'autres exigences qui concernent des 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 et d'autres mesures de sécurité. Dans tous les cas, les organisations seraient bien avisées de poursuivre ces mesures de manière approfondie. La formation sur les vecteurs d'attaque devrait être fréquente plutôt qu'annuelle. Les composants tiers, souvent source de vulnérabilités, doivent être soigneusement inventoriés par le biais d'un programme SBOM (Software Bill of Materials). Et les organisations doivent s'assurer de définir clairement les rôles en matière de gestion des vulnérabilités.
La nouvelle version donne également aux organisations une certaine flexibilité pour répondre à leurs exigences, en se concentrant sur les résultats plutôt que sur les 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 au début du SDLC
Le point commun de ces réglementations est qu'elles visent à établir des normes élevées en matière de protection des données et des transactions dans le secteur des services financiers. Et, comme dans le cas de la dernière version de la norme PCI DSS, ils insistent de plus en plus sur l'importance d'un code sécurisé au 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 confient également la responsabilité de la sécurité aux fabricants de logiciels, avant leur expédition, de sorte que même les entreprises qui ne sont pas directement régies par la réglementation des services financiers doivent s'y conformer.
Les entreprises doivent combler le fossé qui existe entre les équipes DevOps (qui se concentrent sur la rapidité du développement) et les équipes AppSec (qui s'empressent d'intégrer la sécurité au processus) en formant les développeurs à intégrer la sécurité à leur approche. Cela nécessite toutefois un ensemble complexe de compétences, qui implique plus que des sessions de formation annuelles ou des programmes éducatifs standard et stagnants. La formation doit être continue et souple, conçue pour impliquer les apprenants dans des scénarios actifs et réels et dispensée en petites périodes adaptées à leurs horaires de travail.
Les sociétés de services financiers doivent garantir la sécurité à la fois pour se protéger contre les violations et pour rester en conformité avec des réglementations de plus en plus strictes. Les coûts liés à la non-conformité peuvent être aussi dommageables qu'une violation en termes d'impact sur la réputation d'une entreprise et de coûts financiers. Les IBM Rapport sur le coût d'une violation de données 2023, par exemple, a constaté que les organisations présentant un niveau élevé de non-conformité étaient confrontées, en moyenne, à des amendes et à d'autres coûts totalisant 5,05 millions de dollars, soit un demi-million de dollars plus supérieur au coût moyen d'une véritable violation de données.
La croissance continue des environnements basés sur le cloud et des transactions numériques a donné une importance capitale à la sécurité des logiciels dans le secteur des services financiers, ce que reconnaissent les réglementations telles que la norme PCI DSS. Le meilleur moyen de garantir la sécurité des logiciels est d'utiliser un codage sécurisé au début du SDLC. Et pour y parvenir, il faut former efficacement les développeurs aux pratiques de codage sécurisées.
Pour un aperçu complet de la manière dont le codage sécurisé peut contribuer à garantir le succès, la sécurité et les bénéfices des sociétés de services financiers, vous pouvez lire le nouveau livre électronique Secure Code Warrior : Le guide ultime des tendances en matière de sécurité dans les services financiers.
Consultez le Secure Code Warrior des pages de blog pour en savoir plus sur la cybersécurité, le paysage des menaces de plus en plus dangereuses, et pour savoir comment vous pouvez utiliser des technologies innovantes et des formations pour mieux protéger votre organisation et vos clients.
Cliquez sur le lien ci-dessous et téléchargez le PDF de cette ressource.
Secure Code Warrior est là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Afficher le rapportRéservez une démo
Secure Code Warrior fait du codage sécurisé une expérience positive et engageante pour les développeurs à mesure qu'ils améliorent leurs compétences. Nous guidons chaque codeur le long de son parcours d'apprentissage préféré, afin que les développeurs doués pour la sécurité deviennent les super-héros du quotidien de notre monde connecté.
Cet article a été rédigé par l'équipe d'experts du secteur de Secure Code Warrior, qui s'est engagée à donner aux développeurs les connaissances et les compétences nécessaires pour créer des logiciels sécurisés dès le départ. S'appuyant sur une expertise approfondie en matière de pratiques de codage sécurisé, de tendances du secteur et de connaissances du monde réel.
Les institutions de services financiers ont de bonnes raisons de s'assurer que le code logiciel qu'elles utilisent est sécurisé. Une motivation évidente, bien entendu, est la nécessité de protéger leurs données contre une violation, qui peut être coûteuse en termes de fuite d'informations personnelles, de frais de nettoyage, d'amendes et de restitution, et d'atteinte à la réputation d'une organisation. Une autre raison persistante est la nécessité de rester en conformité avec un éventail de réglementations industrielles et gouvernementales.
Parce qu'ils traitent de nombreuses informations sensibles, personnelles et financières, ainsi que l'argent des gens, les services financiers sont un secteur hautement réglementé. En fonction des services qu'elles fournissent, 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 relatives à la protection des données des titulaires de cartes, par exemple. Les exigences de la Loi Sarbanes-Oxely régir la gestion des dossiers financiers. Les entreprises qui opèrent à l'international connaissent bien le Loi sur la résilience opérationnelle numérique (DORA), qui est un cadre de gestion des risques contraignant, et les normes mondiales pour les transferts de fonds établies par le Société pour les télécommunications financières interbancaires mondiales, connu sous le nom de Swift.
Et des lois telles que la Loi californienne sur la confidentialité des consommateurs (CCPA) et celui de l'UE Règlement général sur la protection des données (RGPD) fixe des exigences pour protéger la confidentialité et les informations personnelles des clients. Il en existe d'autres, comme les réglementations établies par l'Office of the Controller of the Currency (OCC) des États-Unis et la Banque centrale européenne (BCE).
Si cela ne suffit pas, Stratégie nationale de cybersécurité stipule notamment que les fabricants de logiciels devraient être tenus responsables de l'inefficacité de la sécurité des logiciels. Et l'Agence de cybersécurité et de sécurité des infrastructures (CISA), aux côtés de 17 partenaires américains et internationaux, a publié des directives sur Sécurisé dès la conception principes pour le développement de logiciels.
Un point commun pour les sociétés de services financiers est que le code sécurisé est un élément essentiel pour atteindre les objectifs de ces réglementations, ce qui peut faciliter la démonstration de leur conformité. Et cela montre pourquoi les développeurs ont besoin de formation et de perfectionnement pour garantir que la sécurité est appliquée au code dès le début du processus de développement.
À titre d'exemple de son fonctionnement, examinons la dernière version de la norme PCI DSS.
Le codage sécurisé (et la formation des développeurs) sont au cœur de la norme PCI DSS 4.0
PCI DSS 4.0, qui est devenue obligatoire le 1er avril 2024, inclut plusieurs mises à jour importantes de la norme PCI DSS 3.2.1, notamment l'accent sur le rôle que jouent les développeurs pour garantir la sécurité du code logiciel.
Dans le passé, PCI a reconnu depuis longtemps l'importance des logiciels sécurisés. La version 2.0, publiée en 2017, comprenait conseils pour les développeurs sur la garantie de transactions sécurisées 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 de logiciels et incluent des conseils spécifiques sur la formation des développeurs.
Les exigences sont souvent énoncé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 les 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 les lacunes en matière de connaissances.
Une autre exigence stipule que les développeurs travaillant sur des logiciels sur mesure doivent suivre une formation au moins une fois tous les 12 mois, portant sur :
- Sécurité logicielle adaptée à leur fonction et à leurs langages de développement.
- Techniques de conception et de codage de logiciels sécurisés.
- Comment utiliser les outils de test de sécurité, s'ils sont utilisés, pour détecter les vulnérabilités des logiciels.
En réalité, une fois par an n'est pas assez fréquente pour résoudre 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 s'assurer qu'elle est utilisée à bon escient.
La norme PCI DSS 4.0 inclut plus d'une demi-douzaine d'autres exigences qui concernent des 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 et d'autres mesures de sécurité. Dans tous les cas, les organisations seraient bien avisées de poursuivre ces mesures de manière approfondie. La formation sur les vecteurs d'attaque devrait être fréquente plutôt qu'annuelle. Les composants tiers, souvent source de vulnérabilités, doivent être soigneusement inventoriés par le biais d'un programme SBOM (Software Bill of Materials). Et les organisations doivent s'assurer de définir clairement les rôles en matière de gestion des vulnérabilités.
La nouvelle version donne également aux organisations une certaine flexibilité pour répondre à leurs exigences, en se concentrant sur les résultats plutôt que sur les 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 au début du SDLC
Le point commun de ces réglementations est qu'elles visent à établir des normes élevées en matière de protection des données et des transactions dans le secteur des services financiers. Et, comme dans le cas de la dernière version de la norme PCI DSS, ils insistent de plus en plus sur l'importance d'un code sécurisé au 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 confient également la responsabilité de la sécurité aux fabricants de logiciels, avant leur expédition, de sorte que même les entreprises qui ne sont pas directement régies par la réglementation des services financiers doivent s'y conformer.
Les entreprises doivent combler le fossé qui existe entre les équipes DevOps (qui se concentrent sur la rapidité du développement) et les équipes AppSec (qui s'empressent d'intégrer la sécurité au processus) en formant les développeurs à intégrer la sécurité à leur approche. Cela nécessite toutefois un ensemble complexe de compétences, qui implique plus que des sessions de formation annuelles ou des programmes éducatifs standard et stagnants. La formation doit être continue et souple, conçue pour impliquer les apprenants dans des scénarios actifs et réels et dispensée en petites périodes adaptées à leurs horaires de travail.
Les sociétés de services financiers doivent garantir la sécurité à la fois pour se protéger contre les violations et pour rester en conformité avec des réglementations de plus en plus strictes. Les coûts liés à la non-conformité peuvent être aussi dommageables qu'une violation en termes d'impact sur la réputation d'une entreprise et de coûts financiers. Les IBM Rapport sur le coût d'une violation de données 2023, par exemple, a constaté que les organisations présentant un niveau élevé de non-conformité étaient confrontées, en moyenne, à des amendes et à d'autres coûts totalisant 5,05 millions de dollars, soit un demi-million de dollars plus supérieur au coût moyen d'une véritable violation de données.
La croissance continue des environnements basés sur le cloud et des transactions numériques a donné une importance capitale à la sécurité des logiciels dans le secteur des services financiers, ce que reconnaissent les réglementations telles que la norme PCI DSS. Le meilleur moyen de garantir la sécurité des logiciels est d'utiliser un codage sécurisé au début du SDLC. Et pour y parvenir, il faut former efficacement les développeurs aux pratiques de codage sécurisées.
Pour un aperçu complet de la manière dont le codage sécurisé peut contribuer à garantir le succès, la sécurité et les bénéfices des sociétés de services financiers, vous pouvez lire le nouveau livre électronique Secure Code Warrior : Le guide ultime des tendances en matière de sécurité dans les services financiers.
Consultez le Secure Code Warrior des pages de blog pour en savoir plus sur la cybersécurité, le paysage des menaces de plus en plus dangereuses, et pour savoir comment vous pouvez utiliser des technologies innovantes et des formations pour mieux protéger votre organisation et vos clients.
Table des matières
Secure Code Warrior fait du codage sécurisé une expérience positive et engageante pour les développeurs à mesure qu'ils améliorent leurs compétences. Nous guidons chaque codeur le long de son parcours d'apprentissage préféré, afin que les développeurs doués pour la sécurité deviennent les super-héros du quotidien de notre monde connecté.
Secure Code Warrior est là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Réservez une démoTéléchargerRessources pour vous aider à démarrer
Sujets et contenus de formation sur le code sécurisé
Notre contenu de pointe évolue constamment pour s'adapter à l'évolution constante du paysage du développement de logiciels tout en tenant compte de votre rôle. Des sujets couvrant tout, de l'IA à l'injection XQuery, proposés pour une variété de postes, allant des architectes aux ingénieurs en passant par les chefs de produit et l'assurance qualité. Découvrez un aperçu de ce que notre catalogue de contenu a à offrir par sujet et par rôle.
%20(1).avif)
.avif)
Threat Modeling with AI: Turning Every Developer into a Threat Modeler
Walk away better equipped to help developers combine threat modeling ideas and techniques with the AI tools they're already using to strengthen security, improve collaboration, and build more resilient software from the start.
Ressources pour vous aider à démarrer
Cybermon est de retour : les missions d'IA Beat the Boss sont désormais disponibles à la demande
Cybermon 2025 Beat the Boss est désormais disponible toute l'année dans SCW. Déployez des défis de sécurité avancés liés à l'IA et au LLM pour renforcer le développement sécurisé de l'IA à grande échelle.
Explication de la loi sur la cyberrésilience : ce que cela signifie pour le développement de logiciels sécurisés dès la conception
Découvrez ce que la loi européenne sur la cyberrésilience (CRA) exige, à qui elle s'applique et comment les équipes d'ingénieurs peuvent se préparer grâce à des pratiques de sécurité dès la conception, à la prévention des vulnérabilités et au renforcement des capacités des développeurs.
Facilitateur 1 : Critères de réussite définis et mesurables
Enabler 1 donne le coup d'envoi de notre série en 10 parties intitulée Enablers of Success en montrant comment associer le codage sécurisé à des résultats commerciaux tels que la réduction des risques et la rapidité pour assurer la maturité à long terme des programmes.
