Bernard Ourghanlian, direction technique et sécurité de Microsoft
La nouvelle vision de la sécurité de Microsoft (2e partie)
Publié le 23 janvier 2008
Dans cette deuxième partie, Bernard Ourghanlian, directeur technique et sécurité de Microsoft France, mentionne la responsabilité de Microsoft quant à l'intégrité du système d'information de ses clients et répond aux interrogations concernant la légitimité de l'éditeur à proposer des solutions de sécurité.
Propos recueillis par Hugo Lunardelli
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é. Notre position sur le marché nous impose d'être très actif dans ce domaine. Un des éléments sur lesquels nous avons beaucoup travaillé et qui est lié à cette prise de conscience, 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.
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 en discuter longuement.
Cette remarque était faite, les produits de la gamme Forefront 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.
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. 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.
Toutefois, 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 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 a pu rentré. Il est probable qu'un utilisateur ait 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é si l'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 uniquement 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 le protocole RPC dans HTTPS de telle façon que l'on puisse directement faire de l'Outlook classique qui va dialoguer 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 si une requête vient d'Outlook, qu'elle correspond 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. L'intérêt majeur 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 (AD) 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, ce qui aurait été impossible sans intégration native avec l'annuaire.
D'une façon générale, toute la gamme Forefront capitalise 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, 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 gérée par des opérateurs jouant 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, j'ai besoin d'entrer dans le détail de ces évènements, de connaître précisément quelle est la cause de mon problème, alors je serais 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, 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 administrer notre plateforme, Il me semble difficile que quelqu'un la gère mieux que nous. 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. 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 déjà 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.
La raison essentielle est que l'objectif de NAP est de pouvoir contrôler l'état d'un poste de travail, d'un serveur ou de n'importe quelle composante de l'environnement Windows. NAPest une fonction nouvelle qui apparaît et 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 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 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 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é à pénétrer le réseau. Ensuite 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é » 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 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 nombre de mécanismes ont besoin d'être intégrés dans le système lui-même pour que cela marche. L'objectif 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, 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 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 que tout fournisseur, en l'occurence Microsoft, n'abuse pas d'une certaine position dominante. 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, 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 CiscoISCO 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.