Entretien avec Bernard Ourghanlian, CTO de Microsoft France, sur la sécurité
Depuis les crises de sécurité du début des années 2000, le nombre d’alertes de sécurité liées aux logiciels Microsoft a connue une décrue sensible au point que Windows apparaît désormais comme mieux protégé que d’autres systèmes. Pouvez-vous expliquer les changements qui ont suivi le lancement de « Trustworthy Computing » ?
Bernard Ourghanlian : Pour aborder la question de la sécurité, il est nécessaire de se rappeler d’où l’on vient. On vient d’un environnement où la sécurité n’était pas une priorité majeure de Microsoft. Vous avez fait allusion au lancement par Bill Gates de l’initiative « informatique de confiance » qui remonte au 15 Janvier 2002. On en est maintenant au-delà de la cinquième année sur ce sujet et il est indéniable que cette initiative a eu un impact assez profond, à la fois sur la façon dont Microsoft développe ses produits et, au-delà, sur la culture de l’entreprise. Si je ne retenais qu’un aspect de la chose ce serait probablement celui là.
Je pense que ces remises en question ont fait beaucoup de bien à Microsoft par rapport à un certain nombre de sujets sur lesquels je reviendrai. Cela nous a un peu appris l’humilité, ce qui ne fait jamais de mal. L’histoire retiendra que cette initiative a été lancée essentiellement à la suite d’un certain nombre de grandes catastrophes à l’échelle de l’Internet qui portaient le nom de Nimda ou de Code Red. Ces crises font partie des claques qu’il faut se prendre de temps en temps pour comprendre qu’il y a des choses qui ne vont pas et qu’il est nécessaire de les corriger. Si l’on essaye de voir ce que l’initiative de confiance a eu comme impact, il faut rappeler son ambition initiale et, pour être très franc, on est encore très loin de la réalisation de cette ambition. L’ambition annoncée visait à faire de l’informatique quelque chose d’aussi simple à utiliser que peut l’être l’eau, le gaz, l’électricité dans nos vies quotidiennes. Cette initiative reposait sur quatre piliers qui sont respectivement la sécurité, le respect de la vie privée, la fiabilité du système et d’une façon générale la qualité des relations commerciales que peut avoir Microsoft et ses clients, ses partenaires et son écosystème.
Il y a certainement eu des progrès sur chacun de ces domaines et il est probable que le pilier qui s’est le plus développé c’est celui de la sécurité, mais ce n’est pas pour autant les autres piliers ont été ignorés. En ce qui concerne le respect de la vie privée, il s’agit d’un élément essentiel et fondamental à la confiance sur Internet. Si on ne respecte pas la confidentialité des échanges …
Comme dans la lecture des emails ?
BO : Oui, c’est un sujet sur lequel il y a beaucoup de tiraillements. Si on fait un aparté sur cette question, on se rend compte que le marché de la publicité en ligne se définit comme un marché sur lequel on échange une partie de sa privée contre l’accès à des services plus ou moins gratuits. Donc, quand on regarde le modèle économique sur lequel sont fondés aussi bien « Live » chez Microsoft que Google dans leurs approches, ce modèle, tous ces modèles sont fondés sur cet échange. Je dirais que ce modèle est poussé à l’extrême sur des réseaux sociaux comme Facebook où on va mettre en ligne une série d’informations personnelles comme son CV, ses goûts qui vont permettre d’enrichir son réseau d’amis et on le fait dans un contexte où, que l’on le veuille ou non, on échange un morceau de soi.
Ce qui est problématique sur un plan sociétal, c’est que les termes de cet échange aujourd’hui ne sont pas clairs. Autrement dit, on échange quelque chose mais on ne sait pas très bien comment ce quelque chose sera utilisé dans le futur. Dans un monde où tout serait parfait, toutes les intentions seraient louables, cela ne poserait pas de problèmes. Dans un monde un peu plus complexe, où il y aurait une version plus policière de la réalité, plus proche de 1984, on pourrait se poser des questions très sérieuses. Ce qui est compliqué sur Internet c’est que potentiellement à travers sa vie numérique on accède à l’éternité, au sens où l’on existe toujours de manière électronique mille ans après sa mort, en raison des traces numériques que l’on a laissé. La question qui se pose par rapport à ça est simple : comment faire disparaître une trace en tant qu’auteur, comment détruire son manuscrit en tant que personne qui a eu un passé trotskiste ou à l’inverse plutôt fasciste (pour prendre deux exemples extrêmes et bien connus du monde politique) et qui s’est repentie ? Ce qui est difficile sur Internet, c’est le remords.
Ce qui, à mon sens, pose problème c’est qu’à partir du moment où on a mis en ligne une information, celle-ci peut nous suivre, suivre nos enfants, nos petits enfants et, en fait, rester gravée pour l’éternité. Ce qui normalement devrait être du ressort de la vie privée, c’est-à-dire la possibilité à tout instant de pouvoir accéder à des informations sur soi, d’avoir le droit à un retrait, n’existe pas de facto sur l’Internet. Je pense que c’est un sujet de réflexion à part entière sur lequel tous les acteurs ont encore besoin de mûrir.
Je pense que paradoxalement le onze septembre a eu un effet extrêmement significatif sur un certain nombre de pratiques en permettant de formuler l’informulé. A savoir qu’à partir du moment où on a eu peur et où règne encore une part importante d’anxiété, on a de facto accepté pour améliorer notre sécurité de renoncer à une partie de notre vie privée. Quand on accepte de transférer aux Etats Unis, parce que c’est rendu obligatoire par la législation américaine, les informations sur les passagers qui embarquent sur des vols transatlantiques, on réalise quelque chose qui n’aurait pas été envisageable avant le onze septembre.
Est-ce une évolution positive ?
BO : Je ne suis pas sûr que ce soit une évolution positive, je dis simplement qu’il y a un lien entre le fait d’avoir peur et d’accepter, de facto, de sacrifier une partie de sa privée parce que l’on a l’impression que cela va permettre de mieux se protéger. A partir de ce moment là, la dérive vers des exploitations marchandes et commerciales de sa privée est assez naturelle. Or, chacun a le droit à son intimité et au respect de sa vie privée. Je me pose même la question – politiquement incorrecte s’il en est – de savoir si les succès commerciaux de Google ou d’autres Facebook ne sont pas dus, indirectement, au 11 septembre, puisque ce bien triste événement nous a conduit à céder à peu de frais une part de notre vie privée en échange d’un monde plus sûr (ou soi-disant tel).
Pour en revenir à l’initiative de confiance, on a également travaillé sur les aspects liés à la fiabilité des systèmes et notamment au sein de Windows Vista …
Sur Dynamic Systems Initiative (DSI)
BO : Oui mais pas seulement. On a travaillé par exemple sur un Framework de développement de drivers pour lequel on a fait appel pour la première fois aux preuves formelles afin d’en démontrer mathématiquement la robustesse. Ce sont des progrès assez significatifs qui vont dans la direction de l’amélioration de la fiabilité des systèmes, surtout quand on considère les statistiques dont on dispose sur les crashs enregistrés notamment sur Windows XP puisque probablement entre 70 et 75 % de ces crashs sont liés à des problèmes de drivers.
Même chose sur les relations apaisées que l’on cherche à établir avec nos partenaires et nos clients. Les démarches que l’on a eues sur l’interopérabilité vont ainsi dans cette même direction.
D’une façon générale, ces quatre piliers ont eu pour Microsoft des impacts extrêmement importants. Cela ne veut pas dire que les choses se sont passées du jour au lendemain, ou non plus qu’il ne reste rien à faire. On dit très souvent que « la sécurité est un voyage, pas une destination » et je pense que quels que soient les progrès que l’on pourra faire dans ce domaine, quelles que soient les avancées technologiques que l’on pourra faire, il faudra toujours se préoccuper du fait que la sécurité parfaite n’existe pas et se souvenir que la sécurité ce n’est pas que de la technologie. Comme beaucoup de choses en informatique, la sécurité est un triptyque dans lequel on trouve à la fois de la technologie, des processus et des femmes et des hommes. Tant que l’on pourra exploiter la crédulité des gens, même si on a des supers moyens informatiques derrière, on arrivera toujours à perturber et induire en erreur un utilisateur qui sera trop crédule et qui sera tombé dans une arnaque trop bien faite.
Si on regarde ce que l’on a fait depuis 2002, l’élément le plus important en ce qui nous concerne, c’est certainement la refonte de nos procédés de développement. Un mois après le lancement de cette initiative pour l’informatique de confiance par Bill Gates, Microsoft a pris la décision d’arrêter tous les développements en cours parce qu’on s’est rendu compte, en considérant la racine du mal, que nos développeurs ne savaient tout simplement pas écrire du code sécurisé. Et la raison pour laquelle ils ne savaient pas, c’est tout simplement qu’on ne leur avait jamais appris. Quand je dis on, c’est au sens collectif du terme car, écrire du code sécurisé, c’est quelque chose qui nécessite à la fois de la théorie et de la pratique et que cela n’est pas enseigné dans les universités, les établissements scientifiques, et c’est encore le cas très largement aujourd’hui.
Nous avons pris la décision de monter des formations en urgence qui nous ont servies à reformer pendant un mois et demi tous nos développeurs, ce que l’on a fait au début de l’année 2002 et ce qui a eu pour conséquence d’arrêter tous les développements en cours, notamment celui de Windows 2003. Petit à petit les choses se sont structurées. On a mis une année pour mettre en place un nouveau processus de développement mais également un certain nombre de mesures permettant en interne de faire en sorte que ces processus soient d’un usage obligatoire, c’est-à-dire qu’ils puissent donner lieu à un certain nombre de dispositifs d’incitation et de sanctions où l’on va mesurer les développeurs sur des critères qui sont liés à la présence ou à l’absence de bugs de sécurité dans le logiciel qu’ils développent
Un des éléments qui a été mis en place c’est une systématisation de la formation. Chaque développeur, lors de son entrée chez Microsoft, a cinq semaines obligatoires de formation. Chaque année, tout développeur à une « piqûre de rappel », qui peut durer une semaine, lui permettant de se mettre à jour à la fois sur l’évolution de la méthodologie qui s’appelle aujourd’hui SDL (Security Development Lifecycle) et, en même temps, sur l’évolution des menaces.
C’est probablement l’élément le plus important qui a affecté en profondeur ce que l’on pourrait appeler « l’usine de fabrication » des logiciels de Microsoft. On a refondu le développement sur la « chaîne d’assemblage » pour faire en sorte que ce nouveau processus SDL soit utilisé en permanence sur tous nos nouveaux développements logiciels. Quand on conçoit un logiciel, on va passer par un certain nombre d’étapes obligatoires où la sécurité n’est plus simplement quelque chose que l’on rajoute à posteriori, un peu comme à regret, comme cela se pratiquait de manière courante dans le passé. On va intégrer dans toutes ces étapes la sécurité comme composante intégrale et obligatoire du processus de développement lui-même. La conséquence en est que, lors la phase de conception, on va systématiquement planifier le temps que représentent les étapes de sécurité pour ne pas être dans le mode encore classique aujourd’hui qui consiste à dire : « j’ai un plan défini mais j’ai oublié de mettre la sécurité dedans et je n’ai pas pris en compte qu’écrire du logiciel sécurisé ça prend plus de temps ». A partir de là mon planning va déborder et cela veut dire sortir le logiciel en retard, se faire taper sur les doigts parce que les objectifs ne sont pas atteints, …
On a injecté de façon formelle dans ce processus, de manière systématique lors de la phase de conception, une obligation de réaliser une modélisation des menaces. Cette modélisation est institutionnalisée. On a développé des outils permettent d’aider à représenter ces menaces, ces outils sont d’ailleurs utilisables sur Internet en libre disposition. L’idée de cette modélisation des menaces c’est d’identifier sur tous les modules logiciels les sources potentielles de danger et de voir comment le design de ces composants va être affecté pour parer ces menaces.
Ces menaces peuvent découler du fait que l’utilisateur va saisir des informations qui ne sont pas nécessairement correctes. Il s’agit d’une erreur commune dans les bugs de sécurité. Par exemple, on demande à l’utilisateur de rentrer son âge et on considère à priori que cela ne sera pas sur 3 digits ou plus, par ce que personne ne vit si longtemps. Mais si l’utilisateur a envie de rentrer 9999 et au-delà et que l’application n’a pas été écrite pour absorber cette information, cela peut potentiellement engendrer dans le cas présent un dépassement du format des entiers, provoquer une exception dans l’application qui sera ensuite utilisée par du code malfaisant. Ça veut dire que, quels que soient les domaines, en input ou en output, il faut être capable de modéliser toutes les menaces associées. Une fois que cela est fait, on va renseigner une base de données qui va suivre l’évolution de ces composants logiciels pendant toute leur vie : pendant la phase de conception, de développement, de test, de bêta, de support, …
Il va falloir s’assurer que lorsque l’on fait des modifications, que l’on apporte des éléments nouveaux dans la brique logicielle on s’assure que les menaces identifiées au départ restent pertinentes.
L’intérêt de ce dispositif c’est de réaliser une traçabilité à la fois en terme de qualité de développement pour s’assurer que les personnes qui ont pensé au module en question ont bien recensé tous les problèmes potentiels qui pourraient s’appliquer, mais également qu’ils ont fait tout ce qui était dans leur pouvoir en matière de programmation pour qu’au moins les principes de précaution élémentaires soient respectés. Par exemple, quand une application lit un format de document, il faut partir du principe que le format peut avoir été « bidouillé » de telle sorte que le logiciel qui va lire ce document provoque une défaillance. Un des phénomènes que l’on a observé au cours des derniers mois est qu’il y a une augmentation considérable des failles de sécurité, non plus au niveau du système d’exploitation, mais au niveau des applications. Ceci découle probablement des avancées en matière de sécurité apportées par Vista ou le service pack 2 de Windows XP qui font que le système en tant que tel est mieux protégé et que les attaques se portent au dessus, sur les éléments les moins sécurisés. Office a ainsi été énormément attaqué ces derniers temps, à travers des technologies qui commencent à se démocratiser, qui portent le nom de « file fuzzing » et qui ont pour objet de bidouiller, de bricoler tout ce qu’il est possible de faire sur un format de fichier donné afin d’essayer de faire apparaître des erreurs dans le logiciel utilisé pour lire ce format de fichier. On a vu des problèmes sur les formats d’Office, sur le format Flash, sur les fichiers aux formats PDF, Real Audio,… Ces formats, pour la plupart d’entre eux ont été conçus il y a longtemps, avant la généralisation de l’Internet. La dernière modification importante des formats binaires d’Office remonte à 1997 et, à cette époque, Internet tel qu’on l’imagine aujourd’hui avec ses usages courants n’existait absolument pas et personne n’imaginait qu’il puisse y a voir quelqu’un qui puisse avoir envie de bidouiller un format de fichier binaire pour lui faire faire des choses douteuses.
C’est une illustration du fait que l’on a mieux sécurisé la plateforme, mais en même temps qu’il faut en permanence remettre l’ouvrage sur le métier et que l’attitude qui consiste à ne jamais croire ce que l’utilisateur nous fournit (comme information, comme fichier,…) est un comportement de programmation défensif que tout développeur doit avoir.
Pour en revenir à SDL, à combien peut-on estimer l’overhead associé à ce processus ?
BO : C’est probablement autour de 10 et 15 %, ce qui est assez considérable quand on l’applique à des milliers de développeurs. Cela a même été plus que ça dans les phases de démarrage.
Dans les mesures que l’on a incorporées de manière native dans SDL figure toute une série d’étapes qui sont obligatoires dans le cycle de vie du logiciel. Par exemple, le fait de dire que juste avant de livrer la première version bêta du logiciel, on a l’obligation de passer par une première phase d’audit qui va être réalisée par une autre équipe. On va faire une revue de code croisée entre deux équipes, on va utiliser les services d’auditeurs extérieurs pour relire le code. On va faire appel à des « chercheurs en sécurité » ou « hackers éthiques » car on ne fait pas appel à des « brigands ».
De la même façon, il y a un certain nombre de pratiques que l’on réprouve de manière extrêmement ferme. On ne va pas, par exemple, aller chercher à acheter des vulnérabilités. J’ai à plusieurs reprises été approché par des individus qui prétendaient avoir découvert une faille de vulnérabilité dans nos produits et qui menaçaient de la rendre publique si nous n’acceptions pas de régler une somme déterminée. A partir du moment où l’on rentre dans ce genre de logique, cela devient extrêmement problématique. J’en veux pour preuve ce qui c’est passé il y a à peu près deux ans au niveau de la plupart des casinos en ligne en Angleterre qui ont été attaqués en déni de service par des truands qui ont fait tomber leurs sites et qui leur ont dit : « si vous voulez être protégés sur Internet, voilà combien ça va vous coûter ». Un certain nombre d’entre eux ont payé et maintenant c’est devenu une véritable plaie pour tous les casinos en ligne d’une façon générale. Une des grandes évolutions que l’on a constaté ces dernières années c’est que l’on est passé de menaces qui provenaient pour simplifier, d’adolescents boutonneux en mal d’ego qui diffusaient des virus ou des vers ayant pour objet de rendre pénible la vie des utilisateurs, à un mode professionnel, criminel où l’objectif essentiel est de faire de l’argent. Dans ce mode, les profils d’attaque sont différents. On n’a plus les phénomènes viraux que l’on a connus avec Blaster, Sasser, I love you, …. On n’a plus de médiatisation sur ces phénomènes qui esquintaient des millions d’ordinateurs dans le monde. On a des attaques beaucoup plus ciblées dont l’objectif est le vol d’identité, le déni de service, l’arnaque, le craquage de clés de chiffrement, le vol de logiciels, … Ce genre d’attaques a pour finalité de faire de l’argent d’une façon ou d’une autre. Ce phénomène est très peu médiatisé car ces attaques portent sur des sociétés, des marques plus que sur des milliers de machines anonymes (même si ce sont des milliers de machines anonymes qui participent souvent, à leur insu, à ce genre d’attaque)
A l’échelle de l’Internet il faut comprendre qu’il y a une continuité qui va de l’entreprise au particulier, la raison en étant que la plupart de ces attaques aujourd’hui sont le fait de machines zombies, regroupées au sein de Botnets, qui sont des machines usurpées, qui de facto n’appartiennent plus à leurs propriétaires même si ceux-ci l’ignorent. On fédère ainsi des dizaines, des centaines de milliers de machines de ce genre et le « berger » du Botnet, selon une expression somme toute assez poétique, va pouvoir contrôler et fédérer l’ensemble de ces ordinateurs pour, par exemple, provoquer une attaque de type déni de service. La capacité de mobilisation des Botnets est absolument gigantesque parce que cela prend en compte tellement de machines qu’aujourd’hui on a la possibilité de faire tomber tout réseau qui ne se serait pas très bien préparé à cette éventualité. C’est la raison pour laquelle depuis quelques années nous avons mis sur pied une « Botnet Taskforce », dont une réunion se tiendra d’ailleurs d’ici peu dans les locaux d’Interpol en France. Régulièrement nous avons des échanges avec les forces de police et de gendarmerie partout dans le monde pour définir des moyens de lutte contre ce phénomène sachant que, de notre côté, on cartographie les Botnets à l’échelle de l’Internet. On essaye d’avoir une vision la plus exhaustive possible.
A combien de machines peut-on estimer le nombre de zombies ?
BO : C’est assez difficile à dire mais, à travers des statistiques comme celles que nous remontent chaque mois les outils d’analyse et d’éradication de logiciels malveillants dans Windows, on a une idée sur le nombre de PC infectés par telle ou telle classe de malwares, par pays, en se fondant sur l’adresse IP (cf. http://www.microsoft.com/downloads/details.aspx?familyid=4EDE2572-1D39-46EA-94C6-4851750A2CB0&displaylang=en).
Quand on regarde la France, par rapport aux pays de la zone EMEA (Europe Middle East and Africa), celle-ci représente une population de PC normalisée de 2,5 % infectés. On ne dispose pas de ce type de données sur les PC en entreprise puisque les données y sont filtrées. Dans d’autres pays, en Allemagne la proportion tombe à 1,4 %, l’Angleterre est à 1,8 %. Les seuls pays qui sont moins bons que la France aujourd’hui, parmi les grands pays européens, sont le Portugal et l’Espagne. L’Italie est à 1,1 %. Dans certaines régions comme l’Amérique latine ou certains pays d’au-delà feu le rideau de fer, c’est pire, plutôt aux alentours de 7 à 8 %. Un rapport réalisé sur la base de ces analyses montre d’ailleurs une corrélation très nette entre le niveau de développement de ces pays et le pourcentage de machines infectées. Cela prouve simplement que la pédagogie joue un rôle fondamental et c’est la raison pour laquelle nous avons toujours essayé de faire progresser les choses dans ce domaine, même si nous avons conscience de l’immensité de la tâche, par exemple en animant deux années de suite une semaine nationale de la sécurité informatique aux côtés de nombreux partenaires ou bien en contribuant au lancement du site http://www.protegetonordi.com.
Pour en revenir à mon point d’origine, il y a un lien incontournable entre la sécurité de l’Internet au sens « utilisateur à la maison » et la sécurité en entreprise. Ainsi, si à la maison, les utilisateurs ne sont pas correctement protégés, leurs machines deviendront des zombies et ces machines seront, à leur tour, utilisées pour attaquer les serveurs des entreprises. Ce phénomène milite pour l’établissement de partenariats avec des acteurs comme les forces de police mais également avec l’éducation nationale pour aller former les futurs utilisateurs dans les écoles.
Il y a également d’autres phénomènes pénibles comme le spam dont on peut considérer qu’il représente aujourd’hui 90 % du trafic de messagerie sur Internet. Sur Hotmail on doit filtrer aux alentours de 2,5 milliards de spam par jour. C’est absolument démentiel et c’est un phénomène contre lequel il est difficile de lutter car l’Internet a été conçu pour « un monde ouvert ». SMTP en tant que protocole est hélas une catastrophe absolue dans ce domaine. N’importe qui peut forger des messages pour le compte d’un utilisateur ou d’un nom de domaine sans aucune difficulté et c’est la raison pour laquelle nous avons fait une proposition sur ce sujet qui porte le nom de SenderID à l’IETF, proposition d’ailleurs finalement adoptée avec un statut de RFC expérimental. Pour l’implémenter il suffit d’aller modifier les enregistrements DNS sur les serveurs de messagerie concernés, cela ne nécessite donc pas d’intervention lourde. Il y a aujourd’hui un très large pourcentage des acteurs de l’Internet (13 millions de domaines l’ont adopté, représentant quelques 47 % de tout le trafic email légitime) qui ont déployé ce type de technologie mais beaucoup reste à faire dans ce domaine et il y a encore beaucoup trop de spam.
Pour finir sur le processus SDL, avant de sortir un logiciel, on passe par une étape qui s’appelle FSR pour Final Security Review, qui est une étape de revue obligatoire avant la mise sur le marché. Cette revue est effectuée par une équipe de spécialistes qui ne dépend pas du groupe produit concerné, qui de facto dépend de Bill Gates et qui à la pouvoir de dire que le logiciel n’est pas prêt à être commercialisé si les critères du SDL ne sont pas respectés. Il n’est, par exemple, plus possible de sortir un logiciel qui présente un bug de sécurité critique connu. Cela n’existait pas avant 2002.
Tout ceci a eu un impact sur les équipes de développement mais cela a eu aussi un impact très fort sur les filiales comme la filiale française. Un exemple que je cite volontiers, car très emblématique, est ce qui s’est passé lors de l’apparition de Blaster. Dans cette crise, on avait en France, par rapport à beaucoup d’autres pays, deux avantages. Le premier était qu’on avait pris le soin de recenser tous les RSSI (responsable de la sécurité des systèmes d’information) dans une base de données avec leurs coordonnées. On avait échangé ces informations contre la promesse de les contacter au cas où un problème de sécurité majeur viendrait à se présenter. Cela nous a permis, trois semaines avant l’éclatement de Blaster, de les prévenir. Certains ont choisi de patcher, d’autres ont choisi hélas de ne pas le faire et ils en ont payé le prix de façon extrêmement lourde. L’autre facteur qui nous a avantagés par rapport à d’autres pays, c’est le fait que pendant les vacances 2003 - cela se passait en Août 2003 - les utilisateurs sont rentrés par vagues, week-end après week-end. Et donc, contrairement à ce qui s’est passé en Allemagne où la filiale a reçu 150 000 appels le même jour, on a reçu le premier jour « seulement » 20 000 appels à comparer aux 400 appels que nous recevons en temps normal sur la sécurité par semaine.
Evidemment cela a été une catastrophe absolue, il a fallu monter en urgence un centre d’appels et on avait un tel déficit de capacité de réponse aux utilisateurs qu’on a été obligés de mobiliser tous les employés de Microsoft France. On a eu très peu d’incidents graves en entreprise, la majorité des problèmes se situaient au niveau des particuliers. Le problème c’est que, à la maison, on peut seulement appeler les gens tôt le matin ou tard le soir. On a été obligé de décaler les horaires de nos collaborateurs, cela a été extrêmement pénible. On a, de fait, dû pratiquement cesser les opérations courantes chez Microsoft pendant cinq semaines. J’ai convoqué par exemple tous les ingénieurs commerciaux, les équipes commerciales et je leur ai expliqué qu’ils devaient cesser leurs activités courantes pour assister les clients. Nous avons organisé plusieurs conférences en amphithéâtre pour expliquer à nos employés ce qui se passait et les former à l’assistance qu’ils devraient ensuite fournir à nos clients. Pour les employés de Microsoft qui étaient présents il y a quatre ans, cela a été très formateur. L’avantage c’est que cela a appris à l’ensemble des collaborateurs la gravité du phénomène et que cela pouvait mettre en péril la société. Cela nous a fait perdre beaucoup d’argent. L’impact sur le plan business d’une crise comme celle là est absolument considérable. D’ailleurs avec le recul, si j’avais su, j’aurai alerté la presse et les médias pour les avertir du caractère catastrophique de la situation et de la nécessité de prévenir l’ensemble des utilisateurs à la maison en leur donnant les mesures à prendre. C’est hélas toujours facile de réécrire l’histoire et il est très difficile d’alerter les utilisateurs d’une crise dont on ne connaît pas à l’avance la gravité.
Tout ça pour dire que depuis cette époque la culture de l’entreprise a changé de façon nette. Cela ne s’est pas fait du jour au lendemain. Il faut beaucoup de temps, plusieurs années. SDL lui-même est un processus en développement perpétuel. Nous avons cependant publié le processus pour pouvoir en faire bénéficier nos entreprises clientes. En effet, ce que l’on constate également, c’est que celles-ci sont confrontées aux mêmes problèmes à savoir que les applications qu’ils développent en interne sont susceptibles d’être attaquées de la même façon que les applications commerciales.
Microsoft semble avoir beaucoup progressé dans le domaine de la sécurité et apparaît comme mieux armé que d’autres éditeurs sur ce point
BO : C’est un sujet sur lequel nous avons fait d’incontestables progrès. Je reste cependant modeste pour plusieurs raisons. Si vous vous rappelez du premier opus de la trilogie des films de Spiderman, il y a un passage dans lequel son oncle lui explique en substance « De grands pouvoirs entraînent de grandes responsabilités ». Au-delà de ce changement culturel, nous avons compris que nous avions un rôle particulier sur le marché. A partir du moment où l’on a l’honneur et le privilège d’avoir un pourcentage enviable des parts de marché aussi bien sur les postes de travail que sur les serveurs, si pour une raison ou une autre ces serveurs ou postes de travail cessent de fonctionner, c’est d’une façon générale les systèmes d’information de nos clients qui cessent de fonctionner. Un des éléments sur lesquels nous avons beaucoup travaillé et qui est lié à cette prise de conscience, c’est que lorsqu’on diffuse un patch de façon automatique, ces patchs sont installés sur des dizaines de millions d’ordinateurs dans le monde. Si, pour une raison ou une autre, il y a un problème sur ce patch, c’est pire que le pire des virus. Si on imaginait de mettre à disposition un patch d’Internet Explorer ou de Windows qui ferait qu’un système sur deux ne rebouterait pas, ce serait une catastrophe planétaire.
Microsoft a en effet une responsabilité majeure dans le fait de maintenir la stabilité du système d’information mais dans ces conditions, êtes vous fondés à commercialiser une offre de solutions de sécurité ?
BO : C’est une vaste question qui peut paraître paradoxale parce que l’on peut avoir l’impression d’être « suspecté » de jouer le rôle du pompier pyromane, c’est-à-dire d’être tenté d’entretenir des problèmes dans ses logiciels aux seules fins de pouvoir ensuite vendre les solutions pour réparer les problèmes en question. Derrière cette question subsiste un doute permanent sur la légitimité de Microsoft à commercialiser une offre de sécurité.
Il y a aussi la considération qui consiste à dire : il vaudrait quand même mieux que ce soit des tiers qui soient « plus impartiaux » qui protègent le système. On peut discuter longuement sur ce sujet, de l’intérêt de la diversité biologique au sens où si l’on a des systèmes divers, on ne met pas tous ses œufs dans le même panier, …. Ces arguments ont parfois leur justification et parfois non.
Ce qui est sûr c’est que si on prend typiquement la gamme Forefront, ces produits ont pour fonction de mettre en œuvre certains services comme la protection périmétrique, la protection antivirale des serveurs d’infrastructure tels qu’Exchange, SharePoint, Communications Server et puis la sécurité des extrémités, c’est-à-dire de sécuriser aussi bien le poste de travail que les serveurs en termes de protection anti virus ou anti malware, terme que je n’aime pas beaucoup et que je préfère appeler « logiciel non désiré ». Cette gamme va aussi servir à faire de la sécurité périmétrique, fonction qui est assurée aujourd’hui essentiellement par ISA (Internet Security and Acceleration Server) et IAG (Intelligent Application Gateway) qui jouent le rôle de pare-feux classiques mais disposent également de capacités de filtrage applicatif et de VPN SSL. On va revenir sur le fait que ce modèle de sécurité périmétrique commence, à mon sens, de présenter des limites.
Il n’en reste pas moins qu’aujourd’hui il y a un besoin à la fois technique mais aussi psychologique exprimé par les entreprises. C’est la démarche classique des sociétés qui sont allées sur Internet à la fin des années 90 et qui ont mis en place un pare-feu pour dire : j’ai ici mon système d’information et là, j’ai un mur, ce qui me permet de ne laisser passer que ce j’autorise. C’est vrai que cela a un côté extrêmement rassurant et facile à comprendre. N’importe quel décideur peut comprendre ce modèle qui est celui de la porte blindée. Si je suis derrière, on ne va pas me voler mon coffre fort et le feu qui peut exister à l’extérieur ne rentrera pas chez moi. C’est un modèle qui a extrêmement bien marché puisque c’est la fonctionnalité de sécurité numéro un, en dehors des anti-virus, qui est déployée dans les entreprises.
Comme je viens d’y faire allusion, cette fonction commence pourtant à présenter un certain nombre de signes de faiblesse, pour plusieurs raisons. La première est que l’on a des collaborateurs de plus en plus mobiles, qui vont et viennent de part et d’autre du pare feu et donc, le résultat, c’est que le rôle de bastion infranchissable du pare feu n’existe plus puisque si je me connecte sur Internet, je peux récupérer sur mon portable une « saleté » que je réinjecte bien vivante dans le système d’information. On a eu ce scénario chez un certain nombre de grands clients avec un ver célèbre qui s’appelait Slammer. Cela se passait le week-end et j’ai le souvenir d’avoir été appelé le lundi par le responsable technique d’un compte dont le réseau était complètement par terre. Slammer avait une caractéristique très particulière qui est que c’était un ver de très petite taille qui utilisait à l’époque une vulnérabilité de SQL Server et qui avait pour propriété de n’avoir aucune existence sur le disque dur ; il n‘existait qu’en mémoire. Par contre il se répliquait extrêmement vite et saturait complètement le réseau. Ce qui s’était passé d’ailleurs, c’est qu’à l’échelle de l’Internet, en moins de dix minutes, 90 % des machines qui étaient infectables l’ont été, ce qui est incroyable et qui heureusement n’est jamais arrivé depuis. Ce ver avait donc pour caractéristique de ne pas exister sur le disque dur et la plupart des gens se demandaient comment il est possible qu’à travers son pare-feu dont on avait fermé les bons ports, ce ver est quand même rentré chez soi. En fait, l’interprétation que j’ai donnée après avoir réfléchi un peu, consistait à dire qu’un utilisateur avait récupéré ce ver sur Internet sans s’en apercevoir parce que la machine ne paraissait pas vraiment infectée, en dehors du fait que, petit à petit, le débit réseau s’amenuisait. Cet utilisateur a ensuite hiberné sa machine (il a, en fait, « congelé » son virus) et, au réveil, l’a injecté directement dans le réseau de l’entreprise. Cet exemple montre les limites du pare-feu dans un tel contexte.
Le deuxième élément qui me parait plus intéressant et qui explique les raisons pour lesquelles Microsoft a investi dans l’acquisition d’un certain nombre de solutions de sécurité, et notamment d’IAG, c’est qu’on a une compréhension assez primitive des problématiques de sécurité quand on pense que, si on diminue le nombre de ports ouverts sur son pare feu, on va augmenter sa sécurité.
Aujourd’hui, on a de plus en plus d’applications qui utilisent en tout et pour tout le port 80, en mode service web ou en encapsulant, au dessus d’http, toute une série de protocoles et beaucoup s’imaginent avoir accru leur niveau de sécurité en fermant un grand nombre de ports devenus inutiles. Dans la réalité, toutes les applications maintenant passent par un seul port et il y a donc une vraie nécessité d’avoir une capacité de filtrage applicatif. C’est une capacité que Microsoft a utilisé massivement dans les déploiements d’Exchange et qui consiste à encapsuler RPC dans HTTPS de telle façon que l’on puisse directement faire de l’Outlook classique qui va discuter en utilisant le protocole MAPI en direction d’un serveur Exchange. La sécurité est assurée par un pare-feu qui va savoir analyser le fait que c’est une requête qui vient bien d’Outlook, qu’elle correspond bien au protocole RPC qui correspond lui-même à Exchange et enfin qui va bien s’adresser à un serveur Exchange dont le « global identifier » a été fourni. On va avoir la possibilité de casser le tunnel pour pouvoir authentifier l’utilisateur et ré-encrypter le tunnel derrière. L’intérêt d’IAG et d’une façon générale d’ISA dans ce modèle là c’est que l’on va savoir faire du filtrage applicatif beaucoup plus élaboré. Une des choses qu’offre IAG et qui était un des éléments qui manquait de façon significative dans notre panoplie, c’est de pouvoir faire du VPN SSL, donc de pouvoir publier à travers SSL n’importe quelle application vis-à-vis de l’extérieur et d’avoir la possibilité que s’établisse, de facto, un tunnel entre son client applicatif et son serveur applicatif en sachant que l’on va savoir authentifier correctement l’utilisateur. Le gros intérêt de cette solution c’est finalement de capitaliser sur notre connaissance de nos applications serveurs pour être capables de faire le bon filtrage qui convient pour toutes ces applications. Pourquoi a-t-on sorti un produit comme celui là ? Bien sûr en raison des revenus potentiels de cette solution mais aussi parce qu’il y a un certain nombre d’éléments dans l’état actuel des choses que l’on peut probablement mieux contrôler que d’autres, simplement parce que l’on connait mieux le fonctionnement de nos logiciels et qu’on a la possibilité de mieux les protéger. Cela ne veut pas dire qu’ISA ne fonctionne qu’avec nos logiciels, mais cela signifie que l’on a la possibilité d’aller beaucoup plus loin dans ce que l’on est capable de faire sur des logiciels que l’on maîtrise parfaitement. On se sert ici d’un effet de gamme et c’est la philosophie de Forefront qui est de capitaliser au maximum sur son intégration avec une infrastructure déjà existante.
Pour changer de gamme, mais cela s’applique aussi à ISA et IAG, le fait que l’on sache très facilement casser le tunnel et le recréer après coup découle de l’intégration avec l’Active Directory et de la possibilité de connaître le mot de passe de l’utilisateur en question. Sachant son mot de passe, je vais pouvoir assurer la sécurité à travers une vérification de son hash, chose que je ne saurai pas faire si je n’étais pas nativement intégré avec l’annuaire.
D’une façon générale, toute la gamme Forefront a comme volonté de capitaliser au maximum sur une infrastructure déjà existante, par exemple AD, pour, par exemple, utiliser cet annuaire de façon à publier des politiques de groupe qui correspondent à des politiques de sécurité vers les postes de travail et vers les serveurs. C’est aussi la possibilité de reposer sur le fait que je vais renseigner l’état de la mise à jour de tous mes postes de travail en matière de signature d’anti-virus dans une base de données et que, derrière cette base de données SQL Server, j’ai la possibilité de faire appel à reporting services, qui est intégrée dans SQL Server, pour produire des rapports et générer le tableau de bord à destination du RSSI lui permettant de savoir où il en est en terme de déploiement de signatures d’anti virus. Je peux également faire appel à System Center Configuration Manager pour pousser les mises à jour de signatures ou, à défaut, utiliser WSUS (Windows Server Update Services) dans ce but. D’une façon générale et c’est également la philosophie de l’offre System Center, notre objectif sur ces sujets est de capitaliser au maximum sur une infrastructure que l’on connaît, qui en l’occurrence est la nôtre, pour faire bien ce que l’on sait faire. Administrer un serveur Windows ou administrer un serveur Exchange, il y a de bonnes chances que l’on sache mieux le faire que d’autres. On est en plein dans la logique de l’écosystème, dans la volonté de faire en sorte que nos logiciels soient le mieux intégrés possible entre eux. La philosophie qui consiste à aboutir à un rapprochement de System Center et de Forefront obéit au même principe. L’idée est de dire qu’à terme, je veux avoir une seule console de management qui pourra être opérée par des opérateurs différents qui jouent des rôles différents (administrateur système, réseaux, sécurité). On aura le même environnement, la même interface homme machine, les mêmes évènements, la même façon de procéder, les mêmes processus ITIL en sachant que l’intérêt pour nous c’est de pouvoir fédérer plusieurs modules logiciels dans une même console et, pour les utilisateurs, de leur donner un environnement le plus homogène possible.
C’est un choix qui privilégie la plateforme Windows au sens large et ceci présente l’inconvénient de ne pas couvrir la diversité qui peut exister dans les entreprises. Pour essayer de pallier cette lacune, nous travaillons avec nos partenaires et d’une façon générale nous savons nous intégrer à des Framework de management tels que Tivoli chez IBM, Unicenter chez Computer Associates ou encore OpenView chez HP. L’idée étant d’être capable de dire que je suis capable de remonter des événements, par exemple des événements SNMP, en direction d’un Framework global d’administration de telle façon que je puisse, avec une console d’administration centrale, gérer tous mes évènements en entreprise. Mais si, par contre, j’ai besoin d’entrer dans le détail de ces évènements, si j’ai besoin très précisément de savoir quelle est la cause de mon problème, à ce moment là je suis probablement beaucoup mieux guidé par un logiciel tel que System Center Operation Manager, tout simplement parce que les modèles sous jacents ont été développés conjointement par les équipes d’engineering d’Exchange, de SQL Server, … Donc, quand il s’agit d’analyser des compteurs de performance, des dérapages en termes de seuils sur tel ou tel type d’erreurs, il y a quand même des chances que l’on connaisse mieux le logiciel que tous les fournisseurs extérieurs, ce qui en l’occurrence est normal puisqu’on a mis en production ces logiciels dans l’environnement d’entreprise qu’est Microsoft et donc, la plupart du temps, six à neuf mois avant la sortie du logiciel, on sait déjà comment administrer en production un tel logiciel.
Techniquement ce raisonnement est recevable mais n’avez-vous pas peur qu’il puisse entraîner des reproches d‘hégémonie ?
BO : Bien sûr on peut toujours entrer dans cette logique et c’est la raison pour laquelle je pense qu’à la suite d’un certain nombre d’exigences de la commission européenne, certains protocoles permettant l’interopérabilité avec nos environnements logiciels sont d’un accès beaucoup plus simple pour nos concurrents qu’ils ne l’ont été dans le passé. Ainsi, la commission européenne joue pleinement son rôle de régulateur afin de nous empêcher d’aller trop loin dans cette direction. Ceci étant, quoi qu’on dise et quoi qu’on fasse, on aura toujours « l’avantage » d’avoir écrit le logiciel, de savoir comment il marche et de l’avoir utilisé en production avant tout le monde. Quelle que soit la façon dont on tourne le problème, il est évident que l’on saura toujours mieux manager nos logiciels que ne le sauront les autres. Cela ne veut pas dire que, dans une vision globale, on aura forcément la meilleure solution pour gérer un environnement hétérogène ; par contre pour ce qui est de manager notre plateforme, je pense que cela n’est pas possible pour quelqu’un d’arriver et de dire : « je vais mieux manager cette plateforme que Microsoft ». Un des grands messages autour de DSI (Dynamic Systems Initiative) c’est que l’on s’impose à nous-mêmes le même type de modélisation que l’on propose ensuite à nos clients. Ainsi, quand on a un modèle à définir, on le définit en même temps que le produit. On n’est pas dans un mode de fonctionnement où, de la même façon que pour la sécurité, on développe le modèle après coup. On essaye de faire en sorte que le produit et le modèle de management associé soient développés conjointement et, forcément, cela nous donne un avantage. Ainsi, je pense qu’il est normal qu’IBM soit mieux capable de gérer Websphere ou Oracle ses bases de données ou ses ERP.
C’est donc vrai que ce reproche d’hégémonie pourrait être formulé mais, d’un autre côté, comment pourrait-on l’éviter ?
Vous allez, avec Windows Server 2008, introduire une technologie de sécurité appelée Network Access Protection (NAP) permettant de garantir qu’un poste de travail respecte les politiques de sécurité de l’entreprise avant d’être autorisé à se connecter au réseau. Il existe une offre fonctionnellement proche appelée Network Access Control (NAC) développée par Cisco. Pourquoi choisir NAP plutôt que NAC ?
BO : Pour plusieurs raisons.
Je pense que la raison essentielle c’est que l’objet de NAP est de pouvoir contrôler l’état de santé d’un poste de travail, d’un serveur ou de n’importe quelle composante de l’environnement Windows. On peut considérer qu’avec NAP, c’est une fonction nouvelle qui apparaît et qui repose sur le fait que lorsque l’on va démarrer un poste de travail (ce qui ne veut pas dire simplement le booter), quand on le sort d’hibernation ou quand on le sort de suspension, on va pouvoir préalablement vérifier son état de santé avant de le considérer comme un interlocuteur de confiance. Concrètement, on va avoir la possibilité, préalablement à l’attribution d’une adresse réseau « définitive », de pouvoir être tout d’abord placé dans une zone de quarantaine depuis laquelle on va savoir présenter un état de santé qui consiste à dire, par rapport aux exigences des politiques de sécurité qui ont été définies, je remonte ma signature d’anti virus, je signale que j’ai un pare-feu actif, que mon logiciel système est à telle ou telle version et ceci, quel que soit mon mode de connexion, réseau physique filaire ou réseau sans fil ou connexion à distance de type RAS par exemple. Je vais présenter cela comme un certificat de santé et interroger le moyen qui va me permettre d’accéder au réseau, comme un serveur DHCP, un serveur 802.x, ou un serveur IPsec.
Dans tous les cas, je vais demander si je suis autorisé ou pas à pénétrer le réseau. Derrière je vais pouvoir interroger mon serveur de politique de sécurité qui va me dire, soit c’est OK, vous êtes en phase avec la politique de santé courante de l’entreprise et vous êtes autorisé à rejoindre le réseau en production. Si ce n’est pas le cas, je vais être connecté à une autre zone de mon réseau, une zone de « réparation » qui va me permettre de corriger mon problème et donc par exemple de mettre à jour mes signatures d’antivirus. Une des raisons pour lesquelles nous sommes naturellement bien armés pour implémenter cette fonction tient tout simplement au fait que c’est loin d’être simple de pouvoir le faire correctement quand on sort d’hibernation ou de suspension. Quand on boote, c’est relativement facile. On pourrait dire : « j’exécute un bout de logiciel ou de script avant de donner la main à l’utilisateur, et puis après avoir monté la pile réseau, je vais regarder si j’ai le droit de faire ce genre de choses ». Mais dans un contexte où on recharge en mémoire tout son environnement, la pile réseau est déjà là et il y a tout un tas de mécanismes qui ont besoin d’être intégrés dans le système lui-même pour que cela marche. L’objectif que l’on a eu en intégrant NAP dans Windows Vista et dans Windows Serveur 2008 mais aussi dans le Service Pack 3 de Windows XP qui va sortir bientôt, c’est de développer une nouvelle fonctionnalité.
Il nous a paru normal, étant donné que cela correspond à un besoin qui nous a été exprimé de manière insistante par nos clients, de l’intégrer au sein du système d’exploitation. Cela n’est pas la même situation que si on avait intégré un antivirus dans Windows. Si nous avions fait cela, de facto, on tuait le marché. Si nous ne l’avons pas fait, c’est aussi par ce que de toute façon nous savions que la commission européenne ou le département de la justice américaine ne nous aurait pas suivis sur ce sujet. C’est le rôle des régulateurs de s’assurer qu’en l’occurrence Microsoft n’abuse pas d’une certaine position dominante dans ce cadre. Dans le cas de NAP, la situation est différente car rien n’existait alors sur le marché. Les développements ont démarré il y a je crois quatre ans, et donc on a commencé à un moment ou cela constituait la réponse à un besoin exprimé par nos clients qui nous ont dit que par rapport aux problèmes dont on a parlé tout à l’heure, il souhaitaient pouvoir s’assurer que les postes de travail se connectant au réseau soient dans un état de santé satisfaisant.
Ceci étant, NAP est tout à fait interopérable avec NAC et, d’une façon plus générale avec les solutions logicielles et réseau de plus de 100 partenaires. Il n’était, en effet, pas possible d’imaginer que la mise en place de NAP au sein d’une entreprise aurait pour conséquence la remise en cause de ses choix de routeurs, de switches, de solutions antivirales, etc. Il est donc tout à fait possible d’utiliser NAP avec des routeurs CISCO ou Juniper, des solutions de sécurité Symantec, etc.
Peut-on rendre obligatoire de scanner la machine pour vérifier la présence d’un logiciel dangereux ?
BO : C’est possible. On peut vraiment faire ce que l’on veut. C’est laissé au libre choix du RSSI, ou de la production suivant les organisations.
Afin de conclure cet entretien sur une note prospective, quelles sont les évolutions que vous prévoyez dans le domaine de la sécurité ?
BO : Si on essaye de se projeter dans le futur, on se rend bien compte que le monde rassurant qui était celui ou j’avais une sorte d’isolation étanche entre l’intérieur et l’extérieur est en train de voler en éclats. A la fois parce que sur un plan technique le pare-feu montre ses limites ; pas parce qu’il ne marche pas, mais simplement parce que dans les vrais scénarios d’usage, on passe son temps à aller et venir de part et d’autre du pare-feu et parce qu’il y a de plus en plus de collaborateurs mobiles dans l’entreprise. C’est vrai que le PC portable est devenu dominant en termes de vente et puis on se rend compte que dans les usages en entreprise, même si beaucoup de DSI ont encore du mal à l’admettre, l’autonomisation des utilisateurs est un phénomène qui est inexorable et qui est, à mon sens, tout à fait en phase avec un des fondements sociologiques du Web 2.0, à savoir l’autonomisation des acteurs.
On fait donc face au phénomène où les collaborateurs sont de plus en plus mobiles et potentiellement de plus en plus autonomes. Avec l’arrivée de l’Internet généralisé à la maison, on a la montée inexorable de consumérisation de l’informatique que l’on doit prendre en compte. C’est une première raison ; la deuxième c’est que à partir du moment où l’on est dans un modèle économique où il y a de plus en plus d’interconnexions entre différents partenaires économiques, toute entreprise a des besoins croissants d’ouverture de son système d’information à des partenaires avec lesquels il va y avoir des échanges, des capacités à interagir directement, par exemple avec une chaîne de fabrication. On doit être capable de dire : « je suis votre donneur d’ordre et vous devez augmenter les capacités de votre chaîne de fabrication car je vais avoir besoin de tant de pièces supplémentaires à rendre disponibles à telle date » ; en tant que donneur d’ordre, je vais donc directement influer sur votre système d’information pour pouvoir faire en sorte que, de votre côté, vous preniez en compte automatiquement ma commande et que vous puissiez adapter votre cadence de fabrication. Pour pouvoir faire cela, ça oblige de facto, dans une approche orientée services, à interconnecter de plus en plus de systèmes d’informations entre eux et dans ce cadre, qui dit connexion du système d’information, dit, soit j’ai un partenaire qui va être lié avec moi sur la base de l’établissement d’un VPN, soit je vais le mettre derrière un pare-feu particulier dans lequel il va pouvoir entrer au sein de mon système d’information sur la base de ports et d’un modèle d’authentification bien spécifiés. Dans tous les cas, on se rend compte qu’il y a de plus en plus de pressions pour que l’entreprise s’ouvre sur le reste du monde et donc que finalement, entre cette dimension et celle du « va et vient » des collaborateurs dans l’entreprise, on aboutisse finalement à la question qui consiste à se demander : « est-ce que ça a encore un sens de parler d’un périmètre de sécurité dans l’entreprise ?».
On considère, sur ce sujet, qu’à terme il va falloir prendre en compte la disparition de ce périmètre de sécurité et arrêter de se réfugier derrière son pare-feu - sa ligne Maginot - qui bien souvent n’apporte qu’un niveau de sécurité imaginaire.
En fait, on voit, sur le plan économique, que le marché de la sécurité progresse beaucoup plus vite que le marché global de l’informatique. En première analyse, on pourrait dire que c’est parce que les utilisateurs sont assez en retard sur ce sujet, mais, en fait, c’est surtout parce qu’on est en face du syndrome classique de « bretelle, parachute,…. » On accumule les moyens de protection pour se dire : plus j’en mets et plus j’ai de chances de passer au travers de problèmes éventuels que je risque de rencontrer. C’est la problématique classique de ce que l’on pourrait appeler la défense en profondeur qui, en soi, est un très bon principe, mais qui bien souvent consiste à accumuler des moyens de défense sans vraiment se préoccuper des vraies menaces qui pèsent sur l’entreprise et on a parfois tendance à acheter beaucoup d’outils qui ne servent pas à grand-chose. Si on part du principe suivant lequel finalement, le périmètre de sécurité a disparu, la frontière entre ce qui s’appelait jusqu’à maintenant l’intranet et ce qui s’appelle l’Internet n’existe plus et que globalement il n’y a plus que l’Internet - en d’autres termes que l’intranet d’une société s’est, de facto, au sens physique du terme, dilué dans l’Internet - on est alors en face d’une perspective plutôt angoissante.
Dans ce cadre, l’approche que l’on va petit à petit mettre en évidence est une approche dans laquelle, au lieu de chercher à faire une sécurisation du périmètre, on va essayer d’établir une sécurisation point à point. Et donc pour ça l’idée c’est de se dire, plutôt que de recourir à des méthodes de sécurité périmètriques entre ces deux entités, plutôt que de mettre un pare feu pour contrôler les flux, je vais plutôt faire en sorte que je puisse chiffrer toutes les informations qui transitent d’un point à un autre, sous réserve que je sache authentifier chacun de ces utilisateurs, mais aussi faire en sorte que les deux points sachent s’authentifier mutuellement.
Ceci implique de recourir à l’utilisation de façon massive d’IPsec en tant que, à la fois protocole de chiffrement, mais aussi et surtout comme capacité d’établir une connexion IPsec si et seulement si je possède sur chacun des points d’extrémité un certificat qui garantisse que la machine A qui parle avec la machine B est bien la machine qui prétend être A ou B. Cela repose sur la possibilité de mettre en place la diffusion de certificats à l’échelle d’une entreprise, donc de mettre en place une PKI machine mais aussi une PKI utilisateur en recourant à l’utilisation d’une authentification forte basée sur l’utilisation d’une carte à puce ou d’autres dispositifs d’authentification à deux ou trois facteurs. Dans ce cadre, cela permet de pouvoir garantir que la communication entre deux points n’est pas « écoutable » de l’extérieur puisqu’elle est chiffrée mais cela va également permettre de garantir qu’il n’est pas possible de manière simple de pouvoir substituer dans une communication, A par A’ qui cherche à communiquer avec B parce qu’en fait A’ ne disposera pas des certificats dont A dispose. Pour être capable de faire cela simplement sur le plan technique, cela nécessite également de pouvoir disposer d’adresses qui ont une visibilité de bout en bout, et donc en particulier que l’on ne passe pas à travers de dispositifs de type traduction d’adresses NAT (Network Address Translation) qui vont faire en sorte de masquer l’adresse du poste ou du serveur qui initie une telle connexion.
Cela nécessite donc pour cela de recourir à IPv6. Evidemment en termes d’impact sur les infrastructures déjà existantes, c’est une révolution, parce qu’on est très, très loin d’avoir un déploiement massif d’IPv6. Par ailleurs, cette approche est extraordinairement provocante par rapport à la plupart des modèles de sécurité qui ont été mis en place depuis des années.
L’idée c’est donc de promouvoir un modèle où on fait de la sécurité de bout en bout entre deux points en sachant que l’intérêt de ce modèle c’est qu’il est également parfaitement utilisable dans un contexte « peer to peer ». Pourquoi ce contexte est-il intéressant ? Parce que c’est un des mécanismes les plus efficaces de diffusion de contenu. Si j’ai besoin de diffuser du contenu en très gros volume, l’idée d’avoir « n » machines qui vont avoir la possibilité de détenir une petite partie de contenu et ensuite de le répliquer aux points les plus extrêmes du réseau est très intéressante et c’est sans doute l’idée la plus pertinente qu’on peut retirer des mécanismes « peer to peer ». Et puis d’autre part, cela va permettre dans un environnement de type services Web, de type communication de machine à machine, sans nécessairement l’intervention d’autre chose qu’un processus métier ou d’un workflow qui va dérouler des communications entre une machine et d’autres, de pouvoir s’adapter à des architectures qui sont résolument orientées services, qui sont capables d’établir une communication entre différents points de l’architecture globale du système d’information dans un contexte où le niveau de sécurité sera à mon sens largement meilleur en raison de la généralisation du chiffrement. Quand on regarde la façon dont on utilise Internet, la plupart des entreprises aujourd’hui hésitent énormément à donner un accès, depuis l’Internet, à leurs utilisateurs parce qu’elles ont peur qu’il se passe des choses, que leurs utilisateurs aient des problèmes. On est ici dans un environnement où l’authentification forte va permettre de garantir que l’utilisateur est bien celui qu’il doit être. Cela ne veut pas dire que si l’utilisateur se voit dérober sous la contrainte ou par astuce sa carte bleue, son code confidentiel, ce problème n’existera plus, mais on aura déjà une bien meilleure authentification que celle qui est pratiquée aujourd’hui, du fait de la généralisation de la carte à puce pour se connecter au réseau de l’entreprise depuis l’extérieur. D’ailleurs dans la droite ligne de ce programme, Microsoft va généraliser l’utilisation de la carte à puce, y compris dans notre réseau interne.
Premier élément très important donc, l’authentification des utilisateurs. Deuxième élément qu’aujourd’hui on ne fait pas vraiment, sauf dans un environnement IPsec, c’est l’authentification des machines entre elles. On va pouvoir garantir que ce n’est pas n’importe quelle machine qui parle à n’importe quelle autre, n’importe comment et n’importe où. On va établir une session IPsec, et c’est là que NAP et des équivalents jouent un rôle très important, puisqu’on ne va être autorisé à établir cette connexion que si on est conforme aux politiques de sécurité exigées par l’entreprise pour établir cette connexion. On va avoir la possibilité de dire : « si je veux rentrer dans le réseau de l’entreprise, je vais pouvoir vérifier que mon niveau de sécurité est conforme ». Aujourd’hui, on imagine naturellement une telle exigence quand on est connecté de l’extérieur mais, si on est réaliste, c’est la problématique à laquelle ont à faire face toutes les entreprises avec les consultants qui viennent de l’extérieur, qui ont leur propre PC dont on ne sait pas trop d’où il vient, ce qu’il contient, … Si on veut lutter contre la présence de PC pirates, ce moyen est extraordinaire. Si on arrive dans l’entreprise d’une façon ou d’une autre en se faisant passer pour quelqu’un ou par ce que l’on est invité et que l’on se connecte via un câble Ethernet en utilisant une prise murale, ou via un réseau Wi-Fi, aujourd’hui il est très difficile de lutter contre ce phénomène, sauf à admettre que l’on a déjà généralisé IPsec dans l’entreprise. Dans ce dernier cas, si l’on est connecté « en pirate » au réseau de l’entreprise, d’une part on ne va rien pouvoir écouter puisque tout est chiffré et, d’autre part, on ne pourra pas établir la moindre session au sein du réseau de l’entreprise parce qu’on n’aura pas les certificats nécessaires sur sa machine. Ça permet de répondre à la fois à la problématique de l’état de santé du poste de travail, la question de l’authentification de l’utilisateur à travers la généralisation des authentifications fortes et en même temps la possibilité d’assurer que les machines sont entre elles authentifiées, dans un contexte où on va établir des communications chiffrées entre les machines.
C’est un modèle dont l’implémentation risque de prendre des années ?
BO : Oui, cela va prendre beaucoup de temps compte tenu de l’impact en termes d’infrastructure. Les éléments sur lesquels on réfléchit ce sont évidemment tout ce qui va concerner la transition : passer d’un environnement qui existe aujourd’hui à un environnement tel qu’il pourra exister demain. L’expérience prouve d’ailleurs que l’utilisation de technologies de transition est une chose difficile et IPv6 est là pour le prouver. IPv6 existe depuis longtemps mais cela ne veut pas dire que son utilisation se soit généralisée. Par contre cela me paraît être un élément qui va, à terme, rendre l’architecture de sécurité probablement plus simple à comprendre et la rendre plus efficace. Le seul point qui est aujourd’hui un « point de controverse » dans cette architecture tient au chiffrement : dire que tous les échanges sont chiffrés signifie, en fait, que tout ce qui est centre de détection d’intrusion ou sondes réseau n’est plus adapté. L’approche que je décris va rendre la vie beaucoup plus difficile pour un certain nombre d’acteurs de la sécurité puisqu’il n’y aura pas un point de contrôle sur le réseau, sauf à recourir à des technologies telles que l’utilisation d’un ISA Server ou équivalent pour aller casser un tunnel RPC au dessus d’HTTPS, parce que l’on est capable d’authentifier l’utilisateur et qu’on peut donc casser le tunnel et le re-chiffrer derrière. Ce genre d’approche semble être est la « seule » façon de contourner ce problème, mais ça veut dire que les équipements qui sont dans le réseau soient capable de faire aussi cela et d’être eux-mêmes authentifiés et donc de disposer eux-mêmes des certificats qui leur permettent d’être éligibles pour faire partie du réseau. Mais après tout, est-ce une demande exagérée de demander d’avoir une très forte sécurité sur tout dispositif présent sur mon réseau logique ? Cela ne paraît pas être si exorbitant que cela. Sinon, ce serait admettre que cette sonde puisse être utilisée par des personnes mal intentionnées et qui pourraient reproduire les problèmes que l’on connait aujourd’hui.
Ce mode de sécurité que je décris me paraît être un mouvement intéressant, ceci d’autant plus dans une perspective où, petit à petit, les entreprises ont, de plus en plus, recours à l’utilisation massive d’Internet pour connecter des briques de leur système d’information, même si cette idée fait encore se dresser sur leur tête les cheveux d’un certain nombre de banquiers par exemple.
Pourtant, si on prend l’exemple d’un réseau d’agences au sein duquel il y une petite agence avec trois ou quatre personnes (ce sont de loin les plus nombreuses), cette agence est aujourd’hui souvent connectée via de vieilles connexions RNIS agrégées en 2×64 Ko. Ces moyens sont totalement obsolètes, coûtent une fortune, n’ont aucune réelle justification autre que psychologique et pourraient être très avantageusement remplacés par des connexions directes sur Internet et où on multiplie sa bande passante par un facteur considérable et où on divise son prix par 4 ou 5. Globalement on a une bonne qualité de service (probablement inférieure à celle d’un réseau RNIS privé mais ce problème potentiel peut se résoudre par de nouvelles approches applicatives comme les « clients intelligents ») pour un coût très sensiblement inférieur. Dans un environnement comme celui là, chaque agence devient, de facto, une partie de cet environnement dans lequel, finalement, on a une partie du système d’information qui est dans le réseau d’agence, une partie du système d’information qui est en central et, entre les deux, on est capable à travers ce dispositif de se passer de pare feu, de VPN, d’un quelconque dispositif compliqué, tout en ayant la possibilité d’établir une connexion point à point entre chaque poste de travail qui se trouve en agence et les systèmes centraux vers lesquels on a besoin de se connecter. C’est un dispositif qui me parait aller parfaitement dans cette direction dans un contexte où il va y avoir de plus en plus de connexions directes. C’est un mouvement que l’on a implémenté chez Microsoft il y a deux ans. Ainsi, toutes nos agences en France sont connectées directement sur Internet à Microsoft. Quand un collaborateur de l’agence de Lyon veut établir un lien avec Microsoft, il rentre sa carte à puce, il réalise son authentification forte, il monte son VPN et il a un accès direct au réseau Microsoft sans aucune restriction d’usage. Il a une bien meilleure qualité de service car, en fait, il a un débit réseau bien supérieur et ceci nous a permis de plus de diviser notre facture dans des proportions considérables tout en sachant que nous sommes, à l’échelle de la planète, le deuxième domaine le plus attaqué dans le monde, juste derrière le département de la défense américaine.
Donc ça prouve qu’il est possible d’y arriver.
Ce que vous présentez là relève t’il d’une stratégie d’entreprise ?
BO : Absolument. On en a parlé la dernière fois lors du dernier RSA Conference de San Francisco en février 2007 où il y a eu une interview conjointe de Bill Gates et Craig Mundie. Ils ont parlé ensemble de cela. On est petit à petit en train de faire monter ce sujet en puissance et on va faire une annonce sérieuse qui sera la présentation de notre stratégie sécurité lors du prochain RSA à San Franciso en Avril. Quand vous lisez ce qui a été publié de cette interview, dont le transcript est en ligne, ce discours c’est exactement cela. http://www.microsoft.com/presspass/press/2007/feb07/02-06RSA07KeynotePR.mspx
Qu’en pensent les acteurs du marché de la sécurité ?
BO : C’est encore prématuré d’en parler. Il est certain que ce modèle là met en péril certains outils de sécurité, y compris les nôtres, car c’est un modèle de rupture. Cependant, comme je l’ai déjà dit plus haut : « la sécurité est un voyage, pas une destination » et il y a fort à partir que de nombreux acteurs du marché de la sécurité continueront de nous accompagner dans ce voyage…
Existe-t-il un consensus de l’industrie sur ce modèle ?
BO : C’est un sujet sur lequel je pense qu’il va falloir avoir un certain nombre d’échanges avec l’ensemble des acteurs. Aujourd’hui il y a pas mal de spécialistes de ce sujet, des chercheurs, des universitaires avec lesquels on a largement échangé. C’est un sujet sur lequel Microsoft Research a pas mal travaillé depuis un certain temps.
Cette communauté de scientifiques pense que c’est la direction dans laquelle il faut aller maintenant, même si c’est une direction qui est difficile en termes de transition et qui est extrêmement angoissante sur le plan psychologique. Je pense qu’il va y a voir des résistances importantes sur ce sujet, parce que cela entraîne des remises en cause d’un certain nombre de présupposés. Cela nécessite par exemple la généralisation d’IPsec et il est inutile que je fasse un dessin sur l’état actuel d’implémentation d’IPv6 à l’échelle de la planète. On peut considérer que c’est un sujet sur lequel il y a beaucoup de lenteurs, donc que cela ne va pas se faire en un jour et on en est bien conscients.
Par contre ce qui est intéressant et qui à mon sens est un élément fondateur, c’est que chez Microsoft sur le plan de la sécurité, nous avons été en permanence en mode « suiveur ». L’objectif est d’arrêter de suivre et c’est cela qui change. On a envie maintenant d’écrire un peu notre histoire sur le sujet de la sécurité, pas simplement d’attendre que d’autres l’écrivent pour nous. C’est évidemment une approche que d’aucuns pourraient trouver arrogante mais nous avons appris de nos erreurs du passé : être arrogant est un luxe que nous ne pouvons pas permettre, surtout sur un sujet comme la sécurité où l’on sait très bien que, tant que l’homme sera homme, il y aura un boulet et une cuirasse, un gendarme et un voleur,… S’il y a bien un sujet sur lequel la modestie est de rigueur, c’est bien celui de la sécurité. De plus, comme je le rappelais tout à l’heure en citant avec un clin d’œil Spiderman : « un grand pouvoir entraine de grandes responsabilités » ; cela nous ne devons et ne pouvons pas l’oublier…
