Les nouvelles directives du NIST : pourquoi une formation personnalisée est essentielle pour créer des logiciels sécurisés

Le 11 juin 2019, le National Institute of Standards & Technology (NIST) a publié une mise à jour de son livre blanc, détaillant plusieurs plans d'action pour réduire les vulnérabilités logicielles et les cyberrisques. Intitulé Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software Development Framework (SSDF), le NIST fournit aux organisations des directives solides pour éviter les conséquences fâcheuses, et coûteuses, d'une violation de données.

Il est important de noter que le SSDF est volontairement générique ; il ne suppose pas que chaque organisation a exactement les mêmes objectifs de sécurité logicielle, et ne prescrit pas non plus de mécanisme précis pour les atteindre. L'objectif principal est la mise en œuvre des meilleures pratiques de sécurité. Comme l'indique l'auteure, Donna Dodson : « Bien que l'on souhaite que chaque producteur de logiciels 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 flexibilité aux responsables de la mise en œuvre, mais elles sont également suffisamment claires pour éviter de 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é logicielle 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 logiciel... mais qu'est-ce qui est adéquat, exactement ? Il existe de nombreuses opinions divergentes à ce sujet. Cependant, je pense que nous franchissons enfin une étape qui permettra d'obtenir des résultats positifs significatifs.

Il y a la formation à la sécurité... et il y a la formation efficace à la sécurité.

J'ai longuement parlé de la nécessité de mettre en œuvre, d'impliquer et d'adapter la formation à la sécurité logicielle aux besoins des développeurs de manière plus efficace. Même aujourd'hui, dans de nombreuses organisations, il s'agit au mieux d'un exercice de pure forme. Il y a peut-être quelques heures de formation vidéo, ou même un 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 un jour sur deux, perpétrées par des attaquants qui exploitent des vulnérabilités bien connues (et généralement faciles à corriger), prouve que la formation à la sécurité logicielle est loin d'être aussi efficace qu'elle devrait l'être. Et, ce qui est peut-être le plus important, il n'existe que très peu de moyens de vérifier si la formation a été efficace : les vulnérabilités sont-elles corrigées plus rapidement ? Les vulnérabilités diminuent-elles dans le code ? Les gens ont-ils réellement suivi la formation, ou ont-ils simplement cliqué sur « suivant » pour la terminer ?

Les développeurs sont des gens occupés, qui travaillent dur pour respecter des délais stricts. La sécurité est souvent un inconvénient, et ils sont rarement équipés des connaissances nécessaires durant leur formation pour atténuer avec succès les cyberrisques. Le mot « sécurité » apparaît généralement lorsqu'un membre de l'équipe AppSec souligne des failles dans leur travail, ce qui crée une relation plutôt froide et dysfonctionnelle. Un scénario du type « ton bébé est moche, va le réparer ».

Qu'est-ce que cela nous dit ? C'est un signal d'alarme vieux de plusieurs décennies qui indique que nous ne faisons pas assez pour convaincre les développeurs de l'importance de la sécurité ; ils ne sont pas motivés à prendre leurs responsabilités, ni à rechercher les outils dont ils ont besoin pour créer des logiciels fonctionnels, tout en gardant à l'esprit les meilleures pratiques de sécurité.

Les développeurs sont intelligents, créatifs et adorent résoudre des problèmes. Il est très peu probable que regarder des vidéos interminables sur les vulnérabilités de sécurité les enthousiasme ou les aide à rester engagés. Au cours de mon expérience en tant qu'instructeur SANS, j'ai appris très rapidement que la meilleure formation est pratique, les obligeant à analyser et à être mis au défi intellectuellement, en utilisant des exemples concrets qui testent leur cerveau et s'appuient sur des acquis antérieurs. 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 leur application.

Les directives du NIST précisent : « Fournir une formation spécifique au rôle pour tout le personnel occupant des postes dont les responsabilités contribuent au développement sécurisé. Examiner périodiquement la formation spécifique au rôle et la mettre à jour si nécessaire. » Et plus loin : « Définir les rôles et les responsabilités du personnel de cybersécurité, des champions de la sécurité, de la haute direction, des développeurs de logiciels, des propriétaires de produits et des autres personnes impliquées dans le cycle de vie du développement logiciel (SDLC). »

Cette déclaration, bien qu'elle ne précise pas le type de formation, contribue tout de même à faire évoluer les organisations vers une approche proactive et à garder les meilleures pratiques de sécurité à l'esprit. Elle renvoie la responsabilité de trouver des solutions de formation efficaces et plus spécifiques à l'entreprise, 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é, l'effort peut souvent être vain si la culture de sécurité d'une organisation reste fondamentalement défaillante.

Lorsque les individus sont formés efficacement, avec des objectifs fixés et des attentes claires, il leur devient beaucoup plus facile de comprendre leur place dans le paysage de la sécurité et d'assumer leurs responsabilités le cas échéant. 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épart. Cependant, cela est mieux orchestré dans un environnement de sécurité positif, où il y a moins de doubles manipulations, de désignation de coupables et de travail en silo.

La sécurité doit être au cœur des préoccupations de toute l'organisation, avec un engagement solidaire et collaboratif pour fournir des logiciels de qualité et sécurisés. Cela signifie que les budgets doivent être suffisants pour déployer une formation ludique et engageante qui utilise des vulnérabilités de code réelles, et que l'adhésion de toute l'organisation est nécessaire pour maintenir la dynamique. 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 de conformité « ponctuelle » ou « à configurer et oublier » était adéquate ou efficace, c'est une erreur.

Bien que ce nouveau cadre du NIST n'articule pas spécifiquement l'exigence de cultiver une culture de sécurité positive, le respect réussi de leurs directives en nécessitera certainement une. Ils notent cependant que les organisations devraient « définir des politiques qui spécifient les exigences de sécurité que les logiciels de l'organisation doivent respecter, y compris les pratiques de codage sécurisé que les développeurs doivent suivre ».

Ce qui précède est essentiel pour développer et affiner les compétences en sécurité au sein des équipes, et il peut être utile de prendre en compte les points suivants lors de l'évaluation de vos propres politiques et du climat actuel de l'AppSec :

• Les directives et les attentes en matière de sécurité logicielle sont-elles clairement définies ?
• Tout le monde comprend-il clairement le rôle qu'il joue dans leur réalisation ?
• La formation est-elle fréquente et évaluée ?
• Vos développeurs sont-ils conscients du rôle majeur qu'ils peuvent jouer dans l'élimination des failles de sécurité courantes avant qu'elles ne surviennent ?

Maintenant, cette dernière partie dépend, comme je l'ai dit, 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 puisse être appliquée à leur travail quotidien et qui renforce leurs connaissances de manière contextuelle.

Et maintenant ?

Plonger dans ces nouvelles directives peut sembler intimidant ; il faut tout un écosystème pour créer, vérifier et déployer les logiciels ultra-sécurisés dont les entreprises ont besoin. Il ne s'agit pas seulement de formation. Il existe des directives concernant 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 recommandations sur la vérification, les tests d'intrusion et la revue de code, ainsi que des directives sur la tenue des registres de sécurité, les chaînes d'outils appropriées et bien plus encore. Des conseils pratiques pour une vision d'ensemble sont disponibles dans le modèle BSIMM du Dr Gary McGraw, auquel le document du NIST fait référence.

Cependant, le moyen le plus rapide d'obtenir des résultats est de donner à vos développeurs les outils et les connaissances nécessaires pour réussir à concevoir des logiciels sécurisés dès le départ. Il est plus économique pour l'entreprise (et plus rapide globalement) d'empêcher l'apparition récurrente de vulnérabilités courantes aux étapes ultérieures du cycle de vie du développement logiciel. Misez sur leurs points forts et incitez-les à s'impliquer dans la sécurité. Cela peut être stimulant, et ils deviendront les héros dont vous avez besoin pour contrer les menaces et protéger nos données.

Références :

1. ATTÉNUER LE RISQUE DE VULNÉRABILITÉS LOGICIELLES EN ADOPTANT UN SSDF (11 JUIN 2019), Page 2.
2. ATTÉNUER LE RISQUE DE VULNÉRABILITÉS LOGICIELLES EN ADOPTANT UN SSDF (11 JUIN 2019), Page 5.
3. ATTÉNUER LE RISQUE DE VULNÉRABILITÉS LOGICIELLES EN ADOPTANT UN SSDF (11 JUIN 2019), Page 4.