Bernard Ourghanlian (Microsoft) : « La divulgation par Google de failles Zero-Day sur IE est une pratique condamnable »

Comment Microsoft gère les menaces « Zero-Day » ? Depuis le début de l’année, l’éditeur en a recensé au moins deux qui touchent son navigateur Internet Explorer.

Cette catégorie particulière de codes d’exploitation donne toujours du fil à retordre car elle cible des vulnérabilités qui ne sont pas encore publiquement annoncées par un éditeur, un constructeur ou un chercheur en sécurité.

Sur le plan des systèmes d’information des entreprises, ces failles « Zero-Day » sont dangereuses car non connues (aucun correctif disponible).

A l’occasion des Microsoft TechDays et sur fond de « Patch Tuesday » (voir encadré), Bernard Ourghanlian, Directeur « Technique et Sécurité » chez Microsoft France, revient sur la manière d’appréhender ce type spécifique de menaces impossible à juguler d’emblée.

Au passage, il n’hésite pas à pointer du doigt l’attitude des chercheurs de Google jugé immature. (interview réalisée le 8 février 2011)

ITespresso.fr : Comment Microsoft peut-il mieux lutter contre les failles « Zero-Day » ?
Bernard Ourghanlian : On mène ce combat depuis des années. Il faut essayer de convaincre les chercheurs en sécurité que la publication des failles « Zero-Day », ce n’est pas forcément une bonne idée. Nous tentons d’avoir des relations apaisées avec eux : on échange sur le plan technique, ils nous apportent un certain nombre de vulnérabilités, on améliore notre logiciel [Internet Explorer, ndlr]. C’est pour cela que nous avons mis en place Blue Hat, une réunion avec les développeurs de Microsoft et les chercheurs de sécurité dont le but est d’avancer ensemble. Mais certains chercheurs comme ceux de Google pratiquent la divulgation de failles « Zero-Day » pour des raisons que je qualifierais de commerciales et concurrentielles. Certes, ils font leur boulot dans un sens. Mais je trouve personnellement que c’est une pratique condamnable. Tout le monde a le droit de faire de la recherche sur la sécurité mais qu’on ne le fasse pas sur le dos d’une société concurrente. C’est comme si Microsoft se mettait à faire des recherches de sécurité sur Google Chrome et à les divulguer. On ne s’autorise pas à le faire. Contrairement à Google qui n’est pas suffisamment mature sur le sujet de la sécurité, Microsoft a appris avec le temps que la divulgation n’était pas une bonne idée. Car, au bout du compte, c’est l’internaute qui trinque.

ITespresso.fr : Peut-on améliorer la prévention des failles « Zero-Day », qui, par définition, sont imprévisibles ?
Bernard Ourghanlian : Eliminer les « Zero-Day », c’est impossible. A moins de faire des logiciels sans bugs, mais cela, on ne sait pas faire. On peut tenter d’autres choses : relever la barre en matière de sécurité à travers des méthodologies de développements et travailler davantage avec les chercheurs de sécurité en amont. C’est ce que l’on essaie de faire. Ce n’est pas une question d’être démuni. Il faut bien distinguer la faille et la capacité d’exploiter. Il nous arrive parfois de dire que cette faille n’est pas exploitable ou atténuée par un ensemble de mesures prises (tout ce qui concerne la détection des débordements de buffer, etc.). Dans ce cas, on ne se trouve pas dans une situation d’urgence. Mais, si la faille est exploitable, la situation se complique. Notre mission est de protéger les internautes le plus rapidement possible. Mais on ne peut pas se tromper dans la qualité de la correction apportée car des centaines de millions d’internautes utilisent Internet Explorer dans le monde. On nous reproche parfois que c’est long mais c’est en raison des tests à effectuer. Et c’est un processus compliqué : il faut prendre en compte toutes les versions du navigateur, toutes les déclinaisons linguistiques…

ITespresso.fr : Avec l’expérience, avez-vous appris à réduire le délai de réaction face à une menace « Zero-Day » ?
Bernard Ourghanlian : Bien sûr, on a appris. Mais il existe les délais qui ne sont pas compressibles. Corriger une faille, c’est une question de quelques heures. Ensuite vient la phase des tests d’une part et une question qui revient systématiquement : pourquoi ce bug est passé au-delà des mailles du filet ? Les outils de développement ne sont-ils pas à la hauteur ? Le développeur du logiciel a-t-il une maîtrise suffisante ? Existe-il un problème systémique dans le logiciel (le même problème apparaît-il dans plusieurs endroits) ? Autant de questions qu’il faut se poser. Nous sommes capables de réagir très vite mais parfois au détriment des tests.

(lire la fin de l’interview page 2)