Retour sur l'incident du bug McAfee

Le 21 avril 2010 s'est produit ce qu'on pourrait qualifier comme étant un incident majeur de production au niveau de la protection antivirale. Dans ce contexte, le DSI est pris en tenaille entre le danger de ne pas déployer au plus tôt les signatures et celui de s'y prendre trop tard.

Concrètement, une signature (5958) d'un éditeur bien connu (McAfee) a détecté par erreur un fichier système comme viral. Le fichier système en question est svchost.exe, ou Service Host Process, un lanceur générique de services. Ce dernier intervient dans de nombreux services et fonctions réseau dont Windows Update, le WiFi, le client DNS, le pare-feu, le service serveur, etc.

Il semble que seules des machines ayant le service pack 3 de Windows XP aient été impactées. Quand on dit "seulement", il s'agit tout de même d'un parc conséquent en entreprises. Pour ces machines, selon la politique antivirale en vigueur, l'antivirus a pu aller jusqu'à supprimer ce dernier du disque. Au mieux, les machines redémarraient en boucle de façon intempestive, au pire, elles ne démarraient plus.

Peu de détails ont été fournis sur les raisons pour lesquelles seul le svchost.exe de XP SP3 a été concerné. En effet, svchost.exe est aussi présent sous les plateformes NT 5 (2000, etc...) et NT 6 (Vista, 7).

Il peut être intéressant de s'interroger tout d'abord sur les solutions de remédiation proposées, y compris par l'éditeur. Il semble peu probable qu'une machine qui ne démarre plus puisse récupérer une nouvelle signature antivirale, et encore moins probable qu'elle puisse être pilotée à distance, en central, pour la réparer.

Ainsi donc, sous des solutions dites industrialisables, se cache le réel problème de passer physiquement sur les machines, une à une. La problématique est double : inventaire du périmètre impacté tout d'abord, puis dégager les ressources nécessaires (influant sur le délai de retour à la normale). L'image de l'antivirus qui est piloté en central, dans une console adaptée à la souris, en a certainement pris un coup.

Parallèlement, des machines intégrées avec une séparation native données et système (via le partitionnement disque, par exemple), auraient pu être remises d'aplomb plus rapidement en restaurant l'image. Mieux, si ces machines disposaient d'une fonction de démarrage par réseau (type PXE) il aurait alors été possible de les restaurer avec une image système en retard au niveau signatures et donc saine.

Cet incident devrait surtout sonner un rappel de la nécessité de tester des signatures avant déploiement. Le problème se pose quand certains éditeurs ont par défaut des préconisations de mise à jour toutes les deux heures, et plusieurs signatures diffusées par jour. Ce n'est à ma connaissance pas le cas de McAfee, mais la problématique reste applicable.

Dans ce contexte, le DSI est pris en tenaille entre le danger de ne pas déployer au plus tôt les signatures antivirales sur son parc (risquant donc l'infection virale, et tous les dégâts associés), et celui de déployer rapidement les signatures, avec le risque de casser une application (voire des systèmes entiers !) métier.

Pour aider dans la recherche d'une réponse à cette problématique, je propose un découpage simplifié du parc, au niveau de la mise à jour antivirale :

- les postes bureautique (non critiques et non métier pur) pourraient recevoir les signatures au plus tôt, après une phase de test standard sur site pilote ;
- les postes métier pourraient être déployés après notification des MOA applicatives, pour leur laisser le temps de tester les signatures. Le délai global serait donc plus long en moyenne, que pour la bureautique, mais garantirait d'avoir bien moins de mauvaises surprises post-déploiement des signatures ;
- les postes VIP : certainement à déployer au plus tôt, compte tenu de la population ciblée (quelque peu sensible). Ceci n'est envisageable que si le périmètre pilote de test est suffisamment représentatif. Dans la négative, ils pourraient être rattachés aux délais de la bureautique.

Ces postes sont à la fois fortement susceptibles d'être infectés, et délicats car pouvant bloquer le pouvoir décisionnel. Il convient donc qu'un arbitrage soit demandé pour le port des risques :

- les serveurs bureautiques : traitement identique aux postes bureautiques ;
- les serveurs applicatifs : qualification forte avant déploiement, comme les postes métier.

Dans une optique de gouvernance par les risques, il semble apparaître une nécessité d'arbitrage :

- déployer au plus tôt sur le parc des signatures antivirales pour se protéger au mieux de l'infection virale tout en prenant le risque d'impacter le SI (métiers, et décideurs) ;
- respecter des phases fortes de qualification, tests sur sites pilotes, avant déploiement de signatures = risque moindre de casser l'outil métier, mais avec un risque viral important.

Néanmoins, il n'est pas nouveau que sensibiliser les projets, les métiers, à la nécessité de prendre en compte la sécurité, reste une tâche de longue haleine, au quotidien. De plus, faire comprendre la nécessité d'assurer une couverture antivirale globale du SI n'est pas encore acquise.

Cependant, suite à ce type d'incident, les métiers pourraient être bien plus réticents à suivre les préconisations sécurité sur leur périmètre (tant que ça marche, l'on ne se posera pas de question, notamment pas concernant la sécurité...). C'est un réel problème que les équipes sécurité auront certainement à gérer dans un proche avenir.

Au final, il ressort que les éditeurs antivirus ont de réelles responsabilités sur l'évolution du niveau de sécurité SI en entreprise. Ne pas avoir identifié un faux positif sur un système Windows standard ne paraît totalement pas envisageable.

La seule barrière contre la catastrophe reste la qualification interne des mises à jour, qui nécessite des ressources comme on l'a vu plus haut. Or, il semble que nombre d'entreprises n'ont pas les budgets pour avoir des experts (ePO, VSE...) à plein temps, et les dernières signatures antivirales partent directement en diffusion sur le SI. Il est tout de même inquiétant que les dommages annoncés sur Internet soient assez globaux, et que même des corps de métier sensibles comme le médical aient semble-t-il été impactés.

Espérons tout de même que la lutte antivirale ne soit pas la première victime de cet incident. Sans quoi, certains milieux malveillants verraient leur tâche grandement facilitée. Au final, cela resterait les entreprises - et les particuliers - qui le paieraient.