L'équipe Microsoft Security Response Center(MSRC) identifie, surveille, répond et résout les incidents de sécurité et les vulnérabilités dans les logiciels Microsoft. Cela aide les clients de l’éditeur à gérer les risques de sécurité, à créer des capacités de défense basées sur la communauté et à développer les meilleures pratiques adoptées par d’autres acteurs de l’industrie du logiciel.Depuis 2004, le MSRC trie toutes les vulnérabilités de sécurité Microsoft signalées. Il ressort de tout cela un fait étonnant: comme l'a expliqué Matt Miller lors de sa présentation à BlueHat IL en 2019, la majorité des vulnérabilités corrigées et associées à une CVE sont causées par des développeurs qui ont inséré par inadvertance des bogues de corruption de mémoire dans leurs codes C et C ++. Gavin Thomas, Principal Security Engineering Manager au sein de la section MSRC, note qu’alors que Microsoft augmente sa base de code et utilise plus de logiciels Open Source dans son code, ce problème ne s’améliore pas, il s’aggrave.
Environ 70% des vulnérabilités que Microsoft attribue à un CVE chaque année continuent de poser des problèmes de sécurité de la mémoire
Tant d'outils, si peu de temps
Ce n’est pas qu’il n’existe aucun outil pour aider les développeurs à écrire du code sécurisé. Le développeur dispose d’une pléthore d’outils : les outils d’analyse statique étonnamment complexes (qu’il faut au moins un mois ou deux pour apprendre), de fuzzing (ou test de données aléatoires), les analyses des défauts ainsi que les résolutions des contraintes. Il existe également des instructions pour aider les développeurs à adopter des pratiques sécurisées: le cycle de vie du développement sécurisé, des encyclopédies de directives de codage, des heures de révision du code, de nombreuses formations et des instructions de modélisation des menaces. MSRC a modifié les compilateurs et créé des mesures d’atténuation pour protéger les développeurs des erreurs. Visual Studio a même des lignes rouges ondulées pour souligner les potentiels défauts.
Ce n'est pas tout. Thomas affirme que lorsqu'une entité interne ou externe découvre une faille de sécurité, l’équipe est là pour le développeur, prête à la signaler et prête à les aider dans leur post-mortem (l’examen a posteriori afin de déterminer les causes d'un succès ou d'un échec qui permet de tirer des leçons qui pourront être réutilisées dans les prochains développements / projets).
Mais qu'est-ce que le développeur peut attendre de plus de l'ingénierie de la sécurité ? Pour commencer, ils voudront peut-être consacrer moins d'effort à l'apprentissage d'outils et de processus pour créer des fonctionnalités sans faille de sécurité.
Les langages protégés contre les vulnérabilités de corruption de mémoire
La tâche principale d’un développeur n’est pas de s’inquiéter pour la sécurité mais de faire du travail sur les fonctionnalités. Plutôt que d’investir dans de plus en plus d’outils, ainsi que dans la formation et les correctifs de vulnérabilité, qu’en est-il d’un langage de développement dans lequel ils ne peuvent pas introduire de problèmes de sécurité de la mémoire dans leur travail sur les fonctionnalités ? Cela aiderait à la fois les développeurs de fonctionnalités et les ingénieurs en sécurité, ainsi que les clients.
Un langage considéré comme protégé contre les vulnérabilités de corruption de la mémoire supprime le fardeau de la sécurité logicielle du développeur de fonctionnalités et le confie à celui-ci. Selon Thomas, plusieurs langages sont considérés comme « protégés » des vulnérabilités de corruption de la mémoire (et il cite C # comme étant l’un d’eux). Et d’assurer que de nombreuses équipes de développement de Microsoft ont embrassé le monde de l’utilisation de ces langages sécurisés pour écrire de nouvelles fonctionnalités liées aux clients.
« Le C ++ a des vertus qui le rendent attrayant et parfois essentiel : il est incroyablement rapide, il a une petite empreinte mémoire et disque, il est mature, son exécution est prévisible, sa plateforme est pratiquement inégalée et vous pouvez l’utiliser sans avoir à installer des composants supplémentaires. Si seulement les développeurs pouvaient avoir toutes les garanties de sécurité de la mémoire de langages comme .NET C # combinés à toute l’efficacité du C ++. Peut-être le pouvons-nous : l’un des langages de programmation les plus récents et les plus prometteurs qui répondent à ces exigences est le langage de programmation Rust initialement développé par Mozilla.
« Si, en tant qu'industrie, nous nous soucions vraiment de la sécurité, nous devrions nous concentrer sur les outils du développeur et ne pas être pris au dépourvu par tout l'attirail sécuritaire, le battage médiatique, les idéologies non axées sur les données et les méthodes et approches dépassées. Plutôt que de fournir des conseils et des outils pour remédier aux défauts, nous devrions nous efforcer d’empêcher le développeur d’introduire les défauts en premier lieu ».
Améliorer la sécurité, un écureuil à la fois
Thomas raconte :
« Alors que je me rendais au travail aujourd'hui, un écureuil a traversé la route devant moi. J'ai freiné rapidement et j'ai dû faire un écart pour l'éviter. Mais je n’ai pas touché l’écureuil et je ne me suis pas fait mal. Non pas parce que j'ai pris des mesures compliquées, mais parce que le système de freinage antiblocage m'empêchait de glisser dans l'autre voie et que ma ceinture de sécurité me protégeait dans mon siège. L'écureuil et moi-même étions mieux lotis à cause des dispositifs de sécurité intégrés à ma voiture qui m'ont permis d'éviter à la fois de le heurter et de causer un autre accident.
« Nous pouvons tirer des enseignements de la manière dont l'industrie automobile fait évoluer ses technologies de manière continue pour protéger les conducteurs et les usagers de la route. Le secteur de la sécurité des logiciels a le privilège de protéger le développeur de la même manière. Peut-être le temps est-il venu de supprimer les anciens langages non sécurisés et de passer à un langage de programmation système plus sûr et moderne ?
« Vous avez probablement déjà l'habitude de penser à Microsoft Security Response Center en tant que groupe répondant aux incidents et aux vulnérabilités...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.