Qu’est-ce qui fait la sécurité d’un OS ou d’un navigateur ? Je ne sais pas si la question a un sens, mais nous sommes bien placés pour constater que tout le monde a une opinion et que souvent elle se limite à “Windows et la sécurité ? Vous plaisantez ?”, “Vos patches menacent ma prod !” ou “J’ai un Mac, je ne cours aucun risque”.

Certes, je travaille chez Microsoft. Vous avez bien sûr le droit d’en déduire que je ne suis pas objectif ou que l’on me paie pour mentir. Je vois plutôt cela comme une indication que je connais mieux les produits et engagements Microsoft que les autres. Mais je me soigne ! J’utilise régulièrement la concurrence, qu’elle vienne de Cupertino, de Mountain View ou de Londres. Ou de Mountain View encore, mais de l’autre côté de l’autoroute… et je suis un grand partisan du libre choix.

Mon premier point est que je ne pense pas que la sécurité des produits se mesure en nombre de vulnérabilités. Jeff Jones a faits les comparatifs jusqu’à il y a environ un an, avec le résultat que l’on sait : Microsoft n’a pas à rougir, loin de là (n’est-ce pas, Oracle). Le problème est que même les mesures les plus objectives comme celles de Jeff Jones sont remises en cause, ou ignorées, par ceux qui refusent le résultat.

Non, l’important à mon avis est plutôt dans ce que l’éditeur met en place pour diminuer l’impact des bugs, et dans la façon dont il gère les vulnérabilités lorsqu’elles sont découvertes.

Mon second point est donc : étant donné que les bugs sont inévitables, que met-on en place pour que leur impact soit moins néfaste, ou pour qu’ils soient plus difficiles à exploiter ? Sur ce terrain, Windows et IE sont plutôt de très bons élèves, depuis Windows XP SP2, Windows Vista et IE7. Je ne citerai que quelques exemples de méthodes ou fonctionnalités qui me viennent à l’esprit :

• SDL est évidemment le premier exemple auquel on pense : une méthode, documentée et ouverte, pour prendre en compte la sécurité dans toutes les phases du développement. La première méthode, à ma connaissance, à interdire explicitement les fonctions “dangereuses” comme strcpy, sprintf, etc. L’objectif ici est de produire du code plus séurisé, avec moins de vulnérabilités.
• Le pare-feu Windows, actif par défaut depuis Windows XP SP2, a quasiment éliminé le mode de propagation des infections par le réseau qui faisaient l’actualité en 2003-2004.
• Le pare-feu Windows, version Vista et Windows 7, permet maintenant de spécifier quels services ont le droit ou non de communiquer ou d’écouter sur le réseau.
• La “refactorisation” des services a été l’occasion de ré-architecturer des services systèmes de façon à ce que ceux qui écoutent sur le réseau ne soient plus Local System.
• /GS, DEP (NX), ASLR, SEHOP sont des fonctionnalités qui rendent plus difficile l’exploitation de vulnérabilité.
• UAC, MIC, l’isolation des services, le mode protégé d’IE, sont des fonctionnalités qui, en mettant en pratique le principe de moindre privilège et en isolant les processus, diminuent l’impact des vulnérabilités lorsqu’elles sont exploitées. A propos d’UAC, vous avez sans doute repéré cette phrase dans la majorité des bulletins de sécurité actuels : Les utilisateurs dont les comptes sont configurés avec des privilèges moins élevés sur le système subiraient moins d'impact que ceux disposant de privilèges d'administrateur.
• Small is beautiful : moins de composants par défaut, moins de surface d’attaque dans Windows Server ; hyperviseur minimal dans Hyper-V : cette tendance est là pour durer. Le mode Server Core est aussi souvent cité dans les bulletins de sécurité pour dire que la vulnérabilité ne concerne pas ce mode d’installation.

Ces fonctionnalités répondent donc à trois objectifs :

• Produire du code avec moins de vulnérabilités,
• Rendre plus difficile l’exploitation de vulnérabilités,
• Diminuer l’impact sur le système de l’exploitation de vulnérabilités.

Et ce n’est pas tout. Si vous avez des applications mal écrites ou anciennes, incompatibles avec ces mesures, vous pouvez, grâce à Windows Virtual PC et Windows XP Mode, les isoler dans leur propre environnement virtuel Windows XP.

Enfin, et c’est donc mon troisième point, que fait l’éditeur lorsqu’une vulnérabilité est découverte ? Microsoft est exemplaire sur ce sujet, le processus mis en place avec le Microsoft Security Response Center (MSRC) est largement reconnu pour son efficacité : veille, réponse, communication, investigation, les actions du MSRC sont nombreuses et vous pouvez en voir l’aspect le plus visible le deuxième mardi de chaque mois à l’occasion des bulletins de sécurité. Qui a de vraies histoires récentes de correctifs Microsoft ayant causé des problèmes dans sa production ? Quel autre éditeur a un cycle de mise à jour aussi régulier, prévisible et ouvert ?

Par exemple : lorsqu’un “0day” est découvert, le MSRC publie un avis et le met à jour avec des mesures de contournement, jusqu’à la publication d’un bulletin de sécurité et des mises à jour associées.

Je n’ai pas de réponse définitive à la question en titre, il y a sûrement d’autres critères importants, comme par exemple les fonctionnalités antimalware, antiphishing, antispam, la gestion d’identité, la crypto, la protection de la vie privée, ou les notions de simplicité, de standards et d’ouverture, difficiles à définir mais pertinentes… Sans compter l’évolution de toutes ces notions dans un contexte de cloud et de profonde mutation de la notion de poste et de serveur, mais c’est peut-être une autre histoire… Sans doute pour 2010 !

Bonnes fêtes !

[2009-12-18, 17h30 :  nombreuses corrections de fautes (!) et quelques précisions]

[2009-12-21 : réécriture du paragraphe 3 ]