Processus de gestion des correctifs

Phase 3 - Évaluation et planification

Dernière mise à jour le 01 juin 2007

Sur cette page

Dans ce module
Objectifs
S'applique à
Comment utiliser ce module
Présentation
Identification des actions appropriées
Planification de la diffusion
Génération de la version
Tests d’acceptation
Synthèse
Passage à la phase de déploiement

Dans ce module

Ce module décrit la troisième des quatre phases du processus de gestion des mises à jour : l'évaluation et la planification. Cette phase consiste à décider si une mise à jour doit être ou non déployée, à déterminer ce qui est nécessaire pour son déploiement et à la tester dans un environnement semblable à celui de la production afin de vérifier qu’elle ne compromet pas la sécurité des applications et des systèmes fondamentaux de l’entreprise.

Ce module a pour objectif de décrire les principes de la phase d’évaluation et de planification du processus de gestion des mises à jour et de vous présenter les types de tâches qui vous permettront d’effectuer l’évaluation et la planification avec Microsoft Windows Server Update Service (WSUS) et Microsoft Systems Management Server (SMS).

Remarque : Vous pouvez télécharger la version bêta 2 de la prochaine version de SMS, appelée System Center Configuration Manager 2007, à l'adresse http://www.microsoft.com/technet/sms/2007/evaluate/download.mspx. Grâce à des améliorations au niveau de la simplicité, de la configuration, du déploiement et de la sécurité, Configuration Manager 2007 simplifie considérablement le déploiement des systèmes, l'automatisation des tâches, la gestion des conformités et la gestion de la sécurité basée sur les stratégies, améliorant ainsi la souplesse de l'entreprise.

Sans processus d’évaluation et de planification, vous ne pouvez pas disposer d’un ensemble de critères clairs vous permettant de décider si une mise à jour doit être ou non déployée. Vous ne saurez donc pas ce qui est nécessaire pour le déploiement et les procédures ne seront pas en place pour générer une version logicielle fiable et parfaitement testée.

Haut de page

Objectifs

Ce module vous permettra d'effectuer les opérations suivantes :

  • déterminer si un déploiement de mise à jour est véritablement nécessaire ;

  • planifier la diffusion de la mise à jour de logiciel ;

  • générer la version ;

  • mener les tests d’acceptation de la version.

Haut de page

S'applique à

Ce module s’applique à l’ensemble des produits et technologies Microsoft.

Haut de page

Comment utiliser ce module

Les étapes de base nécessaires à l’exécution des tâches d’évaluation et de planification à l’aide de WSUS et SMS sont décrites dans ce module. Toutefois, des instructions plus détaillées sont disponibles dans les bibliothèques techniques dont vous trouverez la liste ci-dessous.

Afin de tirer le meilleur parti possible de ce module :

  • Lisez la section Introduction du module « Processus de gestion des mises à jour ». Elle présente les quatre phases du processus de gestion des mises à jour et propose une introduction aux outils permettant la prise en charge de la gestion des mises à jour dans les environnements basés sur un système d’exploitation Microsoft Windows.

  • Vous trouverez des supports de référence détaillés dans les bibliothèques techniques WSUS et SMS. Ces bibliothèques sont disponibles aux adresses suivantes :

Haut de page

Présentation

La phase d’évaluation et de planification est la troisième phase du processus de gestion des mises à jour illustré à la figure 1.

Figure 1 Processus de gestion des mises à jour

Au cours de cette troisième phase, vous allez évaluer la mise à jour de logiciel et, si son déploiement est approuvé, vous allez le planifier dans l’environnement de production.

Le début de la phase d'évaluation et de planification correspond au moment où une requête de modification (RFC) pour une mise à jour de logiciel a été identifiée comme appropriée à votre environnement de production.

À la fin de la phase d’évaluation et de planification, vous devez avoir déterminé si la demande de modification doit être considérée comme urgente, avoir révisé et approuvé la requête et déterminé les tâches nécessaires pour le déploiement des modifications approuvées en production. Vous devez également avoir testé la mise à jour de logiciel dans un environnement semblable à celui de la production pour vérifier qu’elle ne compromet pas la sécurité des applications et des systèmes fondamentaux de l’entreprise.

Ce module met l’accent sur les conditions requises pour l’évaluation et la planification, à savoir :

  • déterminer les actions appropriées ;

  • planifier la diffusion de la mise à jour de logiciel ;

  • générer la version ;

  • mener les tests d’acceptation de la version.

Haut de page

Identification des actions appropriées

La requête de modification (RFC) détermine le type de changement requis dans l’environnement de production, comme le déploiement d’une mise à jour de logiciel, l’application de contre-mesures qui visent à réduire la vulnérabilité, ou les deux. Elle décrit également la modification requise de sorte que des actions puissent être entreprises.

La première étape de cette phase d’évaluation et de planification consiste à réviser le RFC et à déterminer la réponse la plus appropriée à une menace ou à une faille logicielle. Ceci implique les opérations suivantes :

  • attribution de priorité et classification de la requête ;

  • obtention de l’autorisation de déploiement de la mise à jour de logiciel.

Attribution de priorité et classification d’une requête de mise à jour de logiciel

Pour qu’une requête de mise à jour de logiciel soit autorisée, sa priorité et sa catégorie doivent être déterminées. Bien que la priorité et la catégorie soient à l’origine attribuées par l’initiateur de la requête et incluses dans le RFC, celles-ci peuvent être révisées, puis approuvées ou modifiées avant que la demande de modification ne soit autorisée.

Attribution de la priorité d’une mise à jour de logiciel

Le niveau de priorité est particulièrement important du fait qu’il détermine la rapidité avec laquelle une mise à jour de logiciel est transmise via le processus de modification. Les remarques suivantes peuvent vous permettre de déterminer le niveau de priorité d’une mise à jour de logiciel :

  • Quelles sont les principales ressources de l’entreprise ? Seront-elles exposées à une faille de sécurité potentielle ou à l’instabilité du système tant que la mise à jour du logiciel ne sera pas installée ? Vous devez attribuer une priorité aux demandes de modification en fonction de l’impact de la mise à jour ou de l'absence de mise à jour des ressources à haute valeur.

  • La mise à jour de logiciel va-t-elle s’appliquer à un système exécutant un service important de l’entreprise, une application métier ayant fait l’objet d’attaques par le passé ? Ceci peut être une bonne raison d’augmenter la priorité d’une demande de modification.

  • Avez-vous déployé des contre-mesures devant réduire l’exposition à une faille de sécurité particulière ? Ceci peut réduire la priorité de la demande de modification, bien que le déploiement de la mise à jour de logiciel demeure peut-être nécessaire pour éliminer la vulnérabilité.

  • Quelle est la menace de la vulnérabilité en question sur l’environnement de production ? Il se peut que de nombreux bulletins de sécurité et mises à jour de logiciels connexes ne s’appliquent qu’à quelques ordinateurs de votre environnement. Si la menace de la vulnérabilité est faible, le niveau de priorité de la requête peut être réduit.

Les tableaux ci-dessous peuvent vous aider à estimer la priorité de la requête par rapport aux autres requêtes. Le tableau 1 associe les niveaux de priorité aux délais d’exécution recommandés et aux délais d’exécution maximaux recommandés.

Tableau 1 : Priorités des mises à jour et délais d’exécution recommandés

Priorité Délai d’exécution recommandé Délai d’exécution maximal recommandé
Urgente Dans les 24 heures Dans les 2 semaines
Haut D’ici 1 mois D’ici 2 mois
Moyen Selon la disponibilité, déploiement d’un nouveau Service Pack ou d’une mise à jour cumulée incluant un correctif de vulnérabilité dans les 4 mois. Déploiement de la mise à jour de logiciel dans les 6 mois.
Faible Selon la disponibilité, déploiement d’un nouveau Service Pack ou d’une mise à jour cumulée incluant un correctif de vulnérabilité dans les 12 mois. Déploiement de la mise à jour de logiciel dans les 12 mois. Vous pouvez également décider de ne pas la déployer du tout.
Le tableau 2 fournit des exemples de facteurs qui peuvent augmenter ou réduire la priorité. **Tableau 2 : Facteurs affectant les priorités des mises à jour**

Facteur environnemental/organisationnel Ajustement de la priorité
Ressources à haute valeur et à haut risque affectées. Augmentation
Ressources identifiées comme cibles coutumières d’attaques. Augmentation
Facteurs de réduction en place, par exemple des contre-mesures réduisant la menace. Réduction
Ressources à faible valeur et faiblement exposées affectées. Réduction
**Demande de modification urgente** Si la vulnérabilité à laquelle répond la mise à jour de sécurité est déjà exploitée ou est sur le point de l’être, ou si la mise à jour corrige une instabilité du système rencontrée dans l’environnement de production, il se peut que vous deviez classer la requête comme « urgente », lui donnant la priorité sur toutes les autres modifications appliquées à l’environnement de production. ##### Classification d’une mise à jour de logiciel La catégorie d’une mise à jour de logiciel est importante car elle aide les personnes révisant la modification à comprendre l’impact qu’elle aura sur les systèmes et services dans l’environnement de production. Pour définir la catégorie (ou l’impact) de la demande de modification, vous devez déterminer : - Sur quelles machines la mise à jour de logiciel doit être installée et les rôles (gravité applicative) de ces machines. Une mise à jour de logiciel nécessitant, par exemple, qu’un ordinateur fondamental pour l’entreprise soit redémarré, aura un impact plus grand que celle ne le nécessitant pas. - Si des modifications supplémentaires sont nécessaires pour prendre en charge le déploiement de la mise à jour de logiciel. Si, par exemple, la mise à jour de logiciel s’applique uniquement au Service Pack actuel et que celui-ci n’est pas installé sur certains systèmes de production, il se peut qu’il ne soit pas possible de protéger ces systèmes contre une faille de sécurité particulière. Dans ce cas, l’impact et donc la catégorie de la demande de modification seront plus élevés, car le Service Pack et la mise à jour de logiciel doivent être tous deux déployés. - Si la mise à jour de logiciel peut être désinstallée une fois qu’elle a été installée. Dans le cas contraire, elle présente un plus grand risque pour l’environnement de production qu’une mise à jour pouvant être supprimée. Malgré la nécessité de déployer de telles mises à jour de logiciels pour fournir une protection contre une faille de sécurité spécifique ou pour répondre à une instabilité particulière du système, la catégorie de la demande doit en faire état. - L’impact présumé sur l’infrastructure du réseau. Le déploiement simultané d’une mise à jour de logiciel de taille importante sur plusieurs ordinateurs risque de réduire les performances du réseau et de nuire au bon fonctionnement de l'ensemble de votre environnement. Vous devez revoir minutieusement la totalité de la documentation relative à la mise à jour de logiciel et connaître la taille de la mise à jour et le nombre d’ordinateurs concernés par celle-ci. Ces informations peuvent aider à planifier correctement la diffusion. - Si certains services doivent être arrêtés, suspendus ou fermés pendant l’installation. Ceci risque d’affecter les services fondamentaux d’une entreprise ou d’empêcher un utilisateur final de travailler sur l’ordinateur pendant l’installation. Des informations supplémentaires sur la définition de la priorité et de la catégorie d’une demande de modification figurent à la section relative à la fonction de gestion des services (SMF) de gestion des modifications à l’adresse