Organigramme du processus de gestion des correctifs (tester, approuver,…

Modèle d'organigramme de gestion des correctifs : réception et applicabilité des conseils, triage d'urgence ou de routine, tests de régression, autorisation de modification, déploiement en anneau, restauration, vérification de nouvelle…

Utiliser ce modèle

Qu'est-ce que le processus organigramme du processus de gestion des correctifs (tester, approuver,… ?

La gestion des correctifs est le cycle permanent qui transforme un avis de fournisseur en une mise à jour installée, vérifiée et attestée sur chaque actif auquel il s'applique. Le déclencheur est externe : un fournisseur publie un correctif, un flux de sécurité contient un avis ou une analyse signale une mise à jour manquante, et le chronomètre démarre, que le moment soit opportun ou non. Le guide du NIST sur la planification de la gestion des correctifs d'entreprise définit l'ensemble de l'activité comme une maintenance préventive de la technologie, ce qui en est la description honnête : un travail de routine assorti d'un délai. Le graphique ci-dessous suit un avis de bout en bout : comparé à l'inventaire des actifs, évalué en fonction de son exposition et de sa criticité, acheminé soit vers le chemin d'urgence, soit vers le cycle mensuel, testé par rapport au service qu'il touche, autorisé en tant que changement, annoncé, déployé en anneaux avec un chemin de restauration, puis réanalysé, signalé et fermé.

Il s'agit du pipeline de correctifs, et non du programme de vulnérabilité qui l'alimente ni du processus de modification qui l'autorise. La gestion des vulnérabilités est responsable du calendrier d'analyse, de l'inventaire des découvertes, des évaluations des risques et des délais de remédiation pour tous les types de correctifs, dont l'application de correctifs n'est qu'un exemple ; lorsqu'il décide qu'une mise à jour particulière doit être appliquée, ce graphique représente ce qui se passe ensuite. La gestion du changement est propriétaire de la demande, du tableau et du calendrier en général, et apparaît ici comme deux étapes plutôt que comme le sujet. Le déploiement de logiciels couvre vos propres artefacts de construction passant d'un pipeline à la production ; l'application de correctifs déplace le binaire de quelqu'un d'autre sur un système que vous n'avez pas écrit et que vous ne pouvez pas déboguer, c'est pourquoi les tests et la restauration ont une grande part du poids dans ce diagramme. Considérez-le comme un point de départ pour vous adapter à vos propres procédures, obligations réglementaires et examens de sécurité plutôt que comme un contrôle que vous pouvez adopter tel quel.

Quatre décisions portent le processus. « Patch d'urgence ou cycle de routine ? se trouve dans le couloir de sécurité parce que les personnes qui comprennent l'exposition doivent donner le ton, et c'est ce qui empêche le cycle de routine d'être suspendu à chaque fois qu'un avertissement est fort. « Le correctif réussit les tests ? » et « L'anneau pilote est sain ? les deux appartiennent au propriétaire de l'application plutôt qu'à l'administrateur du correctif, car l'outil qui installe une mise à jour ne peut pas vous dire si le service fonctionne toujours par la suite. « Exception de risque acceptée par le propriétaire ? est délibérément dessiné comme une décision avec une branche de refus : un système qui ne peut pas être corrigé est une décision commerciale avec un propriétaire et une date d'expiration, pas un ticket qui vieillit tranquillement. L'étape de vérification à la fin ferme la boucle, car un rapport de déploiement et une nouvelle analyse propre sont des affirmations différentes sur le même domaine.

Ce que couvre cet organigramme

Dans ce modèle

  • Cinq couloirs (équipe de sécurité/vulnérabilité, administrateur de correctifs, gestionnaire des modifications, propriétaire de l'application et centre de services/utilisateurs) répartis en six phases : conseil et portée, évaluation et priorisation, test, autorisation et planification, déploiement, vérification et rapport
  • Prise en charge qui commence par un avis plutôt que par un résultat d'analyse : le couloir de sécurité compare la libération à l'inventaire des actifs et répond "Actifs concernés dans la succession ?", avec un terminateur "Clôturer l'avis comme non applicable" afin qu'un non considéré soit enregistré plutôt que supposé.
  • La criticité est divisée en « Correctif d'urgence ou cycle de routine ? », qui envoie une faille activement exploitée sur un chemin accéléré et regroupe tout le reste dans la référence mensuelle, de sorte que le cycle planifié n'est pas suspendu à chaque fois qu'un avis est bruyant.
  • Une boucle de test qu'aucun outil ne peut raccourcir : le correctif est envoyé dans un environnement de test, le propriétaire de l'application exécute des tests de régression et répond "Le patch réussit les tests ?", et un échec atterrit sur "Correctif du fournisseur attendu à temps ?" plutôt que de réessayer à l'aveugle
  • Autorisation avant déploiement : "Changer **autorisé** pour la fenêtre ?" renvoie une requête légère pour qu'elle soit retravaillée, le gestionnaire des modifications réserve la fenêtre de maintenance et le centre de services annonce la panne avant que quoi que ce soit ne soit installé
  • Déploiement de l'anneau avec deux sorties : « Anneau pilote sain ? » achemine une régression vers « Exécuter le plan de restauration », « Une nouvelle analyse confirme le correctif appliqué ? » recherche les actifs manqués par un rapport de déploiement et un système non patchable atteint « Enregistrer une exception de risque limitée dans le temps »

Quand utiliser ce modèle

  • Vous écrivez ou réécrivez une procédure de gestion des correctifs et avez besoin d'une idée de qui évalue, qui teste, qui autorise et qui vérifie
  • Les correctifs continuent de dépasser leur date limite et vous devez voir s'ils se bloquent lors des tests, lors du tableau des modifications ou lors de la fenêtre de maintenance.
  • Vous configurez des groupes de correctifs, des anneaux et des fenêtres de maintenance dans un outil de gestion et souhaitez que le processus soit convenu avant que l'outil n'en code un pour vous.
  • Une mauvaise mise à jour a interrompu un service et la restauration a été improvisée. Le déclencheur de restauration et la personne autorisée à l'appeler doivent maintenant figurer sur le graphique.
  • Un auditeur ou un client vous a demandé comment les mises à jour de sécurité parviennent à vos systèmes, comment les exceptions sont approuvées et comment prouver que les correctifs ont réellement été reçus.

Comment cela fonctionne

  1. Renommez les voies selon vos rôles

    Remplacez l'équipe de sécurité/vulnérabilité, l'administrateur de correctifs, le gestionnaire des modifications, le propriétaire de l'application et le centre de services/utilisateurs par les rôles que vous avez réellement. Dans une petite équipe, l'analyste de sécurité et l'administrateur des correctifs sont la même personne. Fusionnez donc ces voies plutôt que d'effectuer un transfert qui n'arrive jamais. Gardez le propriétaire de l’application séparé, car c’est dans cette voie que se situent les décisions en matière de tests.

  2. Écrivez votre déclencheur d'urgence sur la décision de triage

    À côté de « Correctif d'urgence ou cycle de routine ? », écrivez ce qui fait d'un correctif une urgence en termes qu'un ingénieur de garde peut appliquer : preuve d'exploitation active, actif accessible sur Internet, aucune solution de contournement utilisable. Un score de gravité décrit la faille, pas votre exposition, alors nommez les autres entrées que vous utilisez (le catalogue de vulnérabilités exploitées connues de CISA est courant) et indiquez qui peut passer l'appel en dehors des heures d'ouverture.

  3. Définir un délai de remédiation par tranche de gravité

    Écrivez la date limite pour chaque bande à côté de l’étape d’évaluation. Certains sont définis pour vous : si vous acceptez des paiements par carte, PCI DSS nécessite des correctifs de sécurité critiques sur les systèmes concernés dans un délai d'un mois après la publication et tout le reste dans un délai que vous définissez et justifiez, et les contrôles CIS demandent des correctifs automatisés pour le système d'exploitation et les applications au moins une fois par mois. Choisissez des numéros que vous pouvez rencontrer au cours d’un mauvais mois.

  4. Dites ce qu'est le domaine de test et ce que signifie une réussite

    Indiquez ce que contient l'environnement de test, à quel point il est proche de la production et ce que le propriétaire de l'application vérifie réellement dans « Le correctif réussit les tests ? ». Nommez les transactions qui doivent encore être terminées, les interfaces qui doivent encore s'authentifier et les rapports qui doivent encore être exécutés. Un correctif qui s'installe proprement et interrompt un travail nocturne a échoué au test, et seule une vérification nommée le détecte.

  5. Définir les cercles, le temps de cuisson et la fenêtre

    Dites quelles machines se trouvent dans l'anneau pilote et pourquoi elles sont représentatives, combien de temps vous attendez avant de passer à l'anneau suivant et quelle fenêtre de maintenance utilise chaque anneau. Les fournisseurs à cadence fixe facilitent la planification : les mises à jour de sécurité mensuelles de Microsoft arrivent le deuxième mardi, avec des versions hors bande lorsque quelque chose ne peut pas attendre la suivante.

  6. Acceptez le déclencheur de restauration et la règle d'exception

    Décidez du déclencheur de restauration avant d'en avoir besoin (quels symptômes, mesuré comment et qui peut l'appeler sans convoquer de réunion) et écrivez les étapes à côté de « Exécuter le plan de restauration ». Définissez ensuite la règle d'exception : ce qu'un contrôle compensatoire doit réaliser, qui peut accepter le risque résiduel, la durée de vie maximale d'une exception et que se passe-t-il le jour de son expiration.

  7. Marchez contre deux vrais conseils

    Prenez deux avis récents, un de routine et un que vous avez traité en cas d'urgence, et tracez les deux dans le graphique. Chaque étape que quelqu'un décrit et qui n'est pas dessinée, et chaque case qui, dans la pratique, est ignorée, est une découverte qui mérite d'être prise en compte avant de publier. Lisez ensuite votre registre d'exceptions par rapport à celui-ci : une exception en direct sans date de révision est l'écart que ce processus vise à combler.

Questions fréquentes

Quelles sont les étapes d’un processus de gestion des correctifs ?

Un avis ou une version de correctif arrive du fournisseur ou d'un flux de sécurité, et l'équipe de sécurité le compare à l'inventaire des actifs ; un avis qui ne touche à rien dans la succession est classé comme non applicable plutôt qu'ignoré. Les actifs concernés sont évalués en fonction de leur exposition, de leur exploitabilité et de leur criticité, et le correctif est acheminé soit vers le chemin d'urgence, soit vers la référence mensuelle. Il est déployé dans un environnement de test et le propriétaire de l'application exécute des tests de régression. Une passe produit une demande de modification avec un plan de restauration ; un échec demande si un correctif du fournisseur est attendu à temps, et si ce n'est pas le cas, un contrôle compensatoire et une exception limitée dans le temps sont pris en compte à la place. Une fois le changement autorisé, la fenêtre est réservée et annoncée, le patch est envoyé à un anneau pilote puis aux anneaux restants. Une nouvelle analyse confirme qu'il a effectivement atterri, les actifs manqués sont recherchés et le cycle se termine par un rapport de conformité.

Quelle est la différence entre la gestion des correctifs et la gestion des vulnérabilités ?

La gestion des vulnérabilités est le programme : un inventaire des actifs, un calendrier d'analyse, des résultats triés et notés, des délais de remédiation par gravité, des propriétaires attribués et des mesures communiquées à la direction. La gestion des correctifs est l’un des moyens par lesquels un résultat est corrigé, et le plus important. La distinction est importante dans les deux sens. Toutes les vulnérabilités ne disposent pas d'un correctif, car les changements de configuration, la désactivation d'une fonctionnalité, la segmentation du réseau et les mises à niveau de version sont tous des résultats proches ; et tous les correctifs ne sont pas liés à une vulnérabilité, car les correctifs fonctionnels et de stabilité passent par le même pipeline. En pratique, les deux partagent un inventaire des actifs et une évaluation des risques et passent le relais en un seul point : la gestion des vulnérabilités décide que cette mise à jour doit être appliquée à cette date, et la gestion des correctifs est tout entre cette décision et une installation vérifiée.

À quelle vitesse les correctifs de sécurité doivent-ils être appliqués ?

Fixez des délais par tranche de gravité et par exposition, et fixez ceux que vous pouvez respecter au cours d'un mauvais mois plutôt que des délais ambitieux. Certains sont définis pour vous. La norme PCI DSS exige que les correctifs de sécurité critiques sur les systèmes concernés soient installés dans le mois suivant leur publication, les autres correctifs applicables étant appliqués dans un délai défini et justifié par l'entité. Les contrôles CIS demandent une gestion automatisée des correctifs du système d'exploitation et des applications sur une base mensuelle ou plus fréquente. Les agences civiles fédérales américaines s'efforcent de rendre contraignantes les directives CISA avec des délais beaucoup plus courts et basés sur les risques pour les vulnérabilités du catalogue des vulnérabilités exploitées connues ; ces directives ne lient pas les organisations privées, mais le catalogue constitue un outil de priorisation utile pour chacun. Quels que soient les délais que vous adoptez, mesurez la conformité à partir d’une nouvelle analyse plutôt qu’à partir du rapport de réussite de l’outil de déploiement.

Que faites-vous des systèmes qui ne peuvent pas être corrigés ?

Certains systèmes ne peuvent réellement pas prendre la mise à jour : une appliance que le fournisseur ne supporte plus, un instrument dont le fournisseur n'a pas qualifié le patch, une application dont le contrat de support interdit la modification, ou encore une machine dont le temps d'arrêt coûte plus cher que le risque qu'il comporte. La réponse est de ne pas laisser le ticket ouvert. Appliquez un contrôle compensatoire qui réduit l'exploitabilité de cette faiblesse spécifique (segmentation, suppression du service exposé, accès plus strict, surveillance supplémentaire) et enregistrez une exception limitée dans le temps nommant le contrôle, le risque résiduel, la personne qui l'a accepté et la date à laquelle il est examiné. Si personne n'accepte le risque, le système passe à un plan de remplacement ou de déclassement, c'est pourquoi la décision d'exception sur ce tableau comporte une branche de refus. Les exceptions qui n'expirent jamais sont la manière dont un domaine accumule des systèmes non corrigés en permanence.

La gestion des correctifs est-elle un processus ITIL et qui autorise un déploiement ?

Pas sous ce nom. ITIL 4 décrit 34 pratiques de gestion plutôt que des processus, et la gestion des correctifs n'en fait pas partie ; le travail s'étend à l'activation du changement, à la gestion des versions et à la gestion du déploiement, la gestion de la sécurité de l'information définissant l'appétit pour le risque. C’est une question de dénomination plutôt qu’une raison pour redessiner quoi que ce soit. L'autorisation d'installation sur les systèmes de production passe normalement par l'activation des modifications, ce qui correspond à l'option « Modification autorisée pour la fenêtre ? » la décision représente ici. L'arrangement sur lequel la plupart des équipes optent est un modèle de changement standard pré-approuvé pour les correctifs de routine et testés qui suivent un cycle publié, un changement normal pour tout ce qui est inhabituel ou à fort impact, et un itinéraire de changement d'urgence pour les failles activement exploitées, avec l'enregistrement d'urgence rédigé immédiatement après plutôt que ignoré.

Où ce processus s'inscrit

Dans la plupart des opérations, ce processus suit Organigramme du processus de gestion des vulnérabilités (analyse jusqu'à la….

Précède

Fait partie de

Fonctionnalités QueryChart pour ce processus

Utiliser ce modèle

Browse all Modèles de processus informatiques et ITSM