Blog

Protection proactive : Tirer parti de la stratégie nationale de cybersécurité pour la prévention des menaces avancées

Pieter Danhieux
Publié le 19 mai 2023

Cet article a été publié à l'origine dans le cadre du Forbes Technology Council. Il a été mis à jour et publié ici.

Selon vous, combien d'enregistrements de données ont été compromis en 2022 ? Vous seriez sur la bonne voie si vous deviniez environ un demi-milliard. D'après les données publiques sur les atteintes à la vie privée, environ 480 014 323 enregistrements ont été volés rien que l'année dernière, mais ce chiffre est probablement beaucoup plus élevé. Quoi qu'il en soit, il s'agit d'une statistique qui donne à réfléchir au citoyen moyen et qui est très préoccupante pour tout professionnel de la sécurité en entreprise.

Nous sommes arrivés à un point où la plupart des habitants des pays développés ont probablement vu au moins une partie de leurs données personnelles tomber entre les mains de criminels à la suite d'une cyberattaque réussie ; il est donc tout à fait naturel que les gouvernements du monde entier cherchent des solutions pour endiguer ce flux perturbateur d'activités criminelles en ligne. La dernière initiative en date émane de l'administration Biden et prend la forme d'une stratégie nationale de cybersécurité, que j'observe avec un vif intérêt. Cette stratégie comprend des directives sur l'un de mes sujets préférés en ce moment : la responsabilité en matière de sécurité.

Cette stratégie, publiée à la suite d'une présentation décisive de Jen Easterly, directrice de la cybersécurité et de la sécurité des infrastructures à la CISA, a, à juste titre, suscité des divisions au sein de la communauté de la sécurité. Cependant, je pense qu'elle représente la meilleure chance que nous ayons d'améliorer les normes logicielles dans tous les domaines et, enfin, d'inaugurer une nouvelle ère de développeurs compétents en matière de sécurité.

Les fournisseurs auraient toujours dû être tenus responsables des logiciels non sécurisés.

Cela fait des décennies qu'en matière de sécurité des logiciels, la responsabilité est une patate chaude avec laquelle aucune équipe ne cherche à jongler. Les cadres et les équipes ont tendance à ne pas être d'accord sur la responsabilité finale de la sécurité des logiciels. Un rapport de Venafi révèle que 97 % des cadres supérieurs de l'informatique reconnaissent que les processus de création de logiciels ne sont pas suffisamment sûrs, mais qu'il existe une divergence sur la responsabilité finale de la mise en œuvre des meilleures pratiques en matière de sécurité. 61 % des cadres ont déclaré que les équipes de sécurité informatique devraient assumer la responsabilité de la sécurité des logiciels, tandis que 31 % ont déclaré que c'était à l'équipe de développement d'assumer cette responsabilité. Et ce n'est qu'une partie de l'équation : la question des composants commerciaux open-source et tiers dans les logiciels est une expansion constante de la surface d'attaque. Même entre les équipes AppSec et de sécurité, il y a rarement un "propriétaire" évident malgré la nécessité d'une vigilance continue dans la mise à jour, la surveillance et les tests.

Cette même enquête a également mis en lumière que - malgré un conflit interne sur qui devrait être responsable de la sécurité et de l'intégrité des logiciels - 94% des cadres estiment qu'il devrait y avoir des pénalités pour les fournisseurs de logiciels qui ne protègent pas leurs pipelines de construction contre les acteurs de la menace, et mettent les clients et les utilisateurs finaux en danger. 

Avec les récentes poursuites engagées contre le RSSI d'Uber pour sa mauvaise gestion d'une cyberattaque dévastatrice en 2016, ainsi que les initiatives réglementaires telles que le GDPR, nous voyons peu à peu les enjeux s'élever pour les fournisseurs qui jouent avec le feu en privant la sécurité de sa priorité. Cependant, cela ne suffit tout simplement pas. Nous sommes en train de perdre la bataille contre les cybercriminels, et bien que la pilule soit difficile à avaler, ce sont les pratiques laxistes des éditeurs de logiciels qui leur offrent des opportunités illimitées de prospérer. 

La stratégie nationale de cybersécurité cherche à tracer une ligne dans le sable et à mettre fin au jeu des reproches circulaires en attribuant la pleine responsabilité des logiciels non sécurisés au vendeur.

Jetons un coup d'œil :

Objectif stratégique 3.3 - Déplacer la responsabilité des produits et services logiciels non sécurisés :

"Trop de fournisseurs "ignorent les meilleures pratiques en matière de développement sécurisé, livrent des produits dont les configurations par défaut ne sont pas sûres ou dont les vulnérabilités sont connues, et intègrent des logiciels tiers dont la provenance n'est pas vérifiée ou inconnue.

Nous devons commencer à faire porter la responsabilité sur les entités qui ne prennent pas de précautions raisonnables pour sécuriser leurs logiciels, tout en reconnaissant que même les programmes de sécurité logicielle les plus avancés ne peuvent pas prévenir toutes les vulnérabilités
".

Cela a, à juste titre, froissé certaines personnes. Mais, comme pour d'autres moments décisifs dans l'élaboration de normes et de réglementations dans la plupart des secteurs, c'est la douleur à moyen terme qui garantit un meilleur résultat à long terme. En tant qu'éditeur de logiciels, il est logique que la responsabilité nous incombe en matière de sécurité. Il s'agit de notre pipeline de construction, de nos processus et de notre contrôle de la qualité, et si nous commettons une erreur, il est de notre responsabilité d'y remédier.

En outre, nous devrions être dans une situation où nous cherchons à créer des logiciels de la plus haute qualité possible, et le codage sécurisé doit faire partie des paramètres qui définissent un résultat réussi. Il s'agit là d'une tâche ardue dans un monde qui privilégie la rapidité à tout prix, mais il incombe aux responsables de la sécurité qui guident notre avenir de veiller à ce que tous les acteurs du processus de création de logiciels, et en particulier les développeurs, reçoivent une formation adéquate leur permettant d'appliquer les meilleures pratiques en matière de sécurité dans le cadre de leur rôle. 

Nous manquons encore d'indications sur les meilleures pratiques à long terme.

L'objectif stratégique 3.3 fait référence au cadre bien établi de développement de logiciels sécurisés du NIST comme base de ses meilleures pratiques générales, et il s'agit de lignes directrices complètes et globales. Elles précisent la nécessité de "veiller à ce que le personnel, les processus et la technologie de l'organisation soient prêts à assurer le développement de logiciels sécurisés au niveau de l'organisation", mais ne sont pas particulièrement prescriptives sur les facteurs que, par exemple, un responsable de la sensibilisation à la sécurité devrait connaître lorsqu'il choisit des solutions d'habilitation.

Pour que l'approche soit réellement transformatrice, les développeurs doivent être considérés comme faisant partie intégrante du programme de sécurité et se voir offrir toutes les possibilités d'améliorer leurs compétences et de partager la responsabilité de la détection et de l'éradication des vulnérabilités. Ils ne peuvent y parvenir de manière mesurable sans un apprentissage et des outils hyper pertinents et contextuels, ni si cela est considéré comme un exercice de conformité annuel au lieu d'un parcours de développement continu des compétences. 

Les développeurs sont une pièce importante du puzzle lorsqu'il s'agit de résoudre l'énigme de la sécurité, et une équipe de développeurs compétents en matière de sécurité est essentiellement l'ingrédient manquant dans la plupart des organisations. Ils permettent d'accélérer la sécurité, mais uniquement lorsque du temps et des ressources sont consacrés à cette tâche au sein de l'équipe. En attendant, toutes les lignes directrices générales sur les meilleures pratiques du monde ne parviendront pas à faire bouger l'aiguille.

Le long chemin vers le nirvana de la sécurité des logiciels.

L'administration Biden s'est engagée à financer la CISA à hauteur de 3 milliards de dollars, dans le but d'assurer une résilience rapide des infrastructures critiques. Si le financement et le soutien des plus hauts niveaux de gouvernement sont essentiels, pour que nous ayons une chance de contrecarrer les acteurs de la menace, il faudra un effort mondial pour réécrire l'histoire de la culture de la sécurité.

La route est longue, mais elle commence avec chaque éditeur de logiciels qui fait le premier pas courageux vers la responsabilisation en matière de sécurité au niveau de l'organisation.

Voir la ressource
Voir la ressource

La stratégie nationale de cybersécurité de la CISA représente la meilleure chance que nous ayons de rehausser les normes logicielles dans tous les domaines et, enfin, d'inaugurer une nouvelle ère de développeurs compétents en matière de sécurité.

Vous souhaitez en savoir plus ?

Directeur général, président et cofondateur

Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO 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émonstration
Partager sur :
Auteur
Pieter Danhieux
Publié le 19 mai 2023

Directeur général, président et cofondateur

Pieter Danhieux est un expert en sécurité mondialement reconnu, avec plus de 12 ans d'expérience en tant que consultant en sécurité et 8 ans en tant qu'instructeur principal pour SANS, enseignant des techniques offensives sur la façon de cibler et d'évaluer les organisations, les systèmes et les individus pour les faiblesses de sécurité. En 2016, il a été reconnu comme l'une des personnes les plus cool d'Australie dans le domaine de la technologie (Business Insider), a reçu le prix du professionnel de la cybersécurité de l'année (AISA - Australian Information Security Association) et détient les certifications GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA.

Partager sur :

Cet article a été publié à l'origine dans le cadre du Forbes Technology Council. Il a été mis à jour et publié ici.

Selon vous, combien d'enregistrements de données ont été compromis en 2022 ? Vous seriez sur la bonne voie si vous deviniez environ un demi-milliard. D'après les données publiques sur les atteintes à la vie privée, environ 480 014 323 enregistrements ont été volés rien que l'année dernière, mais ce chiffre est probablement beaucoup plus élevé. Quoi qu'il en soit, il s'agit d'une statistique qui donne à réfléchir au citoyen moyen et qui est très préoccupante pour tout professionnel de la sécurité en entreprise.

Nous sommes arrivés à un point où la plupart des habitants des pays développés ont probablement vu au moins une partie de leurs données personnelles tomber entre les mains de criminels à la suite d'une cyberattaque réussie ; il est donc tout à fait naturel que les gouvernements du monde entier cherchent des solutions pour endiguer ce flux perturbateur d'activités criminelles en ligne. La dernière initiative en date émane de l'administration Biden et prend la forme d'une stratégie nationale de cybersécurité, que j'observe avec un vif intérêt. Cette stratégie comprend des directives sur l'un de mes sujets préférés en ce moment : la responsabilité en matière de sécurité.

Cette stratégie, publiée à la suite d'une présentation décisive de Jen Easterly, directrice de la cybersécurité et de la sécurité des infrastructures à la CISA, a, à juste titre, suscité des divisions au sein de la communauté de la sécurité. Cependant, je pense qu'elle représente la meilleure chance que nous ayons d'améliorer les normes logicielles dans tous les domaines et, enfin, d'inaugurer une nouvelle ère de développeurs compétents en matière de sécurité.

Les fournisseurs auraient toujours dû être tenus responsables des logiciels non sécurisés.

Cela fait des décennies qu'en matière de sécurité des logiciels, la responsabilité est une patate chaude avec laquelle aucune équipe ne cherche à jongler. Les cadres et les équipes ont tendance à ne pas être d'accord sur la responsabilité finale de la sécurité des logiciels. Un rapport de Venafi révèle que 97 % des cadres supérieurs de l'informatique reconnaissent que les processus de création de logiciels ne sont pas suffisamment sûrs, mais qu'il existe une divergence sur la responsabilité finale de la mise en œuvre des meilleures pratiques en matière de sécurité. 61 % des cadres ont déclaré que les équipes de sécurité informatique devraient assumer la responsabilité de la sécurité des logiciels, tandis que 31 % ont déclaré que c'était à l'équipe de développement d'assumer cette responsabilité. Et ce n'est qu'une partie de l'équation : la question des composants commerciaux open-source et tiers dans les logiciels est une expansion constante de la surface d'attaque. Même entre les équipes AppSec et de sécurité, il y a rarement un "propriétaire" évident malgré la nécessité d'une vigilance continue dans la mise à jour, la surveillance et les tests.

Cette même enquête a également mis en lumière que - malgré un conflit interne sur qui devrait être responsable de la sécurité et de l'intégrité des logiciels - 94% des cadres estiment qu'il devrait y avoir des pénalités pour les fournisseurs de logiciels qui ne protègent pas leurs pipelines de construction contre les acteurs de la menace, et mettent les clients et les utilisateurs finaux en danger. 

Avec les récentes poursuites engagées contre le RSSI d'Uber pour sa mauvaise gestion d'une cyberattaque dévastatrice en 2016, ainsi que les initiatives réglementaires telles que le GDPR, nous voyons peu à peu les enjeux s'élever pour les fournisseurs qui jouent avec le feu en privant la sécurité de sa priorité. Cependant, cela ne suffit tout simplement pas. Nous sommes en train de perdre la bataille contre les cybercriminels, et bien que la pilule soit difficile à avaler, ce sont les pratiques laxistes des éditeurs de logiciels qui leur offrent des opportunités illimitées de prospérer. 

La stratégie nationale de cybersécurité cherche à tracer une ligne dans le sable et à mettre fin au jeu des reproches circulaires en attribuant la pleine responsabilité des logiciels non sécurisés au vendeur.

Jetons un coup d'œil :

Objectif stratégique 3.3 - Déplacer la responsabilité des produits et services logiciels non sécurisés :

"Trop de fournisseurs "ignorent les meilleures pratiques en matière de développement sécurisé, livrent des produits dont les configurations par défaut ne sont pas sûres ou dont les vulnérabilités sont connues, et intègrent des logiciels tiers dont la provenance n'est pas vérifiée ou inconnue.

Nous devons commencer à faire porter la responsabilité sur les entités qui ne prennent pas de précautions raisonnables pour sécuriser leurs logiciels, tout en reconnaissant que même les programmes de sécurité logicielle les plus avancés ne peuvent pas prévenir toutes les vulnérabilités
".

Cela a, à juste titre, froissé certaines personnes. Mais, comme pour d'autres moments décisifs dans l'élaboration de normes et de réglementations dans la plupart des secteurs, c'est la douleur à moyen terme qui garantit un meilleur résultat à long terme. En tant qu'éditeur de logiciels, il est logique que la responsabilité nous incombe en matière de sécurité. Il s'agit de notre pipeline de construction, de nos processus et de notre contrôle de la qualité, et si nous commettons une erreur, il est de notre responsabilité d'y remédier.

En outre, nous devrions être dans une situation où nous cherchons à créer des logiciels de la plus haute qualité possible, et le codage sécurisé doit faire partie des paramètres qui définissent un résultat réussi. Il s'agit là d'une tâche ardue dans un monde qui privilégie la rapidité à tout prix, mais il incombe aux responsables de la sécurité qui guident notre avenir de veiller à ce que tous les acteurs du processus de création de logiciels, et en particulier les développeurs, reçoivent une formation adéquate leur permettant d'appliquer les meilleures pratiques en matière de sécurité dans le cadre de leur rôle. 

Nous manquons encore d'indications sur les meilleures pratiques à long terme.

L'objectif stratégique 3.3 fait référence au cadre bien établi de développement de logiciels sécurisés du NIST comme base de ses meilleures pratiques générales, et il s'agit de lignes directrices complètes et globales. Elles précisent la nécessité de "veiller à ce que le personnel, les processus et la technologie de l'organisation soient prêts à assurer le développement de logiciels sécurisés au niveau de l'organisation", mais ne sont pas particulièrement prescriptives sur les facteurs que, par exemple, un responsable de la sensibilisation à la sécurité devrait connaître lorsqu'il choisit des solutions d'habilitation.

Pour que l'approche soit réellement transformatrice, les développeurs doivent être considérés comme faisant partie intégrante du programme de sécurité et se voir offrir toutes les possibilités d'améliorer leurs compétences et de partager la responsabilité de la détection et de l'éradication des vulnérabilités. Ils ne peuvent y parvenir de manière mesurable sans un apprentissage et des outils hyper pertinents et contextuels, ni si cela est considéré comme un exercice de conformité annuel au lieu d'un parcours de développement continu des compétences. 

Les développeurs sont une pièce importante du puzzle lorsqu'il s'agit de résoudre l'énigme de la sécurité, et une équipe de développeurs compétents en matière de sécurité est essentiellement l'ingrédient manquant dans la plupart des organisations. Ils permettent d'accélérer la sécurité, mais uniquement lorsque du temps et des ressources sont consacrés à cette tâche au sein de l'équipe. En attendant, toutes les lignes directrices générales sur les meilleures pratiques du monde ne parviendront pas à faire bouger l'aiguille.

Le long chemin vers le nirvana de la sécurité des logiciels.

L'administration Biden s'est engagée à financer la CISA à hauteur de 3 milliards de dollars, dans le but d'assurer une résilience rapide des infrastructures critiques. Si le financement et le soutien des plus hauts niveaux de gouvernement sont essentiels, pour que nous ayons une chance de contrecarrer les acteurs de la menace, il faudra un effort mondial pour réécrire l'histoire de la culture de la sécurité.

La route est longue, mais elle commence avec chaque éditeur de logiciels qui fait le premier pas courageux vers la responsabilisation en matière de sécurité au niveau de l'organisation.

Voir la ressource
Voir la ressource

Remplissez le formulaire ci-dessous pour télécharger le rapport

Nous aimerions que vous nous autorisiez à vous envoyer des informations sur nos produits et/ou sur des sujets liés au codage sécurisé. Nous traiterons toujours vos données personnelles avec le plus grand soin et ne les vendrons jamais à d'autres entreprises à des fins de marketing.

Soumettre
Pour soumettre le formulaire, veuillez activer les cookies "Analytics". N'hésitez pas à les désactiver à nouveau une fois que vous aurez terminé.

Cet article a été publié à l'origine dans le cadre du Forbes Technology Council. Il a été mis à jour et publié ici.

Selon vous, combien d'enregistrements de données ont été compromis en 2022 ? Vous seriez sur la bonne voie si vous deviniez environ un demi-milliard. D'après les données publiques sur les atteintes à la vie privée, environ 480 014 323 enregistrements ont été volés rien que l'année dernière, mais ce chiffre est probablement beaucoup plus élevé. Quoi qu'il en soit, il s'agit d'une statistique qui donne à réfléchir au citoyen moyen et qui est très préoccupante pour tout professionnel de la sécurité en entreprise.

Nous sommes arrivés à un point où la plupart des habitants des pays développés ont probablement vu au moins une partie de leurs données personnelles tomber entre les mains de criminels à la suite d'une cyberattaque réussie ; il est donc tout à fait naturel que les gouvernements du monde entier cherchent des solutions pour endiguer ce flux perturbateur d'activités criminelles en ligne. La dernière initiative en date émane de l'administration Biden et prend la forme d'une stratégie nationale de cybersécurité, que j'observe avec un vif intérêt. Cette stratégie comprend des directives sur l'un de mes sujets préférés en ce moment : la responsabilité en matière de sécurité.

Cette stratégie, publiée à la suite d'une présentation décisive de Jen Easterly, directrice de la cybersécurité et de la sécurité des infrastructures à la CISA, a, à juste titre, suscité des divisions au sein de la communauté de la sécurité. Cependant, je pense qu'elle représente la meilleure chance que nous ayons d'améliorer les normes logicielles dans tous les domaines et, enfin, d'inaugurer une nouvelle ère de développeurs compétents en matière de sécurité.

Les fournisseurs auraient toujours dû être tenus responsables des logiciels non sécurisés.

Cela fait des décennies qu'en matière de sécurité des logiciels, la responsabilité est une patate chaude avec laquelle aucune équipe ne cherche à jongler. Les cadres et les équipes ont tendance à ne pas être d'accord sur la responsabilité finale de la sécurité des logiciels. Un rapport de Venafi révèle que 97 % des cadres supérieurs de l'informatique reconnaissent que les processus de création de logiciels ne sont pas suffisamment sûrs, mais qu'il existe une divergence sur la responsabilité finale de la mise en œuvre des meilleures pratiques en matière de sécurité. 61 % des cadres ont déclaré que les équipes de sécurité informatique devraient assumer la responsabilité de la sécurité des logiciels, tandis que 31 % ont déclaré que c'était à l'équipe de développement d'assumer cette responsabilité. Et ce n'est qu'une partie de l'équation : la question des composants commerciaux open-source et tiers dans les logiciels est une expansion constante de la surface d'attaque. Même entre les équipes AppSec et de sécurité, il y a rarement un "propriétaire" évident malgré la nécessité d'une vigilance continue dans la mise à jour, la surveillance et les tests.

Cette même enquête a également mis en lumière que - malgré un conflit interne sur qui devrait être responsable de la sécurité et de l'intégrité des logiciels - 94% des cadres estiment qu'il devrait y avoir des pénalités pour les fournisseurs de logiciels qui ne protègent pas leurs pipelines de construction contre les acteurs de la menace, et mettent les clients et les utilisateurs finaux en danger. 

Avec les récentes poursuites engagées contre le RSSI d'Uber pour sa mauvaise gestion d'une cyberattaque dévastatrice en 2016, ainsi que les initiatives réglementaires telles que le GDPR, nous voyons peu à peu les enjeux s'élever pour les fournisseurs qui jouent avec le feu en privant la sécurité de sa priorité. Cependant, cela ne suffit tout simplement pas. Nous sommes en train de perdre la bataille contre les cybercriminels, et bien que la pilule soit difficile à avaler, ce sont les pratiques laxistes des éditeurs de logiciels qui leur offrent des opportunités illimitées de prospérer. 

La stratégie nationale de cybersécurité cherche à tracer une ligne dans le sable et à mettre fin au jeu des reproches circulaires en attribuant la pleine responsabilité des logiciels non sécurisés au vendeur.

Jetons un coup d'œil :

Objectif stratégique 3.3 - Déplacer la responsabilité des produits et services logiciels non sécurisés :

"Trop de fournisseurs "ignorent les meilleures pratiques en matière de développement sécurisé, livrent des produits dont les configurations par défaut ne sont pas sûres ou dont les vulnérabilités sont connues, et intègrent des logiciels tiers dont la provenance n'est pas vérifiée ou inconnue.

Nous devons commencer à faire porter la responsabilité sur les entités qui ne prennent pas de précautions raisonnables pour sécuriser leurs logiciels, tout en reconnaissant que même les programmes de sécurité logicielle les plus avancés ne peuvent pas prévenir toutes les vulnérabilités
".

Cela a, à juste titre, froissé certaines personnes. Mais, comme pour d'autres moments décisifs dans l'élaboration de normes et de réglementations dans la plupart des secteurs, c'est la douleur à moyen terme qui garantit un meilleur résultat à long terme. En tant qu'éditeur de logiciels, il est logique que la responsabilité nous incombe en matière de sécurité. Il s'agit de notre pipeline de construction, de nos processus et de notre contrôle de la qualité, et si nous commettons une erreur, il est de notre responsabilité d'y remédier.

En outre, nous devrions être dans une situation où nous cherchons à créer des logiciels de la plus haute qualité possible, et le codage sécurisé doit faire partie des paramètres qui définissent un résultat réussi. Il s'agit là d'une tâche ardue dans un monde qui privilégie la rapidité à tout prix, mais il incombe aux responsables de la sécurité qui guident notre avenir de veiller à ce que tous les acteurs du processus de création de logiciels, et en particulier les développeurs, reçoivent une formation adéquate leur permettant d'appliquer les meilleures pratiques en matière de sécurité dans le cadre de leur rôle. 

Nous manquons encore d'indications sur les meilleures pratiques à long terme.

L'objectif stratégique 3.3 fait référence au cadre bien établi de développement de logiciels sécurisés du NIST comme base de ses meilleures pratiques générales, et il s'agit de lignes directrices complètes et globales. Elles précisent la nécessité de "veiller à ce que le personnel, les processus et la technologie de l'organisation soient prêts à assurer le développement de logiciels sécurisés au niveau de l'organisation", mais ne sont pas particulièrement prescriptives sur les facteurs que, par exemple, un responsable de la sensibilisation à la sécurité devrait connaître lorsqu'il choisit des solutions d'habilitation.

Pour que l'approche soit réellement transformatrice, les développeurs doivent être considérés comme faisant partie intégrante du programme de sécurité et se voir offrir toutes les possibilités d'améliorer leurs compétences et de partager la responsabilité de la détection et de l'éradication des vulnérabilités. Ils ne peuvent y parvenir de manière mesurable sans un apprentissage et des outils hyper pertinents et contextuels, ni si cela est considéré comme un exercice de conformité annuel au lieu d'un parcours de développement continu des compétences. 

Les développeurs sont une pièce importante du puzzle lorsqu'il s'agit de résoudre l'énigme de la sécurité, et une équipe de développeurs compétents en matière de sécurité est essentiellement l'ingrédient manquant dans la plupart des organisations. Ils permettent d'accélérer la sécurité, mais uniquement lorsque du temps et des ressources sont consacrés à cette tâche au sein de l'équipe. En attendant, toutes les lignes directrices générales sur les meilleures pratiques du monde ne parviendront pas à faire bouger l'aiguille.

Le long chemin vers le nirvana de la sécurité des logiciels.

L'administration Biden s'est engagée à financer la CISA à hauteur de 3 milliards de dollars, dans le but d'assurer une résilience rapide des infrastructures critiques. Si le financement et le soutien des plus hauts niveaux de gouvernement sont essentiels, pour que nous ayons une chance de contrecarrer les acteurs de la menace, il faudra un effort mondial pour réécrire l'histoire de la culture de la sécurité.

La route est longue, mais elle commence avec chaque éditeur de logiciels qui fait le premier pas courageux vers la responsabilisation en matière de sécurité au niveau de l'organisation.

Accès aux ressources

Cliquez sur le lien ci-dessous et téléchargez le PDF de cette ressource.

Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO 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é.

Voir le rapportRéservez une démonstration
Télécharger le PDF
Voir la ressource
Partager sur :
Vous souhaitez en savoir plus ?

Partager sur :
Auteur
Pieter Danhieux
Publié le 19 mai 2023

Directeur général, président et cofondateur

Pieter Danhieux est un expert en sécurité mondialement reconnu, avec plus de 12 ans d'expérience en tant que consultant en sécurité et 8 ans en tant qu'instructeur principal pour SANS, enseignant des techniques offensives sur la façon de cibler et d'évaluer les organisations, les systèmes et les individus pour les faiblesses de sécurité. En 2016, il a été reconnu comme l'une des personnes les plus cool d'Australie dans le domaine de la technologie (Business Insider), a reçu le prix du professionnel de la cybersécurité de l'année (AISA - Australian Information Security Association) et détient les certifications GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA.

Partager sur :

Cet article a été publié à l'origine dans le cadre du Forbes Technology Council. Il a été mis à jour et publié ici.

Selon vous, combien d'enregistrements de données ont été compromis en 2022 ? Vous seriez sur la bonne voie si vous deviniez environ un demi-milliard. D'après les données publiques sur les atteintes à la vie privée, environ 480 014 323 enregistrements ont été volés rien que l'année dernière, mais ce chiffre est probablement beaucoup plus élevé. Quoi qu'il en soit, il s'agit d'une statistique qui donne à réfléchir au citoyen moyen et qui est très préoccupante pour tout professionnel de la sécurité en entreprise.

Nous sommes arrivés à un point où la plupart des habitants des pays développés ont probablement vu au moins une partie de leurs données personnelles tomber entre les mains de criminels à la suite d'une cyberattaque réussie ; il est donc tout à fait naturel que les gouvernements du monde entier cherchent des solutions pour endiguer ce flux perturbateur d'activités criminelles en ligne. La dernière initiative en date émane de l'administration Biden et prend la forme d'une stratégie nationale de cybersécurité, que j'observe avec un vif intérêt. Cette stratégie comprend des directives sur l'un de mes sujets préférés en ce moment : la responsabilité en matière de sécurité.

Cette stratégie, publiée à la suite d'une présentation décisive de Jen Easterly, directrice de la cybersécurité et de la sécurité des infrastructures à la CISA, a, à juste titre, suscité des divisions au sein de la communauté de la sécurité. Cependant, je pense qu'elle représente la meilleure chance que nous ayons d'améliorer les normes logicielles dans tous les domaines et, enfin, d'inaugurer une nouvelle ère de développeurs compétents en matière de sécurité.

Les fournisseurs auraient toujours dû être tenus responsables des logiciels non sécurisés.

Cela fait des décennies qu'en matière de sécurité des logiciels, la responsabilité est une patate chaude avec laquelle aucune équipe ne cherche à jongler. Les cadres et les équipes ont tendance à ne pas être d'accord sur la responsabilité finale de la sécurité des logiciels. Un rapport de Venafi révèle que 97 % des cadres supérieurs de l'informatique reconnaissent que les processus de création de logiciels ne sont pas suffisamment sûrs, mais qu'il existe une divergence sur la responsabilité finale de la mise en œuvre des meilleures pratiques en matière de sécurité. 61 % des cadres ont déclaré que les équipes de sécurité informatique devraient assumer la responsabilité de la sécurité des logiciels, tandis que 31 % ont déclaré que c'était à l'équipe de développement d'assumer cette responsabilité. Et ce n'est qu'une partie de l'équation : la question des composants commerciaux open-source et tiers dans les logiciels est une expansion constante de la surface d'attaque. Même entre les équipes AppSec et de sécurité, il y a rarement un "propriétaire" évident malgré la nécessité d'une vigilance continue dans la mise à jour, la surveillance et les tests.

Cette même enquête a également mis en lumière que - malgré un conflit interne sur qui devrait être responsable de la sécurité et de l'intégrité des logiciels - 94% des cadres estiment qu'il devrait y avoir des pénalités pour les fournisseurs de logiciels qui ne protègent pas leurs pipelines de construction contre les acteurs de la menace, et mettent les clients et les utilisateurs finaux en danger. 

Avec les récentes poursuites engagées contre le RSSI d'Uber pour sa mauvaise gestion d'une cyberattaque dévastatrice en 2016, ainsi que les initiatives réglementaires telles que le GDPR, nous voyons peu à peu les enjeux s'élever pour les fournisseurs qui jouent avec le feu en privant la sécurité de sa priorité. Cependant, cela ne suffit tout simplement pas. Nous sommes en train de perdre la bataille contre les cybercriminels, et bien que la pilule soit difficile à avaler, ce sont les pratiques laxistes des éditeurs de logiciels qui leur offrent des opportunités illimitées de prospérer. 

La stratégie nationale de cybersécurité cherche à tracer une ligne dans le sable et à mettre fin au jeu des reproches circulaires en attribuant la pleine responsabilité des logiciels non sécurisés au vendeur.

Jetons un coup d'œil :

Objectif stratégique 3.3 - Déplacer la responsabilité des produits et services logiciels non sécurisés :

"Trop de fournisseurs "ignorent les meilleures pratiques en matière de développement sécurisé, livrent des produits dont les configurations par défaut ne sont pas sûres ou dont les vulnérabilités sont connues, et intègrent des logiciels tiers dont la provenance n'est pas vérifiée ou inconnue.

Nous devons commencer à faire porter la responsabilité sur les entités qui ne prennent pas de précautions raisonnables pour sécuriser leurs logiciels, tout en reconnaissant que même les programmes de sécurité logicielle les plus avancés ne peuvent pas prévenir toutes les vulnérabilités
".

Cela a, à juste titre, froissé certaines personnes. Mais, comme pour d'autres moments décisifs dans l'élaboration de normes et de réglementations dans la plupart des secteurs, c'est la douleur à moyen terme qui garantit un meilleur résultat à long terme. En tant qu'éditeur de logiciels, il est logique que la responsabilité nous incombe en matière de sécurité. Il s'agit de notre pipeline de construction, de nos processus et de notre contrôle de la qualité, et si nous commettons une erreur, il est de notre responsabilité d'y remédier.

En outre, nous devrions être dans une situation où nous cherchons à créer des logiciels de la plus haute qualité possible, et le codage sécurisé doit faire partie des paramètres qui définissent un résultat réussi. Il s'agit là d'une tâche ardue dans un monde qui privilégie la rapidité à tout prix, mais il incombe aux responsables de la sécurité qui guident notre avenir de veiller à ce que tous les acteurs du processus de création de logiciels, et en particulier les développeurs, reçoivent une formation adéquate leur permettant d'appliquer les meilleures pratiques en matière de sécurité dans le cadre de leur rôle. 

Nous manquons encore d'indications sur les meilleures pratiques à long terme.

L'objectif stratégique 3.3 fait référence au cadre bien établi de développement de logiciels sécurisés du NIST comme base de ses meilleures pratiques générales, et il s'agit de lignes directrices complètes et globales. Elles précisent la nécessité de "veiller à ce que le personnel, les processus et la technologie de l'organisation soient prêts à assurer le développement de logiciels sécurisés au niveau de l'organisation", mais ne sont pas particulièrement prescriptives sur les facteurs que, par exemple, un responsable de la sensibilisation à la sécurité devrait connaître lorsqu'il choisit des solutions d'habilitation.

Pour que l'approche soit réellement transformatrice, les développeurs doivent être considérés comme faisant partie intégrante du programme de sécurité et se voir offrir toutes les possibilités d'améliorer leurs compétences et de partager la responsabilité de la détection et de l'éradication des vulnérabilités. Ils ne peuvent y parvenir de manière mesurable sans un apprentissage et des outils hyper pertinents et contextuels, ni si cela est considéré comme un exercice de conformité annuel au lieu d'un parcours de développement continu des compétences. 

Les développeurs sont une pièce importante du puzzle lorsqu'il s'agit de résoudre l'énigme de la sécurité, et une équipe de développeurs compétents en matière de sécurité est essentiellement l'ingrédient manquant dans la plupart des organisations. Ils permettent d'accélérer la sécurité, mais uniquement lorsque du temps et des ressources sont consacrés à cette tâche au sein de l'équipe. En attendant, toutes les lignes directrices générales sur les meilleures pratiques du monde ne parviendront pas à faire bouger l'aiguille.

Le long chemin vers le nirvana de la sécurité des logiciels.

L'administration Biden s'est engagée à financer la CISA à hauteur de 3 milliards de dollars, dans le but d'assurer une résilience rapide des infrastructures critiques. Si le financement et le soutien des plus hauts niveaux de gouvernement sont essentiels, pour que nous ayons une chance de contrecarrer les acteurs de la menace, il faudra un effort mondial pour réécrire l'histoire de la culture de la sécurité.

La route est longue, mais elle commence avec chaque éditeur de logiciels qui fait le premier pas courageux vers la responsabilisation en matière de sécurité au niveau de l'organisation.

Table des matières

Télécharger le PDF
Voir la ressource
Vous souhaitez en savoir plus ?

Directeur général, président et cofondateur

Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO 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émonstrationTélécharger
Partager sur :
Centre de ressources

Ressources pour vous aider à démarrer

Plus d'articles
Centre de ressources

Ressources pour vous aider à démarrer

Plus d'articles