Security WatchJe viens de recevoir un bulletin de sécurité. Que faire maintenant ?

Christopher Budd

Le processus de publication mensuelle de bulletins de sécurité de Microsoft a été mis en place en octobre 2003 en réponse à une demande des clients. L'une des demandes principales concernait la prévisibilité dans la publication de bulletins de sécurité. Nous étions capables d'utiliser ces bulletins régulièrement et de manière prévisible pour affûter et améliorer nos processus.

Le site des bulletins de sécurité Microsoft présente le bulletin de sécurité le plus récent et recherche les bulletins déjà publiés, comme l'illustre la figure 1. Le bulletin d'août 2006 est illustré à titre d'exemple à la figure 2.

Figure 1** Site des bulletins de sécurité Microsoft **(Cliquer sur l'image pour l'agrandir)

Pour de nombreux clients, le bulletin de sécurité mensuel de Microsoft a contribué à la mise en place de processus plus aboutis pour déployer des mises à jour de sécurité. Grâce à la publication de bulletins de sécurité à une date prévisible, les clients ont pu élaborer régulièrement leurs propres processus pour les gérer. Ils ont créé des chronologies et des étapes pour évaluer la mise à jour de leur propre sécurité et déployer des processus intégrant les chronologies prévisibles concernant la publication de bulletins mensuels de sécurité Microsoft. Les clients utilisent ce processus pour analyser, tester et déployer systématiquement des mises à jours afin d'augmenter leur niveau global de sécurité et de diminuer le nombre d'arrêts et d'interruptions.

Figure 2** Bulletin de sécurité d'août 2006 **(Cliquer sur l'image pour l'agrandir)

Toutefois, certains clients continuent à évaluer et à déployer une mise à jour de sécurité sans mettre de procédure en place. Même s'il est possible de déployer des mises à jour de manière non systématique sans pour autant rencontrer de problème, cette pratique va à l'encontre de ce que nous considérons comme les meilleures pratiques en matière de gestion de la mise à jour de sécurité.

Nous avons fourni des informations utiles sur la publication des bulletins, sans avoir donné beaucoup d'indications sur la fonction de ces bulletins et sur leur intégration dans vos propres processus. Certains clients n'ont pas conscience des processus qui pourraient leur être utiles ou de la meilleure manière de les mettre en place.

Par conséquent, je voudrais insister dans cet article sur les étapes et les processus que nous recommandons dans le cadre de l'évaluation et du déploiement de la mise à jour de sécurité. Les organisations de toute taille peuvent suivre les étapes suivantes. Pour les organisations plus importantes, il serait approprié de diviser les étapes entre les différents groupes, en fonction de leur structure interne. Pour les organisations plus petites, ces étapes peuvent être exécutées par un seul groupe voire une seule personne. Quelle que soit l'attribution des responsabilités, ces étapes doivent être explicitement prises en compte dans votre processus d'évaluation et de déploiement. La figure 3 donne un aperçu du processus.

Figure 3** Processus de déploiement et d'évaluation des bulletins de sécurité **

1. Réception d'une notification avancée

La première étape du processus de bulletin mensuel de sécurité doit permettre d'assurer la réception d'une notification avancée des futures mises à jour de sécurité. Microsoft poste les informations sur son site Web vers 10 heures (Pacifique, GMT -8) trois jours ouvrés avant la publication mensuelle normale, ce qui correspond au deuxième mardi de chaque mois ; par conséquent, les informations de la notification avancée sont postées le jeudi de la semaine précédente.

L'objectif de cette notification avancée consiste à fournir des informations permettant de planifier à l'avance le déploiement de la publication réelle. Le niveau de détail inclus est ajusté en fonction du besoin de protection des clients jusqu'à la publication des mises à jour de sécurité, ainsi toutes informations susceptibles de faciliter les attaques ne sont pas divulguées. La notification avancée regroupe des informations sur les futures mises à jour par nom de produit sans information sur les versions spécifiques (par exemple, Microsoft® Windows® ou Microsoft Office). Chacune de ces entrées indique le nombre de bulletins publiés pour ce produit, l'échelle de gravité maximale de ces bulletins, si des mises à jour nécessitent un redémarrage et nos outils de détection utilisés dans ces bulletins.

Pour éviter toute mauvaise surprise et tout risque de confusion, la notification avancée fournit également des informations sur d'autres mises à jour non associées aux bulletins de sécurité publiés le même jour. Elle indique notamment le nombre de mises à jour haute priorité n'impliquant pas la sécurité qui seront publiées sur Microsoft Update (MU) et sur Windows Update (WU), ainsi que toutes les mises à jour de l'outil de suppression des logiciels malveillants Microsoft Windows .

Enfin, nous fournissons des informations sur les problèmes éventuels susceptibles d'entraîner des retards dans votre déploiement, comme nous l'avons fait pour la modification de l'autorisation « Envoyer comme » dans le bulletin MS06-019.

Chaque mois, la nouvelle notification avancée est postée, en même temps une notification est envoyée par le service SNSCE (Security Notification Service Comprehensive Edition). Vous pouvez vous inscrire au service SNSCE.

2. Évaluation de l'impact potentiel

Lorsque vous recevez la notification avancée, la première chose à faire est d'évaluer la pertinence des versions à venir dans votre environnement. Même si la notification avancée contient des informations limitées sur les produits concernés, elle fournit suffisamment d'informations pour vous permettre de juger si les bulletins à venir sont pertinents pour votre environnement.

Par exemple, supposons que la notification avancée répertorie deux bulletins Microsoft Exchange dont le niveau de gravité est maximal et qui exigent un redémarrage. Si vous n'exécutez pas ce programme, vous savez tout de suite que ces bulletins ne s'appliqueront pas à votre environnement. Inversement, si vous exécutez Exchange Server 2003, vous saurez que vous recevrez le jeudi jusqu'à deux bulletins évalués comme critiques nécessitant un redémarrage.

À des fins de planification, la notification avancée doit vous servir d'outil permettant de déterminer l'impact maximal possible sur votre organisation en terme de nombre de bulletins, de leur gravité et de leur impact sur le déploiement par rapport aux redémarrages. Lorsque vous avez terminé l'évaluation de la pertinence et de l'impact maximal possible sur les mises à jour, vous pouvez créer une chronologie qui inclut les actions suivantes :

• Personnel pour l'évaluation des risques, les tests et le déploiement
• Projets et durée des tests
• Projets de déploiement et redémarrages programmés (si nécessaire)

Toute planification à cette étape doit rester à l'état de tentative, car les informations de la notification avancée sont soumises à des modifications. De même, en raison de la restriction des informations dans la notification avancée, vous pouvez apporter des modifications une fois en possession de tous les détails.

Pour finir, si des informations s'ajoutent, par exemple concernant des modifications de fonctionnalité, vous devez profiter de la période entre la notification avancée et la publication réelle du bulletin de sécurité pour faire une recherche sur la question et évaluer son impact éventuel sur votre environnement. Vous devrez probablement réviser votre planification de tentatives en fonction de votre recherche.

3. Réception de nouveaux bulletins de sécurité Microsoft

Microsoft publie ses bulletins de sécurité tous les deuxièmes mardis du mois, à 10 heures (Pacifique) en règle générale, mais si la publication fait partie d'un processus important, complexe et interdépendant, elle peut être retardée pour diverses raisons. Dans cette publication, les bulletins de sécurité, les mises à jour de sécurité, les mises à jour des outils de détection et de déploiement tels que Microsoft Baseline Security Analyzer (MBSA) et Windows Server® Update Services (WSUS) et les nouveaux outils de détection tels qu'une nouvelle version de Enterprise Scan Tool (EST) sont tous postés sur les sites Web de Microsoft.

La page concernant le bulletin de sécurité Microsoft prend en charge les flux RSS. Si les bulletins de sécurité incluent des mises à jour, notre flux RSS est également mis à jour, qui en retour met à jour les agrégateurs RSS et les afficheurs. De plus, la notification est envoyée à l'aide du service SNS (Security Notification Service) et du service SNSCE. Les notifications sont envoyées par courrier électronique et alertes MSN®.

Pour en savoir plus sur la disponibilité des nouveaux bulletins de sécurité, vous devez vous inscrire à tous les mécanismes de notification proposés. Vous pouvez vous inscrire au flux RSS et aux services SNS et SNSCE.

4. Évaluation de la pertinence des bulletins de sécurité

Il est important d'attribuer explicitement la responsabilité quant à l'examen des nouveaux bulletins de sécurité et l'évaluation de leur pertinence pour votre environnement. Dans le cadre de cette évaluation, vous pouvez extraire les informations spécifiques des bulletins de sécurité pour effectuer des révisions et des ajustements, comme il convient, à votre planification de tentatives. Revenons à l'exemple : si vous avez averti votre équipe d'administration Exchange d'une éventuelle mise à jour de sécurité critique, mais que vous vous apercevez qu'Exchange Server n'est pas concerné, vous pouvez ajuster la planification de ces ressources.

Lorsque vous avez terminé l'évaluation de la pertinence des bulletins de sécurité pour votre organisation, vous pouvez poursuivre avec les bulletins qui concernent vos processus.

5. Évaluation des risques et estimation des bulletins

À cette étape, vous devez effectuer l'évaluation des risques des bulletins pertinents. Dans les organisations où les responsabilités sont partagées, cette étape est souvent effectuée par le groupe de sécurité. Tandis que chaque bulletin de sécurité Microsoft présente une échelle de gravité maximale, celle-ci reflète la gravité la plus élevée de toutes les vulnérabilités de tous les produits concernés. L'échelle de gravité Microsoft qui s'applique à votre organisation peut être différente de l'échelle de gravité maximale répertoriée, selon la gravité du problème sur les versions de votre environnement. Il est important de consulter le tableau complet des identificateurs de vulnérabilité et d'échelles de gravité sous la section Synthèse du bulletin de sécurité et d'obtenir les informations de vulnérabilité spécifiques à vos versions.

Ensuite, vous devez examiner les informations techniques telles que les facteurs de réduction et les détails techniques sur le Forum aux questions pour chaque vulnérabilité et ajuster votre évaluation des risques en fonction de votre environnement et de vos stratégies. Vos stratégies peuvent également stipuler que votre évaluation concerne les facteurs non techniques et environnementaux, tels que l'environnement de menace ou le caractère critique de certaines applications dans votre organisation.

À la fin de ce processus, vous devez posséder une évaluation des risques pour chaque bulletin et les mises à jour qui leur sont associées. Toujours dans notre exemple, le groupe d'administration Exchange peut évaluer une mise à jour de sécurité comme « risque modéré » selon les modifications indiquées dans le bulletin de sécurité. Selon vos stratégies, vous devez intégrer les mises à jour et les modifications dans votre planification comme il convient. Par exemple, vos stratégies peuvent stipuler que les mises à jour de risque modéré nécessitent un ou deux jours de test en plus que les mises à jour de risque faible.

Dans certains cas, vos stratégies peuvent stipuler que, pour des bulletins avec une certaine échelle de risque, vous devez également considérer la mise en œuvre de solutions de rechange. Par exemple, la stratégie de votre organisation peut stipuler que, pour toutes les mises à jour de sécurité évaluées comme critiques, vous devez examiner et déployer des solutions de rechange dès que possible. Dans ce cas, vous devez effectuer une évaluation supplémentaire des risques liés aux solutions de rechange pour déterminer les éléments à implémenter et la date de leur implémentation.

À la fin de ce processus, vous devez disposer d'une liste de mises à jour à déployer dans votre environnement avec les évaluations des risques associés à chacune. En outre, vous devez disposer d'une liste de solutions de rechange à implémenter pour mettre à jour votre planification de test et de déploiement. Les modifications apportées à votre planification doivent refléter les chronologies spécifiées par vos stratégies. Par exemple, votre stratégie peut stipuler que, pour toutes les mises à jour de sécurité critiques, des solutions de rechange doivent être déployées dans les 24 heures et des mises à jour déployées dans les 7 jours.

6. Définition de l'impact éventuel des mises à jour de sécurité et/ou des solutions de rechange sur l'organisation

La compréhension de l'impact des mises à jour de sécurité ou des solutions de rechange sur votre environnement constitue une étape essentielle dans le processus d'évaluation. Dans les organisations où les responsabilités sont partagées, cette étape est souvent effectuée par le groupe qui gère les systèmes directement concernés par les mises à jour de sécurité ou les solutions de rechange.

La connaissance de l'impact éventuel permet de comprendre et de déterminer le risque posé par les mises à jour de sécurité ou les solutions de rechange. Des informations supplémentaires se trouvent dans le bulletin de sécurité de la section « Frequently Asked Questions (FAQ) Related to This Security Update » (Forum aux questions relatives à cette mise à jour de sécurité). Des informations sur la résolution de la vulnérabilité par la mise à jour de sécurité se trouvent sur le forum Vulnerability FAQ (FAQ sur la vulnérabilité) dans la section « Vulnerability Details » (Informations sur la vulnérabilité).

L'objectif de cette étape consiste à déterminer une évaluation des risques pour les mises à jour et les solutions de rechange. Toujours dans notre exemple, le groupe d'administration Exchange peut évaluer une mise à jour de sécurité comme « risque modéré » selon les modifications indiquées dans le bulletin de sécurité. En fonction de vos stratégies, vous devez réviser votre planification si nécessaire. Par exemple, vos stratégies peuvent stipuler que les mises à jour de « risque modéré » nécessitent un ou deux jours de test en plus que les mises à jour de « risque faible ».

Vous devrez probablement revoir les décisions concernant le déploiement de solutions de rechange en fonction de l'impact de votre évaluation des risques sur votre planification. Par exemple, vous pouvez avoir besoin de prolonger la période de test de deux jours, ce qui laisse vos systèmes sans protection pendant une période plus longue que celle autorisée par vos stratégies. Dans ce cas, vous devez revoir le déploiement de solutions de rechange afin de respecter vos stratégies.

Enfin, vous devez utiliser les informations qui proviennent de cette étape lorsque vous passez au développement d'un projet de tests pour les mises à jour.

7. Définition d'un projet de tests

Pour être efficace, le test doit être systématique et élaboré à partir d'un projet significatif. Votre test doit cibler les zones les plus susceptibles de présenter des problèmes dans votre environnement. Puisque chaque environnement est différent, nous ne pouvons pas fournir de modèle standard de projet de tests efficace.

Pour les organisations où les responsabilités sont partagées, le projet de tests est souvent conçu par plusieurs groupes. Le groupe qui gère les technologies ou les systèmes directement concernés par les mises à jour de sécurité ou par les solutions de rechange peuvent fournir une expertise particulière. Le groupe de test peut fournir une expertise pour élaborer des cas de test, des options pour les outils de test et des explications sur les chronologies pratiques.

Au cours de cette phase, vous devez noter l'ampleur de l'impact du projet de tests sur votre évaluation des risques liés aux mises à jour de sécurité ou aux solutions de rechange, puis apporter les modifications correspondantes à votre planification de test et de déploiement. Par exemple, si vous déterminez que vous ne pouvez pas développer de projet de tests d'une mise à jour comme vous le souhaitez, vous pouvez augmenter son évaluation des risques, choisir de retarder le déploiement et implémenter des solutions de rechange pendant cette période provisoire.

8. Développement d'un plan de déploiement

Le déploiement est le processus qui met réellement en œuvre la protection fournie par les mises à jour de sécurité ou les solutions de rechange. Étant donné que le déploiement est véritablement l'objectif final du processus, comprendre les méthodes appropriées disponibles et les factoriser dans vos évaluations est aussi important qu'une évaluation des risques de sécurité. Dans les organisations où les responsabilités sont partagées, les méthodes de déploiement possibles pour les mises à jour de sécurité sont souvent définies par les groupes chargés de la gestion de l'infrastructure des mises à jour logicielles, comme le groupe qui gère le Systems Management Server (SMS). Les groupes ayant une vue d'ensemble sur les technologies de gestion de la configuration, telles qu'Active Directory, peuvent être impliqués dans la définition de méthodes de déploiement possibles pour les solutions de rechange.

Dans cette étape, votre objectif consiste à comprendre les méthodes de déploiement possibles qui serviront de base pour élaborer un plan permettant de déployer des mises à jour de sécurité ou des solutions de rechange. Un point important à comprendre est la manière dont les méthodes de déploiement possibles peuvent influencer votre planification et nécessiter des modifications. Par exemple, si une mise à jour de sécurité n'est pas prise en charge par WSUS, qui représente alors votre méthode de déploiement principale, vous pouvez déterminer qu'un délai de deux jours supplémentaires par rapport à votre plan d'origine sera nécessaire pour déployer la mise à jour. Vous pouvez, par conséquent, décider d'implémenter des solutions de rechange pour apporter les protections nécessaires pendant cette période de déploiement.

Les informations concernant les méthodes de déploiement sont présentées dans le bulletin de sécurité de la section « FAQ Related to This Security Update » (FAQ relatives à cette mise à jour de sécurité). Les informations relatives aux méthodes d'implémentation de solutions de rechange sont répertoriées avec chaque solution de rechange ; des solutions de rechange individuelles sont associées à chaque vulnérabilité.

Nous arrivons à la fin des étapes de planification. À ce point précis, votre chronologie doit refléter tous les éléments de vos évaluations et de votre planification relatifs aux risques de sécurité, à l'évaluation des risques des mises à jour de sécurité et des solutions de rechange, aux tests et au déploiement. Comme vous avez pu le constater, leur interdépendance est très complexe, et non nécessairement linéaire. Selon les organisations, ces étapes sont simultanées ou séquentielles. Vous devez décider de la mise en œuvre de ces étapes en fonction des stratégies, besoins et ressources de votre organisation. Le point fondamental de ces étapes n'est pas leur structure ou leur ordre spécifique, mais leur capacité à informer et répondre à tout un chacun. La clé de toute implémentation est de rester flexible et adaptable.

9. Test des mises à jour et des solutions de rechange

Au cours de l'étape des tests, vous allez placer les mises à jour de sécurité et les solutions de rechange dans le projet de tests défini précédemment dans votre environnement de test. L'objectif de votre environnement de test consiste à répliquer les éléments critiques dans votre environnement de production. En testant les mises à jour de sécurité ou les solutions de rechange, vous vous efforcez de trouver les problèmes susceptibles de se produire avant le déploiement dans votre environnement de production.

Une fois les problèmes identifiés, vous devez déterminer leur gravité et les étapes nécessaires pour les résoudre. Vous pouvez détecter des problèmes mineurs dont l'échelle d'impact est acceptable et des problèmes devant être résolus avant le déploiement des mises à jour. Si vous choisissez d'accepter le problème, informez-en le personnel de support.

Pour résoudre le problème, vous pouvez ouvrir un cas avec le Support technique de Microsoft, qui offre une assistance gratuite pour les problèmes relatifs aux mises à jour de sécurité. Pour savoir comment contacter le Support technique, rendez-vous à l'adresse suivante : support.microsoft.com/security. Comme la résolution des problèmes peut rallonger la durée des tests et, par conséquent, retarder le déploiement, vous devez considérer l'impact potentiel sur votre planification avant de choisir de résoudre un problème.

À la fin des tests, si tous les problèmes sont soit résolus soit documentés, vous pouvez alors certifier les mises à jour de sécurité ou les solutions de rechange pour le déploiement dans votre environnement de production.

10. Déploiement des mises à jour et des solutions de rechange

Une fois les mises à jour de sécurité ou les solutions de rechange certifiées suite à des tests, vous pouvez passer au processus de déploiement. Au cours du déploiement, utilisez le plan comme guide lorsque vous appliquez réellement les mises à jour de sécurité ou les modifications de la configuration aux systèmes. Les groupes impliqués dans le développement du plan sont généralement chargés des déploiements réels.

Si vous rencontrez des problèmes au cours du déploiement (par exemple, échec de l'installation d'une mise à jour de sécurité dans l'infrastructure de gestion des mises à jour), vous devrez examiner attentivement ces problèmes. Si le problème engendre des retards, vous souhaiterez probablement examiner une nouvelle fois les options et/ou considérer les solutions de rechange afin de protéger vos systèmes.

Dans l'idéal, votre processus de test identifiera tous les problèmes susceptibles de survenir dans la production avant le déploiement. Toutefois, si vous rencontrez des problèmes après le déploiement dans votre environnement de production, suivez les mêmes étapes que pour un problème rencontré pendant les tests. Évaluez le problème, puis décidez de l'accepter ou de le résoudre.

Si les mises à jour de sécurité sont appliquées avec succès, les protections sont alors en place et l'objectif final de ces processus est atteint. Dans le cas contraire, vos systèmes sont toujours vulnérables.

Comme certains systèmes n'ont peut-être pas effectué les mises à jour avec succès, l'étape finale du processus de déploiement est très importante : vérifier si les systèmes ont réussi le déploiement. Dans certaines organisations, cette vérification est assurée par un groupe d'audit distinct, souvent en relation avec les équipes de sécurité. Les outils Microsoft tels que WSUS, MBSA et SMS peuvent être utilisés pour contrôler la réussite de l'application des mises à jour de sécurité. De plus, certaines informations contenues dans la section Security Update Information (Informations relatives aux mises de sécurité) du bulletin de sécurité indiquent comment vérifier que la réussite de l'application de la mise à jour de sécurité.

Conclusion

Grâce à la publication mensuelle des bulletins de sécurité Microsoft, vous pouvez mettre en œuvre une planification et des processus plus réguliers pour gérer les mises à jour de sécurité. Élaborer des procédures et des processus réguliers vous permettent de mieux protéger vos systèmes tout en diminuant le temps d'interruption et les arrêts potentiels.

Mêmes si chaque organisation doit élaborer ses propres processus pour gérer les mises à jour de sécurité, les processus de votre organisation doivent inclure les étapes recommandées dans cet article. Vous n'êtes pas obligé de disposer d'équipes de mise à jour et de sécurité distinctes, mais vous devez à la fois évaluer les risques de sécurité et développer un plan de déploiement.

La clé se trouve dans la planification. Grâce à une bonne planification, les étapes impliquant une activité réelle, comme les étapes de tests et de déploiement, sont beaucoup plus fluides, ce qui aboutit à la réussite du processus des mises à jour de sécurité.

Christopher Budd est responsable du programme de sécurité au Centre MSRC (Microsoft Security Response Center). Il est spécialisé dans la communication technique avec les professionnels de l'informatique et de la sécurité, entre autres.

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.