Tout est parti d’un mémo de Bill Gates aux employés en janvier 2002. La société devait prendre un virage résolument axé sur la sécurité, qu’il ne fallait plus considérer comme une simple couche supplémentaire.
Dans un billet, l’entreprise revient sur la genèse de ce mémo et les personnes impliquées. Michael Howard et David LeBlanc tout particulièrement, deux spécialistes de la sécurité à qui de nombreux développeurs posaient des questions au sein de Microsoft.
En 2001, ils écrivirent un livre, Writing Secure Code, enrichi par les dures leçons imposées par les vers CodeRed et Nimda. L’équipe chargée du compilateur C++ se demanda alors s’il n’était pas possible d’ajouter directement des défenses dans le code compilé et Microsoft Research commença un travail sur des outils d’analyse.
Lorsque le livre sortit en décembre 2001, Michael Howard fit une présentation avec Bill Gates sur les vulnérabilités. Il lui remit à cette occasion une copie du livre, que Gates aurait particulièrement apprécié.
Ce travail avait en fait créé des remous dans la société. Un programme plus large était en préparation et fut officialisé quelques jours plus tard par Craig Mundie. Le mémo Trustworthy Computing de Gates fut envoyé peu de temps après.
C’est ce mouvement qui avait d’ailleurs entraîné à l’époque le retard de Vista, l’équipe de Windows travaillant alors sur le Service Pack 2 de Windows XP, qui dotait pour la première fois un Windows d’un pare-feu intégré.
Aujourd’hui, la division Trustworthy Computing n’existe plus en tant que telle. Elle a été supprimée en 2014, Microsoft estimant que son travail était terminé. Les connaissances accumulées étaient diffusées et d’autres initiatives avaient été prises entre temps, notamment le Security Development Lifecycle, toujours un élément central de sécurité aujourd’hui.
Le Microsoft Security Response Center (MSRC) concentre aujourd’hui les efforts de sécurité dans l’entreprise. Lui aussi a été créé il y a presque 20 ans. Il « travaille avec des milliers de chercheurs et professionnels internes et externes pour corriger rapidement les failles dans les produits commercialisés ».
Le billet contient plusieurs anecdotes intéressantes de personnes impliquées dans ces projets durant les deux dernières décennies.
Commentaires (5)
#1
L’histoire ne dit pas s’ils se sont inspirés de “Secure Programming for Linux and Unix HOWTO” écrit par David Wheeler deux ans plus tôt…
#2
Et c’est à cause de ca qu’on a plus d’easter eggs dans les produits Microsoft :(
Adieu simulateurs de vol dans Excel et autres joyeusetés…
#3
Une nouvelle qui va ravir certainement Jvachez
#4
Qu’ils se soient “inspirés” d’UNIX, puis de GNU/Linux ou non, c’est finalement une bonne nouvelle qu’ils n’aient pas suivi les mêmes radicaux.
Ça donne un bon gros noyau monolithique interdépendants d’une myriades de processus s’exécutant avec le niveau de privilège distinct, le plus élevés, processus parfois directement appelés/utilisés en espace utilisateur pour en traiter la charge utile.
“Il suffirait d’une étincelle”
La gestion de contrôle d’accès avec élévation temporaire de permissions (z’appellent ça User Account Control) ne donne qu’une apparence de ce que fait l’élévation temporaire de privilèges côté UNIX sans en disposer du fond.
Faut-il aller jusqu’à creuser au niveau des API système accessibles, par exemple, par les pilotes, qui permettent de contourner à peu près tout, à peu près n’importe quand ?
C’est un formidable terrain de jeu quand on cherche à se cacher (on appelle ça Advanced Persistent Threats). Pour l’amusement, il y a plus simple : #LOLBin
Au début, on s’énerve, et puis, avec le temps, on relativise l’incapacité humaine à être intelligent. Répéter les mêmes erreurs structurelles pendant des dizaines d’années ? C’est divertissant pour les autres, parfois.