Audit d’évaluation et d’autorisation de sécurité
Table des matières
- Résumé
- A. Introduction
- B. Constatations, recommandations et réponses de la direction
- C. Conclusion
- Annexe A – Domaines d’intérêt et critères d’audit précis
- Annexe B – Méthode d’échantillonnage
- Annexe C – Priorités concernant les recommandations faisant suite à la vérification
- Annexe D – Liste des acronymes
Résumé
L’évaluation et l’autorisation de sécurité (EAS) est le processus par lequel les ministères s’assurent que seuls des logiciels et du matériel autorisés sont installés dans leur environnement de technologie de l’information (TI). L’évaluation de la sécurité est un processus continu qui évalue les pratiques et les contrôles de sécurité afin de déterminer s’ils sont mis en œuvre correctement, s’ils fonctionnent comme prévu et s’ils permettent d’atteindre les résultats souhaités. L’autorisation de sécurité consiste à obtenir et à maintenir une décision de gestion sur le risque en matière de sécurité qui accepte explicitement le risque résiduel connexe en s’appuyant sur les résultats d’une évaluation de sécurité. Cette autorisation est appelée « autorisation d’exploitation » (AE).
La politique du Conseil du Trésor (CT)Note de bas de page 1 et la politique ministérielle de Services partagés Canada (SPC)Note de bas de page 2 stipulent que l’EAS doit être effectuée et examinée de façon périodique pour tous les systèmes et applications informatiques du Ministère.
Le présent audit visait à garantir que les examens d’EAS des services et des systèmes informatiques sont effectués conformément au processus officiel et aux exigences des politiques du CT et de SPC. La structure de gouvernance de SPC comporte deux entités distinctes qui mènent des EAS : les Services ministériels sont responsables de l’EAS des systèmes internes (ministériels); et la Direction générale du dirigeant principal de la technologie (DGDPT) est responsable de l’infrastructure de l’entreprise (entreprise).
La gestion des risques de SPC pour les applications et l’infrastructure informatiques fait appel à des éléments standards, à une consignation active des risques et à un registre de risques visant à cerner les risques en suspens liés aux applications et à l’infrastructure informatiques. Les pratiques de gestion des risques pour les EAS des systèmes ministériels et d’entreprise sont conformes à la politique du CT et aux directives connexes.
L’équipe responsable de l’audit a également constaté ce qui suit :
- L’élaboration d’instruments de politique et de directives destinés aux EAS évolue lentement;
- Les rôles et responsabilités des EAS ne sont pas à jour et ne sont pas clairement communiqués ou compris par les directions générales de SPC ou les clients du Ministère;
- Les changements organisationnels et les préoccupations continues en matière de ressources ont eu des répercussions négatives sur la supervision de l’EAS;
- Les activités de l’EAS, l’établissement d’une AE et les examens de la conformité sont communiqués à la haute direction. Cependant, bien que des tableaux de bord soient utilisés, les renseignements sont incomplets et mettent l’accent sur les statistiques relatives au débit plutôt que sur les analyses et les propositions de solution;
- Les modèles d’éléments d’EAS ne sont pas toujours standards en ce qui concerne le format et le contenu;
- Bien qu’un ensemble de pratiques soutiennent les activités d’EAS, il n’existe pas de processus opérationnel officiel de l’EAS approuvé par la direction et communiqué couvrant toutes les étapes de l’intégration opérationnelle jusqu’à l’établissement de rapports sur les conditions de l’AE;
- Malgré des indications claires que les efforts de SPC en matière d’EAS produisent des résultats, les activités d’EAS et l’émission d’AE ne suivent pas des pratiques uniformes;
- Les examens des conditions des AE n’ont pas été suivis de manière uniforme ou normalisée.
L’équipe d’audit a formulé des recommandations afin de répondre à certaines constatations de l’audit. La direction de SPC devrait établir des plans d’action de la direction en réponse à l’audit.
Begonia Lojk
Dirigeante principale de la vérification et de l’évaluation par intérim
A. Introduction
1. Contexte
L’EAS est le processus qui consiste à obtenir et à maintenir une décision de la direction d’autoriser l’exploitation d’un système d’information ou d’un service et d’accepter explicitement le risque résiduel d’un ensemble convenu de contrôles de sécurité, ainsi que les résultats d’une évaluation continue de la sécuritéNote de bas de page 3. L’évaluation de la sécurité évalue les pratiques et les contrôles de sécurité afin de déterminer s’ils sont mis en œuvre correctement, s’ils fonctionnent comme prévu et s’ils permettent d’atteindre le résultat souhaité en ce qui concerne le respect des exigences de sécurité définies. L’autorisation de sécurité est la décision de gestion relative au risque de sécurité qui consiste à accepter le risque résiduel connexe et à maintenir la posture de sécurité de façon continue.
L’EAS est régie par la Politique sur la sécurité du gouvernement (PSG) et la Directive sur la gestion de la sécurité (DGS) du CT ainsi que ses procédures obligatoires Note de bas de page 4, qui sont toutes entrées en vigueur le 1er juillet 2019. L’alinéa 3.2.4 de la PSG stipule aux ministères que « des pratiques et des mesures de sécurité normalisées et fondées sur les risques seront mises en œuvre, feront l’objet d’une surveillance et seront tenues à jour ». Les procédures obligatoires de la DGSNote de bas de page 5 indiquent que les ministères doivent « mettre en œuvre des processus d’évaluation et d’autorisation liés à la sécurité de la TI ». En outre, la politique ministérielle de SPC aborde le sujet de la sécurité informatique et de la relation avec les applications et les services informatiques. La Politique sur la sécurité ministérielle (2014) de SPC énonce les exigences qui comprennent l’approbation de l’EAS pour tous les systèmes et servicesNote de bas de page 6. En outre, les changements apportés à un système ou à une application qui ont une incidence sur l’énoncé de sensibilité annulent l’évaluation précédente et nécessitent une nouvelle évaluation avant leur mise en œuvreNote de bas de page 7. La procédure d’EAS proprement dite est décrite dans les Conseils en matière de sécurité des technologies de l’information (ITSG-33) publiées par le Centre de la sécurité des télécommunicationsNote de bas de page 8.
En tant qu’organisation de services internes intégrés (OSII)Note de bas de page 9, SPC a le mandat de fournir des services d’infrastructure informatique de manière globale (c’est-à-dire à l’échelle du gouvernement) aux organisations clientes qui exploitent des systèmes informatiques dans des environnements contrôlés par SPC. Il incombe à SPC d’émettre une AE pour l’infrastructure d’entreprise. Le Ministère doit également gérer les AE pour ses systèmes opérationnels ministériels.
Deux organisations au sein de SPC participent directement à l’activité d’EAS. Pour les services et environnements d’entreprise, la Direction de la gestion de la sécurité et de la gouvernance (DGSG), au sein de la Direction générale du dirigeant principal de la technologie, accomplit les activités d’EAS et formule des recommandations sur l’émission de l’AE, assorties ou non de condition au signataire autorisé de l’organisation. Le dirigeant principal de la sécurité (DPS) de la Direction générale des services ministériels (DGSM) accomplit les activités d’EAS pour les services et les systèmes ministériels et est également le signataire autorisé du Ministère. Ces activités d’EAS sont associées à l’intégration opérationnelle et à la surveillance des conditions afin de créer un cycle de vie opérationnel du concept à la conformité. Ainsi, l’EAS d’entreprise est déclenchée par la procédure d’intégration opérationnelleNote de bas de page 10 de la DGSG et est normalement associée à un projet visant à fournir un système ou à assurer la prestation d’un service à l’aide de l’infrastructure de SPC. L’EAS ministérielle est un effort de coopération entre le personnel de Sécurité des TI et les équipes de projet relevant du dirigeant principal de l’information (DPI). Avant la livraison du produit final, le projet est soumis à une évaluation de la sécurité qui permet de cerner et d’évaluer la manière dont les contrôles de sécurité informatique sont intégrés. L’AE est la dernière étape avant le déploiement. Si l’émission de l’AE est assortie de conditions, celles-ci font par la suite l’objet d’une surveillance.
Le processus opérationnel fonctionne au sein de la structure du comité de gouvernance de SPC. Le mandat du Conseil d’examen des services, des projets et de l’approvisionnement (CESPA) comprend l’approbation des recommandations relatives aux normes informatiques et cybernétiques et des recommandations de l’EAS pour les nouveaux services d’entrepriseNote de bas de page 11. Le sous-ministre adjoint principal de la Direction générale de la prestation et de la gestion des services (DGPGS) est le président du CESPA et assume le rôle de signataire autorisé de l’entreprise. Pour mener à bien la tâche qui lui a été confiée, le CESPA s’appuie sur les avis et les recommandations du Conseil de la gestion des risques liés à la sécurité (CGRS). Le mandat du CGRS comprend l’examen, l’analyse et la gestion d’un éventail d’enjeux de risque moyen à élevé liés à la cybersécurité et à la sécurité de la TI ainsi que de risques qui pourraient avoir une incidence sur l’infrastructure informatique du gouvernement du CanadaNote de bas de page 12. Plus précisément, il formule des recommandations au CESPA au cours du processus d’EAS. Selon la procédure ministérielle de l’EAS, le DPI est le signataire autorisé.
2. Justification de l’audit
Afin d’améliorer la sécurité globale au sein de la communauté informatique du gouvernement du Canada, les organisations doivent vérifier que les exigences de sécurité établies pour un système ou un service particulier sont respectées et doivent prouver que les contrôles et les mesures de protection fonctionnent. Pour cela, il faut cerner et évaluer les risques pour l’environnement informatique, et accepter le risque résiduel associé à l’exploitation du système ou du service une fois que les risques cernés ont été atténués.
Un processus opérationnel d’EAS mis en place correctement et fonctionnant bien peut procurer à la direction l’assurance que seuls des systèmes et services informatiques acceptés et autorisés sont mis en service avec des niveaux de sécurité appropriés. L’absence d’un processus opérationnel d’EAS fonctionnant correctement peut avoir une incidence sur la prestation de services informatiques, et entraîner l’acceptation de services et de systèmes informatiques fonctionnant mal ou peu sûrs. Des systèmes et services informatiques non protégés peuvent entraîner une perte de contrôle des réseaux ou des systèmes, ou un accès accidentel ou intentionnel à de l’information à caractère sensible.
3. Autorité responsable de l’audit
L’audit figure dans le plan d’audit axé sur les risques 2019-2022 de SPC, approuvé par le président le 5 mars 2019. Le présent audit a été réalisé sous l’autorité du Bureau de la vérification et de l’évaluation (BVE).
4. Objectif de l’audit
Le présent audit visait à fournir l’assurance que les examens d’EAS des services et systèmes informatiques sont effectués conformément au processus officiel et aux exigences des politiques du CT et de SPC.
5. Portée
La portée du présent audit met l’accent sur le processus opérationnel de l’EAS à SPC, sur les AE existantes émises à l’issue dudit processus et la mesure dans laquelle les principaux projets d’entreprise et ministériels de SPC produisent les éléments requis utilisés dans l’évaluation des systèmes et des services informatiques. L’audit a également examiné l’intégration opérationnelle et la surveillance des conditions de l’AE. L’audit portait sur la période du 1er avril 2018 au 31 août 2019.
L’audit ne visait en aucun cas à apporter des modifications à des évaluations de sécurité réelles, ou à réévaluer les données probantes utilisées lors de ces évaluations.
6. Méthodologie et approche
L’audit a été mené conformément aux normes internationales pour les missions d’audit interne de l’Institut des auditeurs internes (IAI) et à la Politique sur la vérification interne du CT du Canada. L’audit a été réalisé, y compris les procédures d’audit suivantes :
- Entrevues auprès de la haute direction et du personnel opérationnel;
- Examen des documents;
- Revue générale des principaux contrôles et processus;
- Détermination des contrôles clés;
- Échantillonnage de projets ou de services à l’aide de la méthode d’échantillonnage discrétionnaire;
- Analyse des données;
- Mise à l’essai des contrôles.
7. Énoncé de conformité
Selon le jugement professionnel de la dirigeante principale de la vérification, les méthodes de vérification employées et les éléments probants recueillis sont suffisants et adéquats pour appuyer l’exactitude de l’opinion formulée dans ce rapport. Celle-ci s’appuie sur la comparaison des conditions de l’époque et des critères d’audit préétablis qui ont été acceptés par la direction. L’avis concerne uniquement l’organisation ayant fait l’objet de l’examen. La mission a été réalisée conformément à la Politique sur la vérification interne, à la directive connexe et au Code de déontologie de l’IAI. Les éléments de preuve ont été recueillis en conformité avec les procédures et les pratiques qui satisfont aux normes d’audit et corroborés par les résultats du programme d’assurance de la qualité et d’amélioration. Les données compilées étaient suffisantes pour fournir à la haute direction une preuve d’opinion fondée sur l’audit interne.
B. Constatations, recommandations et réponses de la direction
1. Gouvernance
1.1 Cadre stratégique de l’évaluation et de l’autorisation de la sécurité de la TI
Critère d’audit : SPC a élaboré, approuvé, communiqué et mis à jour une politique/directive sur l’évaluation et l’autorisation des systèmes et services informatiques, avant leur installation et dans le cadre d’un processus continu après celle-ci.
Nous nous attendions à ce qu’il existe un cadre stratégique se rapportant à l’EAS ainsi qu’un ensemble de documents officiels décrivant de quelle façon le cadre stratégique devrait être mis en œuvre. Nous nous attendions également à constater que le personnel responsable de l’exécution des tâches associées à l’EAS était bien informé sur la mise en œuvre des orientations et que les clients du processus connaissaient la politique, les orientations et les exigences en matière d’EAS.
Un cadre stratégique complet et à jour garantit l’établissement et l’application d’un processus officiel qui respecte le mandat de SPC en tant qu’organisation de services d’entreprise interne et souligne la nécessité de communiquer ces exigences à tous les intervenants.
Les récents changements apportés à la politique gouvernementale ont mis en évidence la nécessité d’une évaluation et d’une autorisation de sécuritéNote de bas de page 13. SPC a publié plusieurs documents de politique et de directive qui répondent à cette exigence essentielle du gouvernement et fournissent un fondement politique solide pour l’EAS, qui fait partie de la vision du gouvernement et du Ministère en matière de gestion des risques de sécurité informatique et cybernétique. Deux processus organisationnels parallèles sont en place pour traiter l’EAS, l’un pour les applications ministérielles et l’autre pour les systèmes et services d’infrastructure d’entreprise. Il n’existe cependant aucune ligne directrice relative au processus prescrite, définitive et approuvée concernant les activités d’EAS, depuis l’intégration jusqu’à la surveillance des conditions. Le Plan de sécurité ministériel (PSM) de 2019-2022 indique que le changement organisationnel peut avoir entraîné un manque de compréhension des tâches réellement assignées, et laisse à penser que des mises à jour de la politique, des directives et des processus sont nécessairesNote de bas de page 14. L’équipe responsable de l’audit a noté ce qui suit :
- Les documents d’orientation qui traitent de certains aspects du processus d’EAS ne sont pas datés, ne font pas référence à un auteur précis ou ne mentionnent pas d’approbation, ne sont pas rédigés de façon uniforme, ou sont désuets ou à l’état d’ébauche. La DGDPT a travaillé sur une mise à jour de la norme de sécurité d’EAS qui sert actuellement de guide pour l’EAS d’entreprise. La mise à jour de cette norme a commencé en 2016; elle n’a pas encore été publiée;
- La politique et les directives connexes n’ont pas été communiquées au personnel de SPC. La plupart des personnes interrogées qui ne participent pas directement au processus ont indiqué mal connaître en général les exigences, les éléments de preuve, les coûts et les délais de l’EAS.
SPC a publié plusieurs documents de politique et de directive qui réitèrent la position du gouvernement du Canada concernant l’EAS. Des orientations suffisantes concernant le processus opérationnel n’ont cependant pas été élaborées ou tenues à jour pour la mise en œuvre de ce cadre stratégique. Des orientations insuffisantes en matière de mise en œuvre de la politique seront probablement à l’origine d’un manque d’uniformité dans la façon dont la politique est mise en œuvre. En outre, l’absence de communication des orientations sur la politique à tous les intervenants accroît le risque qu’ils ne respectent pas les exigences.
En conclusion, les instruments de politique de SPC pour la gestion de l’évaluation et de l’autorisation de sécurité sont incomplets et ne sont pas communiqués à tous les intervenants.
Voir la recommandation 4.
1.2 Rôles et responsabilités de l’EAS
Critère d’audit : Les rôles et les responsabilités de l’EAS sont documentés, attribués et communiqués à tous les intervenants et clients de SPC concernés, et fonctionnent tel que défini.
Nous nous attendions à constater que les rôles et responsabilités de l’EAS étaient documentés et communiqués à tous les intervenants, particulièrement au personnel qui gère et exécute les tâches de l’EAS. Nous nous attendions également à ce que d’autres intervenants aient été informés et connaissent leurs rôles dans le processus.
Les rôles et responsabilités associés à l’EAS ainsi que leurs autorités connexes doivent être communiqués et clairement compris par tous les intervenants. Cela contribue à garantir que les participants connaissent leurs responsabilités dans le processus et qu’ils les assument.
D’une manière générale, les rôles sont bien compris au sein des organisations participant à l’EAS, à savoir le dirigeant principal de la sécurité pour le Ministère et la Direction générale du dirigeant principal de la technologie (DGDPT) au niveau d’entreprise. L’équipe d’audit a constaté cependant que l’EAS des systèmes ministériels se servait du Guide de l’EAS (2016) en tant que lignes directrices pour la procédure alors que l’EAS des systèmes d’entreprise suivait la version provisoire de la norme d’EAS. L’équipe d’audit a également constaté ce qui suit :
- Les descriptions des rôles sont différentes selon qu’il s’agit de fonctions de l’EAS des systèmes ministériels ou de l’EAS des systèmes d’entreprise. Le Plan de sécurité ministériel (PSM) indique qu’il peut y avoir des lacunes dans les contrôles de sécurité ou le cadre de gestion de SPC en raison d’un manque de clarté concernant la gouvernance, les rôles et les responsabilités, tant au sein du Ministère qu’avec ses clients et d’autres intervenants externesNote de bas de page 15.
- L’organisation de la conformité d’entreprise a été créée en août 2018 afin de surveiller les conditions des AE et de produire des rapports à ce sujet. Les documents de procédures pour cette fonction sont insuffisants.
- L’annexe 2 du document ITSG-33Note de bas de page 16 décrit les étapes de la mise en œuvre des contrôles de sécurité dans les systèmes d’information. L’annexe 3 fournit un catalogue de contrôles de sécurité contenant des définitions que les spécialistes de la sécurité peuvent utiliser pour sélectionner des contrôles spécifiques en vue de protéger les systèmes et les services informatiques du gouvernement du Canada. Le document ITSG-33 ne propose aucune définition du spécialiste de la sécurité (aide le projet à trouver des éléments preuves) par rapport à l’évaluateur de sécurité (mesure la qualité des éléments de preuve). Cela peut avoir pour conséquence que la mise en œuvre des contrôles de sécurité et l’évaluation de celle-ci ne soient pas séparées comme il se doit.
- Les rôles de l’évaluateur par rapport à ceux du signataire autorisé ne sont pas clairs pour les services ministériels et les services d’entreprise, pour les éléments propres au ministère et ceux à l’échelle du gouvernement. Par exemple, bien que le PSM de février 2019 indique que le premier vice-président est le signataire autorisé des AE d’entreprise, le mandat le plus récent du CESPA indique que le SMA principal de la DGPGS assume ce rôle.
- C’est peut-être la raison pour laquelle les personnes interrogées ont indiqué que les rôles étaient peu clairs, tout comme l’application des responsabilités dans certains domaines.
Si les rôles de l’EAS ne sont pas bien définis ou documentés, il existe un risque que la séparation des tâches entre le spécialiste et l’évaluateur de la sécurité ne soit pas claire, ce qui compromet la validité du résultat de l’évaluation. De plus, si les rôles et les responsabilités ne sont pas communiqués ou clairement compris, il existe un risque de dédoublement des efforts et de confusion.
En conclusion, l’audit a permis de constater que les rôles et les responsabilités associés à l’EAS ne sont pas bien documentés, ni communiqués officiellement à tous les intervenants concernés au sein de SPC.
Recommandation 1
Priorité Moyenne
Le SMAP de la DGDPT et le SMAP de la DGSM (par l’intermédiaire du DPS) devraient clarifier le mandat de l’évaluation de la sécurité des TI pour les environnements ministériels et d’entreprise et veiller à ce que les rôles et les responsabilités soient établis et communiqués à tous les intervenants.
Réponse de la direction
La direction est d’accord avec la recommandation.
On est en train d’élaborer et de mettre à jour des instruments de politique en fonction des attentes énoncées dans la nouvelle Politique sur la sécurité du gouvernement (PSG) du Secrétariat du Conseil du Trésor (SCT)Note de bas de page 17 et la Directive sur la gestion de la sécurité (DGS)Note de bas de page 18 connexe. On révise actuellement la Politique sur la sécurité ministérielle (PSM)Note de bas de page 19 de SPC afin de clarifier les rôles et les responsabilités. Le président a désigné un DPS de la DGSM pour superviser les activités de gestion de la sécurité du ministère, et SPC examine les autres changements qui doivent être apportés pour respecter la PSG en ce qui concerne la prestation de ses services d’entreprise. En outre, on trouvera des rôles et des responsabilités clairs et précis pour la sécurité informatique en ce qui concerne la fourniture de services d’entreprise dans la directive de SPC sur la gestion de la sécurité des services d’entrepriseNote de bas de page 20 (en cours d’élaboration).
1.3 Surveillance
Critère d’audit : Un régime de surveillance efficace est en place pour gérer l’EAS des systèmes/services informatiques.
Nous nous attendions à ce qu’un régime de surveillance soit en place et à ce qu’il comprenne une structure de gouvernance, une gestion et des orientations, un financement, un contrôle de l’ESA et l’établissement de rapports à ce sujet.
Une surveillance efficace et efficiente garantit que les exigences et les objectifs du ministère en matière de sécurité des TI sont conformes à la PSG et à la DGS du CT, et que l’on a recensé et les stratégies opérationnelles, les orientations ainsi que les principaux risques liés à l’exécution du mandat ministériel et qu’ils sont contrôlés de manière adéquate.
Comme nous l’avons indiqué précédemment, SPC dispose de deux fonctions de gestion distinctes, mais liées qui dirigent les activités d’EAS : la fonction interne, ministérielle responsable des systèmes ministériels de SPC, qui relève de la DGSM et la DGDPT responsable de la TI de l’entreprise (pangouvernementale) dans le cadre de laquelle SPC agit en tant qu’OSII pour l’infrastructure de TI du gouvernement.
L’équipe responsable de l’audit a noté ce qui suit :
- Il existe des différences entre les activités des EAS des systèmes ministériels et des systèmes d’entreprise, notamment en ce qui concerne leur mandat et portée respectifs (budget, portée des travaux, etc.). Même si le PSM tente de résoudre les enjeux au niveau de l’entreprise, on n’a pas pu trouver les documents sources appuyant ces enjeux d’entreprise. Il n’existe pas de plan de sécurité d’entreprise équivalent ayant été officiellement établi ou défini, ce qui signifie que les enjeux d’entreprise ne sont pas abordés.
- Dans les organisations ministérielles et d’entreprise participant à l’EAS, la capacité n’est pas suffisante pour permettre d’atteindre les objectifs de charge de travail imposés par la politique du gouvernement. Cela entraîne des retards, des lenteurs et des préoccupations soulevées par les clients. L’opération d’EAS ministérielle est très petite et la charge de travail est souvent gérée de façon informelle. L’EAS d’entreprise est une opération beaucoup plus importante. L’équipe d’audit a constaté que l’unité des services d’évaluation des risques en matière sécurité de la TI responsable de l’activité d’évaluation de la sécurité d’entreprise est faiblement pourvue en personnel et dépend fortement de ressources externes pour les postes de spécialistes et d’évaluateurs de la sécurité. En outre, l’unité Conformité de la sécurité d’entreprise, responsable de la surveillance de la conformité aux conditions d’exploitation autorisées et de l’établissement de rapports à ce sujet a été mise sur pied et travaille comme une nouvelle fonction pour laquelle aucune nouvelle ressource n’a été ajoutée.
- Le modèle de financement de recouvrement des coûts ne répond pas aux exigences en matière de contrôle interne pour l’EAS. La durée du cycle de l’évaluation initiale au recouvrement des coûts peut être importante, on estime qu’il se déroule sur neuf moisNote de bas de page 21. L’EAS est une activité axée sur la demande, pourtant il semble qu’il n’existe pas de moyen facile à SPC de s’assurer que les travaux d’EAS peuvent être financés de manière proactive afin d’obtenir les ressources adéquates en temps opportun pour garantir que les travaux d’EAS ne soient pas limités.
- Dans l’ensemble, la structure de gouvernance n’est pas suffisamment officielle. Les documents ne sont pas datés et ne comportent pas de signature d’approbation. Les mandats des principaux comités de gouvernance, le CESPA et le CGRS, n’ont pas été approuvés par le président.
- Le CGRS a connu un changement opérationnel peu après décembre 2018. Ce comité au niveau des directeurs généraux met l’accent sur la gestion des risques de sécurité et, entre autres points à l’ordre du jour, reçoit des rapports concernant la charge de travail, les statistiques et les enjeux associés à l’EAS. Les coprésidents du CGRS reconstitué n’ont pas déterminé les renseignements adéquats et la visibilité de l’EAS au sein de SPC n’est pas optimale.
- L’établissement de rapports réguliers sur l’état de la sécurité des systèmes d’information d’entreprise destinés au signataire autorisé, au propriétaire opérationnel et à d’autres intervenants conformément à la stratégie de surveillance continue de SPC et au plan d’autorisation du système est défini dans la version provisoire de la Norme de sécurité relative à l’évaluation de la sécurité et autorisationNote de bas de page 22. Tous les gestionnaires d’EAS d’entreprise sont tenus de mettre à jour des tableaux de bord hebdomadaires. Ceux-ci sont ensuite regroupés afin de présenter les travaux accomplis au cours de la semaine. L’équipe responsable de l’audit a constaté qu’aucune analyse de tendance n’était effectuée pour cet instrument normalisé d’établissement de rapports. Les risques et les enjeux relevés dans les tableaux de bord mettent en évidence des préoccupations symptomatiques. Toutefois, il n’existe pas de rapport global sur le nombre de projets qui connaissent des retards, ni de preuve d’un dialogue permanent sur les résultats des mesures suggérées requis pour faire face aux risques ou aux enjeux.
- Il y a un manque de rigueur dans la saisie des indicateurs clés et l’établissement de rapports à leurs sujets en ce qui concerne la communication des retards des projets d’évaluation de la sécurité des systèmes d’entreprise, la communication de l’agrégation horizontale des risquesNote de bas de page 23 à partir des analyses d’EAS et des options d’acheminement au palier hiérarchique approprié en cas de non-conformité.
En raison de ces lacunes dans la surveillance de SPC pour l’EAS, il existe un risque que le manque de capacité entraîne des retards dans la charge de travail et des lenteurs en matière de déploiement, que les problèmes de financement aboutissent à des contrôles internes inefficaces dans le processus de l’EAS, que les structures de gouvernance ne soient pas suffisamment adaptées à l’évolution du rôle de SPC en matière de sécurité d’entreprise, et que des rapports inadéquats limitent l’efficacité de la prise de décision relative à la gestion. Ces préoccupations constituent un risque pour la réputation opérationnelle de SPC en tant qu’OSII de confiance.
En conclusion, la gestion de l’évaluation et de l’autorisation de la sécurité ne fait pas l’objet d’une surveillance adéquate.
Recommandation 2
Priorité Élevée
Le SMAP de la DGDPT et le SMAP de la DGSM (par l’intermédiaire du DPS) devraient veiller à ce qu’un régime de surveillance efficace soit en place pour :
- créer une organisation officiellement approuvée et suffisamment dotée en personnel pour permettre aux deux volets de l’EAS de mener à bien leurs activités obligatoires qui sont en cours de manière rentable et axée sur le client;
- établir et garantir un mécanisme de financement approprié de sorte que les équipes responsables des EAS des systèmes d’entreprise et des systèmes ministériels puissent s’organiser pour répondre aux exigences en matière de charge de travail;
- revoir et mettre la dernière main à une structure de gouvernance approuvée, y compris le mandat et la composition du Conseil de la gestion des risques liés à la sécurité (CGRS) afin de consolider la réputation de SPC en tant qu’organisation de services internes intégrés dans le contexte de l’EAS;
- définir le niveau de suivi et de rapport attendu et le type de renseignements sur la sécurité des services d’entreprise et ministériels pour la gestion de l’EAS, afin de permettre une prise de décision efficace par la haute direction.
Réponse de la direction
La direction est d’accord avec la recommandation.
Gestion de la sécurité et gouvernance de la DGDPT et le dirigeant principal de la sécurité examineront la structure de l’organisation et ses effectifs actuels afin de s’assurer que cette dernière dispose des ressources nécessaires pour mener à bien les activités courantes prescrites de manière rentable et axée sur le client. On prendra des mesures pour veiller à ce qu’un nombre suffisant d’employés à plein temps soient formés pour fournir des services d’EAS cohérents et rentables. Il s’agira notamment de mener un processus de sélection pour pourvoir les postes, d’actualiser la structure organisationnelle afin d’améliorer la prestation de services, de réviser le modèle de financement pour répondre aux exigences de la charge de travail provisoire et d’améliorer la structure de gouvernance en rendant des comptes au CGRS.
Recommandation 3
Priorité Moyenne
Le SMAP de la DGDPT devrait établir un cadre de planification permettant de repérer, d’étudier et de traiter les enjeux d’entreprise d’une manière similaire à celle du PSM.
Réponse de la direction
La direction est d’accord avec la recommandation.
Selon la PSG, le PSM doit englober tous les programmes et services du Ministère. Par conséquent, le PSM de SPC porte à la fois sur les services ministériels et les services d’entreprise. La Politique sur les services et le numérique du Conseil du Trésor, entrée en vigueur le 1er avril 2020, prévoit également l’intégration de la cybersécurité dans un plan ministériel pour la gestion intégrée des services, de l’information, des données, des technologies de l’information et de la cybersécurité. Ensemble, ces plans fourniront une orientation stratégique pour améliorer la sécurité des services d’entreprise de SPC, conformément aux priorités du gouvernement.
2. Risque
2.1 Gestion des risques liés à la sécurité des TI
Critère d’audit : Il existe un processus permettant de cerner et de surveiller les risques en matière de sécurité associés à l’ensemble des projets tout au long de leur cycle de vie en ce qui concerne : l’utilisation d’éléments de risques standards abordant des aspects des risques liés à la sécurité des TI énoncés dans le document ITSG-33; le recours à une journalisation et à une surveillance actives des éléments des risques liés à la sécurité des TI; l’utilisation d’un registre des risques informatiques qui comprend la détermination des risques et une stratégie d’atténuation visant à gérer les risques liés à la sécurité informatique.
Nous nous attendions à ce que SPC ait :
- mis en place une journalisation et une surveillance actives des projets (infrastructures et applications);
- réalisé des évaluations de routine des risques en matière de sécurité pour les projets recensés;
- établi un registre des risques informatiques qui comprend la détermination des risques et une stratégie d’atténuation visant à gérer les risques liés à la sécurité informatique.
Les gestionnaires et les promoteurs de projets doivent être au courant de l’évolution du paysage des menaces et des risques et comprendre comment gérer leurs risques liés à la sécurité informatique. À cette fin, on s’attend à ce que les projets aient recours aux contrôles et suivent les étapes énoncées dans le document ITSG-33 pour cerner les contrôles de sécurité nécessaires et déterminer dans quelle mesure ces contrôles ont été mis en œuvre dans le cadre de la solution opérationnelle en cours de développement. La mise en place et la tenue d’un registre des risques liés à la sécurité informatique permettent aux gestionnaires de projets de SPC de prendre conscience de l’évolution des risques liés à la sécurité des TI. Ce registre devrait également permettre le suivi des mesures d’atténuation des risques.
La gestion des risques liés à la sécurité de SPC pour les applications et l’infrastructure informatiques fait appel de façon adéquate à des éléments standards, à une consignation active des risques et à l’établissement de rapport à ce sujet en vue de cerner les risques en suspens liés aux applications et à l’infrastructure informatiques. Néanmoins, il y a des divergences entre les documents actuels et les projets de documents qui décrivent les éléments et les données probantes attendus comme :
- l’EAS des systèmes ministériels suit le Guide de l’EAS (2016) alors que celle des systèmes d’entreprise suit la Norme de sécurité relative à l’évaluation de la sécurité et autorisation (qui doit encore être achevée); chaque groupe utilise des modèles légèrement différents pour la production des éléments requis; tous les modèles ne se trouvent pas dans le même dépôt et plusieurs documents sources offrent une analyse partielle des éléments à utiliser ainsi que des circonstances dans lesquelles les utiliser. Cette situation donne lieu à un ensemble d’instructions déroutantes.
- Les gestionnaires de projet qui produisent les données probantes visant à traiter les éléments requis ne connaissent pas l’existence d’un processus officiel; ils utilisent simplement la liste d’éléments fournie par la fonction d’EAS. Bien que la plupart d’entre eux considèrent les éléments de l’EAS comme des résultats naturels d’une bonne gestion de projet, ils ne comprennent pas pourquoi il est nécessaire de disposer de ces éléments, raison pour laquelle il leur est difficile de fournir des données probantes adéquates.
La mise en œuvre inadéquate des modèles standard d’éléments a eu des répercussions négatives sur la capacité de SPC à contrôler la qualité de l’achèvement des éléments et restreint son aptitude à comparer ces documents.
En conclusion, les procédures de consignation et de surveillance actives et la mise à disposition d’un registre des risques sont suffisantes, mais il n’existe pas d’ensembles standard d’éléments acceptables accompagnés d’instructions d’utilisation adéquates.
(Voir la recommandation 4).
3. Contrôles internes
3.1 Processus d’EAS
Critère d’audit : Un processus standard d’EAS a été documenté, communiqué et intégré officiellement au cadre de gouvernance du projet (CGP).
Nous nous attendions à trouver des procédures documentées, approuvées, mises en œuvre et communiquées aux fins de la gestion des EAS.
Une source unique faisant autorité pour le processus d’EAS à SPC permettrait d’éviter l’extrême variabilité des niveaux de données probantes pour des AE précises, et de garantir que des AE sont annulées, au besoin. Un moyen de communication officiel destiné aux gestionnaires de projet concernant les objectifs de l’EAS, les éléments, etc. contribuerait à garantir un processus d’EAS efficace. L’incertitude quant aux processus peut nécessiter un effort de coordination important de la part des équipes d’EAS, ce qui entraîne l’inefficacité dans les processus.
Le document ITSG-33 du Centre de la sécurité des télécommunications (CST) fournit un ensemble d’activités de contrôle de référence et des contrôles de sécurités réels à appliquer dans le cadre de l’exécution d’un projet – qu’il concerne une application ou l’infrastructure. Les pratiques concernant à la fois les EAS des systèmes ministériels ou d’entreprise cadrent bien avec le document ITSG-33. En outre, le CGP de SPC décrit un ensemble de points d’approbation de projet et cite dans la liste de vérification des points de contrôle de nombreux éléments utilisés comme données probantes pour l’EAS. Il n’y a cependant pas suffisamment de documents sur le processus opérationnel officiel en ce qui concerne les activités d’EAS. L’équipe responsable de l’audit a constaté ce qui suit :
- Deux documents d’orientation existent – le Guide de l’EAS, un document plus ancien datant de 2016 pour lequel il existe un projet de refonte, et la version provisoire de la norme de sécurité de l’EAS. Idéalement, les deux volets de l’EAS devraient être des éléments différents du même processus. Ces deux volets représentent cependant des ensembles de pratiques distincts, ce qui est susceptible d’entraîner des incohérences dans le domaine de l’évaluation de sécurité.
- Il n’existe pas de source unique faisant autorité pour les normes et les lignes directrices en matière d’EAS. Si plusieurs documents existent, il y a des incohérences entre eux. L’ébauche de la norme de sécurité de l’EAS est en cours de rédaction depuis 2016 et elle devait être publiée en janvier 2020. Plusieurs présentations (datant de 2017-2018) décrivent le processus d’EAS des systèmes d’entreprise et son lien avec Gestion et exécution des projets. Ces présentations ne sont pas des documents faisant autorité. De plus, le Guide de l’EAS (mai 2016) indique qu’il fournit un aperçu du cadre de gestion des risques liés à la sécurité de la TI de SPC. Ce document n’est plus utilisé pour les projets d’entreprise. En outre, le guide de l’EAS décrit les responsabilités et la production des principaux éléments, qui ne sont pas toujours les mêmes que ceux utilisés pour les fonctions concernant les systèmes d’entreprise;
- La version provisoire de la norme indiquait que certaines références plus anciennes du CGPNote de bas de page 24 étaient inexactes, ce qui nécessitera des efforts plus importants pour harmoniser les deux cadres. De même, le processus ministériel utilise le guide de l’EAS qui décrit également les étapes de la gestion des projets informatiques en se référant aux interfaces et aux résultats de l’EAS, mais comme le CGP est axé sur les systèmes d’entreprise, il n’y a pas d’harmonisation évidente.
- En l’absence d’un programme de communication, les gestionnaires de l’EAS sont censés communiquer aux intervenants les questions relatives à la politique et au processus de l’EAS. Cependant, la communication relative à l’EAS n’est pas considérée comme une priorité et représente un défi pour les gestionnaires déjà occupés par les activités de l’EAS.
La procédure d’EAS décrite dans la série de documents ITSG-33 porte sur les spécificités de l’intégration des contrôles de sécurité dans le système ou la prestation de services. Par exemple, elle comprend une procédure pour définir les besoins d’entreprise en matière de sécurité, adapter les contrôles de sécurité, les intégrer et les mettre à l’essai, puis évaluer le caractère adéquat de l’adaptation, de l’intégration et de la mise à l’essai des contrôles. Cet audit adopte une vision plus large de l’EAS dans la mesure où il examine également l’intégration opérationnelle, l’affectation de ressources adéquates et la surveillance continue des conditions. L’équipe responsable de l’audit a noté ce qui suit :
- Le PSM (2019-2022) soulève plusieurs préoccupations, notamment : le manque d’uniformité entre les processus d’EAS des systèmes d’entreprise et des systèmes ministériels; [L’information a été retranchée]; des systèmes existants qui ont fait l’objet de changements majeurs depuis l’obtention de leur autorisation initiale après leur transfert à SPC;
- On ne sait pas si tous les investissements de la taille d’un projet sont reconnus comme des projets et s’ils sont saisis pour l’EAS. Les activités d’entreprise (c’est-à-dire les projets) arrivent par l’intermédiaire de l’unité d’intégration opérationnelle à la suite d’un contact direct avec le directeur, Services d’évaluation des risques liés à la sécurité de la TI ou simplement parce qu’elles sont considérées comme un besoin. Si les projets n’ont pas recours au CGP ou ne passent pas par le point d’intégration opérationnelle, il n’existe pas de processus en place pour informer ou déclencher l’activation des services d’EAS. Les activités ministérielles sont souvent cernées de façon officieuse lors de communications entre le coordonnateur de l’EAS et le personnel de la DGDPI;
- Il n’existe pas de mécanisme permettant déclencher le suivi des changements apportés aux services et systèmes existants. L’utilisateur apportant les changements n’est pas tenu d’en informer l’unité Conformité ou de réévaluer l’AE;
- Lorsque l’infrastructure existante a été transférée à SPC, on a supposé, par défaut, qu’elle disposait d’une autorisation d’exploitation, même s’il n’existe pas de données probantes fondées étayant cette supposition. Le personnel de l’EAS et le personnel des secteurs de service ont indiqué que des changements sont apportés aux environnements existants lorsque SPC a accepté le modèle de transfert « lift and shift » des [L’information a été retranchée]Note de bas de page 25Note de bas de page 26
- Le signataire autorisé pour les systèmes d’entreprise s’appuie sur les approbations du DPT et des propriétaires opérationnels. Le DPT approuve le processus d’EAS et les propriétaires opérationnels approuvent les conditions d’AE qui comprennent les plans visant à examiner et à atténuer les risques. Le rôle de signataire autorisé est peu soutenu par exemple, l’exhaustivité des dossiers d’AE reçus varie; les contraintes de temps en ce qui concerne l’approbation des autorisations entraînent un sentiment d’urgence dans tous les cas et il n’existe pas d’examen direct de la gouvernance en ce qui concerne les risques liés à l’AE et les conditions de celle-ci.
Bien qu’il existe des indications claires que le processus d’EAS donne des résultats, les préoccupations cernées concernant les activités d’EAS et l’émission d’AE indiquent que le processus est inefficace. L’absence de normalisation, comme le manque d’uniformité dans l’application des procédures et les exigences différentes en ce qui concerne l’interprétation des données probantes constituent des faiblesses dans le processus. Les défaillances du processus d’EAS peuvent permettre l’émission d’AE par erreur. Les différences entre le processus pour les systèmes ministériel et le processus pour les systèmes d’entreprise peuvent aboutir à une prise de décisions non optimale en matière d’AE et [L’information a été retranchée] L’officialisation des processus et leur communication au personnel et aux partenaires réduiraient la probabilité d’accepter un risque résiduel plus élevé.
En conclusion, SPC n’a pas mis en œuvre ou documenté des procédures uniformes pour la gestion des EAS à l’échelle du Ministère.
Recommandation 4
Priorité Élevée
Le SMAP de la DGDPT et le SMAP de la DGSM (par l’intermédiaire du DPS) devraient veiller à ce que des directives suffisantes soient élaborées, approuvées et appliquées pour l’évaluation des risques de sécurité et l’autorisation des systèmes et des services en :
- officialisant et harmonisant les processus et les procédures pour effectuer des EAS concernant les systèmes et les services ministériels et d’entreprise;
- veillant à ce que tous les travaux qui nécessitent une EAS soient recueillis et à ce que le risque de ne pas déterminer l’ensemble du contexte de l’EAS soit évalué;
- déterminant le risque de l’environnement et des systèmes désuets pour SPC;
- améliorant le soutien au responsable de l’autorisation tout en veillant à ce que l’état de toutes les trousses relatives à l’autorisation d’exploitation soit examiné par le CGRS;
- établissant une formation structurée et des communications régulières concernant les activités du processus d’EAS;
- mettant en place des modèles communs pour répondre aux exigences de l’ITSG-33 dans l’ensemble du Ministère.
Réponse de la direction
La direction est d’accord avec la recommandation.
Selon la réponse à la recommandation 1, une directive sur la gestion des risques liés à la sécurité des TINote de bas de page 27 et une norme d’EAS seront élaborées conjointement par la DGDPT et la DGSM pour SPC. Cela contribuera à harmoniser les processus et les procédures d’analyse et d’évaluation des systèmes d’entreprise et du Ministère, et permettra également de mieux comprendre les risques.
La directive sur la gestion des risques liés à la sécurité des TI et une norme d’EAS de SPC porteront sur la tenue à jour des renseignements d’EAS pour toute l’infrastructure (y compris l’ancienne infrastructure) dont SPC est responsable. On y décrira également la gouvernance de l’examen des dossiers d’AE par le CGRS afin de renforcer le processus d’autorisation. Le bureau de la surveillance opérationnelle de Gestion de la sécurité et gouvernance peaufinera ses processus pour mieux les intégrer à l’intégration opérationnelle d’entreprise et au cadre de contrôle de la gestion des projets afin de s’assurer que toutes les EAS applicables sont saisies et prises en considération.
La gestion du rendement doit tenir compte des besoins en formation des personnes qui participent au processus d’EAS, conformément aux processus de gestion des ressources humaines de SPC. Enfin, on examinera les modèles d’EAS pour s’assurer qu’ils sont harmonisés et cohérents avec les processus ITSG-33.
3.2 Examens de l’EAS standard
Critère d’audit : SPC applique un ensemble standard de déclencheurs et de procédures d’EAS visant à recenser, à saisir et à évaluer tous les projets adéquats, et à autoriser tous les systèmes et services informatiques qui en résultent.
Nous nous attendions à ce que toutes les évaluations de sécurité soient effectuées d’une façon normalisée, selon des processus uniformes et documentés en vue de l’obtention de résultats fiables.
La collecte de données probantes est au cœur du processus de l’EAS. Des éléments de preuve sont requis pour confirmer que chaque contrôle de sécurité (exigence) est en place et traçable. Il incombe à l’équipe de mise en œuvre du projet de prouver que le contrôle est bien conçu et qu’il fonctionne correctement. Il ne devrait pas revenir à l’évaluateur de la sécurité de trouver des défaillances dans les éléments de preuve. Les élémentsNote de bas de page 28 créés par l’équipe d’évaluation doivent donc présenter un haut niveau de qualité ainsi qu’une mise en forme cohérente; ils doivent indiquer la présence ou l’absence d’éléments dépendants. Ils doivent comporter des décisions claires; ils doivent être exhaustifs, à jour et exacts et énoncer de façon explicite les rôles qui sont responsables de fournir les preuves.
L’échantillon d’éléments d’EAS montre que l’opportunité, la clarté et l’exhaustivité des documents utilisés pour les évaluations de la sécurité des systèmes d’entreprise sont en général insuffisantes. Pour plus de renseignements sur la méthode d’échantillonnage, veuillez consulter l’annexe B. Les résultats de l’échantillonnage montrent que :
- certains produits sont exploités sans AE officielle. Par exemple :
- Projet d’actualisation du logiciel WMWare : des mises à niveau et des mises à jour successives du logiciel WMWare ont été installées après avoir fait l’objet d’activités d’évaluation de sécurité, pourtant aucune autorisation n’a été émise;
- Services de contrôles d’accès administratifs (SCAA) : Trois modules ont été concernés : le module Administration (AM), le module Vérificateur du changement (Change Auditor, CA); le module de gestion des privilèges d’accès (PAM). L’équipe responsable de l’audit n’a pas trouvé de documents relatifs au module AM du SCAA indiquant qu’il était officiellement dispensé (à l’étape de l’intégration opérationnelle ou autrement) de l’EAS. Le module AM du SCAA avait déjà franchi le point de contrôle 4 (déploiement) et s’approchait du point de contrôle 5 (déploiement achevé). Aucune AE n’existe pour le module AM du SCAA. Le module CA du SCAA avait déjà franchi le point de contrôle 4 (déploiement) et s’approchait du point de contrôle 5 (déploiement achevé). Aucune AE n’a été émise. Le module PAM du SCAA passait le point de contrôle 4. L’évaluation était toujours en cours. Aucune AE n’a été émise.
- L’équipe responsable de l’audit a constaté que la structure des dossiers de CGdocs pour l’EAS des systèmes d’entreprise qui présente des éléments communs à tous les projets était, en général, mal organisée avec un certain degré d’aléa à l’échelle des projets faisant l’objet d’une EAS. De même, les dossiers de l’EAS des systèmes ministériels étaient mal organisés;
- Les gestionnaires de projets de services et de systèmes ont indiqué que les demandes d’EAS pour les éléments de preuve et l’évaluation de ceux-ci varient en fonction de la personne participant à l’EAS des systèmes d’entreprise concernée. Ils ont également constaté que les éléments de preuve recueillis d’un projet à un autre n’étaient pas centralisés, ce qui entraînait un dédoublement des travaux engendrant une frustration liée au fait de devoir traiter plusieurs demandes pour un même élément de preuve.
En l’absence d’une méthode normalisée ou de procédures officielles pour les pratiques d’EAS, SPC risque de ne pas être en mesure de démontrer sa rigueur dans les évaluations de sécurité et l’autorisation des services ou des systèmes exploités sur l’infrastructure informatique de l’entreprise qui en résulte, ce qui aurait un impact négatif sur la réputation de SPC et sur la confiance du public ou des clients à son égard.
En conclusion, il n’existe pas de méthode normalisée d’EAS, ni de déclencheurs ou de procédures permettant de cerner, de saisir et d’évaluer tous les projets adéquats, et d’autoriser tous les systèmes et services informatiques qui en résultent, tant pour les fonctions d’EAS des systèmes d’entreprise que pour celles des systèmes ministériels.
Recommandation 5
Priorité Moyenne
Le SMAP de la DGDPT et le SMAP de la DGSM (par l’intermédiaire du DPS), en collaboration avec le SMAP, DGPGS, devraient résoudre les problèmes du processus d’EAS, en particulier :
- examiner les incohérences dans les pratiques d’EAS, qui entraînent des différences dans les éléments de preuve demandés et évalués;
- veiller à ce que les éléments de preuve ne soient recueillis qu’une seule fois et réutilisés si nécessaire;
- mettre en place une conception centrale bien organisée pour tous les dossiers de GCdocs liés à l’EAS.
Réponse de la direction
La direction est d’accord avec la recommandation.
La DGDPT et la DGSM élaboreront ensemble une directive sur la gestion des risques liés à la sécurité des TI et une norme d’EAS pour SPC afin de garantir une approche cohérente et organisée pour les processus, les procédures et les pratiques en matière d’EAS. La DGDPT mettra également en place une nouvelle solution de gestion des risques et de la conformité en matière de gouvernance (RSA Archer) qui automatisera le processus d’EAS et en augmentera l’efficacité tout en assurant la cohérence entre les équipes et leurs pratiques.
3.3 Surveillance des conditions de l’AE et renouvellement de l’autorisation
Critère d’audit : SPC a mis en place un processus d’examen et de révision des AE des services ou des systèmes afin de vérifier que les autorisations restent valables, et utilise des déclencheurs normalisés pour garantir le respect permanent des conditions et des exigences des AE.
Une partie de la fonction globale d’évaluation de la sécurité et de l’autorisation consiste à surveiller les cas où les AE sont émises sous certaines conditions et à veiller à ce que celles-ci soient respectées. Nous nous attendions à ce que les examens des conditions des AE soient réalisés d’une façon normalisée, en suivant des processus uniformes.
Les politiques ministérielles et du gouvernement du Canada exigent une surveillance des conditions et une réévaluation des risques liés à la sécurité, au besoin. Plus précisément :
- Les EAS doivent être effectuées et passées en revue régulièrement pour tous les systèmes informatiques et applications ministérielsNote de bas de page 29
- Les modifications apportées à un système ou à une application ayant une incidence sur les valeurs de confidentialité, d’intégrité et de disponibilité (CID) des données, stipulées dans l’énoncé de la nature délicate (END) annuleront l’EAS précédente et nécessiteront une réévaluation avant la mise en œuvreNote de bas de page 30.
La surveillance des conditions a été médiocre pour les fonctions d’EAS des systèmes ministériels et d’entreprise. L’équipe responsable de l’audit a noté ce qui suit :
- Pour les systèmes d’entreprise, l’organisation de la conformité a été mise sur pied en août 2018 et demeure très petite, composée d’un gestionnaire, d’un membre du personnel et d’un étudiant. Aucun organigramme n’est disponible et la gouvernance globale n’est pas documentée. Un processus officiel de transfert entre le groupe responsable des évaluations (Services d’évaluation des risques liés à la sécurité de la TI) et le groupe de la conformité est en cours de rédaction. Les EAS des systèmes ministériels ont assuré une certaine surveillance, mais en raison de leur effectif très restreint, il n’y a pas eu de séparation des tâches entre la mission d’évaluation et celle de conformité.
- Une surveillance continue n’a pas été pleinement mise en œuvre pour les AE des systèmes d’entreprise et a été exécutée par les mêmes personnes qui ont assuré les fonctions d’EAS pour les AE des systèmes ministériels. Une fois le service autorisé à « être mis en ligne », rien n’était en place pour convaincre les responsables du service ou du système de la nécessité d’achever le processus d’AE et d’obtenir cette dernière. Si aucune AE n’était obtenue (ou, d’un point de vue conceptuel, si l’AE était annulée), le service n’était pas mis hors service.
- L’éventail des conséquences en cas de non-conformité à la suite d’une surveillance des conditions de l’AE reste à déterminer. La direction n’était pas sûre de ce qui pouvait être fait une fois que l’exploitation du service ou du système a commencé. Bien que cela puisse être modifié, on a noté que certains systèmes supportaient mal une mise hors service.
- L’établissement de rapports sur les conditions est un élément essentiel de la surveillance de la conformité. Avec la mise en œuvre de processus plus normalisés, les équipes responsables des systèmes d’entreprise ont commencé à effectuer le suivi des conditions connexes. Actuellement, aucune AE de systèmes d’entreprise n’est signée si les conditions ne comportent pas de BPR, s’il manque une signature de la haute direction du responsable du système et s’il manque une date d’achèvement prévue.
- L’analyse des AE accordées à ce jour avait pris du retard pour les AE plus anciennes. Aucun processus officiel d’acheminement au palier hiérarchique approprié n’existait. Si les responsables de secteur de service étaient considérés comme responsables du respect des conditions des AE, ils n’assuraient pas de suivi régulier et rien n’indiquait que des mesures d’application aient été prises pour gérer les AE expirées (AE intérimaire et AE définitive assorties de conditions).
Les activités de conformité ministérielles et d’entreprise, par l’intermédiaire de la surveillance et de l’application des conditions, n’ont pas la capacité ou le soutien de la direction pour garantir de manière efficace que les systèmes et services du gouvernement du Canada sont suffisamment protégés contre des menaces potentielles. En conséquence, SPC ne respecte pas la directive politique de surveillance continue et de renouvellement de l’autorisation.
Recommandation 6
Priorité Moyenne
Le SMAP de la DGDPT et le SMAP de la DGSM (par l’intermédiaire du DPS) devraient mettre en place un processus uniformisé pour la surveillance et l’application des conditions d’AE.
Réponse de la direction
La direction est d’accord avec la recommandation.
Selon la réponse à la recommandation 1, une directive sur la gestion des risques liés à la sécurité des TI et une norme d’EAS seront élaborées conjointement par la DGDPT et la DGSM. Ces instruments de politique définiront les responsabilités en matière de surveillance, de conformité et de reddition de comptes au CGRS sur l’état d’avancement des activités d’EAS et le respect des conditions d’AE.
C. Conclusion
SPC a deux responsabilités distinctes en matière de sécurité et d’autorisation : une organisation de services ministériels et l’organisation de services d’entreprise internes. La structure de gouvernance définit deux entités distinctes qui mènent des EAS : les Services ministériels sont responsables de l’EAS des systèmes ministériels de SPC, et la Direction générale du dirigeant principal de la technologie (DGDPT) est responsable de la TI de l’entreprise. Cela a conduit à l’élaboration de deux ensembles distincts mais liés d’orientations documentées, de modèles d’éléments et de pratiques de travail.
Les examens d’évaluation de la sécurité sont effectués par le personnel du ministère et de l’entreprise en suivant les directives du document ITSG-33. Le rôle de signataire autorisé a été attribué dans les deux cas, et les AE sont approuvées. La conformité et la surveillance des conditions des AE sont moins bien gérées. En outre, on constate l’absence d’un processus officiel pour garantir la conformité avec les politiques du CT et de SPC.
SPC présente des faiblesses en ce qui concerne les documents d’orientation officiels, les approches coordonnées des EAS pour les systèmes ministériels et les systèmes d’entreprise, la normalisation des modèles et un ensemble de pratiques professionnelles communes. Cela a abouti à une mauvaise compréhension des rôles et responsabilités. Les changements de gouvernance récents et en cours ont eu pour conséquence que les questions d’organisation et de capacité relatives aux deux environnements n’ont pas été traitées en temps utile.
Le manque de documentation à jour et officielle pour le processus de travail fait que l’on se fie davantage au format et au contenu des modèles pour les éléments utilisés dans l’évaluation et l’autorisation des systèmes et des services. Les différences entre les modèles utilisés pour les systèmes ministériels et les systèmes d’entreprise ajoutent une complexité inutile. Il en résulte également un dédoublement du travail en ce qui concerne les demandes d’éléments de preuve et l’évaluation de ceux-ci, qui est également sujette à des variations en fonction de la personne qui effectue le travail. Il n’est pas garanti que l’EAS requise soit réalisée pour tous les projets ou pour les travaux ne portant pas sur des projets.
Jusqu’en août 2018, la fonction de surveillance continue des systèmes d’entreprise était hébergée conjointement avec l’évaluation. C’est toujours le cas pour les EAS des systèmes ministériels. La fonction de contrôle des systèmes d’entreprise est en cours de séparation, mais les procédures pour la gestion de cet effort sont encore en cours d’élaboration. L’absence d’un processus officiel d’acheminement au palier hiérarchique approprié associé à un manque de mesures d’application entraîne un risque accru en matière de surveillance.
Les différences qui existent entre les EAS des systèmes d’entreprise et des systèmes ministériels portent sur les délais, la portée, les ressources et l’implication des clients. Même si le Plan de sécurité ministériel tente de résoudre les enjeux au niveau de l’entreprise, on n’a pas pu trouver les documents sources appuyant ces enjeux d’entreprise. Il n’existe aucune disposition pour un plan qui traite des enjeux relatifs aux systèmes d’entreprise.
Un processus officiel commun est nécessaire, avec des mises en œuvre distinctes, pour tenir compte des différences entre la EAS des systèmes ministériels et d’entreprise. L’évolution actuelle des processus et pratiques d’EAS distincts est inefficace et pose des défis pour l’application correcte des pratiques exemplaires de gestion de l’évaluation et autorisation de sécurité.
Annexe A – Domaines d’intérêt et critères d’audit précis
Titre du critère | Critères d’audit |
---|---|
Domaine d’intérêt 1 : gouvernanceNote des sources des critères 1Note des sources des critères 2Note des sources des critères 3Note des sources des critères 4 | |
1.1 Cadre stratégique de l’évaluation et de l’autorisation de la sécurité de la TI | SPC a élaboré, approuvé, communiqué et mis à jour une politique/directive sur l’évaluation et l’autorisation des systèmes et services informatiques, avant leur installation et dans le cadre d’un processus continu après celle-ci. |
1.2 Rôles et responsabilités de l’EAS | Les rôles et les responsabilités de l’EAS sont documentés, attribués et communiqués à tous les intervenants et clients de SPC concernés, et fonctionnent comme prévu. |
1.3 Surveillance | Un régime de surveillance efficace est en place pour gérer l’EAS des systèmes/services informatiques. |
Domaine d’intérêt 2 : Gestion des risquesNote des sources des critères 3Note des sources des critères 8 | |
2.1 Gestion des risques pour la sécurité des TI | Il existe un processus permettant de cerner et de surveiller les risques en matière de sécurité associés à l’ensemble des projets tout au long de leur cycle de vie en ce qui concerne : l’utilisation d’éléments de risques standards (ITSG-33); le recours à une journalisation et à une surveillance actives des éléments des risques liés à la sécurité des TI pour les projets; l’utilisation d’un registre des risques visant à gérer les risques liés à la sécurité informatique. |
Domaine d’intérêt 3 : Mécanismes de contrôle internesNote des sources des critères 1Note des sources des critères 3Note des sources des critères 4Note des sources des critères 5Note des sources des critères 6Note des sources des critères 7Note des sources des critères 9 | |
3.1 Intégration de l’EAS dans la gestion de projet | Un processus normalisé d’EAS a été documenté, communiqué et intégré officiellement au cadre de gouvernance du projet (CGP). |
3.2 Examens normalisés de l’EAS | SPC applique un ensemble de déclencheurs et de procédures normalisés d’EAS visant à recenser, à saisir et à évaluer tous les projets adéquats, et à autoriser tous les systèmes et services informatiques qui en résultent. |
3.3 Surveillance des conditions de l’AE et renouvellement de l’autorisation | SPC a mis en place un processus d’examen et de révision des AE des services ou des systèmes afin de vérifier que les autorisations restent valables, et utilise des déclencheurs normalisés pour garantir le respect permanent des conditions et des exigences des AE. |
Annexe B – Méthode d’échantillonnage
À partir d’un ensemble de 39 projets en cours d’EAS sur des systèmes d’entreprise et de 12 projets d’EAS sur des systèmes ministériels, l’équipe responsable de l’audit a extrait un échantillon discrétionnaire de sept projets et de deux projets respectivement. Pour vérifier la fiabilité et l’uniformité de la méthode d’EAS en place, l’équipe responsable de l’audit a examiné six éléments clés d’EAS sur des systèmes d’entreprise (4 pour des EAS sur les systèmes ministériels) pour chacun des projets d’EAS échantillonné, en fonction des critères suivants :
- Qualité de l’élément par rapport au modèle respectif;
- Présence ou absence d’élément par rapport au modèle respectif;
- Présence ou absence de certains éléments;
- Décisions prises;
- Exhaustivité, actualité et exactitude;
- Rôles ou matrices RACI pour présenter la garde des éléments de preuve.
L’échantillon pour les systèmes d’entreprise représentait divers environnements, y compris quatre projets de centre de données d’entreprise, deux projets d’informatique en nuage et un projet existant (dirigé par un client). En outre, les projets faisant partie de l’échantillon ont été tirés du rapport de situation de la DGSG et représentaient trois projets rouges (à risque important), trois projets verts (sur la bonne voie) et un projet jaune (à risque). L’échantillon pour les systèmes ministériels était composé d’une évaluation achevée et d’une évaluation en cours.
Annexe C – Priorités concernant les recommandations faisant suite à la vérification
Le Bureau de la vérification et de l’évaluation attribue une note d’évaluation aux recommandations relatives à la mobilisation interne pour indiquer la priorité de chaque recommandation à la haute direction. Cette évaluation correspond à l’exposition au risque attribué aux observations indiquées dans la vérification et aux conditions sous-jacentes à la recommandation et selon le contexte organisationnel.
Cote | Explication |
---|---|
Priorité Élevée |
|
Priorité Moyenne |
|
Priorité Faible |
|
Annexe D – Liste des acronymes
Terme | Définition |
---|---|
SCAA |
Services de contrôles d’accès administratifs |
AM |
Module Administration (SCAA) |
AE |
Autorisation d’exploiter |
DO |
Demande opérationnelle |
DBO |
Document sur les besoins opérationnels |
CA |
Module Vérificateur du changement (SCAA) |
CCC |
Centre canadien pour la cybersécurité |
CID |
Confidentialité, intégrité et disponibilité |
DPIS |
Dirigeant principal de l’information et de la sécurité |
DPS |
Dirigeant principal de la sécurité (SPC) |
DGDPT |
Direction générale du dirigeant principal des technologies (anciennement Cybersécurité et sécurité de la technologie de l’information) (SPC) |
DGS |
Directive sur la gestion de la sécurité (Secrétariat du Conseil du Trésor) |
PSM |
Plan de sécurité ministériel |
CDE |
Centre de données d’entreprise |
GCdocs |
Système de gestion des documents du gouvernement du Canada |
GC |
Gouvernement du Canada |
OSII |
Organisation de services internes intégrés (c’est-à-dire ministère fédéral qui fournit des services à l’ensemble du gouvernement) |
IAI |
Institut des auditeurs internes |
TI |
Technologie de l’information |
ITSG-33 |
Conseils en matière de sécurité des technologies de l’information – 33 |
SERSTI |
Services d’évaluation des risques liés à la sécurité de la TI (DGSG) |
CGRSTI |
Cadre de gestion des risques en matière de sécurité de la TI |
DGRSSN |
Direction générale des réseaux, de la sécurité et des services numériques (SPC) |
BVE |
Bureau de la vérification et de l’évaluation (SPC) |
BPR |
Bureau de première responsabilité |
PAM |
Module de gestion des privilèges d’accès SCAA) |
CGP |
Cadre de gouvernance des projets |
PSG |
Politique sur la sécurité du gouvernement |
GP |
Gestionnaire de projet |
DGGEP |
Direction générale de la gestion et de l’exécution des projets (SPC) |
PAJ |
Plan d’action et jalons (anciennement appelé Plan d’action stratégique, PAS) |
EAS |
Évaluation et autorisation de sécurité |
SMAP |
Sous-ministre adjoint principal |
DGPGS |
Direction générale de la prestation et de la gestion des services (SPC) |
CHD |
Conseil de la haute direction (SPC) |
GGS |
Gestion et gouvernance de la sécurité (DGDPT) |
END |
Énoncé de la nature délicate |
CESPA |
Conseil d’examen des services, des projets et de l’approvisionnement (SPC) |
CGRS |
Conseil de la gestion des risques liés à la sécurité (SPC) |
SPC |
Services partagés Canada |
(S)CT |
(Secrétariat du) Conseil du Trésor |
Détails de la page
- Date de modification :