Orientation sur la gestion des rustines

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 :

• Politique sur la sécurité du gouvernement^{Note en bas de page 3}
• Politique sur les services et le numérique^{Note en bas de page 4}
• Directive sur la gestion de la sécurité^{Note en bas de page 1}
• Plan stratégique des opérations numériques de 2018 à 2022^{Note en bas de page 5}
• Plan de gestion des événements de cybersécurité du gouvernement du Canada (PGEC GC)^{Note en bas de page 6}

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.

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 - 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.

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 Web^{Note 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.

É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 applications^{Note 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‑96^{Note 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 - 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.

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 rustines^{Note 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 existants^{Note 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 GC^{Note 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.