Les coulisses de la stratégie sécurité de Microsoft

La sécurité a longtemps été le talon d'Achille de Microsoft. Pourtant, depuis 2002, la firme de Redmond tente de remédier à ce problème récurrent, avec une démarche censée intégrer la sécurité dans le développement de ses logiciels et systèmes. Ce que Microsoft appelle l'informatique de confiance fait-elle ses preuves ?

Que l'on aime ou que l'on déteste Microsoft, il est indéniable que la firme de Redmond tient une place unique dans le paysage de l'informatique mondiale, de par sa taille et sa domination, toujours importante, Windows demeurant un système d'exploitation massivement utilisé. D'où l'intérêt de se pencher sur sa stratégie de sécurité, ce que nous avons pu faire en rencontrant plusieurs membres des équipes en charge de la sécurisation des produits Microsoft : la division Trustworthy Computing.

« Trustworthy computing ». La notion d'informatique de confiance est en fait, à la base, le sujet d'un e-mail interne de Bill Gates. Celui-ci s'émeut, en 2002, des inquiétudes des clients, professionnels comme particuliers concernant la sécurité de leur système. Depuis, Microsoft a progressivement mis en place une démarche, notamment connue sous le nom de Security Development Lifecycle (SDL). Le but ? Intégrer au processus de développement la notion de sécurité, selon plusieurs étapes allant de la formation des développeurs et ingénieurs à la correction des vulnérabilités après le lancement, en passant par le design et l'audit. La mise en place de ce processus explique la longue attente avant la disponibilité du Service Pack 2 de Windows XP, qui allait beaucoup plus loin qu'un simple ensemble de correctifs pour modifier les fondations de l'OS en lui apportant de nombreuses fonctionnalité

Après avoir intégré cette démarche à ses propres produits, Microsoft cherche à l'étendre à ses partenaires industriels. Alors que l'initiative semble porter ses fruits depuis Windows Vista et surtout 7, et en pleine explosion des attaques portant sur le vol de données personnelles sur de nombreux sites, le « trustworthy computing » made in Microsoft est-elle une solution pertinente ? Revenons sur l'historique et la logique de sécurité de la firme de Redmond !

L'épreuve d'Internet : le choc des années 2000

L'informatique, notamment en entreprise, a connu une nette évolution des menaces avec le développement d'Internet, et Microsoft a en quelque sorte accusé le coup. Directeur Senior de la division Trustworthy Computing de Microsoft, Steve Lipner revient sur cette mutation : « Pendant longtemps, les problèmes de sécurité dans l'entreprise étaient considérés comme secondaires. Les seules menaces réelles provenaient de l'intérieur. C'est toujours le cas aujourd'hui, mais depuis le développement de l'Internet les menaces viennent principalement de l'extérieur : les gens échangent des informations hors de l'entreprise, ils se connectent à Internet ou sur des réseaux locaux ». La situation finit par virer à la catastrophe en 2001 : le tout nouveau Windows XP est victime de menaces telles que Blaster et ses déclinaisons, et d'une grosse faille de sécurité au niveau de l'UPnP.

Vient alors l'e-mail de Bill Gates et la volonté de replacer la sécurité au centre du développement de Windows : « Comme j'en ai discuté avec nos clients au cours de l'année passée - des particuliers aux grandes entreprises - tout le monde reconnaît le rôle de plus en plus important que jouent les ordinateurs dans notre vie. En même temps, la plupart des gens à qui je parle sont inquiets par rapport à la sécurité des technologies dont ils dépendent ... ».



Néanmoins, entre cette prise de conscience et son aboutissement, la firme de Redmond avance à tâtons. La première étape, rappelle Steve Lipner, est la sensibilisation des équipes aux problématiques de sécurité : « Nous avons réuni l'ensemble de nos connaissances sur le problème, puis nous avons dit aux employés d'arrêter leur travail en cours, et d'aller se former. Nous avons mis en place des sessions où les développeurs pouvaient apprendre à créer un code sécurisé »

Viennent ensuite plusieurs étapes, telles que la « Security Science », qui consistait à découvrir de nouvelles classes de vulnérabilités dans le logiciel, puis de les résoudre, ainsi qu'une phase d'audit où une autre équipe analysait le code afin de déterminer sa qualité.

Selon Steve Lipner, cette approche a porté ses fruits, notamment sur SQL Server, mais se confrontait à ses limites : développer un logiciel, puis le soumettre à des améliorations de sécurité n'était pas viable : « Ce que nous voulions, c'était intégrer la sécurité au niveau du développement, mais également dès la phase de conception, ce que nous avons fait début 2004 avec le Security Developpement Lifecycle, ou SDL ».

Le SDL : un processus en 7 étapes

Le Security Development Lifecycle est donc implémenté pour la première fois en 2004, soit à l'époque de Windows XP SP2. Depuis, le processus, obligatoire dans tout développement Microsoft a été mis à jour à de maintes reprises, la version actuelle, estampillée 5.2, étant la dixième. Le SDL est systématiquement intégré à tous les nouveaux projets de Microsoft et se compose de plusieurs étapes :

MSRC : le suivi du produit après sa sortie

La phase de conception du produit est assurée par le MSEC (Microsoft Security Engineering Center). Une fois le produit sorti, c'est le Microsoft Security Response Center, ou MSRC, qui prend le relai. Pour l'utilisateur, c'est la partie visible de l'iceberg : c'est le MSRC qui gère cette institution de Windows qu'est le patch Tuesday, les correctifs mis à disposition de l'utilisateur le deuxième mardi de chaque mois.

Le MSRC se divise lui même essentiellement en plusieurs parties. On commence par le MSRC Program Management dont le but, selon Mike Reavey, directeur du MSRC est de « s'assurer que les bonnes décisions soient prises, ou du moins que les mauvaises décisions soient réduites au minimum ». La partie Program Management gère notamment la veille de nouvelles vulnérabilités, s'appuyant notamment sur les mails : « Nous recevons plus de 120 000 mails par an. Nous n'utilisons pas de filtre anti spam, car des mails en apparence anodins peuvent nous révéler des vulnérabilités. En outre, nous lisons intégralement tous les courriers reçus, car nous ne souhaitons pas donner à un hacker qui nous guiderait vers une vulnérabilité l'équivalent d'une musique d'ascenseur en guise de réponse ».



Et Mike Reavey de citer l'exemple d'un mail reçu en 2006 : «le sujet était Yo ! et le contenu se limitait à un smiley et quelques caractères chinois. Mais en réalité le message exécutait du code à distance, en exploitant une vulnérabilité de Windows »

Quand de telles vulnérabilités sont détectées, la main passe à l'équipe MSRC Engineering qui va appliquer ce que Mike Reavey définit comme un « état d'esprit de hacker ». En fait, l'équipe MSRC Engineering adopte un processus en étapes qui consiste notamment à :



Selon Mike Reavey, l'enjeu du MSRC est de compliquer l'économie des hackers, qui repose sur 3 critères : le coût de la découverte d'une vulnérabilité, le coût de développement d'une exploitation, et la durée de la fenêtre de tir. « Augmenter le coût de la découverte des vulnérabilités, c'est le rôle du SDL, en essayant par exemple de supprimer des classes entières de vulnérabilités, en mettant l'accent sur l'automatisation en complément des efforts humains. De notre côté, nous agissons sur le coût de développement de l'exploitation de ces vulnérabilités. Pour cela, on va tenter de fragiliser les exploitations en rendant le code plus complexe ».



Sur ce point, il semble que Microsoft a réussi son pari : « Lors d'une conférence de hackers à Miami, un représentant du groupe Mutiny s'est plaint de la complexité de développement des exploitations : il déclarait qu'il fallait plus de 40 jours pour exploiter une vulnérabilité sous Windows Vista, contre 4 jours du temps de Windows 2000 ».

En pratique, Mike Reavey décrit deux techniques employées ces dernières années par Microsoft. La première est la prévention de l'exécution des données (Data Execution Prevention ou DEP), qui consiste à empêcher l'exécution de code aux niveaux heap et stack. La DEP nécessite un processeur compatible pour l'assurer au niveau matériel, et a permis selon le directeur du MSRC, de bloquer plusieurs exploitations de failles zero day sous Internet Explorer. L'intéressé souligne également que son intégration a bloqué 100% des exploitations de failles de Microsoft Office pour les versions antérieures à la version 2010.



La seconde technique, l'ASLR (pour Address Space Layout Randomization) consiste comme son nom l'indique à déplacer l'adresse de différentes bibliothèques de Windows à chaque redémarrage. C'est ce qui a notamment permis de limiter l'exploitation de la vulnérabilité MS08-067 sur Windows Vista, 7 et 2008.

MMPC : protection contre les malwares et analyse du paysage

Le 3e et dernier pilier de l'initiative Trustworthy Computing est le Microsoft Malware Protection Center (MMPC). Le centre a plusieurs fonctions, et s'occupe en premier lieu de l'offre de Microsoft en matière de logiciels de sécurité. C'est le MMPC qui gère donc le développement de Microsoft Security Essentials, Windows Defender, l'Outil de Suppression des Logiciels Malveillants, ou encore la suite Forefront pour les entreprises.

L'autre rôle notable du MMPC réside dans la surveillance du paysage des malwares et la publication de conseils et de tendances, notamment via le Security Intelligence Report, un rapport semestriel réalisé à partir des données capturées par les différentes solutions de sécurité de Microsoft. Les deux rôles sont donc liés, puisque comme la majorité des logiciels de sécurité actuels, toutes les solutions proposées par Microsoft sont des outils de protection tout autant que des sondes permettant de récolter des informations sur les menaces détectées. Pour réaliser son SIR, Microsoft mobilise notamment les outils suivants :

Conficker : exemple de la démarche sécurité de Microsoft en action

La vulnérabilité MS08-067, qui a été exploitée par le ver Conficker à la fin de l'année 2008, donne un bon exemple de la manière dont Microsoft gère une situation de crise, qui conduit à déclencher le SSIRP (Software Security Incident Response Process), un processus utilisé dans les cas de vulnérabilité critique. Le processus va alors suivre une fois de plus un certain nombre d'étapes.



Les 2 premières phases ont lieu le 6 octobre. La vulnérabilité est passée immédiatement au SSIRP, qui se met au travail.

La phase d'évaluation s'établit entre le 6 et le 10 octobre. Les équipes produits commencent leur investigation, et des tests de variantes et de contournement de la vulnérabilité, comme expliqué plus haut dans le processus habituel de la MSRC, ont lieu. Le 10 octobre, il est décidé d'inclure la correction de la vulnérabilité dans le patch Tuesday du mois de novembre 2008.

Les événements prennent néanmoins un autre tournant le 17 octobre, pendant la phase de stabilisation. Plusieurs rapports montrent ainsi une menace grandissante. Suite à des tests de qualité estimés positifs par Microsoft, il est donc décidé entre le 21 et le 22 octobre de sortir le correctif du patch Tuesday, qui a lieu tous les 2e mardis du mois, et de le publier le 23 octobre 2008.

En analysant la séquence des événements décrite par Mike Reavey, il est intéressant de constater que Microsoft aura été particulièrement réactif sur la correction de la vulnérabilité, et Mike Reavey de noter qu'elle ne touchait ni Windows Vista, ni Windows Server 2008 (Windows 7 n'étant pas encore disponible à l'époque).

Néanmoins, cette réactivité n'a pas empêché Conficker de faire des dégâts ! La raison ? Le talon d'Achille du modèle de sécurité de Microsoft : l'utilisation encore très répandue d'anciennes versions de Windows, et le réflexe de mise à jour encore loin d'être généralisé chez les utilisateurs.

Windows XP et les mises à jour : le talon d'Achille de Microsoft

Comme c'est le cas du côté des navigateurs web avec Internet Explorer 6, Microsoft a eu beaucoup de mal à faire évoluer sa base d'utilisateurs vers la dernière version de Windows. En parcourant le Security Intelligence Report volume 10 de Microsoft, qui couvre la période de juillet à décembre 2010, on s'aperçoit que la plupart des vulnérabilités exploitées sous Windows pendant cette période touchent surtout Windows XP et son pendant 2003 Server. Une exception notable : la fameuse CVE 2010-2568, exploitée par Stuxnet, qui a impacté toutes les versions de Windows. Aujourd'hui, Windows XP est toujours largement utilisé : deux ans après sa sortie, Windows 7 vient à peine de le supplanter dans le monde.



Néanmoins, même en considérant l'obsolescence des différentes versions de Windows, le problème se pose toujours. D'une part, on a vu avec le cas de Conficker évoqué par Microsoft, que la mise à jour, même pour Windows XP, était disponible rapidement. D'autre part, même sur des versions récentes du système, on découvre toujours de nouvelles vulnérabilités... Quand celles-ci ne sont pas le fait de logiciels provenant d'éditeurs autres que Microsoft ! D'où le principal problème : il ne suffit pas de publier des mises à jour de sécurité, encore faut-il que les utilisateurs les appliquent.

Microsoft admet elle même cette faille dans son tout dernier SIR, le volume 11 paru le 11 octobre 2011. Une des principales conclusions de Microsoft sur ce rapport : de nombreuses attaques sont dues à des systèmes non mis à jour. Ainsi, on note par exemple une résurgence des attaques exploitant la vulnérabilité CVE 2010-2568 au cours des deux premiers trimestres 2011, qui repassent même devant les attaques ciblant HTML et Javascript, alors que le rapport précédent montrait un net écart entre les deux. On rappelle que cette vulnérabilité a été corrigée depuis quelques mois déjà. En observant les chiffres de répartition des types d'attaques détectées par l'Outil de Suppression des Logiciels Malveillants, on constate que les menaces de type « 0 day » sont littéralement inexistantes sur la période analysée... Mais aussi que plus la faille est ancienne, plus le nombre d'attaques détectées est élevé !

Les logiciels tiers ne sont pas épargnés

Une autre tendance, également à double tranchant : la répartition entre les attaques ciblant le système d'exploitation et les attaques ciblant les logiciels tiers. Pour Microsoft, c'est une bonne nouvelle : l'éditeur peut se targuer de garder ces attaques à un niveau relativement bas. Plus haut que les attaques ciblant les documents (Office, Adobe Reader...) ou le plug-in Flash, mais nettement inférieur aux attaques ciblant Java. Néanmoins, les logiciels tels qu'Adobe Reader, Flash Player et surtout Java, qui reste le « champion » sur les deux dernières éditions, continuent à voir leurs vulnérabilités exploitées.



Là encore, on peut citer l'absence de mise à jour côté utilisateur pour expliquer en partie ce phénomène. Prenons le cas intéressant d'Adobe Reader. Intéressant, car Adobe est un des partenaires de Microsoft à avoir appliqué sa propre implémentation du SDL pour ses développements, avec en ligne de mire la correction des problèmes de sécurité touchant Flash et Adobe Reader, et notamment une source de vulnérabilité d'Adobe Reader : sa faculté à exécuter du code Javascript au sein d'un document PDF, utilisée à des fins néfastes par de nombreuses menaces.

L'application du SDL a notamment abouti à la sortie d'Adobe Reader X, une version nettement plus sécurisée du lecteur, utilisant un système de bac à sable, pour prévenir l'exécution de code directement dans le système d'exploitation ainsi qu'une liste noire de fonctions Javascript. Brad Arkin, Directeur Senior de la Sécurité et de la Vie Privée chez Adobe, se félicite des résultats de cette politique : « Depuis la sortie d'Adobe Reader X en novembre 2010, nous n'avons constaté aucune nouvelle exploitation de vulnérabilité dans le lecteur. Le mode protégé d'Adobe Reader X n'est sans doute pas parfait, mais il semble suffisamment efficace pour décourager les auteurs de logiciels malveillants »



Pourtant, les deux dernières éditions du SIR montrent une nette « domination » d'Adobe Reader en ce qui concerne les attaques ciblant les documents, loin devant Microsoft Office (on pourra bien sur prétexter que ces chiffres sont fournis par Microsoft...). Elles ont même progressé entre le 3e trimestre 2010 et le 2e trimestre 2011, après une baisse au 4e trimestre 2010 (trimestre qui a vu la sortie d'Adobe Reader X), pour atteindre un niveau supérieur au niveau initial.



La question cruciale est donc la suivante : les utilisateurs mettent-ils régulièrement à jour ces logiciels tiers ? Pour Java, par exemple, la vulnérabilité la plus utilisée ces derniers mois cible la version 5.0 update 23, et la version 6.0 update 18, alors que la dernière mise à jour pour la version 6 est l'update 29 à l'heure où nous écrivons ces lignes ! Lors de la présentation du SIR volume 11, Tim Rains, un des directeurs de la section Trustworthy Computing confirme cette tendance : « Certaines de ces vulnérabilités remontent à 2008, et ont été patchées à l'époque par Sun. Lorsque des auteurs de logiciels malveillants découvrent une vulnérabilité, ils vont essayer de l'exploiter sans cesse, afin de toucher des systèmes qui n'ont pas été corrigés ». Tim Rains fait le même constat concernant les vulnérabilités de Windows ou de Microsoft Office, et incite les utilisateurs à utiliser Microsoft Update plutôt que Windows Update sous Windows XP, afin de mettre à jour simultanément Office et Windows. Sous Windows Vista et 7, bien entendu, le processus est automatisé.



A cela, on peut imaginer qu'un autre facteur vient s'ajouter : la confusion entre ce que l'utilisateur assimile comme faisant partie intégrante de Windows et les applications provenant d'éditeurs tiers. Ainsi, même si un utilisateur lambda a effectivement activé les mises à jour automatiques de Windows Update, ce processus ne couvrira pas des applications tierces, puisque dans le meilleur des cas limité aux logiciels Microsoft extérieurs à Windows. Il se sentira donc à jour, mais ne le sera pas.

Il y a donc là un vrai travail d'éducation à effectuer auprès des utilisateurs, un message martelé lors de la présentation des conclusions du SIR volume 11. Néanmoins, on peut se demander si cet effort est réellement suffisant, et peut être tirer des leçons d'autres modèles en train de se dessiner dans le paysage des logiciels et OS.

Sécurisation de Windows : quelques pistes ?

On l'a vu, les efforts de Microsoft concernant le SDL pour le développement du système, et sur la réactivité des équipes MSRC pour la publication de patches, ont permis de rendre le système plus sûr, « out of the box ». Un autre enseignement des derniers rapports de Microsoft montrent clairement que plus le système est récent, moins le taux d'infection est élevé, et Microsoft de se féliciter également des résultats positifs d'un patch publié en février 2011, qui désactive enfin par défaut l'autorun, à la source de nombreuses infections.

Néanmoins, on voit bien que malgré tout, la situation reste imparfaite : Windows XP est toujours largement utilisé, les utilisateurs ne sont pas forcément tous passés au SP3 qui est le seul à être encore pris en charge officiellement par Microsoft, et même sur des versions plus récentes de Windows, les réflexes de mise à jour ne sont pas automatiques, loin de là.

Les recommandations de Microsoft sur la nécessité de maintenir son système à jour tombent sous le sens, mais les éditeurs ne portent-ils pas une part de responsabilité dans cette mauvaise volonté de la part des utilisateurs ? S'ils rechignent à mettre à jour des composants comme Flash, Adobe Reader ou Java, c'est peut-être parce qu'ils considèrent le processus de mise à jour comme une mauvaise expérience. Vous avez sans doute déjà été agacé plus d'une fois par une alerte de mise à jour Java ou Flash, et quel sera votre premier réflexe ? Peut être d'effectuer la mise à jour en geek averti que vous êtes, mais il n'est pas fou de penser que l'utilisateur lambda cherchera avant tout à se débarrasser de l'alerte pour aller à son but. Dans le cas d'une mise à jour, la sécurisation n'est pas le but recherché : cette alerte est inattendue, et interrompt l'utilisateur dans son travail, donc on peut imaginer que le réflexe sera de remettre cette mise à jour à plus tard.



Une solution peut donc être de rendre ces mises à jour plus transparentes pour l'utilisateur. Dans ce domaine, il faut admettre que Microsoft a su se montrer relativement efficace : une fois les mises à jour automatiques configurées, le processus est relativement transparent. Adobe affirme à ce sujet avoir amélioré cette situation ces dernières années : à travers son implémentation du SDL, l'éditeur a pu intégrer, selon Brad Arkin, plusieurs améliorations, notamment pour Adobe Reader qui active par défaut les mises à jour automatiques sous Windows, et bénéficie d'un cycle trimestriel de mises à jour de sécurité, calqué sur le modèle du Patch Tuesday (avec un rythme tout de même nettement moins soutenu). Flash Player et Adobe Reader sont en outre compatibles avec les technologies System Center Configuration Manager et System Center Update Publisher de Microsoft pour le déploiement en entreprise.

Néanmoins, d'autres exemples encore plus radicaux, pour le grand public notamment, peuvent faire école. Google Chrome en est un : le navigateur se met à jour de manière complètement silencieuse, et l'utilisateur n'a jamais à s'en soucier, ni même à redémarrer quoi que ce soit : son logiciel est toujours à jour ! D'un autre côté, cette approche a de quoi surprendre un utilisateur qui souhaite savoir ce qui se passe sur son système...

Ecosystèmes fermés : mises à jour centralisées... et logiciels plus surs ?

Une autre piste est naturellement à voir du côté des écosystèmes fermés comme iOS, ou même simplement centralisés comme Android et son Market, qui n'est pas le seul moyen d'obtenir des logiciels, mais de loin le mieux intégré au système. Une des forces de ces plateformes est de proposer une source centrale de distribution des logiciels, avec à la clé une gestion centralisée des mises à jour. L'OS et les applications, même tierces, passent donc tous par le même processus, qui passe même souvent par une installation automatique en un clic.



Un modèle fermé comme celui de l'App Store d'Apple, même s'il souffre de limites parfois contraignantes pour les développeurs, a au moins un avantage au niveau de la sécurité. En interdisant la publication d'application utilisant des API privées, et en obligeant les développeurs à placer leurs applications dans un bac à sable, afin d'éviter toute interaction directe avec l'OS, on est sûr que l'utilisateur ne téléchargera pas d'application mettant en péril la sécurité du système. Certains spécialistes prédisent qu'Apple imposera à terme les mêmes limitations aux applications du Mac App Store, ou fera même de celui-ci le seul canal de distribution de logiciels pour Mac OS X.

Windows 8 : du changement... du moins sous Metro

D'ailleurs, cette approche fermée et centralisée, Microsoft semble y mettre un pied avec le futur Windows 8. On sait que le prochain système de Microsoft proposera une interface tactile, le fameux Metro, et un accès au bureau et aux applications Windows « traditionnelles ». De ce côté, rien ne devrait changer. En revanche, il y a fort à parier que Microsoft essayera de pousser Metro sur tous les fronts, et dans ce cas, le seul moyen de télécharger des logiciels sera de passer par le Marketplace de Microsoft, et donc pour les développeurs, par la validation des applications. Et parmi les conditions de cette validation, figurera, comme chez Apple, l'utilisation d'une sandbox.



On sait que tous les utilisateurs ne se limiteront pas à Metro. Les « power users » auront forcément besoin de lancer le bureau Windows pour retrouver un système plus conforme à leurs attentes. Mais pour tous les utilisateurs grand public, si Microsoft parvient à éduquer l'utilisateur et à pousser Metro comme la meilleure expérience pour la plupart des tâches, ils se retrouveront alors dans un environnement sécurisé, avec une source d'applications et de mises à jour centralisée, et moins de tentations de compromettre la stabilité et la sécurité de leur système. En outre, sous Metro, Internet Explorer ne prendra tout simplement pas en charge les plug-ins tels que Java ou Flash.

Liberté ou sécurité de l'utilisateur ?

On comprend assez bien en revanche les limites d'une démarche fermée et centralisée : pour l'utilisateur, cela signifie moins de liberté, et la nécessité de passer par un kiosque d'application où tout est validé au préalable, et obéit donc à des règles qui empêchent d'y trouver tout type d'application. Un bon exemple réside dans la situation actuelle du Mac : Apple laisse la porte ouverte aux développeurs, puisque le Mac App Store n'est qu'un des moyens de se procurer des applications. En revanche, passer par le Mac App Store interdit certains types de logiciels tels que ceux qui modifient par exemple l'interface du système. Apple, qui n'est pourtant pas un spécialiste de la rétro compatibilité et de la sauvegarde des habitudes des développeurs, ne peut pas, actuellement, faire ce qu'elle a fait avec iOS, qui fonctionne, car il s'agit d'une nouvelle plateforme. Disons-le clairement, ce serait totalement impensable avec Windows, et c'est une bonne chose, car un ordinateur a besoin d'un système plus ou moins ouvert.

Conclusion

Au terme de ce tour d'horizon de l'initiative Trustworthy Computing, il apparaît que malgré toutes les critiques que l'on a pu faire à Microsoft sur ce sujet dans le passé, les choses ont quand même bien bougé et la sécurité est visiblement prise au sérieux par la firme de Redmond. L'approche de Microsoft et ses 3 piliers semble cohérente : le MSEC intègre la démarche sécurité dans le développement des produits, le MSRC assure le suivi avec une efficacité grandissante, et le MMPC effectue une veille du paysage des logiciels malveillants, tout en proposant aux utilisateurs des outils de sécurité tels que Microsoft Security Essentials, Forefront ou Windows Defender.

Le défi auquel doit faire face Microsoft est de faire en sorte que la démarche ne se brise pas au niveau de l'utilisateur. Et on constate en parcourant les derniers rapports SIR de l'éditeur qu'il s'agit d'un travail plus complexe qu'il en a l'air : nombre d'infections constatées sur les périodes étudiées exploitent des failles qui ont déjà été corrigées dans Windows, alors que les chiffres portant sur les nouvelles vulnérabilités sont au plus bas. De même, on constate que les anciennes versions de Windows sont nettement plus attaquées que les dernières en date (Windows 7 et 2008 Server R2). Problème : Windows XP est encore largement utilisé et Windows 7 vient à peine de lui passer devant à l'heure où nous écrivons ces lignes. On peut donc en déduire que la situation est en bonne voie, mais elle nous rappelle la difficulté qu'a Microsoft a faire évoluer sa base d'utilisateurs. Windows 7 a réussi là où Windows Vista avait échoué, mais XP va tout de même sur ses 10 ans !

Le problème est compliqué par le fait que si les vulnérabilités touchant directement Windows sont en baisse, les attaques ciblant les vulnérabilités de logiciels tiers tels que Java ou Adobe Reader, elles, ont toujours le vent en poupe. Là encore, il s'agit souvent d'anciennes vulnérabilités, corrigées par les éditeurs, et les attaques trouvent donc leur cible en raison d'un manque de vigilance de l'utilisateur. D'un manque de vigilance ou d'un processus de mise à jour perçu par celui-ci comme une nuisance.

Beaucoup d'inconnues subsistent quant aux évolutions futures de Windows : on sait que les applications Metro seront exclusivement distribuées via un kiosque de téléchargement en ligne, qu'elles seront soumises à une validation de Microsoft, et qu'elles devront passer, à l'image des applications iOS, par des techniques de sandboxing. Néanmoins, ces règles ne s'appliqueront pas, visiblement, aux applications « classiques » qui continueraient donc à nécessiter une attention accrue de la part des utilisateurs. L'équilibre entre la sécurisation du système et la liberté de l'utilisateur sera donc plus que jamais la clé...