Orientation sur la gestion des rustines

Sur cette page

Introduction

Titres de la section

Objet et portée

La Directive sur la gestion de la sécuritéNote en bas de page 1 du Conseil du Trésor, à l’annexe B : Procédures obligatoires relatives aux mesures de sécurité de la technologie de l’information, exige des ministères qu’ils mettent en œuvre « des mesures pour protéger les systèmes d’information, leurs composants et l’information qu’ils traitent et transmettent contre les attaques qui exploitent les vulnérabilités dans les systèmes d’information pour toucher leur intégrité et qui pourraient avoir une incidence sur leur disponibilité ou leur confidentialité (p. ex., un code malveillant) ». Cela comprend la mise en œuvre de mesures correctives, comme l’application de rustines pour corriger les vulnérabilités. De plus, le Centre canadien pour la cybersécurité (CCC)Note en bas de page 2 accorde la priorité à la correction des systèmes d’exploitation et des applications comme deuxième mesure de sécurité de la TI la plus importante qu’une organisation peut prendre pour minimiser les intrusions et leurs incidences.

Le présent document donne des conseils sur l’établissement d’une stratégie efficace de gestion des rustines et détermine les indicateurs de rendement clés (IRC) à mesurer afin de faciliter une approche d’amélioration continue.

Les mesures contenues dans la présente orientation sont des minimums recommandés et sont fournies pour éclairer l’évolution d’une approche intégrée en matière de gestion des rustines.

La présente orientation s’harmonise avec les documents gouvernementaux suivants :

Public cible

Ce document vise les responsables de services de la TI, les administrateurs de services de la TI et les opérateurs de sécurité de la TI responsables de l’acquisition, de la mise à l’essai, de l’établissement des priorités, du déploiement et de la vérification des rustines de sécurité dans l’ensemble du gouvernement fédéral.

Aperçu de la gestion des rustines

Titres de la section

Les rustines sont des modifications ou des mises à jour apportées aux micrologiciels et aux logiciels pour corriger les lacunes fonctionnelles et de sécurité. L’application de rustines aux systèmes d’exploitation, aux applications et aux dispositifs est une activité essentielle pour assurer la sécurité des systèmes.

La gestion des rustines est une mesure de sécurité organisationnel clé prescrit par les Conseils en matière de sécurité de la technologie de l’information du CCC, ITSG-33 – Catalogue des mesures de sécurité (SI-2 Correction des défauts)Note en bas de page 12.

La gestion des rustines est le processus d’évaluation, d’acquisition, de mise à l’essai, d’établissement des priorités, de déploiement et de validation des rustines pour les produits et les systèmesNote en bas de page 7. Les activités répétitives et normalisées de gestion des rustines permettent de réaliser des économies en atténuant les lacunes et les vulnérabilités des logiciels, en réduisant au minimum l’exposition d’une organisation et en évitant les compromissions évitables. La gestion efficace des rustines exige la coordination de divers rôles et processus organisationnel afin de tenir à jour les configurations dans des environnements de la TI hétérogènes. Les opérateurs de sécurité et les opérateurs de service doivent travailler ensemble pour établir l’ordre des priorités des rustines des systèmes et des applications, les mettre à l’essai, les appliquer et les vérifier tout en tenant compte des exigences opérationnelles en matière de disponibilité.

Dépendances de la gestion des rustines

Les processus de gestion des rustines exigent une responsabilisation et une appropriation adéquates, ainsi qu’une bonne gouvernance et une bonne gérance. La gestion des rustines est l’une des composantes d’une stratégie de défense en profondeur qui devrait également inclure la conception d’une architecture sécurisée, la gestion intégrée des risques, un plan de continuité des activités et les fonctions liées aux opérations de sécurité, comme la surveillance et l’intervention en cas d’incident.

Le processus de gestion des rustines repose sur trois capacités opérationnelles de base, illustrées par la figure 2‑1 : Dépendances fondamentales de la gestion des rustines, qui doivent être en place pour en assurer l’efficience et l’efficacité.

Figure 2‑1 : Dépendances fondamentales de la gestion des rustines
Version textuelle ci-dessous:
Figure 2‑1 - Version textuelle

La figure 2-1 est un diagramme de Venn qui illustre comment la relation entre la gestion des vulnérabilités, de la configuration et du changement, et le répertoire et la découverte des actifs fait partie de l’ensemble du processus de gestion des rustines.

Répertoire et découverte des actifs

La gestion des rustines exige un répertoire complet et à jour des logiciels d’une organisation, ainsi que leurs versions et leur emplacement dans les hôtes connectés à un réseau. Les caractéristiques communes du répertoire et de la découverte des actifs, ou de la gestion des actifs, recoupent la gestion des vulnérabilités et un programme élargi de gestion des rustines. La capacité relative au répertoire et à la découverte des actifs comprend l’identification des applications sur les actifs, les micrologiciels sur les dispositifs, les versions et les vulnérabilités attribuées. Elle offre aussi des options de gestion à distance, par exemple la mise à jour, l’installation, la désinstallation, etc. L’attribution des actifs aux systèmes et la capacité de refléter la criticité opérationnelle sont des caractéristiques primordiales qui peuvent contribuer à éclairer les décisions relatives à la priorisation des rustines et au calendrier de déploiement, en particulier l’incidence sur la disponibilité des services.

La capacité de gestion des actifs permet à l’organisation de faire le suivi des logiciels et des micrologiciels non conformes (comme les versions expirées) déployés dans les environnements de la TI. Comme avantage secondaire, cette capacité appuie la rationalisation des applications, ce qui permet de dresser un répertoire des logiciels semblables afin de déterminer et d’éliminer les programmes redondants et les licences inutilisées.

Le répertoire et la découverte des actifs devraient comprendre une capacité de surveillance continue pour automatiser la découverte de nouveaux actifs de réseau et s’intégrer au processus ou à l’outil de gestion des changements et de la configuration de l’organisation afin de veiller à ce que la priorisation des rustines soit toujours fondée sur les renseignements actuels relatifs aux actifs.

Gestion des vulnérabilités

L’analyse des vulnérabilités et l’évaluation des vulnérabilités (EV) sont des éléments de la gestion des vulnérabilités et constituent une dépendance fondamentale de la gestion des rustines. Cette dépendance, du point de vue du processus de gestion des rustines, recoupe le répertoire et la découverte des actifs pour établir une corrélation entre les répertoires de logiciels et les vulnérabilités cernées.

L’analyse automatisée des systèmes en réseau à l’aide d’une capacité de VE intégrée offre les avantages suivants :

  • Indiquer l’ordre de priorité pour le déploiement de rustines pour les logiciels disponibles sur le marché.
  • Établir et quantifier le niveau d’exposition et qualifier le risque résultant de vulnérabilités non atténuées.
  • Fournir des mesures concernant le rendement de la gestion des rustines au fil du temps, ce qui permet à l’organisation de développer l’efficience et l’efficacité de son programme de gestion des rustines. 

Pour obtenir des renseignements détaillés sur les options technologiques et les capacités des plateformes de gestion des vulnérabilités, il est recommandé de consulter la publication SP 800‑40 Rev. 3 du NIST (en anglais seulement), Guide to Enterprise Patch Management TechnologiesNote en bas de page 7. Ce guide, publié à l’origine en 2013, établit une base solide pour comprendre la fonction des outils de gestion de la vulnérabilité. Toutefois, le domaine a évolué depuis et il est recommandé de faire d’autres recherches pour se tenir au courant des options et des capacités des plateformes modernes.

Une capacité de surveillance continue visant à automatiser l’évaluation de la vulnérabilité devrait être une fonction de la plateforme de gestion de la vulnérabilité. La mise en œuvre de cette capacité constitue une pratique exemplaire pour veiller à ce que la priorisation des rustines soit toujours fondée sur les renseignements actuels sur les risques. Remarque importante : Bien qu’elle ne soit pas visée par la présente orientation, la gestion des incidents et des événements cybernétiques repose également sur des données de gestion des vulnérabilités actualisées pour évaluer avec précision les incidences potentielles ou réelles d’un incident.

Les plateformes commerciales de gestion de la vulnérabilité ne peuvent généralement pas détecter les failles dans les applications commerciales personnalisées ou les applications PGPE. Le cycle de vie géré en fonction des risques de ces catégories d’applications devrait comprendre une évaluation périodique ciblée des vulnérabilités afin de cerner les défauts de logiciels et les lacunes de configuration.

Les applications personnalisées reposent souvent sur des composants, des ensembles ou des progiciels disponibles sur le marché ou en source ouverte sous-jacents. Les responsables d’applications doivent être conscients de ces dépendances et de leurs responsabilités à l’égard de la gestion des rustines par rapport à celles des fournisseurs de services. Le processus de gestion des rustines devrait aborder la marche à suivre pour faire face à ces circonstances.

Gestion de la configuration et du changement

La correction d’un logiciel constitue un changement de configuration dont devrait tenir compte un processus de gestion de la configuration et du changement. Les rustines et les mises à jour doivent faire l’objet d’un suivi dans le système ministériel de gestion du changement. Les plans d’application des rustines soumis dans le cadre de la gestion du changement doivent comporter des plans de contingence et de retour en arrière (voir la phase de validation du cycle de vie de la gestion des rustines pour plus de détails).

Les plateformes et les applications doivent être déployées dans une configuration renforcée, selon les 10 mesures de sécurité des TI du CCCNote en bas de page 2. Les fonctions qui sont activées par défaut, mais qui ne sont pas requises pour le traitement, devraient être désactivées afin de minimiser l’exposition et de réduire la nécessité d’appliquer d’urgence des rustines (voir la phase de l’évaluation du cycle de vie pour plus de détails).

Cycle de vie de la gestion des rustines

Titres de la section

La gestion des rustines est un processus à circuit fermé qui fait partie de la stratégie globale d’une organisation en matière d’intégrité des systèmes et de gestion des risques. La meilleure manière d’exécuter le processus est de le rendre reproductible et en grande partie automatisé au moyen d’un outil organisationnel qui intègre les fondements de la gestion de la vulnérabilité et du répertoire et de la découverte des actifs. L’outil permet une capacité de surveillance continue et exécute le processus cyclique décrit dans les sections qui suivent.

Figure 3‑1 : Gestion du cycle de vie des rustines
Version textuelle ci-dessous:
Figure 3‑1 - Version textuelle

La figure 3-1 est un diagramme de cycle qui montre les six étapes du cycle de vie de la gestion des rustines : notification, évaluation, acquisition, test, déploiement et validation. Chaque étape est ensuite décrite en détail dans les sections qui suivent.

Notification

Les déclencheurs du processus de gestion des rustines peuvent comprendre des notifications de vulnérabilité provenant :

  • D’un logiciel intégré de gestion des rustines : Le logiciel tient à jour un répertoire des applications et une base de données de définition des rustines, avisant les administrateurs lorsque de nouvelles mises à jour sont publiées et téléchargées à partir de sources fiables.
  • De la gestion des appareils mobiles : Une plateforme de gestion des appareils mobiles tels que les tablettes et les téléphones intelligents comprendra des notifications et des politiques pour la mise à jour à distance des applications des appareils.
  • De publications du CCC : Les alertes et les avis du CCC sont accessibles par un flux de dépêches et sur son site WebNote en bas de page 8. Les publications du CCC sont également envoyées à la boîte de réception générique des Opérations de sécurité de la TI de chaque organisation du GC, à partir de laquelle elles peuvent être acheminées aux boîtes aux lettres de l’équipe ou au personnel opérationnel.
  • D’un avis du fournisseur : Les fournisseurs individuels offrent habituellement un service d’abonnement pour signaler les rustines et les mises à jour. 
  • De processus opérationnels internes : Une organisation peut déclencher le processus de gestion des rustines à la suite de processus opérationnels internes, le plus souvent ceux qui sont associés à la sécurité, par exemple après un incident découlant d’une EV.
  • D’autres sources : Des rapports de médias, des médias sociaux, des entreprises de cybersécurité, des services de regroupement des vulnérabilités, des listes d’envoi, des fils RSS, etc.

Les organisations du GC doivent avoir une boîte aux lettres générique des Opérations de sécurité de la TI conformément au PGEC GCNote en bas de page 6. Le profil des mesures de l’ITSG-33 exige également la conformité pour la surveillance et la réception des publications de sécurité du CCC. (Voir la section SI-5 de la « Famille : Intégrité de l’information et des systèmes, Alertes, avis et directives de sécurité »Note en bas de page 12.)

Évaluation

La cote de priorité attribuée à une rustine par le fournisseur ou le développeur est un excellent indice de son importance et de la priorité à lui accorder. Toutefois, l’établissement des priorités des rustines au sein du GC est aussi une activité d’évaluation des risques qui tient compte du risque que représente une vulnérabilité dans le contexte de l’environnement opérationnel.

L’ITSB‑96 – Correction des systèmes d’exploitation et des applicationsNote en bas de page 9 du CCC décrit les facteurs dont les ministères du GC doivent tenir compte lorsqu’ils déterminent la priorité d’une rustine, y compris son incidence possible sur les actifs de grande valeur, le profil de la menace, la complexité et la probabilité de l’exploitation, et l’incidence des mesures d’atténuation sur son exposition. Les lignes directrices du CCC doivent être consultées et citées en référence lors de l’élaboration d’un cadre d’évaluation ministériel pour la priorité des rustines.

Échéancier du déploiement

Une fois que la priorité a été évaluée, il faut déterminer un délai de déploiement. Bien que l’échéancier du déploiement d’une rustine qui corrige la fonctionnalité puisse se fonder uniquement sur des préoccupations relatives à la réduction de l’incidence sur les activités, une rustine de sécurité, par défaut, doit avoir une priorité plus élevée. L’ITSB‑96Note en bas de page 9 du CCC donne aussi des conseils sur les délais de déploiement des rustines de sécurité au GC. Le tableau suivant en résume les recommandations :

Tableau 3‑1  : Échéancier proposé du déploiement du CCC
Priorité de la rustine Échéancier proposé du déploiement
Extrême Urgence : À déployer dans les 48 heures
Élevée À déployer dans les 2 semaines
Modérée À déployer lors de la prochaine mise à jour importante ou dans les 3 mois
Faible À déployer lors de la prochaine mise à jour importante ou dans l’année

L’échéancier du déploiement du CCC ne suggère que des délais. En réalité, une organisation devrait tenir compte de la tolérance au risque et de l’exposition à une vulnérabilité donnée et à des vecteurs d’attaque connexes dans le cadre d’une approche de correction fondée sur le risque, tout en tenant pleinement compte de leur profil de menace individuel. Les outils de gestion des rustines continuent d’améliorer l’efficacité du processus et permettent aux organisations d’accélérer l’échéancier du déploiement.

En règle générale, les organisations du GC devraient toujours accorder la priorité aux systèmes et services essentiels dans n’importe quel scénario de correction. Les systèmes et services essentiels sont définis par le SCT comme ceux dont la compromission sur le plan de la disponibilité ou de l’intégrité « porterait un préjudice élevé ou très élevé à la santé, à la sûreté, à la sécurité ou au bien-être économique des Canadiens et des Canadiennes, ou encore au fonctionnement efficace du gouvernement du Canada »Note en bas de page 3.

La figure 3‑2 illustre les étapes et la justification pour établir la bonne priorité des rustines et l’échéancier du déploiement correspondant. Lorsqu’il est utilisé, le processus doit également tenir compte des conditions particulières de chaque situation et des facteurs énumérés dans la section de l’évaluation, y compris les solutions de rechange existantes ou les mesures d’atténuation, les profils de menace et les détails de vulnérabilité, enfin les risques de dommages collatéraux, en particulier pour les actifs et services essentiels.

Figure 3‑2  : Incidence des vulnérabilités et échéancier déploiement des rustines
Version textuelle ci-dessous:
Figure 3‑2 - Version textuelle

La figure 3-2 présente un organigramme permettant de déterminer les mesures à prendre en réponse à une notification de vulnérabilité. Les étapes sont les suivantes :

  • Après réception d’une notification, l’organisation détermine si elle a déployé le produit et la ou les versions concernées, et si les composants vulnérables du logiciel sont activés. Si le logiciel est déployé, mais que le ou les composants vulnérables ne sont pas activés, une rustine peut être déployée lors de la prochaine mise à jour ou dans l’année.
  • Si le ou les composants vulnérables sont activés, l’organisation détermine alors si l’incidence sur la sécurité est faible, moyenne, élevée ou extrême.
  • Une vulnérabilité à faible incidence peut être traitée lors de la prochaine mise à jour ou dans l’année. Pour toutes les autres notations, l’organisation doit poursuivre le processus afin de déterminer si une solution de contournement pour atténuer la vulnérabilité existe et est mise en œuvre.
  • Si la réponse est oui, la mise à jour peut être déployée lors de la prochaine mise à jour ou dans l’année. Si aucune mesure d’atténuation n’a été prise, l’évaluation de l’incidence sur la sécurité est utilisée pour déterminer la prochaine ligne de conduite.
  • Pour les vulnérabilités d’incidence moyenne et élevée sans risque de dommages collatéraux importants, le déploiement d’une mise à jour peut avoir lieu dans les trois mois.
  • Pour les vulnérabilités à incidence moyenne ou élevée qui pourraient entraîner des dommages collatéraux importants, par exemple en exposant des actifs supplémentaires à un risque de compromission, le déploiement des rustines devrait avoir lieu dans les deux semaines.
  • Si l’incidence d’une vulnérabilité est jugée comme étant extrême, mais sans risque de dommage collatéral important, la fenêtre de deux semaines pour le déploiement des rustines s’applique également.
  • Pour les vulnérabilités d’incidence extrêmes qui comportent également un risque de dommages collatéraux importants à d’autres actifs, un calendrier de déploiement d’urgence des rustines dans les 48 heures suivant la notification s’applique.

Acquisition

Les rustines sont couramment acquises auprès du fournisseur de logiciels ou d’une autre source fiable, par exemple une société de développement de logiciels communautaires ou les dépôts Linux standard. Le logiciel intégré de gestion des rustines peut automatiser le téléchargement et la vérification des rustines, habituellement à l’aide de méthodes de vérification fondées sur les totaux de contrôle de l’intégrité et les signatures numériques.

Si une rustine est obtenue par téléchargement manuel, la source et l’intégrité du progiciel doivent être confirmées avant son déploiement.

Essais

La mise à l’essai des rustines peut se faire dans un réseau d’essai ou de type bac à sable qui simule l’environnement de production. Il s’agit de l’approche idéale, mais elle est aussi la plus coûteuse et la moins pratique. La virtualisation peut servir à minimiser les coûts du matériel et à tirer profit du déploiement d’une vaste gamme de systèmes dans un environnement d’essai, mais elle ne réglera pas les frais généraux liés au maintien d’un environnement parallèle.

La solution de rechange recommandée consiste à tirer parti d’une communauté d’utilisateurs dans toutes les unités opérationnelles de l’organisation comme banc d’essai de production pour le déploiement de rustines. Les commentaires concernant les défauts peuvent servir à déterminer si le déploiement d’une rustine a une incidence opérationnelle. Cette incidence doit ensuite être mesurée par rapport au risque de retarder le déploiement ou de ne pas apporter de rustines et de recourir à une solution de rechange.

Les solutions de rechange sont temporaires, comme la désactivation de la fonctionnalité vulnérable ou la mise en œuvre de mesures d’accès pour limiter son exposition. Il est envisageable d’y recourir si des défauts sont décelés et que l’attente d’une rustine fonctionnelle n’est pas une option viable en raison du risque accru.

Les rustines peuvent être testées individuellement ou encore regroupées afin de veiller à ce que les défauts soient détectés avant le déploiement à grande échelle.

Déploiement

Le logiciel intégré de gestion des rustines est la méthode privilégiée pour la distribution des mises à jour logicielles. Les rustines peuvent être regroupées ou appliquées progressivement et devraient être échelonnées dans l’ensemble de l’organisation afin de veiller à ce qu’aucune interruption de service ne se produise si une anomalie se matérialise et n’ait pas été révélée au cours de la phase d’essai.

La mise à jour automatique est une fonction commune à de nombreuses applications, mais généralement non recommandée pour un environnement organisationnel, étant donné que son utilisation supprime les essais de rustines du processus, à l’exception de ceux effectués par le fournisseur. Cela dit, la mise à jour automatique peut parfois être la méthode de déploiement privilégiée, par exemple dans le cas des navigateurs Web et des applications mobiles. D’autres scénarios peuvent s’appliquer, et les organisations du GC doivent faire preuve de diligence raisonnable en matière de gestion des risques lorsqu’elles décident s’il faut activer la fonctionnalité de mise à jour automatique, et dans quels cas.

Noter aussi que le déploiement intégré n’est pas toujours faisable, comme dans le cas des PGPE ou des applications personnalisées. Les options de déploiement de rechange, comme l’application de rustine manuscrite ou scénarisée, devraient être prises en compte dans la stratégie de gestion des rustines de l’organisation pour traiter les valeurs aberrantes et les exceptions.

Validation

Une vérification du succès du déploiement des rustines et des taux d’échec devrait être effectuée après chaque déploiement afin de déterminer les valeurs aberrantes et de repérer et de corriger les défaillances de l’installation des rustines. Les fonctions du répertoire et de la découverte des actifs d’une suite de gestion intégrée des rustines refléteront l’état du déploiement et fourniront les statistiques pour répondre aux exigences des IRC et de l’entente sur les niveaux de service définies dans la stratégie de l’organisation.

Il peut être nécessaire d’exécuter un retour en arrière si le déploiement d’une rustine entraîne des incidences imprévues sur les systèmes de production. Les renseignements tirés de l’enquête et de la correction des défaillances d’installation devraient être utilisés pour améliorer le programme de gestion des rustines et réduire au minimum la nécessité d’effectuer un retour en arrière et des rustines à l’avenir.

Gestion des rustines d’urgence

Les circonstances exigeant de déclarer une situation de rustine d’urgence varient et dépendent fortement des actifs, du micrologiciel, des systèmes d’exploitation et des applications déployés dans l’infrastructure d’une organisation. La décision de déployer immédiatement une rustine critique devrait se fonder sur la gestion des risques, comme il est indiqué à la section 3.2.1 Échéancier du déploiement.

Dans le contexte d’un scénario de gestion des rustines d’urgence à l’échelle du gouvernement, le Plan de gestion des événements de cybersécurité du gouvernement du CanadaNote en bas de page 3 précise quels intervenants et quelles mesures sont nécessaires afin de veiller à ce que les événements de cybersécurité soient traités de façon cohérente, coordonnée et rapide. Les événements de cybersécurité comprennent les avis de vulnérabilité qui peuvent obliger les organisations du GC à exécuter des procédures de gestion des rustines d’urgence.

Ce scénario est lancé dans la phase de notification du cycle de vie de la gestion des rustines, par la publication d’un Bulletin cybernétique par le CCC.

La décision de publier un Bulletin cybernétique est prise par les principaux organismes chargés de la sécurité (POCS) et les intervenants spécialisés des POCS et peut être prise pour un événement de niveau 2 ou 3 du PGEC (voir le PGEC GCNote en bas de page 6pour obtenir des renseignements détaillés sur les niveaux du PGEC).

Figure 4‑1 : Niveaux d’intervention du PGEC GC
Version textuelle ci-dessous:
Figure 4‑1 - Version textuelle

La figure 4-1 représente les quatre niveaux de réponse du GC qui régissent les activités de gestion des événements de cybersécurité du GC et qui dictent la nécessité et le degré de réponse de l’organisation. La figure utilise quatre boîtes empilées, le niveau de coordination requis étant indiqué à droite des boîtes.

  1. Niveau 1 – Réponse du ministère
    (nécessite une coordination normalisée)
  2. Niveau 2 – Réponse limitée à l’échelle du GC
    (nécessite la coordination du PGEC GC)
  3. Niveau 3 – Réponse globale à l’échelle du GC
    (nécessite la coordination du PGEC GC)
  4. Niveau 4 – Réponse d’urgence (crise)
    (nécessite la coordination du PFIU)

On publie normalement un Bulletin cybernétique lorsqu’une vulnérabilité critique qui s’applique à un produit et à une version qui sont omniprésents dans le GC a une incidence d’exploitation extrême, est peu susceptible d’être protégée par des mesures d’atténuation, et peut entraîner des dommages collatéraux importants aux systèmes ou services critiques.

Après la réception d’un Bulletin cybernétique, les organisations du GC doivent effectuer une évaluation des incidences afin de déterminer leur exposition à la compromission de la vulnérabilité et ses incidences potentielles. Des rustines d’urgence devraient être apportées si l’incidence potentielle sur la sécurité est extrême et que les dommages collatéraux probables sont importants, conformément à l’évaluation des POCS.

Lorsqu’un déploiement d’urgence est déclaré, les phases restantes du cycle de vie ne changent guère. Cependant, le calendrier pour les phases des essais et du déploiement doivent être simplifiés pour concorder avec l’urgence d’atténuer la vulnérabilité.

Enfin, la phase de validation pourrait nécessiter une rétroaction à l’intention du CCC au sujet de l’état d’avancement ou de l’achèvement des efforts d’atténuation.

Environnements fonctionnels

Titres de la section

Les sous-sections suivantes décrivent brièvement les environnements fonctionnels les plus fréquents du GC. Cette liste n’est pas exhaustive ni ne fait pas autorité, et elle ne couvre pas toutes les conditions d’exploitation potentielles des systèmes du GC. Le rôle et les responsabilités attribués au processus de gestion du changement, tant à l’extérieur qu’à l’intérieur d’une organisation, sont somme toute uniques, tiennent compte de la dépendance de l’organisation à l’égard des fournisseurs de services externes, et peuvent s’appuyer sur des mécanismes contractuels, des pouvoirs contractuels ou des protocoles d’entente.

Infrastructure organisationnelle

Les ministères et organismes du GC sont responsables de leur propre infrastructure de la TI et de la mise en œuvre des outils et des processus visant à respecter les délais normaux pour les mesures correctives et à assurer des délais d’intervention rapides en cas de déploiement d’urgence ou critique de rustinesNote en bas de page 1. Pour les organisations qui fonctionnent de façon autonome, cette infrastructure peut comprendre des serveurs, de l’équipement réseau, des postes de travail, des applications, etc. Quant à celles qui relèvent de SPC, l’infrastructure est un sous-ensemble de ce qui précède.

Services partagés Canada

SPC agit à titre de fournisseur de services pour les ministères du GC et a élaboré sa propre Norme sur la gestion des rustines qui définit les étapes, les rôles et responsabilités visant à assurer la gestion efficace des rustines de l’infrastructure de SPC dans les centres de données organisationnels et les réseaux clients existantsNote en bas de page 10.

Les responsabilités de SPC ne s’étendent pas à l’infrastructure organisationnelle susmentionnée. Par conséquent, les ministères desservis par SPC sont tenus de coordonner les activités de gestion du changement et de la configuration avec SPC, y compris toutes les activités de gestion des rustines, afin d’en assurer la mise à l’essai, l’établissement des priorités, le déploiement et la validation appropriés.

Fournisseur de services d’informatique en nuage et fournisseurs de services gérés

La Stratégie d’adoption de l’informatique en nuage du gouvernement du Canada prévoit une approche d’informatique en nuage d’abord pour la prestation de services de la TI au sein du GCNote en bas de page 11. Les fournisseurs de services d’informatique en nuage peuvent servir à fournir un ou plusieurs des modèles de services d’informatique en nuage définis de l’infrastructure comme service, de la plateforme comme service et de logiciel comme service.

Les utilisateurs de l’informatique en nuage du GC qui font appel à un fournisseur de services informatiques en nuage ou à un tiers, comme un fournisseur de services gérés, doivent tenir compte de la gestion des rustines et de la gestion des rustines d’urgence dans leurs contrats.

Indicateurs de rendements clé

Une stratégie de gestion des rustines devrait inclure des mesures pour les IRC afin d’en évaluer l’efficacité et l’efficience. Un système de gestion intégrée des rustines devrait fournir des capacités d’établissement de rapports pour permettre d’inclure ces mesures au fil du temps. Voici quelques exemples d’IRC :

  • Couverture :
    • Pourcentage des systèmes et des applications de l’organisation répertoriés et couverts par la gestion automatisée des rustines.
  • Efficience et efficacité :
    • Fréquence à laquelle les hôtes sont automatiquement vérifiés pour s’assurer de leur conformité.
    • Fréquence à laquelle les répertoires d’actifs sont mis à jour automatiquement.
    • Temps minimum, moyen ou maximum pour corriger X pourcentage des hôtes.
    • Pourcentage des systèmes corrigés dans les jours X, Y et Z suivant le déploiement.
    • Pourcentage des hôtes opérationnels au sein de l’organisation entièrement corrigés à un moment donné.
    • Nombre d’hôtes à incidence extrême, élevée, modérée et faible, ou de vulnérabilités non corrigées, pour les hôtes organisationnels en tout temps.
    • Temps moyen écoulé entre la disponibilité d’une rustine et sa mise en œuvre en production par niveau de notation.
    • Pourcentage des hôtes corrigés automatiquement, en partie automatiquement (dans le cas de rustines regroupées dans un progiciel) ou manuellement.
    • Pourcentage de rustines déployées selon l’échéancier proposé du déploiement.

Des rapports réguliers sur les IRC permettront à l’organisation d’établir une base de référence pour le rendement de son processus de gestion des rustines et de l’améliorer rapidement.

Détails de la page

Date de modification :