Lignes directrices en matière de gestion des correctifs

But
Portée
Responsabilités
Recommandations en matière de correctifs
Comment

But

L’application rapide des correctifs s’avère l’une des solutions les plus efficaces et économiques qu’un organisme peut apporter pour atténuer le risque de menaces en matière de cybersécurité. La mise en place précoce des correctifs, comme les mises à jour de sécurité, réduit le risque d’exposition aux vulnérabilités informatiques.

Ce document définit les lignes directrices pour la gestion de correctifs au sein du Service numérique canadien (SNC).

Portée

Ces lignes directrices mettent l’accent sur l’ensemble des ressources et services développés par le SNC et sur le personnel du SNC qui les crée, les déploie ou les entretient.

Responsabilités

IFS interne

L’ingénierie de fiabilité des sites (IFS) assure l’entretien de tout outil développé par l’équipe de l’IFS (intégrations GitHub sur mesure, gestion secrète, outils de test de charge à l’échelle du SNC) et utilisé par les équipes du SNC.

L’IFS aide également à mettre au jour les problèmes de sécurité pour permettre aux équipes d’y remédier.

Équipes du SNC

Les responsables du développement du SNC et leurs équipes ont pour responsabilité de veiller à l’entretien des logiciels gérés par leurs soins à l’aide de mises à jour et de correctifs réguliers.

S’il n’existe pas de correctif disponible pour une vulnérabilité connue, les équipes du SNC ont la responsabilité de trier les vulnérabilités concernées et de déterminer d’autres approches à adopter pour atténuer les risques.

Les équipes du SNC ont pour responsabilité de dresser un inventaire exhaustif et précis des ressources.

Équipe des services de base de la plateforme

L’équipe des services de base de la plateforme a pour responsabilité de régulièrement évaluer la conformité du SNC avec les normes en matière de gestion des correctifs. Elle offre également des conseils à tous les groupes de parties prenantes concernant les problèmes de sécurité et la gestion des correctifs.

Recommandations en matière de correctifs

Les responsables d’équipe du SNC ou leurs représentants sont responsables d’évaluer les composantes de système et les logiciels dont ils ou elles assurent la gestion ou la supervision et de remédier aux éventuels problèmes connexes.
Tous les correctifs ou changements de configuration doivent être appliqués aux composantes de système et aux logiciels dans le respect des délais précisés dans la planification des correctifs ci-dessous.
Les correctifs pour les vulnérabilités de niveau « critique / très élevé » doivent être appliqués dans un délai de sept (7) jours
Si le déploiement de correctifs pour les vulnérabilités de niveau « critique / très élevé » n’est pas possible dans un délai de sept (7) jours, il faut appliquer les contrôles de compensation appropriés ou employer des moyens d’atténuation temporaires.
S’il n’existe aucune correction disponible pour remédier à une vulnérabilité, le ou la chef·fe en charge de la situation doit approuver tout contrôle de compensation ou d’atténuation ou, si aucune solution n’est disponible, approuver l’acceptation du risque.
Les étapes de correction doivent être documentées par les responsables d’équipe et des délais doivent être déterminés pour l’évaluation et l’application de correctifs futurs.
Il est possible qu’il faille respecter des délais plus brefs pour l’application de correctifs en fonction de la gravité de la vulnérabilité et de ses conséquences potentielles ou réelles (comme c’est le cas pour les vulnérabilités de type « zero-day »).

Comment?

Les équipes doivent maintenir à jour toutes les bibliothèques de systèmes et tous les logiciels en y incorporant de petites modifications progressives à un rythme gérable et régulier.

Automatisation de la gestion de correctifs

Ajoutez votre projet à Renovate.

Les équipes peuvent activer l’application GitHub Renovate dans le référentiel GitHub du projet. Cela crée une demande de tirage (pull request) pour la configuration dans Renovate. Une fois la fusion de la configuration effectuée, utilisez le tableau de bord des dépendances pour créer et fusionner la demande de tirage relative à la dépendance.

Planification des correctifs

Versions mineures et mises à jour correctives

Chaque sprint devrait compter un élément à tester et fusionner les demandes de tirage liées à la version mineure, celles liées à la mise à jour corrective et celles épinglées antérieurement au fur et à mesure de leur création chaque semaine.

Versions majeures

Les mises à jour majeures doivent être évaluées sur le tableau de bord des dépendances et abordées au minimum une fois tous les deux sprints. Il est possible que la mise à jour du code soit plus longue pour une version majeure. De ce fait, il convient d’incorporer cette dernière de la même manière que pour l’ajout d’une petite fonctionnalité.

Vulnérabilités en matière de sécurité

Les demandes de tirage relatives aux vulnérabilités doivent être fusionnées selon notre planification des correctifs, laquelle dépend de la gravité de la vulnérabilité et de la possibilité d’exploiter cette dernière.

Pour protéger les ressources et services du SNC de vulnérabilités connues, les correctifs de sécurité doivent être déployés dans des délais raisonnables en fonction de la gravité des vulnérabilités et de la possibilité d’exploitation, comme indiqué ci-dessous :

Gravité	Possibilité d’attaque publique	Pas d’exploitation détectée
Niveau critique / très élevé	24 heures	7 jours
Niveau élevé	48 heures	2 semaines
Niveau moyen	7 jours	Chaque mois
Niveau faible	2 semaines	Chaque mois

La gravité est évaluée selon plusieurs métriques mesurant :

la facilité d’exploitation de la vulnérabilité;
l’incidence de cette exploitation; et
la façon dont nous utilisons la dépendance présentant la vulnérabilité.

Voici des exemples des différents niveaux de gravité :

Les vulnérabilités de niveau critique peuvent être exploitées à distance, sans authentification, et entraînent des pertes de données ou compromettent le système.
Les vulnérabilités de niveau faible nécessitent la présence d’un accès local au serveur et d’une attaque spécifiquement préparée et causant l’instabilité du système (déni de service).

Quand ignorer une mise à jour

De manière temporaire

Clore la demande de tirage contenant la mise à jour à l’aide d’un commentaire expliquant pourquoi cette demande ne fait pas encore l’objet d’un traitement ou d’une fusion. De cette façon, la demande fera l’objet d’un suivi dans le tableau de bord des dépendances de Renovate, ce qui permettra de l’appliquer en toute simplicité à l’avenir.

De manière permanente

Mettre à jour la configuration Renovate du projet directement à l’aide d’un bloc ignoreDeps pour la dépendance. Inclure une explication de ce changement dans la demande de tirage mettant à jour la configuration Renovate.

Alertes de vulnérabilité GitHub

Nos référentiels de projets recevront également des alertes de vulnérabilité de la part de GitHub. Celles-ci doivent faire l’objet de la même évaluation de vulnérabilité et du même processus de correction que les demandes de tirage Renovate.

Si une vulnérabilité est découverte, mais n’a pas d’incidence sur le projet, il est possible de l’ignorer en cliquant sur le bouton d’alerte Ignorer et en fournissant une justification ainsi qu’un commentaire expliquant pourquoi la vulnérabilité a été ignorée.

Language selection

Rechercher