Protection proactive : Tirer parti de la stratégie nationale de cybersécurité pour la prévention des menaces avancées
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.
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é.
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émonstrationDirecteur 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.
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.
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.
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émonstrationDirecteur 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.
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
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échargerRessources pour vous aider à démarrer
Évaluation comparative des compétences en matière de sécurité : Rationalisation de la conception sécurisée dans l'entreprise
Le mouvement "Secure-by-Design" (conception sécurisée) est l'avenir du développement de logiciels sécurisés. Découvrez les éléments clés que les entreprises doivent garder à l'esprit lorsqu'elles envisagent une initiative de conception sécurisée.
DigitalOcean réduit sa dette de sécurité avec Secure Code Warrior
L'utilisation par DigitalOcean de la formation Secure Code Warrior a considérablement réduit la dette de sécurité, permettant aux équipes de se concentrer davantage sur l'innovation et la productivité. L'amélioration de la sécurité a renforcé la qualité des produits et l'avantage concurrentiel de l'entreprise. À l'avenir, le score de confiance SCW les aidera à améliorer leurs pratiques de sécurité et à continuer à stimuler l'innovation.
Ressources pour vous aider à démarrer
Sécurité réactive contre sécurité préventive : La prévention est un meilleur remède
L'idée d'apporter une sécurité préventive aux codes et systèmes existants en même temps qu'aux applications plus récentes peut sembler décourageante, mais une approche "Secure-by-Design", mise en œuvre en améliorant les compétences des développeurs, permet d'appliquer les meilleures pratiques de sécurité à ces systèmes. C'est la meilleure chance qu'ont de nombreuses organisations d'améliorer leur sécurité.
Les avantages de l'évaluation des compétences des développeurs en matière de sécurité
L'importance croissante accordée au code sécurisé et aux principes de conception sécurisée exige que les développeurs soient formés à la cybersécurité dès le début du cycle de développement durable, et que des outils tels que le Trust Score de Secure Code Warriorles aident à mesurer et à améliorer leurs progrès.
Assurer le succès des initiatives de conception sécurisée de l'entreprise
Notre dernier document de recherche, Benchmarking Security Skills : Streamlining Secure-by-Design in the Enterprise est le résultat d'une analyse approfondie d'initiatives réelles de conception sécurisée au niveau de l'entreprise, et de l'élaboration d'approches de meilleures pratiques basées sur des conclusions fondées sur des données.
Plongée en profondeur : Naviguer dans la vulnérabilité critique de CUPS dans les systèmes GNU-Linux
Découvrez les derniers défis de sécurité auxquels sont confrontés les utilisateurs de Linux en explorant les récentes vulnérabilités de haute sévérité dans le système d'impression commun d'UNIX (CUPS). Apprenez comment ces problèmes peuvent conduire à une potentielle exécution de code à distance (RCE) et ce que vous pouvez faire pour protéger vos systèmes.