Sensibilisation certifiée à la sécurité : un décret visant à améliorer les compétences des développeurs

S'il existe un timing divin, il faut dire que l'administration Biden a réussi à le faire avec son Décret exécutif (EO) annonce, concernant le plan du gouvernement américain visant à renforcer les réseaux fédéraux et à améliorer les normes et les meilleures pratiques de cybersécurité à travers le pays. Cette stratégie fait suite à deux récentes cyberattaques dévastatrices : la violation continue de la chaîne d'approvisionnement de Vents solaires, en plus du Pipeline Colonial attaque d'infrastructures gazières.

Bien que ces événements aient sans aucun doute eu des répercussions à tous les niveaux de gouvernement, cette directive marque une période passionnante pour le l'avenir de la cybersécurité. Il semble que nous prenions enfin au sérieux la question de la protection de notre existence numérique dès le sommet, et il n'y a pas de meilleur moment que maintenant pour promouvoir de meilleures normes et des logiciels de meilleure qualité.

L'EO aborde de nombreux aspects de la cybersécurité fonctionnelle, mais pour la première fois, il décrit spécifiquement l'impact des développeurs et la nécessité pour eux de vérifié compétences et sensibilisation à la sécurité. Pendant des années, nous n'avons cessé de clamer que c'est la voie à suivre pour combattre les vulnérabilités courantes qui nous font si souvent trébucher, et que l'alignement des mandats gouvernementaux sur cette approche est la voie à suivre pour un succès généralisé en matière de cyberdéfense.

Comment les organisations, tout comme les ministères fédéraux, devraient-elles réagir à cet ordre ? Découvrons quelques catégories principales.

« Tick-the-box » n'est pas envisageable.

Nous soulignons depuis longtemps l'inefficacité de la plupart des types de formations en cybersécurité destinées aux développeurs. Il est souvent trop générique, n'est pas diffusé d'une manière qui engage et inspire le résultat souhaité (lire : un code plus sécurisé), et est abordé beaucoup trop rarement. Pire encore, de nombreuses entreprises se contentent d'une formation « cochée » : une approche qui fournit le strict minimum, « une fois fait », pour répondre à une exigence opérationnelle et obtenir une case à cocher à côté du nom du développeur. Ces stratégies de formation permettent à chaque RISO de rester sur le fil du rasoir, en croisant les doigts et en espérant que son entreprise ne sera pas victime de la prochaine faille de sécurité Zero Day. Ils ne permettent tout simplement pas de réduire les vulnérabilités et de créer un code de meilleure qualité.

Dans la section 4 du mandat de Biden, la nécessité pour une organisation de démontrer que ses développeurs affichent une conformité de sécurité documentée et vérifiée est clairement énoncée :

‍

»Les directives doivent inclure des critères qui peuvent être utilisés pour évaluer la sécurité des logiciels, inclure des critères pour évaluer les pratiques de sécurité des développeurs et des fournisseurs eux-mêmes, et identifier des outils ou des méthodes innovants pour démontrer la conformité aux pratiques de sécurité.»

Cela pose un léger problème : il n'existe actuellement aucune certification standard spécifique aux développeurs. Il est fondamental de pouvoir évaluer le niveau de compétence des développeurs en matière de codage sécurisé et de suivre des cours et des évaluations pour améliorer ces compétences, afin de permettre aux entreprises de se fixer des objectifs et de se mettre en conformité. Lorsque les développeurs peuvent démontrer leurs compétences de base dans un environnement pratique, cela peut être évalué et certifié de manière significative et fiable. C'est au cœur de notre offre chez Secure Code Warrior, et nous avons travaillé d'arrache-pied pour créer un système pouvant être utilisé pour une certification fiable et personnalisable en fonction de leur infrastructure technologique et des exigences organisationnelles.

Ces compétences sont précieuses et ne peuvent pas être automatisées. La certification peut transformer les développeurs en une force soucieuse de la sécurité capable de défendre la base de code contre les menaces insidieuses.

‍

L'accent est mis sur les outils de développement (et les outils en général).

Outre les directives relatives à la vérification des pratiques de codage sécurisées, l'EO approfondit les aspects de la sécurité liés à l'automatisation et à l'outillage.

Il y a tout simplement trop de code produit pour que les humains puissent les gérer seuls du point de vue de la sécurité, et l'automatisation, en tant que partie intégrante d'un ensemble technologique complet, occupe une place majeure dans tout programme de sécurité, comme il se doit. Cependant, tous les outils ne sont pas créés de la même manière, et il n'existe pas d' « outil unique pour les contrôler tous » capable de détecter toutes les vulnérabilités, dans tous les langages de programmation. Un bon programme de sécurité adopte une approche nuancée, en particulier lorsqu'il s'agit d'outils et de services destinés aux développeurs.

La section 3 de l'EO décrit les attentes des fournisseurs qui créent des logiciels pouvant être utilisés par le gouvernement fédéral, ainsi que des directives instructives concernant l'utilisation des outils dans le processus de développement :

‍

» (iii) en utilisant des outils automatisés, ou des processus comparables, pour maintenir des chaînes d'approvisionnement fiables en code source, garantissant ainsi l'intégrité du code ;
(iv) en utilisant des outils automatisés, ou des processus comparables, qui vérifient les vulnérabilités connues et potentielles et y remédient, qui doivent fonctionner régulièrement, ou au moins avant la publication du produit, de la version ou de la mise à jour.»

Les outils de sécurité intégrés à la pile technologique des développeurs constituent l'un des moyens d'améliorer rapidement les meilleures pratiques en matière de sécurité, en veillant à ce que les versions aient les meilleures chances de respecter les délais et de ne pas être retardées par des bogues de sécurité ou d'autres obstacles. Le fait est que les développeurs auront toujours besoin d'un apprentissage contextuel pour tirer le meilleur parti des outils les plus puissants. Il est essentiel qu'ils comprennent ce qui a été signalé, pourquoi c'est dangereux et comment y remédier, et cela permettra de réduire le nombre d'erreurs que les outils devront identifier dès le départ.

Les meilleurs outils s'intégreront à l'environnement des développeurs, les aideront à produire un code de meilleure qualité (et plus sécurisé) et veilleront à ce que la sécurité reste une priorité.

‍

Sécurisation de la chaîne d'approvisionnement.

L'un de mes aspects préférés de l'EO concerne les plans complets visant à sécuriser la chaîne d'approvisionnement logicielle. Ce n'est pas surprenant, compte tenu de l'événement SolarWinds, mais c'est un moment fort important :

»La sécurité des logiciels utilisés par le gouvernement fédéral est essentielle à la capacité du gouvernement fédéral à exécuter ses fonctions critiques. Le développement de logiciels commerciaux manque souvent de transparence, d'une attention suffisante à la capacité du logiciel à résister aux attaques et de contrôles adéquats pour empêcher toute manipulation par des acteurs malveillants. Il est urgent de mettre en œuvre des mécanismes plus rigoureux et prévisibles pour garantir que les produits fonctionnent en toute sécurité, et comme prévu... le gouvernement fédéral doit prendre des mesures pour améliorer rapidement la sécurité et l'intégrité de la chaîne d'approvisionnement logicielle, en accordant la priorité aux logiciels critiques.»

Cette décision affectera toute société de logiciels souhaitant faire affaire avec le gouvernement américain, mais elle devrait être appliquée comme norme partout. Le manque de transparence de la part des fournisseurs tiers (sans parler des développeurs utilisant des composants tiers) quant à leurs mesures de sécurité rend extrêmement difficile l'évaluation, la validation et la déclaration du respect des meilleures pratiques en matière de cybersécurité. Nous devons analyser les fournisseurs que nous utilisons et les logiciels qu'ils écrivent. Ces actions peuvent être considérées comme un « effort supplémentaire », mais elles devraient être inhérentes à une norme de référence en matière de meilleures pratiques en matière de cybersécurité.

L'envoi de code sécurisé en toute confiance est un problème dans notre secteur depuis longtemps, mais c'est l'occasion idéale d'évaluer les processus actuels et de mener la course vers des logiciels renforcés et une infrastructure cloud qui font l'envie de ceux qui sont laissés pour compte. Contactez-nous dès maintenant et découvrez comment vous pouvez tirer parti Cours, Évaluations, et outils de développement pour certifier votre prochaine équipe de développeurs soucieux de la sécurité.

‍