Les nouvelles lignes directrices du NIST : Pourquoi une formation personnalisée est essentielle pour créer des logiciels sûrs
Le 11 juin 2019, le National Institute of Standards & Technology(NIST) a publié un livre blanc mis à jour, détaillant plusieurs plans d'action pour réduire les vulnérabilités des logiciels et les cyber-risques. Intitulé Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software Development Framework (SSDF), le NIST fournit aux organisations des lignes directrices solides pour éviter les conséquences désagréables - pour ne pas dire coûteuses - d'une violation de données.
Il est important de noter que le SSDF est délibérément générique, il ne suppose pas que chaque organisation a exactement les mêmes objectifs en matière de sécurité des logiciels, et il ne prescrit pas non plus de mécanisme précis pour les atteindre. L'objectif principal est de mettre en œuvre les meilleures pratiques en matière de sécurité. Comme l'indique l'auteur, Donna Dodson : "Bien que l'on souhaite que chaque producteur de sécurité suive toutes les pratiques applicables, on s'attend à ce que le degré de mise en œuvre de chaque pratique varie en fonction des hypothèses de sécurité du producteur. Les pratiques offrent une certaine souplesse aux responsables de la mise en œuvre, mais elles sont également claires afin de ne pas laisser trop de place à l'interprétation".
Ce qui m'a particulièrement intéressé, bien sûr, ce sont les inclusions spécifiques concernant la formation à la sécurité des logiciels pour les développeurs. Nous savons depuis longtemps que les développeurs ont besoin d'une formation adéquate s'ils veulent défendre une organisation dès le début du processus de développement de logiciels... mais qu'est-ce qui est adéquat, exactement ? Il existe de nombreuses opinions divergentes. Cependant, je pense que l'enveloppe est enfin poussée dans une direction qui produira des résultats positifs significatifs.
Il y a la formation à la sécurité... et il y a la formation à la sécurité efficace.
J'ai longuement parlé de la nécessité d'une mise en œuvre plus efficace de la formation à la sécurité des logiciels, d'un engagement et d'une adaptation aux besoins du développeur. Aujourd'hui encore, dans de nombreuses organisations, il s'agit au mieux d'un exercice de type "cocher la case". Il y a peut-être quelques heures de formation vidéo, ou même du temps précieux passé hors des outils pour un apprentissage en classe. Le fait qu'il y ait des violations de données à grande échelle tous les deux jours, perpétrées par des attaquants qui exploitent des vulnérabilités bien connues (et généralement facilement corrigées), prouve que la formation à la sécurité des logiciels est loin d'être aussi efficace qu'elle devrait l'être. Et, ce qui est peut-être le plus important, il existe très peu de moyens de vérifier l'efficacité de la formation : les vulnérabilités sont-elles corrigées plus rapidement ? Les personnes ont-elles réellement suivi la formation ou ont-elles simplement cliqué sur "suivant" pour la terminer ?
Les développeurs sont des gens très occupés, qui travaillent dur pour respecter des délais stricts. La plupart du temps, la sécurité est un inconvénient, et il est rare que leur formation leur apporte les connaissances nécessaires pour atténuer les cyberrisques. Le mot "sécurité" est généralement prononcé lorsqu'un membre de l'équipe AppSec signale des failles dans leur travail, ce qui crée une relation plutôt froide et dysfonctionnelle. Un scénario du type "votre bébé est moche, allez le réparer".
Qu'est-ce que cela nous apprend ? C'est un signal d'alarme vieux de plusieurs décennies qui montre que nous ne faisons pas assez pour convaincre les développeurs de la nécessité de la sécurité ; ils ne sont pas motivés pour prendre des responsabilités, ni pour rechercher les outils dont ils ont besoin pour créer des logiciels fonctionnels, tout en gardant à l'esprit les meilleures pratiques en matière de sécurité.
Les développeurs sont intelligents, créatifs et aiment résoudre des problèmes. Il est peu probable que regarder d'interminables vidéos sur les vulnérabilités en matière de sécurité les passionne ou les aide à rester engagés. En tant qu'instructeur SANS, j'ai très vite appris que la meilleure formation est pratique, les obligeant à analyser et à être défiés intellectuellement, en utilisant des exemples du monde réel qui mettent leur cerveau à l'épreuve et s'appuient sur leurs connaissances antérieures. La gamification et la compétition amicale sont également des outils puissants pour faire adhérer tout le monde à de nouveaux concepts, tout en restant utiles et pratiques dans l'application.
Les lignes directrices du NIST précisent "Fournissez une formation spécifique à chaque rôle à l'ensemble du personnel dont les responsabilités contribuent à un développement sécurisé. Révisez périodiquement la formation spécifique au rôle et mettez-la à jour si nécessaire." Plus loin, elles précisent : "Définir les rôles et les responsabilités du personnel chargé de la cybersécurité : "Définissez les rôles et les responsabilités du personnel chargé de la cybersécurité, des champions de la sécurité, des cadres supérieurs, des développeurs de logiciels, des propriétaires de produits et des autres personnes impliquées dans le cycle de développement durable.
Cette déclaration, bien qu'elle ne soit pas spécifique au type de formation, contribue à faire évoluer les organisations vers la gauche et à maintenir les meilleures pratiques en matière de sécurité au premier plan. Elle renvoie à l'entreprise la responsabilité de trouver des solutions de formation efficaces et plus spécifiques, ce qui, espérons-le, permettra aux développeurs d'être armés des bons outils et des bonnes connaissances pour réussir.
La culture : le chaînon manquant.
Même si une organisation consacre du temps et des ressources à la formation des développeurs et d'autres membres clés du personnel, en mettant l'accent sur leur rôle dans la prévention des vulnérabilités et la réduction des risques de sécurité, ces efforts peuvent souvent être réduits à néant si la culture de sécurité de l'organisation reste fondamentalement défaillante.
Lorsque les individus sont formés efficacement, que les objectifs sont fixés et que les attentes sont claires, il leur est beaucoup plus facile de comprendre leur place dans le paysage de la sécurité et d'assumer les responsabilités qui s'imposent. Dans le cas des développeurs en particulier, ils reçoivent les outils et les connaissances nécessaires pour écrire du code sécurisé dès le début. Toutefois, la meilleure façon d'y parvenir est d'instaurer un environnement de sécurité positif, où il y a moins de double manipulation, de pointes de doigt et de travail en silo sur les projets.
La sécurité doit être au centre des préoccupations de l'ensemble de l'organisation, avec un engagement de soutien et de collaboration pour fournir des logiciels sûrs et de qualité. Cela signifie que les budgets sont suffisants pour mettre en place des formations amusantes et attrayantes qui utilisent des vulnérabilités de code réelles, et que l'ensemble de l'organisation adhère à ces formations pour maintenir l'élan. Dans ce paysage numérique en constante évolution, la formation doit être aussi continue que la livraison. Si l'on vous a dit par le passé qu'une formation à la conformité "unique" ou "à mettre en place et à oublier" était suffisante ou efficace, c'est une erreur.
Bien que le nouveau cadre du NIST n'énonce pas spécifiquement l'obligation d'entretenir une culture de sécurité positive, l'adhésion à ses lignes directrices en nécessitera très certainement une. Il indique toutefois que les organisations doivent "définir des politiques qui précisent les exigences de sécurité auxquelles doivent répondre les logiciels de l'organisation, y compris les pratiques de codage sécurisées que doivent suivre les développeurs".
Ce qui précède est essentiel pour développer et affiner les compétences en matière de sécurité au sein des équipes, et il peut être utile de prendre en compte les éléments suivants lors de l'évaluation de vos propres politiques et du climat actuel en matière d'AppSec :
- Les lignes directrices et les attentes en matière de sécurité des logiciels sont-elles clairement définies ?
- Chacun est-il conscient du rôle qu'il joue dans la réalisation de ces objectifs ?
- La formation est-elle fréquente et évaluée ?
- Vos développeurs sont-ils conscients du rôle considérable qu'ils peuvent jouer dans l'élimination des bogues de sécurité courants avant qu'ils ne se produisent ?
Comme je l'ai dit, cette dernière partie dépend en grande partie de l'organisation et de la formation qu'elle choisit. Elle doit être pertinente, fréquente et engageante. Trouvez une solution qui peut être appliquée à leur travail quotidien et développez leurs connaissances de manière contextuelle.
Et maintenant ?
Il faut vraiment tout un village pour créer, vérifier et déployer les logiciels sécurisés à toute épreuve dont la plupart des entreprises ont besoin, de la manière la plus sûre possible. Il ne s'agit pas seulement de formation. Il existe des lignes directrices à prendre en compte lors de l'utilisation de logiciels tiers(l'utilisation de composants présentant des vulnérabilités connues figure toujours dans le Top 10 de l'OWASP, après tout), des suggestions concernant la vérification, les tests de pénétration et l'examen du code, ainsi que des lignes directrices concernant la tenue des registres de sécurité, les chaînes d'outils appropriées et tout le reste. Gary McGraw, qui est référencé dans le document du NIST .
Toutefois, la victoire la plus rapide peut être obtenue si vos développeurs disposent des bons outils et des bonnes connaissances pour réussir à créer des logiciels sécurisés dès le départ. Il est moins coûteux pour l'entreprise (et plus rapide dans l'ensemble) d'empêcher les vulnérabilités courantes d'apparaître à des stades ultérieurs du cycle de développement logiciel, encore et encore. Jouez avec leurs forces et offrez-leur une incitation à s'impliquer dans la sécurité de l'organisation. Cela peut vraiment être amusant, et ils peuvent être les héros juste à temps dont vous avez besoin pour garder les méchants à l'extérieur, et nos données en sécurité.
Références :
Le National Institute of Standards & Technology (NIST) a publié un livre blanc actualisé, détaillant plusieurs plans d'action pour réduire les vulnérabilités des logiciels et les cyber-risques.
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
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.
Le 11 juin 2019, le National Institute of Standards & Technology(NIST) a publié un livre blanc mis à jour, détaillant plusieurs plans d'action pour réduire les vulnérabilités des logiciels et les cyber-risques. Intitulé Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software Development Framework (SSDF), le NIST fournit aux organisations des lignes directrices solides pour éviter les conséquences désagréables - pour ne pas dire coûteuses - d'une violation de données.
Il est important de noter que le SSDF est délibérément générique, il ne suppose pas que chaque organisation a exactement les mêmes objectifs en matière de sécurité des logiciels, et il ne prescrit pas non plus de mécanisme précis pour les atteindre. L'objectif principal est de mettre en œuvre les meilleures pratiques en matière de sécurité. Comme l'indique l'auteur, Donna Dodson : "Bien que l'on souhaite que chaque producteur de sécurité suive toutes les pratiques applicables, on s'attend à ce que le degré de mise en œuvre de chaque pratique varie en fonction des hypothèses de sécurité du producteur. Les pratiques offrent une certaine souplesse aux responsables de la mise en œuvre, mais elles sont également claires afin de ne pas laisser trop de place à l'interprétation".
Ce qui m'a particulièrement intéressé, bien sûr, ce sont les inclusions spécifiques concernant la formation à la sécurité des logiciels pour les développeurs. Nous savons depuis longtemps que les développeurs ont besoin d'une formation adéquate s'ils veulent défendre une organisation dès le début du processus de développement de logiciels... mais qu'est-ce qui est adéquat, exactement ? Il existe de nombreuses opinions divergentes. Cependant, je pense que l'enveloppe est enfin poussée dans une direction qui produira des résultats positifs significatifs.
Il y a la formation à la sécurité... et il y a la formation à la sécurité efficace.
J'ai longuement parlé de la nécessité d'une mise en œuvre plus efficace de la formation à la sécurité des logiciels, d'un engagement et d'une adaptation aux besoins du développeur. Aujourd'hui encore, dans de nombreuses organisations, il s'agit au mieux d'un exercice de type "cocher la case". Il y a peut-être quelques heures de formation vidéo, ou même du temps précieux passé hors des outils pour un apprentissage en classe. Le fait qu'il y ait des violations de données à grande échelle tous les deux jours, perpétrées par des attaquants qui exploitent des vulnérabilités bien connues (et généralement facilement corrigées), prouve que la formation à la sécurité des logiciels est loin d'être aussi efficace qu'elle devrait l'être. Et, ce qui est peut-être le plus important, il existe très peu de moyens de vérifier l'efficacité de la formation : les vulnérabilités sont-elles corrigées plus rapidement ? Les personnes ont-elles réellement suivi la formation ou ont-elles simplement cliqué sur "suivant" pour la terminer ?
Les développeurs sont des gens très occupés, qui travaillent dur pour respecter des délais stricts. La plupart du temps, la sécurité est un inconvénient, et il est rare que leur formation leur apporte les connaissances nécessaires pour atténuer les cyberrisques. Le mot "sécurité" est généralement prononcé lorsqu'un membre de l'équipe AppSec signale des failles dans leur travail, ce qui crée une relation plutôt froide et dysfonctionnelle. Un scénario du type "votre bébé est moche, allez le réparer".
Qu'est-ce que cela nous apprend ? C'est un signal d'alarme vieux de plusieurs décennies qui montre que nous ne faisons pas assez pour convaincre les développeurs de la nécessité de la sécurité ; ils ne sont pas motivés pour prendre des responsabilités, ni pour rechercher les outils dont ils ont besoin pour créer des logiciels fonctionnels, tout en gardant à l'esprit les meilleures pratiques en matière de sécurité.
Les développeurs sont intelligents, créatifs et aiment résoudre des problèmes. Il est peu probable que regarder d'interminables vidéos sur les vulnérabilités en matière de sécurité les passionne ou les aide à rester engagés. En tant qu'instructeur SANS, j'ai très vite appris que la meilleure formation est pratique, les obligeant à analyser et à être défiés intellectuellement, en utilisant des exemples du monde réel qui mettent leur cerveau à l'épreuve et s'appuient sur leurs connaissances antérieures. La gamification et la compétition amicale sont également des outils puissants pour faire adhérer tout le monde à de nouveaux concepts, tout en restant utiles et pratiques dans l'application.
Les lignes directrices du NIST précisent "Fournissez une formation spécifique à chaque rôle à l'ensemble du personnel dont les responsabilités contribuent à un développement sécurisé. Révisez périodiquement la formation spécifique au rôle et mettez-la à jour si nécessaire." Plus loin, elles précisent : "Définir les rôles et les responsabilités du personnel chargé de la cybersécurité : "Définissez les rôles et les responsabilités du personnel chargé de la cybersécurité, des champions de la sécurité, des cadres supérieurs, des développeurs de logiciels, des propriétaires de produits et des autres personnes impliquées dans le cycle de développement durable.
Cette déclaration, bien qu'elle ne soit pas spécifique au type de formation, contribue à faire évoluer les organisations vers la gauche et à maintenir les meilleures pratiques en matière de sécurité au premier plan. Elle renvoie à l'entreprise la responsabilité de trouver des solutions de formation efficaces et plus spécifiques, ce qui, espérons-le, permettra aux développeurs d'être armés des bons outils et des bonnes connaissances pour réussir.
La culture : le chaînon manquant.
Même si une organisation consacre du temps et des ressources à la formation des développeurs et d'autres membres clés du personnel, en mettant l'accent sur leur rôle dans la prévention des vulnérabilités et la réduction des risques de sécurité, ces efforts peuvent souvent être réduits à néant si la culture de sécurité de l'organisation reste fondamentalement défaillante.
Lorsque les individus sont formés efficacement, que les objectifs sont fixés et que les attentes sont claires, il leur est beaucoup plus facile de comprendre leur place dans le paysage de la sécurité et d'assumer les responsabilités qui s'imposent. Dans le cas des développeurs en particulier, ils reçoivent les outils et les connaissances nécessaires pour écrire du code sécurisé dès le début. Toutefois, la meilleure façon d'y parvenir est d'instaurer un environnement de sécurité positif, où il y a moins de double manipulation, de pointes de doigt et de travail en silo sur les projets.
La sécurité doit être au centre des préoccupations de l'ensemble de l'organisation, avec un engagement de soutien et de collaboration pour fournir des logiciels sûrs et de qualité. Cela signifie que les budgets sont suffisants pour mettre en place des formations amusantes et attrayantes qui utilisent des vulnérabilités de code réelles, et que l'ensemble de l'organisation adhère à ces formations pour maintenir l'élan. Dans ce paysage numérique en constante évolution, la formation doit être aussi continue que la livraison. Si l'on vous a dit par le passé qu'une formation à la conformité "unique" ou "à mettre en place et à oublier" était suffisante ou efficace, c'est une erreur.
Bien que le nouveau cadre du NIST n'énonce pas spécifiquement l'obligation d'entretenir une culture de sécurité positive, l'adhésion à ses lignes directrices en nécessitera très certainement une. Il indique toutefois que les organisations doivent "définir des politiques qui précisent les exigences de sécurité auxquelles doivent répondre les logiciels de l'organisation, y compris les pratiques de codage sécurisées que doivent suivre les développeurs".
Ce qui précède est essentiel pour développer et affiner les compétences en matière de sécurité au sein des équipes, et il peut être utile de prendre en compte les éléments suivants lors de l'évaluation de vos propres politiques et du climat actuel en matière d'AppSec :
- Les lignes directrices et les attentes en matière de sécurité des logiciels sont-elles clairement définies ?
- Chacun est-il conscient du rôle qu'il joue dans la réalisation de ces objectifs ?
- La formation est-elle fréquente et évaluée ?
- Vos développeurs sont-ils conscients du rôle considérable qu'ils peuvent jouer dans l'élimination des bogues de sécurité courants avant qu'ils ne se produisent ?
Comme je l'ai dit, cette dernière partie dépend en grande partie de l'organisation et de la formation qu'elle choisit. Elle doit être pertinente, fréquente et engageante. Trouvez une solution qui peut être appliquée à leur travail quotidien et développez leurs connaissances de manière contextuelle.
Et maintenant ?
Il faut vraiment tout un village pour créer, vérifier et déployer les logiciels sécurisés à toute épreuve dont la plupart des entreprises ont besoin, de la manière la plus sûre possible. Il ne s'agit pas seulement de formation. Il existe des lignes directrices à prendre en compte lors de l'utilisation de logiciels tiers(l'utilisation de composants présentant des vulnérabilités connues figure toujours dans le Top 10 de l'OWASP, après tout), des suggestions concernant la vérification, les tests de pénétration et l'examen du code, ainsi que des lignes directrices concernant la tenue des registres de sécurité, les chaînes d'outils appropriées et tout le reste. Gary McGraw, qui est référencé dans le document du NIST .
Toutefois, la victoire la plus rapide peut être obtenue si vos développeurs disposent des bons outils et des bonnes connaissances pour réussir à créer des logiciels sécurisés dès le départ. Il est moins coûteux pour l'entreprise (et plus rapide dans l'ensemble) d'empêcher les vulnérabilités courantes d'apparaître à des stades ultérieurs du cycle de développement logiciel, encore et encore. Jouez avec leurs forces et offrez-leur une incitation à s'impliquer dans la sécurité de l'organisation. Cela peut vraiment être amusant, et ils peuvent être les héros juste à temps dont vous avez besoin pour garder les méchants à l'extérieur, et nos données en sécurité.
Références :
Le 11 juin 2019, le National Institute of Standards & Technology(NIST) a publié un livre blanc mis à jour, détaillant plusieurs plans d'action pour réduire les vulnérabilités des logiciels et les cyber-risques. Intitulé Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software Development Framework (SSDF), le NIST fournit aux organisations des lignes directrices solides pour éviter les conséquences désagréables - pour ne pas dire coûteuses - d'une violation de données.
Il est important de noter que le SSDF est délibérément générique, il ne suppose pas que chaque organisation a exactement les mêmes objectifs en matière de sécurité des logiciels, et il ne prescrit pas non plus de mécanisme précis pour les atteindre. L'objectif principal est de mettre en œuvre les meilleures pratiques en matière de sécurité. Comme l'indique l'auteur, Donna Dodson : "Bien que l'on souhaite que chaque producteur de sécurité suive toutes les pratiques applicables, on s'attend à ce que le degré de mise en œuvre de chaque pratique varie en fonction des hypothèses de sécurité du producteur. Les pratiques offrent une certaine souplesse aux responsables de la mise en œuvre, mais elles sont également claires afin de ne pas laisser trop de place à l'interprétation".
Ce qui m'a particulièrement intéressé, bien sûr, ce sont les inclusions spécifiques concernant la formation à la sécurité des logiciels pour les développeurs. Nous savons depuis longtemps que les développeurs ont besoin d'une formation adéquate s'ils veulent défendre une organisation dès le début du processus de développement de logiciels... mais qu'est-ce qui est adéquat, exactement ? Il existe de nombreuses opinions divergentes. Cependant, je pense que l'enveloppe est enfin poussée dans une direction qui produira des résultats positifs significatifs.
Il y a la formation à la sécurité... et il y a la formation à la sécurité efficace.
J'ai longuement parlé de la nécessité d'une mise en œuvre plus efficace de la formation à la sécurité des logiciels, d'un engagement et d'une adaptation aux besoins du développeur. Aujourd'hui encore, dans de nombreuses organisations, il s'agit au mieux d'un exercice de type "cocher la case". Il y a peut-être quelques heures de formation vidéo, ou même du temps précieux passé hors des outils pour un apprentissage en classe. Le fait qu'il y ait des violations de données à grande échelle tous les deux jours, perpétrées par des attaquants qui exploitent des vulnérabilités bien connues (et généralement facilement corrigées), prouve que la formation à la sécurité des logiciels est loin d'être aussi efficace qu'elle devrait l'être. Et, ce qui est peut-être le plus important, il existe très peu de moyens de vérifier l'efficacité de la formation : les vulnérabilités sont-elles corrigées plus rapidement ? Les personnes ont-elles réellement suivi la formation ou ont-elles simplement cliqué sur "suivant" pour la terminer ?
Les développeurs sont des gens très occupés, qui travaillent dur pour respecter des délais stricts. La plupart du temps, la sécurité est un inconvénient, et il est rare que leur formation leur apporte les connaissances nécessaires pour atténuer les cyberrisques. Le mot "sécurité" est généralement prononcé lorsqu'un membre de l'équipe AppSec signale des failles dans leur travail, ce qui crée une relation plutôt froide et dysfonctionnelle. Un scénario du type "votre bébé est moche, allez le réparer".
Qu'est-ce que cela nous apprend ? C'est un signal d'alarme vieux de plusieurs décennies qui montre que nous ne faisons pas assez pour convaincre les développeurs de la nécessité de la sécurité ; ils ne sont pas motivés pour prendre des responsabilités, ni pour rechercher les outils dont ils ont besoin pour créer des logiciels fonctionnels, tout en gardant à l'esprit les meilleures pratiques en matière de sécurité.
Les développeurs sont intelligents, créatifs et aiment résoudre des problèmes. Il est peu probable que regarder d'interminables vidéos sur les vulnérabilités en matière de sécurité les passionne ou les aide à rester engagés. En tant qu'instructeur SANS, j'ai très vite appris que la meilleure formation est pratique, les obligeant à analyser et à être défiés intellectuellement, en utilisant des exemples du monde réel qui mettent leur cerveau à l'épreuve et s'appuient sur leurs connaissances antérieures. La gamification et la compétition amicale sont également des outils puissants pour faire adhérer tout le monde à de nouveaux concepts, tout en restant utiles et pratiques dans l'application.
Les lignes directrices du NIST précisent "Fournissez une formation spécifique à chaque rôle à l'ensemble du personnel dont les responsabilités contribuent à un développement sécurisé. Révisez périodiquement la formation spécifique au rôle et mettez-la à jour si nécessaire." Plus loin, elles précisent : "Définir les rôles et les responsabilités du personnel chargé de la cybersécurité : "Définissez les rôles et les responsabilités du personnel chargé de la cybersécurité, des champions de la sécurité, des cadres supérieurs, des développeurs de logiciels, des propriétaires de produits et des autres personnes impliquées dans le cycle de développement durable.
Cette déclaration, bien qu'elle ne soit pas spécifique au type de formation, contribue à faire évoluer les organisations vers la gauche et à maintenir les meilleures pratiques en matière de sécurité au premier plan. Elle renvoie à l'entreprise la responsabilité de trouver des solutions de formation efficaces et plus spécifiques, ce qui, espérons-le, permettra aux développeurs d'être armés des bons outils et des bonnes connaissances pour réussir.
La culture : le chaînon manquant.
Même si une organisation consacre du temps et des ressources à la formation des développeurs et d'autres membres clés du personnel, en mettant l'accent sur leur rôle dans la prévention des vulnérabilités et la réduction des risques de sécurité, ces efforts peuvent souvent être réduits à néant si la culture de sécurité de l'organisation reste fondamentalement défaillante.
Lorsque les individus sont formés efficacement, que les objectifs sont fixés et que les attentes sont claires, il leur est beaucoup plus facile de comprendre leur place dans le paysage de la sécurité et d'assumer les responsabilités qui s'imposent. Dans le cas des développeurs en particulier, ils reçoivent les outils et les connaissances nécessaires pour écrire du code sécurisé dès le début. Toutefois, la meilleure façon d'y parvenir est d'instaurer un environnement de sécurité positif, où il y a moins de double manipulation, de pointes de doigt et de travail en silo sur les projets.
La sécurité doit être au centre des préoccupations de l'ensemble de l'organisation, avec un engagement de soutien et de collaboration pour fournir des logiciels sûrs et de qualité. Cela signifie que les budgets sont suffisants pour mettre en place des formations amusantes et attrayantes qui utilisent des vulnérabilités de code réelles, et que l'ensemble de l'organisation adhère à ces formations pour maintenir l'élan. Dans ce paysage numérique en constante évolution, la formation doit être aussi continue que la livraison. Si l'on vous a dit par le passé qu'une formation à la conformité "unique" ou "à mettre en place et à oublier" était suffisante ou efficace, c'est une erreur.
Bien que le nouveau cadre du NIST n'énonce pas spécifiquement l'obligation d'entretenir une culture de sécurité positive, l'adhésion à ses lignes directrices en nécessitera très certainement une. Il indique toutefois que les organisations doivent "définir des politiques qui précisent les exigences de sécurité auxquelles doivent répondre les logiciels de l'organisation, y compris les pratiques de codage sécurisées que doivent suivre les développeurs".
Ce qui précède est essentiel pour développer et affiner les compétences en matière de sécurité au sein des équipes, et il peut être utile de prendre en compte les éléments suivants lors de l'évaluation de vos propres politiques et du climat actuel en matière d'AppSec :
- Les lignes directrices et les attentes en matière de sécurité des logiciels sont-elles clairement définies ?
- Chacun est-il conscient du rôle qu'il joue dans la réalisation de ces objectifs ?
- La formation est-elle fréquente et évaluée ?
- Vos développeurs sont-ils conscients du rôle considérable qu'ils peuvent jouer dans l'élimination des bogues de sécurité courants avant qu'ils ne se produisent ?
Comme je l'ai dit, cette dernière partie dépend en grande partie de l'organisation et de la formation qu'elle choisit. Elle doit être pertinente, fréquente et engageante. Trouvez une solution qui peut être appliquée à leur travail quotidien et développez leurs connaissances de manière contextuelle.
Et maintenant ?
Il faut vraiment tout un village pour créer, vérifier et déployer les logiciels sécurisés à toute épreuve dont la plupart des entreprises ont besoin, de la manière la plus sûre possible. Il ne s'agit pas seulement de formation. Il existe des lignes directrices à prendre en compte lors de l'utilisation de logiciels tiers(l'utilisation de composants présentant des vulnérabilités connues figure toujours dans le Top 10 de l'OWASP, après tout), des suggestions concernant la vérification, les tests de pénétration et l'examen du code, ainsi que des lignes directrices concernant la tenue des registres de sécurité, les chaînes d'outils appropriées et tout le reste. Gary McGraw, qui est référencé dans le document du NIST .
Toutefois, la victoire la plus rapide peut être obtenue si vos développeurs disposent des bons outils et des bonnes connaissances pour réussir à créer des logiciels sécurisés dès le départ. Il est moins coûteux pour l'entreprise (et plus rapide dans l'ensemble) d'empêcher les vulnérabilités courantes d'apparaître à des stades ultérieurs du cycle de développement logiciel, encore et encore. Jouez avec leurs forces et offrez-leur une incitation à s'impliquer dans la sécurité de l'organisation. Cela peut vraiment être amusant, et ils peuvent être les héros juste à temps dont vous avez besoin pour garder les méchants à l'extérieur, et nos données en sécurité.
Références :
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
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.
Le 11 juin 2019, le National Institute of Standards & Technology(NIST) a publié un livre blanc mis à jour, détaillant plusieurs plans d'action pour réduire les vulnérabilités des logiciels et les cyber-risques. Intitulé Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software Development Framework (SSDF), le NIST fournit aux organisations des lignes directrices solides pour éviter les conséquences désagréables - pour ne pas dire coûteuses - d'une violation de données.
Il est important de noter que le SSDF est délibérément générique, il ne suppose pas que chaque organisation a exactement les mêmes objectifs en matière de sécurité des logiciels, et il ne prescrit pas non plus de mécanisme précis pour les atteindre. L'objectif principal est de mettre en œuvre les meilleures pratiques en matière de sécurité. Comme l'indique l'auteur, Donna Dodson : "Bien que l'on souhaite que chaque producteur de sécurité suive toutes les pratiques applicables, on s'attend à ce que le degré de mise en œuvre de chaque pratique varie en fonction des hypothèses de sécurité du producteur. Les pratiques offrent une certaine souplesse aux responsables de la mise en œuvre, mais elles sont également claires afin de ne pas laisser trop de place à l'interprétation".
Ce qui m'a particulièrement intéressé, bien sûr, ce sont les inclusions spécifiques concernant la formation à la sécurité des logiciels pour les développeurs. Nous savons depuis longtemps que les développeurs ont besoin d'une formation adéquate s'ils veulent défendre une organisation dès le début du processus de développement de logiciels... mais qu'est-ce qui est adéquat, exactement ? Il existe de nombreuses opinions divergentes. Cependant, je pense que l'enveloppe est enfin poussée dans une direction qui produira des résultats positifs significatifs.
Il y a la formation à la sécurité... et il y a la formation à la sécurité efficace.
J'ai longuement parlé de la nécessité d'une mise en œuvre plus efficace de la formation à la sécurité des logiciels, d'un engagement et d'une adaptation aux besoins du développeur. Aujourd'hui encore, dans de nombreuses organisations, il s'agit au mieux d'un exercice de type "cocher la case". Il y a peut-être quelques heures de formation vidéo, ou même du temps précieux passé hors des outils pour un apprentissage en classe. Le fait qu'il y ait des violations de données à grande échelle tous les deux jours, perpétrées par des attaquants qui exploitent des vulnérabilités bien connues (et généralement facilement corrigées), prouve que la formation à la sécurité des logiciels est loin d'être aussi efficace qu'elle devrait l'être. Et, ce qui est peut-être le plus important, il existe très peu de moyens de vérifier l'efficacité de la formation : les vulnérabilités sont-elles corrigées plus rapidement ? Les personnes ont-elles réellement suivi la formation ou ont-elles simplement cliqué sur "suivant" pour la terminer ?
Les développeurs sont des gens très occupés, qui travaillent dur pour respecter des délais stricts. La plupart du temps, la sécurité est un inconvénient, et il est rare que leur formation leur apporte les connaissances nécessaires pour atténuer les cyberrisques. Le mot "sécurité" est généralement prononcé lorsqu'un membre de l'équipe AppSec signale des failles dans leur travail, ce qui crée une relation plutôt froide et dysfonctionnelle. Un scénario du type "votre bébé est moche, allez le réparer".
Qu'est-ce que cela nous apprend ? C'est un signal d'alarme vieux de plusieurs décennies qui montre que nous ne faisons pas assez pour convaincre les développeurs de la nécessité de la sécurité ; ils ne sont pas motivés pour prendre des responsabilités, ni pour rechercher les outils dont ils ont besoin pour créer des logiciels fonctionnels, tout en gardant à l'esprit les meilleures pratiques en matière de sécurité.
Les développeurs sont intelligents, créatifs et aiment résoudre des problèmes. Il est peu probable que regarder d'interminables vidéos sur les vulnérabilités en matière de sécurité les passionne ou les aide à rester engagés. En tant qu'instructeur SANS, j'ai très vite appris que la meilleure formation est pratique, les obligeant à analyser et à être défiés intellectuellement, en utilisant des exemples du monde réel qui mettent leur cerveau à l'épreuve et s'appuient sur leurs connaissances antérieures. La gamification et la compétition amicale sont également des outils puissants pour faire adhérer tout le monde à de nouveaux concepts, tout en restant utiles et pratiques dans l'application.
Les lignes directrices du NIST précisent "Fournissez une formation spécifique à chaque rôle à l'ensemble du personnel dont les responsabilités contribuent à un développement sécurisé. Révisez périodiquement la formation spécifique au rôle et mettez-la à jour si nécessaire." Plus loin, elles précisent : "Définir les rôles et les responsabilités du personnel chargé de la cybersécurité : "Définissez les rôles et les responsabilités du personnel chargé de la cybersécurité, des champions de la sécurité, des cadres supérieurs, des développeurs de logiciels, des propriétaires de produits et des autres personnes impliquées dans le cycle de développement durable.
Cette déclaration, bien qu'elle ne soit pas spécifique au type de formation, contribue à faire évoluer les organisations vers la gauche et à maintenir les meilleures pratiques en matière de sécurité au premier plan. Elle renvoie à l'entreprise la responsabilité de trouver des solutions de formation efficaces et plus spécifiques, ce qui, espérons-le, permettra aux développeurs d'être armés des bons outils et des bonnes connaissances pour réussir.
La culture : le chaînon manquant.
Même si une organisation consacre du temps et des ressources à la formation des développeurs et d'autres membres clés du personnel, en mettant l'accent sur leur rôle dans la prévention des vulnérabilités et la réduction des risques de sécurité, ces efforts peuvent souvent être réduits à néant si la culture de sécurité de l'organisation reste fondamentalement défaillante.
Lorsque les individus sont formés efficacement, que les objectifs sont fixés et que les attentes sont claires, il leur est beaucoup plus facile de comprendre leur place dans le paysage de la sécurité et d'assumer les responsabilités qui s'imposent. Dans le cas des développeurs en particulier, ils reçoivent les outils et les connaissances nécessaires pour écrire du code sécurisé dès le début. Toutefois, la meilleure façon d'y parvenir est d'instaurer un environnement de sécurité positif, où il y a moins de double manipulation, de pointes de doigt et de travail en silo sur les projets.
La sécurité doit être au centre des préoccupations de l'ensemble de l'organisation, avec un engagement de soutien et de collaboration pour fournir des logiciels sûrs et de qualité. Cela signifie que les budgets sont suffisants pour mettre en place des formations amusantes et attrayantes qui utilisent des vulnérabilités de code réelles, et que l'ensemble de l'organisation adhère à ces formations pour maintenir l'élan. Dans ce paysage numérique en constante évolution, la formation doit être aussi continue que la livraison. Si l'on vous a dit par le passé qu'une formation à la conformité "unique" ou "à mettre en place et à oublier" était suffisante ou efficace, c'est une erreur.
Bien que le nouveau cadre du NIST n'énonce pas spécifiquement l'obligation d'entretenir une culture de sécurité positive, l'adhésion à ses lignes directrices en nécessitera très certainement une. Il indique toutefois que les organisations doivent "définir des politiques qui précisent les exigences de sécurité auxquelles doivent répondre les logiciels de l'organisation, y compris les pratiques de codage sécurisées que doivent suivre les développeurs".
Ce qui précède est essentiel pour développer et affiner les compétences en matière de sécurité au sein des équipes, et il peut être utile de prendre en compte les éléments suivants lors de l'évaluation de vos propres politiques et du climat actuel en matière d'AppSec :
- Les lignes directrices et les attentes en matière de sécurité des logiciels sont-elles clairement définies ?
- Chacun est-il conscient du rôle qu'il joue dans la réalisation de ces objectifs ?
- La formation est-elle fréquente et évaluée ?
- Vos développeurs sont-ils conscients du rôle considérable qu'ils peuvent jouer dans l'élimination des bogues de sécurité courants avant qu'ils ne se produisent ?
Comme je l'ai dit, cette dernière partie dépend en grande partie de l'organisation et de la formation qu'elle choisit. Elle doit être pertinente, fréquente et engageante. Trouvez une solution qui peut être appliquée à leur travail quotidien et développez leurs connaissances de manière contextuelle.
Et maintenant ?
Il faut vraiment tout un village pour créer, vérifier et déployer les logiciels sécurisés à toute épreuve dont la plupart des entreprises ont besoin, de la manière la plus sûre possible. Il ne s'agit pas seulement de formation. Il existe des lignes directrices à prendre en compte lors de l'utilisation de logiciels tiers(l'utilisation de composants présentant des vulnérabilités connues figure toujours dans le Top 10 de l'OWASP, après tout), des suggestions concernant la vérification, les tests de pénétration et l'examen du code, ainsi que des lignes directrices concernant la tenue des registres de sécurité, les chaînes d'outils appropriées et tout le reste. Gary McGraw, qui est référencé dans le document du NIST .
Toutefois, la victoire la plus rapide peut être obtenue si vos développeurs disposent des bons outils et des bonnes connaissances pour réussir à créer des logiciels sécurisés dès le départ. Il est moins coûteux pour l'entreprise (et plus rapide dans l'ensemble) d'empêcher les vulnérabilités courantes d'apparaître à des stades ultérieurs du cycle de développement logiciel, encore et encore. Jouez avec leurs forces et offrez-leur une incitation à s'impliquer dans la sécurité de l'organisation. Cela peut vraiment être amusant, et ils peuvent être les héros juste à temps dont vous avez besoin pour garder les méchants à l'extérieur, et nos données en sécurité.
Références :
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
La puissance d'OpenText Fortify + Secure Code Warrior
OpenText Fortify et Secure Code Warrior unissent leurs forces pour aider les entreprises à réduire les risques, à transformer les développeurs en champions de la sécurité et à renforcer la confiance des clients. Pour en savoir plus, cliquez ici.
É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.
Ressources pour vous aider à démarrer
10 prédictions clés : Secure Code Warrior sur l'influence de l'IA et de la conception sécurisée en 2025
Les organisations sont confrontées à des décisions difficiles sur l'utilisation de l'IA pour soutenir la productivité à long terme, la durabilité et le retour sur investissement de la sécurité. Au cours des dernières années, il nous est apparu clairement que l'IA ne remplacera jamais complètement le rôle du développeur. Des partenariats IA + développeurs aux pressions croissantes (et à la confusion) autour des attentes en matière de conception sécurisée, examinons de plus près ce à quoi nous pouvons nous attendre au cours de l'année prochaine.
OWASP Top 10 pour les applications LLM : Ce qui est nouveau, ce qui a changé et comment rester en sécurité
Gardez une longueur d'avance dans la sécurisation des applications LLM avec les dernières mises à jour du Top 10 de l'OWASP. Découvrez ce qui est nouveau, ce qui a changé et comment Secure Code Warrior vous fournit des ressources d'apprentissage actualisées pour atténuer les risques dans l'IA générative.
La note de confiance révèle la valeur des initiatives d'amélioration de la sécurité par la conception
Nos recherches ont montré que la formation au code sécurisé fonctionne. Le Trust Score, qui utilise un algorithme s'appuyant sur plus de 20 millions de points de données d'apprentissage issus du travail de plus de 250 000 apprenants dans plus de 600 organisations, révèle son efficacité à réduire les vulnérabilités et la manière de rendre l'initiative encore plus efficace.
.png)
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é.
Codage axé sur le développeur.
En toute sécurité.
Contactez-nous dès aujourd'hui et faites de la sécurité des logiciels une partie intrinsèque de votre processus de développement.
