Vérification des contrôles d’accès aux systèmes

Direction générale de la vérification interne et de la responsabilisation
Citoyenneté et Immigration Canada
Rapport définitif
Mai 2012

• Liste des acronymes
• Sommaire
• 1.0 Introduction
  • 1.1 Contexte
    • 1.1.1 Organisation
    • 1.1.2 Au sujet des contrôles d’accès aux systèmes
    • 1.1.3 Contexte environnemental
  • 1.2 Évaluation des risques liés à la vérification
  • 1.3 Objectif de la vérification
  • 1.4 Critères de la vérification
  • 1.5 Portée de la vérification
  • 1.6 Méthode
• 2.0 Conclusion de la vérification
• 3.0 Observations et recommandations
  • 3.1 Environnement de contrôle
    • 3.1.1 Gouvernance et orientation stratégique
    • 3.1.2 Responsabilisation
    • 3.1.3 Résultats et rendement
    • 3.1.4 Gestion des risques
  • 3.2 Cadre de contrôle interne
    • 3.2.1 Gérance
      • 3.2.1.1 Identification et authentification
      • 3.2.1.2 Autorisation et contrôle
      • 3.2.1.3 Examen et détection
    • 3.2.2 Personnes
• Annexe A : Critères de vérification détaillés
• Annexe B : Plan d’action de la direction
• Annexe C : Calendrier de la vérification

Liste des acronymes

AC

Administration centrale

ASFC

Agence des services frontaliers du Canada

CIC

Citoyenneté et Immigration Canada

CIPC

Centre d’information de la police canadienne

COBIT

Control Objectives for Information and Related Technology

CRG

Cadre de responsabilisation de gestion

CSA

Coordonnateur de la sécurité de l’accès

DGGTI

Direction générale de la gestion et des technologies de l’information

DGSGI

Direction générale des solutions et de la gestion de l’information

EMR

Évaluation des menaces et des risques

GI-TI

Gestion de l’information et technologie de l’information

GSTI

Gestion de la sécurité des technologies de l’information

PRM

Profil de risque ministériel

PVR

Plan de vérification axé sur le risque

RC

Recherche sur le client

RH

Ressources humaines

SAP/SIGF

Système intégré de gestion financière

SCRI

Système de comptes à recevoir du programme d’immigration

SCT

Secrétariat du Conseil du Trésor

SGRH

Système de gestion des ressources humaines

SMGC

Système mondial de gestion des cas

SNGC

Système national de gestion des cas

SSOBL

Système de soutien des opérations des bureaux locaux

TI

Technologie de l’information

UCA

Unité du contrôle de l’accès

Sommaire

Le Plan de vérification axé sur le risque (PVR) de la Direction générale de la vérification interne et de la responsabilisation de Citoyenneté et Immigration Canada (CIC) précise les engagements en matière de vérification et d’avis à prendre au cours d’un exercice donné à la lumière d’une combinaison de priorités et de risques ministériels. Le PVR 2011–2014, qui a été approuvé par le Comité de vérification du Ministère en avril 2011, indique le besoin de procéder à la vérification des contrôles d’accès aux systèmes. La présente vérification met l’accent sur les mesures de contrôle interne en place concernant l’accès aux systèmes.

Relevant du Secteur des services ministériels, la Direction générale de la gestion et des technologies de l’information (DGGTI) a la responsabilité de planifier, de créer et d’exécuter les applications, ainsi que l’infrastructure technologique et informatique, nécessaires à la prestation des services et des programmes de CIC aux Canadiens, aux immigrants et aux réfugiés, et à la gestion du Ministère. Le 1^er avril 2012, la DGGTI et l’équipe du Système mondial de gestion des cas (SMGC) ont été fusionnées pour donner lieu à la Direction générale des solutions et de la gestion de l’information (DGSGI).

L’objectif de cette vérification était d’évaluer la robustesse de l’environnement de contrôle et la justesse du cadre de contrôle interne connexe en place concernant l’accès aux systèmes. Les critères employés pour la vérification reposent sur les lois, les politiques et les lignes directrices du Secrétariat du Conseil du Trésor (SCT) et de CIC, de même que sur des éléments tirés d’un cadre de gouvernance de la technologie de l’information (TI) généralement reconnu.

Les résultats de la vérification permettent de conclure que des politiques exposant les grandes lignes de la structure de gouvernance et de l’orientation stratégique des contrôles d’accès aux systèmes sont en place.

Plus précisément, nous pouvons conclure que l’environnement de contrôle et le cadre de contrôle interne répondaient en partie à nos attentes. La mesure dans laquelle nos attentes étaient satisfaites varie selon les systèmes examinés.

La direction devra prêter une attention particulière à certains points signalés à la section 3.0 du présent rapport, pour lesquels des observations détaillées et des recommandations sont formulées en vue d’apporter les améliorations nécessaires, notamment :

• Renforcer davantage les responsabilités liées à la propriété des systèmes et des données;
• Surveiller les constats associés aux indicateurs et aux résultats et en rendre compte à la haute direction, conformément à ce qui est prévu;
• Veiller à ce que des évaluations du risque concernant l’accès aux systèmes aient été effectuées et documentées à l’égard des systèmes;
• Renforcer les contrôles concernant l’accès aux systèmes, y compris les contrôles par mot de passe, l’autorisation d’accès aux systèmes, le suivi des comptes inactifs et la surveillance de l’accès non autorisé;
• Améliorer les directives fournies aux personnes responsables de gérer l’accès aux systèmes.

Le rapport comprend des réponses à nos recommandations, un plan d’action de la direction et des dates cibles pour la mise en œuvre de mesures pour le suivi des recommandations.

La vérification a été effectuée conformément aux Normes relatives à la vérification interne pour le gouvernement du Canada et aux Normes internationales pour la pratique professionnelle de la vérification interne.

1.0 Introduction

Le Plan de vérification axé sur le risque (PVR) de la Direction générale de la vérification interne et de la responsabilisation précise les engagements en matière de vérification et d’avis à prendre au cours d’un exercice donné à la lumière d’une combinaison de priorités et de risques ministériels. Le PVR 2011–2014, qui a été approuvé par le Comité de vérification du Ministère en avril 2011, indique le besoin de procéder à la vérification des contrôles d’accès aux systèmes. La présente vérification met l’accent sur les mesures de contrôle interne en place concernant l’accès aux systèmes. La phase d’examen s’est déroulée de juin 2011 à janvier 2012.

1.1 Contexte

1.1.1 Organisation

Relevant du Secteur des services ministériels, la DGGTI a la responsabilité de planifier, de créer et d’exécuter les applications TI, qui constituent l’infrastructure technologique et informatique nécessaire à la prestation des services et des programmes de CIC aux Canadiens, aux immigrants et aux réfugiés, et à la gestion du Ministère.

Le 1^er avril 2012, la DGGTI et l’équipe du SMGC ont été fusionnées pour donner lieu à la Direction générale des solutions et de la gestion de l’information.

Au sein de la DGSGI, la Direction de la technologie de l’information a pour responsabilités, entre autres, le soutien au poste de travail, la sécurité des TI, l’administration des bases de données, la gestion des versions, la certification, la gestion des biens de TI, le contrôle de l’accès, la mobilité des TI, l’ingénierie ne relevant pas de Services partagés Canada et le bureau d’aide national et international.

De façon générale, l’accès aux systèmes est contrôlé par la DGSGI, à la fois à l’administration centrale (AC) et dans les bureaux régionaux. Toutefois, la Direction générale des opérations financières et la Direction générale des ressources humaines ont toutes deux certaines responsabilités à assumer à l’égard de l’accès à certains systèmes de TI propres aux finances ou à l’administration. Les coordonnateurs de la sécurité de l’accès (CSA) et les super utilisateurs du Ministère participent également à la gestion de l’accès aux systèmes.

1.1.2 Au sujet des contrôles d’accès aux systèmes

CIC dépend grandement de divers systèmes électroniques pour l’exécution de son mandat. Ainsi, il est essentiel que des contrôles d’accès efficaces soient en place pour garantir la sécurisation des données contenues dans ces systèmes et leur protection contre l’accès non autorisé. Les systèmes en question sont utilisés au Canada et à l’étranger.

Les exigences du gouvernement à l’endroit des ministères qui mettent en place des contrôles d’accès aux systèmes sont décrites dans la Politique sur la sécurité du gouvernement du SCT et la norme de sécurité opérationnelle connexe, ou Gestion de la sécurité des technologies de l’information (GSTI). La GSTI définit les exigences fondamentales en matière de sécurité que doivent satisfaire les ministères. Elle va plus loin que la Politique en ce qui a trait à la sécurité des TI, y compris les contrôles d’accès aux systèmes. La GSTI prévoit des mesures de protection préventive, notamment pour l’identification et l’authentification, ainsi que l’autorisation et le contrôle de l’accès, et des exigences en matière de protection fondées sur le risque. Les exigences signalées dans ces deux documents ont servi de fondement à l’établissement de nos critères de vérification.

1.1.3 Contexte environnemental

La mission de CIC à l’égard de la gestion de l’information et de la technologie de l’information (GI-TI) est de rendre ses clients plus indépendants en offrant un accès aux solutions informatiques et technologiques en tout temps et de partout. CIC est déterminé à maintenir un environnement mondial de GI-TI de grande qualité, qui permet l’élaboration de solutions commerciales en misant sur les progrès réalisés dans le domaine de la technologie et sur les initiatives pangouvernementales telles que les services partagés.

La technologie de l’information est omniprésente, facile à utiliser et totalement intégrée au travail de CIC. L’environnement de travail offre un ensemble d’outils collaboratifs en constante évolution qui permettent au Ministère de collaborer avec ses partenaires internes et externes. L’échange d’information et la collaboration au sein du Ministère et avec les partenaires sont mis en relief et accrus au moyen des médias sociaux et de services semblables, à mesure qu’ils naissent. La GI-TI de CIC tire profit de l’analyse de l’information et des outils et applications de gestion des connaissances liés aux fonctions principales pour progresser vers l’atteinte des objectifs de la modernisation du service à la clientèle, de la réforme concernant les réfugiés et de l’excellence en gestion.

L’identité et la gestion de l’accès sont des éléments centraux de la sécurité des TI et de l’information. Les autorisations d’accès accordées au personnel sont de première importance quant aux éléments à prendre en considération pour assurer la sécurité de l’information de CIC : quand, pour quels systèmes et renseignements, et pendant combien de temps.

1.2 Évaluation des risques liés à la vérification

Au cours de la phase de planification de cette vérification, une évaluation préliminaire des risques a été effectuée au moyen d’entrevues et de réunions de planification à l’AC, et d’un examen des documents. Cette information a été analysée à la lumière des principaux contrôles de gestion catégorisés dans le Cadre de responsabilisation de gestion (CRG), ainsi que d’autres normes et cadres pertinents comme les Control Objectives for Information and Related Technology (COBIT) et la GSTI, en vue de cerner et d’évaluer les éléments posant un risque particulier. Cette analyse a été réalisée dans le but d’établir la portée de la vérification, les critères de vérification et la méthode de fonctionnement qui permettrait de recueillir suffisamment de faits fiables et utiles pour appuyer les observations et les constatations découlant de la vérification.

À la suite de cette analyse, nous avons recommandé d’inclure les éléments qui suivent à la portée de la vérification (cette portée est expliquée plus en détail ultérieurement).

1.3 Objectif de la vérification

L’objectif de cette vérification était d’évaluer la robustesse de l’environnement de contrôle et la justesse du cadre de contrôle interne connexe en place concernant l’accès aux systèmes.

1.4 Critères de la vérification

Les critères sont des points de référence permettant d’évaluer les objectifs de la vérification en matière d’engagement. Ils reposent sur les lois, les politiques et les lignes directrices du SCT et de CIC qui s’appliquent, de même que sur des éléments tirés d’un cadre de gouvernance de la technologie de l’information (TI) généralement reconnu. Les critères détaillés de la vérification, qui ont été fournis à la direction au début de cet engagement, sont présentés à l’annexe A.

1.5 Portée de la vérification

La vérification portait sur la gestion des contrôles d’accès aux systèmes à l’AC et tenait compte des procédures régionales dans lesquelles l’AC est concernée. La portée se limitait aux activités dont CIC a le contrôle.

CIC possède 135 systèmes fonctionnels, ministériels, de gestion de l’information et en ligne. Toutefois, un nombre important de ces systèmes présentent des risques limités quant à leur fonctionnement, sont utilisés principalement par des personnes à l’extérieur de CIC ou ont récemment fait l’objet d’activités de vérification au chapitre des contrôles.

Afin de centrer les ressources affectées à la vérification sur les systèmes essentiels aux activités de CIC qui présentent des risques élevés, l’équipe chargée de la vérification a exclu un grand nombre de ces systèmes de la portée de la vérification. Les applications TI en ligne ont notamment été exclues afin d’axer la vérification sur les applications TI utilisées à l’interne plutôt que sur celles accessibles au grand public. Le Système de traitement informatisé des dossiers d’immigration a été exclu puisqu’il est visé par les vérifications concernant les missions et que son utilisation a diminué à la suite de la mise en œuvre du SMGC à l’étranger.

Parmi les systèmes restants, l’équipe chargée de la vérification s’est concentrée sur les plus gros et les plus importants^{Note de bas de page 1} pour en arriver aux huit systèmes énumérés ci dessous. Le Système national de gestion des cas (SNGC) a été inclus à la suggestion de la direction, tout comme la Recherche sur le client (RC) en raison de son lien avec le SNGC.

Les systèmes choisis dans le cadre de cette vérification sont les suivants :

• Système mondial de gestion des cas (SMGC)
• Système de soutien des opérations des bureaux locaux (SSOBL)
• Système intégré de gestion financière (SAP/SIGF)
• Système de gestion des ressources humaines PeopleSoft (SGRH PeopleSoft)
• Système de comptes à recevoir du programme d’immigration (SCRI)
• Système national de gestion des cas (SNGC)
• Recherche sur le client (RC)
• Centre d’information de la police canadienne (CIPC)

La période visée par la portée comprenait des activités de contrôle principalement liées à l’exercice 2010–2011.

En ce qui concerne le CIPC, le SNGC et laRC, notre examen se limitait aux éléments de l’accès aux systèmes dont CIC a la responsabilité. Dans le cas du SNGC, l’assignation des rôles aux utilisateurs est faite par l’Agence des services frontaliers du Canada (ASFC) une fois que CIC a créé les comptes individuels pour l’accès au système, tandis que l’accès à laRC est limité aux demandes d’information. Ainsi, l’examen de ces systèmes portait principalement sur la création et la surveillance des comptes par CIC. La gestion du CIPC est assurée par les Services nationaux de police, et son administration par la GRC. L’examen de ce système a été limité aux responsabilités de l’Unité du contrôle de l’accès (UCA), en particulier celles liées à l’administration des comptes utilisateurs.

La vérification était axée sur l’administration des contrôles d’accès aux applications utilisateurs, au niveau de l’application. Elle ne visait aucunement les contrôles aux niveaux du réseau, de la base de données ou du système d’exploitation.

1.6 Méthode

La vérification a été effectuée conformément aux Normes relatives à la vérification interne pour le gouvernement du Canada et aux Normes internationales pour la pratique professionnelle de la vérification interne.

Deux secteurs d’intérêt ont été examinés :

• l’environnement de contrôle;
• le cadre de contrôle interne.

Au cours de la phase de planification de la vérification, l’équipe chargée de la vérification a mené des entrevues et procédé à un examen préliminaire des documents afin de cerner et d’évaluer les éléments présentant un risque particulier. L’évaluation des risques nous a permis d’axer la portée de la vérification et les critères sur les éléments présentant les plus grands risques. De plus, elle nous a aidés à établir nos procédures de vérification en vue de recueillir suffisamment de données fiables et pertinentes pour appuyer nos observations et nos constats.

Dans le cadre de notre examen de l’environnement de contrôle et du cadre de contrôle interne, nous avons mené de nouvelles entrevues auprès de la direction et du personnel, examiné des documents, procédé à des tests de vérification, examiné des dossiers et analysé nos observations et nos constatations.

2.0 Conclusion de la vérification

Nous pouvons conclure que l’environnement de contrôle et le cadre de contrôle interne répondaient en partie à nos attentes. La mesure dans laquelle nos attentes étaient satisfaites variait selon les systèmes examinés. Nous avons constaté que des politiques définissant la structure de gouvernance et l’orientation stratégique relatives aux contrôles d’accès aux systèmes étaient en place.

La direction devra prêter une attention particulière à un certain nombre d’éléments signalés à la prochaine section du présent rapport. Des observations détaillées et des recommandations sont formulées en vue d’apporter les améliorations nécessaires. Le rapport comporte les réponses de la direction, un plan d’action et des dates cibles pour la mise en œuvre de mesures pour le suivi des recommandations.

3.0 Observations et recommandations

3.1 Environnement de contrôle

L’objectif concernant ce secteur d’intérêt était d’évaluer la justesse des cadres de gouvernance et de gestion des risques en place à CIC pour la mise en œuvre de contrôles d’accès aux systèmes, en prêtant une attention particulière aux éléments suivants :

• gouvernance et orientation stratégique;
• responsabilisation;
• résultats et rendement;
• gestion des risques.

Nous nous attendions à constater la présence de politiques ministérielles établissant les attentes en matière de contrôles d’accès aux systèmes; à ce que les rôles et les responsabilités concernant la propriété des données et des systèmes soient clairement définis afin de veiller à ce que le contrôle de l’accès aux systèmes soit géré de manière conforme aux objectifs de l’organisation; à ce que des procédures soient en place pour mesurer l’efficacité du rendement des contrôles d’accès aux systèmes et d’en rendre compte à la haute direction; et à ce que les risques associés aux contrôles d’accès aux systèmes aient été cernés et évalués, et des mesures d’atténuation mises en œuvre.

De manière générale, l’environnement de contrôle en place concernant les contrôles d’accès aux systèmes répondait partiellement à nos attentes.

3.1.1 Gouvernance et orientation stratégique

Nous nous attendions à ce qu’une politique ou un cadre obligatoire établissant les attentes ministérielles à l’égard des politiques de contrôle à l’accès au niveau des systèmes et guidant l’utilisation de la TI dans l’atteinte des objectifs de l’organisation soit en place.

Nous avons constaté que la Politique sur la sécurité des TI de CIC (« la Politique ») tient compte des exigences liées aux contrôles d’accès aux systèmes prescrites par la GSTI.

La Politique établit les exigences en matière de confidentialité, de disponibilité et d’intégrité des biens de TI de manière à assurer la viabilité des programmes du Ministère et de ceux de ministères partenaires ou intervenants. La Politique comprend l’exigence d’identifier et de catégoriser les ressources d’information et de TI, et de limiter l’accès aux applications TI et leur utilisation au moyen de niveaux de sécurité appropriés et d’un accès réservé aux personnes qui ont besoin de savoir. De plus, la Politique exige expressément que le Ministère établisse des processus pour examiner et rajuster l’accès aux privilèges et leur utilisation.

3.1.2 Responsabilisation

Nous nous attendions à ce que les politiques ministérielles ou propres aux systèmes définissent les rôles et les responsabilités quant à la propriété des données et des systèmes.

Nous avons constaté que les politiques ou documents propres aux systèmes examinés étaient présents dans une mesure allant de « non existants » à « des politiques sont en place et définissent clairement les rôles et les responsabilités à l’égard de la propriété des données et des systèmes ».

Dans le cas du SGRH PeopleSoft, nous avons constaté que des procédures et des lignes directrices en matière de sécurité définissant clairement les rôles et les responsabilités étaient en place à l’intention des utilisateurs.

Dans le cas du SMGC, nous avons constaté qu’un énoncé de sensibilité et une évaluation des menaces et des risques (EMR) étaient en place. Ces documents renferment des éléments clés de ce que nous nous attendrions à trouver dans une politique propre à un système concernant la définition des rôles et des responsabilités, y compris la désignation du propriétaire fonctionnel; la classification des objectifs en matière de sécurité liés à la confidentialité, à l’intégrité et à la disponibilité du système; et la transmission de renseignements à la haute direction pour lui permettre de prendre des décisions éclairées au sujet de la sécurité du SMGC. De plus, nous avons constaté que les directives du SMGC sur la création de comptes utilisateurs définissaient les rôles fondamentaux concernant les programmes d’immigration et de citoyenneté, ainsi que les rôles fonctionnels des directions générales de l’immigration et de la gestion de la santé.

Dans le cas du SAP/SIGF, nous avons remarqué que des politiques propres au système étaient en cours d’élaboration et n’étaient donc pas en place. Pour ce qui est du SSOBL, aucun document ou politique propre au système ne définit les rôles et les responsabilités relatives à la propriété des données et des systèmes. Il n’est pas clair qui a le pouvoir de déterminer les niveaux d’accès et peu de restrictions sont établies, et ce rôle est assumé par le gestionnaire de l’utilisateur et le coordonnateur de la sécurité de l’accès dans chacun des bureaux. Il n’existait pas non plus de politiques ou de documents propres au système pour le SCRI, le SNGC et laRC.

CIC n’est pas responsable des politiques et des procédures sur la propriété du système et des données pour ce qui est du CIPC. Ainsi, nous n’avons pas examiné ces politiques.

Recommandation 1

La DGSGI, en collaboration avec les Finances s’il y a lieu, devrait veiller à ce que des politiques et des procédures précisant la propriété des systèmes et des données soient en place pour l’ensemble des systèmes de TI.

Réponse de la direction

La DGSGI examinera ses produits de gouvernance afin de s’assurer que la propriété du SAP/SIGF, du SSOBL et du SCRI et de leurs données est bien précisée. En collaboration avec les Finances s’il y a lieu, la DGSGI rédigera les documents nécessaires inexistants pour l’approbation par la haute direction. L’échéance est fixée au quatrième trimestre de 2012–2013.

LaRC est un système d’interrogation et non un dépôt de données. De plus, elle sera retirée sous peu. La propriété des données ne s’applique pas dans ce cas.

Comme le SNGC appartient à l’ASFC, la propriété des données de ce système ne concerne pas CIC.

Remarque : La propriété du SNGC a été officiellement transférée à l’ASFC le 1^er décembre 2011. Toutefois, le système demeure sur le réseau de CIC. Si les comptes continuent d’être créés par CIC, les données sont la propriété de l’ASFC.

3.1.3 Résultats et rendement

Nous nous attendions à ce que les résultats en matière de rendement soient évalués et communiqués à la haute direction.

Nous avons constaté que les résultats et les indicateurs liés aux contrôles d’accès aux systèmes étaient définis dans le plan d’activités de la DGGTI. Toutefois, d’après les discussions que nous avons eues avec la direction, ces résultats et indicateurs n’étaient pas surveillés de manière active, et par conséquent, n’étaient pas communiqués à la haute direction dans les rapports trimestriels du Ministère et leurs tableaux de bord connexes.

Chaque année, CIC présente au SCT une évaluation de la GSTI qui est utilisée pour étayer l’évaluation fondée sur leCRG. L’évaluation de CIC comprend une section sur la conformité du Ministère à la GSTI en ce qui a trait à l’autorisation et au contrôle de l’accès. Dans sa présentation de décembre 2010, à la section « Autorisation et contrôle de l’accès », CIC a évalué qu’il était partiellement en conformité avec les éléments « Gestion des privilèges d’accès » et « Contrôle de l’accès à l’information et aux systèmes de TI ».

La nouvelle politique de CIC sur la sécurité des TI (entrée en vigueur le 1^er avril 2011) établit les exigences en matière de surveillance et de reddition de comptes qui n’étaient pas explicitement abordées dans l’ancienne version. Ces exigences comprennent les responsabilités relatives à la mise en œuvre de la politique à l’échelle du Ministère, la surveillance de la conformité globale du Ministère et l’évaluation périodique de son efficacité.

Recommandation 2

La DGSGI devrait s’assurer que les indicateurs et les résultats établis concernant les contrôles d’accès aux systèmes font l’objet d’une surveillance et que les résultats qui y sont associés sont communiqués à la haute direction de manière périodique, comme prévu.

Réponse de la direction

La DGSGI surveillera les comptes valides des applications actives et signalera les cas ou l’incidence d’accès non autorisé à la haute direction dans les tableaux de bord trimestriels. L’échéance est fixée au quatrième trimestre de 2012–2013.

3.1.4 Gestion des risques

Nous nous attendions à ce que la direction ait cerné les risques associés aux contrôles d’accès aux systèmes, à ce que ces risques aient été évalués, et à ce que des mesures d’atténuation aient été mises en œuvre.

Le Ministère a cerné les principaux risques liés à l’atteinte de ses objectifs, y compris ceux liés à laGI-TI, dans le cadre de son Profil de risque ministériel (PRM). De plus, les risques ont été évalués et des mesures d’atténuation ont été signalées dans le PRM. Les progrès réalisés à l’égard des jalons associés au PRM sont rapportés dans le rapport trimestriel du Secteur des services ministériels. L’accès non autorisé aux systèmes de TI figure bel et bien parmi les risques potentiels relevés dans le PRM. Nous avons constaté que le plan d’activités de la DGGTI indiquait que la GI-TI jouait également un rôle contributif dans la gestion d’autres risques ministériels, notamment ceux liés à l’intégrité et à l’exécution des programmes.

Les risques sont également cernés et signalés à la haute direction et au SCT par l’entremise de la présentation annuelle de la conformité à la GSTI qui sert à étayer l’évaluation fondée sur leCRG au chapitre de la sécurité des TI.

Pour chacun des systèmes, nous nous attendions à trouver des documents de certification et d’accréditation, des énoncés de sensibilité et des EMR qui énoncent et évaluent les risques particuliers associés au système, ainsi que des mesures d’atténuation. CIC n’est pas responsable de la gestion des risques relatifs au CIPC. Par conséquent, nous n’avons pas examiné cet élément.

En ce qui a trait au SMGC, nous avons constaté que les documents de certification et d’accréditation, les énoncés de sensibilité et les EMR étaient présents.

Nous n’avons trouvé aucun document de certification ou d’accréditation, énoncé de sensibilité ou EMR pour le SSOBL, le SGRH PeopleSoft, le SNGC, laRC et le SCRI. Cette lacune ou cet élément de risque a été souligné dans la présentation sur la conformité à la GSTI.

Recommandation 3

La DGSGI, en collaboration avec les Finances et les Ressources humaines (RH) s’il y a lieu, devrait s’assurer que des évaluations de risques concernant l’accès aux systèmes sont rédigées et étayées pour l’ensemble des systèmes de TI.

Réponse de la direction

L’EMR de PeopleSoft a été rédigée et le travail se poursuit, en collaboration avec les RH, en vue de son achèvement. L’échéance est fixée au troisième trimestre de 2012–2013.

Comme il existe une EMR et une Évaluation des facteurs relatifs à la vie privée pour le SAP/SIGF, qui sont toutes deux encore valides, cette exigence est jugée comme étant satisfaite. Ces documents seront présentés conformément à ce qui a été demandé.

Aucune EMR ne sera effectuée pour le SSOBL, puisque le système ne sera plus en fonction d’ici deux à trois ans; pour le SNGC, puisque son propriétaire est maintenant l’ASFC à qui la responsabilité à l’égard de l’EMR a été transférée; pour le SCRI puisqu’il sera retiré d’ici 18 mois; et pour laRC, puisque le système sera également retiré d’ici 18 mois.

3.2 Cadre de contrôle interne

L’objectif concernant ce secteur d’intérêt était d’évaluer la justesse du cadre de contrôle interne à l’égard de la mise en œuvre des contrôles d’accès aux systèmes, en accordant une attention particulière à la gérance et aux personnes.

Nous nous attendions à ce qu’un cadre de contrôle approprié soit en place afin de veiller à ce que l’accès aux systèmes soit accordé à des utilisateurs uniquement identifiables; à ce que l’accès soit contrôlé au moyen de mesures d’authentification appropriées; à ce que l’accès soit accordé à des utilisateurs ayant fait l’objet de vérifications convenables et autorisés; à ce que l’accès aux systèmes soit surveillé pour s’assurer que les niveaux d’accès des utilisateurs demeurent appropriés avec le temps; à ce que l’accès non autorisé puisse être détecté; et à ce que les employés et les gestionnaires aient reçu la formation et les outils nécessaires pour assumer efficacement leurs responsabilités à l’égard du contrôle de l’accès aux systèmes.

De façon générale, le cadre de contrôle interne en place pour l’accès aux systèmes répondait partiellement à nos attentes.

3.2.1 Gérance

3.2.1.1 Identification et authentification

Nous nous attendions à ce que des mesures de protection en matière d’identification et d’authentification soient intégrées aux systèmes en fonction du niveau de risque évalué pour le système de TI. Ces mesures de protection devraient comprendre l’ID unique assigné à chacun des utilisateurs, ainsi qu’un contrôle par mot de passe approprié pour les risques et les sensibilités cernés liés au système de TI et à ses données.

En ce qui concerne les mesures de protection en matière d’identification, nous avons constaté qu’elles étaient en place pour deux des huit systèmes examinés. Dans le cas des autres systèmes, nous avons constaté l’existence de comptes génériques et des cas où les utilisateurs avaient obtenu de multiples comptes.

Concernant le SGRH PeopleSoft et le CIPC, nous avons constaté que tous les utilisateurs possédaient un ID personnel et unique permettant l’enregistrement et l’examen de leurs activités.

Dans le cas du SAP/SIGF, nous avons trouvé quelques comptes génériques qui n’étaient pas assignés à un utilisateur en particulier. Nous avons remarqué que tous ces comptes génériques avaient été dépourvus de leurs autorisations d’accès aux fonctionnalités, et tous à l’exception d’un seul étaient bloqués et ne pouvaient donc être utilisés pour accéder au système et à ses données.

Pour ce qui est du SNGC et de laRC, nous avons trouvé quelques ID pour des comptes qui n’avaient pas été assignés à des utilisateurs précis et identifiables. Toutefois, nous avons constaté que personne n’avait accédé à ces comptes.

Dans le cas du SCRI, nous avons constaté que cinq pour cent des ID concernant des comptes actifs n’avaient pas été assignées à des utilisateurs précis et identifiables. Nous n’avons pas été en mesure de déterminer si des personnes avaient accédé à ces comptes en raison de l’absence de fonctionnalité dans le système permettant de suivre l’accès des utilisateurs.

Concernant le SMGC, nous avons constaté que neuf pour cent des comptes utilisateurs n’avaient pas été assignés à un employé en particulier, mais plutôt à un titre de poste ou à une région. Par conséquent, il est impossible d’établir un lien entre l’accès d’usager et une personne précise pour ces comptes. Nous avons également remarqué que personne n’accédait à certains de ces comptes et qu’ils n’étaient pas utilisés.

En ce qui concerne le SSOBL, nous avons constaté la présence de comptes génériques « actifs » (non suspendus) et « réguliers » (sans lien d’urgence) pour lesquels aucun utilisateur précis n’était identifiable dans une proportion d’un pour cent. De ces comptes, certains semblaient avoir été utilisés dans des cas d’urgence (bien qu’ils ne soient pas classés comme des comptes « urgence » pour lesquels des mesures de contrôle supplémentaires sont prévues), certains étaient utilisés à des fins de test ou de développement du système, tandis que le rôle des autres comptes demeurait flou.

De plus, nous avons remarqué qu’un petit pourcentage des utilisateurs du SMGC (2 %), du SSOBL (<1 %), du SGRH PeopleSoft (7 %), du SCRI (5 %) et du SNGC/RC (>1 %) semblaient posséder des comptes multiples.

En ce qui a trait aux mesures de protection en matière d’authentification, nous n’avons pas examiné le CIPC puisque les paramètres des mots de passe et les exigences relatives au changement des mots de passe sont la responsabilité de la GRC. Dans le cas du SMGC, nous avons constaté que les exigences en matière d’authentification (p. ex. les paramètres des mots de passe et les exigences relatives au changement du mot de passe) étaient établies en fonction des risques et des sensibilités liés au système et à ses données cernés par la direction. Concernant tous les autres systèmes examinés, nous avons constaté que les exigences en matière d’authentification n’étaient pas établies en fonction des risques puisque les sensibilités et les risques propres à chacun de ces systèmes n’étaient pas cernés par la direction. Par conséquent, la direction ne peut avoir la certitude que le niveau de protection des mots de passe de ces systèmes est convenable.

Recommandation 4

La DGSGI, en collaboration avec les Finances et les RH s’il y a lieu, devrait cerner les risques et les sensibilités associés à chacun des systèmes de TI et à leurs données connexes afin de veiller à ce que les mesures de contrôle des mots de passe de ces systèmes soient appropriées.

Réponse de la direction

Lorsqu’il existe des mesures de contrôle des mots de passe, la DGSGI s’assure qu’elles sont appropriées selon les recommandations découlant de l’EMR effectuée à l’égard du système. Les nouvelles EMR indiqueront les risques et les sensibilités de chacun des systèmes de TI qui feront l’objet d’une EMR.

En ce qui concerne le SAP/SIGF, le compte générique non assigné à un utilisateur en particulier est nécessaire à des fins d’interaction. Les comptes génériques de laRC seront supprimés s’ils ne sont pas utilisés comme interface avec un autre système. Pour ce qui est du SSOBL, la DGSGI collaborera avec ses partenaires afin de mieux classifier ou de supprimer les comptes signalés, s’il y a lieu.

Comme le SMGC a récemment été mis en œuvre dans l’ensemble des bureaux à l’étranger et au Canada, des comptes utilisateurs ont d’abord été créés en vrac après vérification auprès des gestionnaires. L’équipe du SMGC a amorcé un processus en collaboration avec le Secteur des opérations pour envoyer l’information sur les comptes utilisateurs par bureau à tous les bureaux du réseau et à l’AC à des fins de validation. Cet exercice visant à valider les comptes utilisateurs par bureau sera réalisé à intervalles réguliers. Le premier ensemble de listes a été envoyé à la fin de janvier 2012. Une fois que les bureaux et l’AC auront examiné les listes, les changements nécessaires seront apportés à la lumière de procédures établies concernant la modification des comptes utilisateurs.

L’échéance pour l’examen des comptes utilisateurs du SSOBL et du SMGC a été fixée au troisième trimestre de 2012–2013.

3.2.1.2 Autorisation et contrôle

Nous nous attendions à ce que les utilisateurs fassent l’objet d’une vérification et soient autorisés, identifiés et authentifiés avant d’obtenir l’accès à un système, et à ce que l’accès des utilisateurs soit surveillé en continu pour en assurer la pertinence.

Nous nous attendions à trouver dans le dossier de chacun des utilisateurs un formulaire d’autorisation à l’accès au compte dûment rempli, approuvé par un représentant du Ministère compétent. Le formulaire de demande d’accès au système doit être conçu pour clairement indiquer le niveau d’accès nécessaire selon le type d’utilisateur du système en particulier, et posséder des sections réservées à l’identification et à la signature de l’utilisateur prévu, ainsi qu’à l’identification et à l’autorisation du représentant du Ministère compétent.

Nous avons constaté que les formulaires de demande d’accès utilisateur des différents systèmes examinés étaient bien conçus en ce qui a trait à l’identification et à la signature de l’utilisateur, et à l’identification et à l’autorisation de l’agent compétent. Au chapitre du niveau d’accès exigé par type d’utilisateur, nous avons constaté que les formulaires de demande d’accès étaient appropriés pour l’ensemble des systèmes examinés, à l’exception du SAP/SIGF. Dans le cas du SAP/SIGF, le formulaire de demande d’accès ne comporte aucune section sur les conditions d’accès propres aux besoins de l’utilisateur.

Lorsque nous avons voulu examiner un échantillon de formulaires d’autorisation d’accès à un compte, nous avons remarqué qu’un nombre important de ces formulaires ne pouvaient être situés (SAP/SIGF : 3 %; SGRH PeopleSoft : 10 %; SMGC : 33 %; et SSOBL/SNGC/RC : 12 %). De plus, un certain nombre de formulaires sélectionnés que nous avons pu trouver n’avaient pas été correctement autorisés au moyen de la signature d’un agent compétent du Ministère (SAP/SIGF : 15 %; SGRH PeopleSoft : 11 %; SMGC : 5 %; et SSOBL/SNGC/RC : 13 %). Dans certains cas, les formulaires ne comportaient pas une des deux signatures requises, tandis que dans un petit nombre d’autres formulaires, le coordonnateur de la sécurité de l’accès (CSA) et le gestionnaire étaient la même personne.

Pour ce qui est de la surveillance de l’activité des comptes utilisateurs, nous nous attendions à trouver des procédures de surveillance régulière de l’activité des comptes pour veiller à ce que le niveau d’accès demeure approprié aux besoins de l’utilisateur au fil du temps.

Nous avons constaté que des procédures concernant les comptes inactifs étaient en place pour le SAP/SIGF et le SGRH PeopleSoft. Toutefois, aucune procédure du genre n’était en place pour le SMGC, le SSOBL et le SNGC/RC. Pour ce dernier groupe de systèmes, l’UCA se fie aux CSA du Ministère pour demander à ce que les privilèges d’accès soient retirés aux personnes qui quittent l’organisation, ou révisés lorsqu’une personne occupe un nouveau poste qui ne nécessite pas le même niveau d’accès. En l’absence d’une politique concernant les comptes inactifs, nous avons constaté que personne n’avait accédé à 11 % des comptes du SSOBL (utilisateurs du SSOBL à CIC et dans d’autres ministères), 18 % des comptes du SMGC, 7 % des comptes du SNGC et 8 % des comptes de laRC depuis le 1^er janvier 2010.

En outre, nous avons constaté que des comptes qui semblaient appartenir à des employés qui ont quitté le Ministère en 2010–2011 et qui n’étaient pas revenus en août 2011 restaient actifs dans nombre des systèmes examinés. Cela comprend 5 % des comptes du SSOBL à CIC, 3,5 % des comptes du SMGC au Canada et un petit nombre de comptes du CIPC, du SNGC, de laRC et du SAP/SIGF.

Recommandation 5

La DGSGI, en collaboration avec les Finances et les RH s’il y a lieu, devrait s’assurer qu’un formulaire de demande d’accès aux systèmes dûment autorisé soit conservé pour l’ensemble des utilisateurs des systèmes.

Réponse de la direction

La DGSGI, en collaboration avec les Finances et les RH s’il y a lieu, s’assurera que les formulaires de demande soient conservés pour l’ensemble des utilisateurs des systèmes afin de gérer de manière efficace l’accès autorisé aux systèmes. L’échéance est fixée au quatrième trimestre de 2012–2013.

Recommandation 6

La DGSGI, en collaboration avec les Finances et les RH s’il y a lieu, devrait veiller à ce que des procédures soient en place pour assurer la surveillance régulière des comptes utilisateurs inactifs et s’assurer que les privilèges d’accès continuent de correspondre aux besoins des utilisateurs.

Réponse de la direction

La DGSGI, en collaboration avec les Finances et les RH s’il y a lieu, élaborera et étayera un processus visant à surveiller les comptes utilisateurs inactifs et à s’assurer que les privilèges d’accès continuent de correspondre aux besoins des utilisateurs. L’échéance est fixée au quatrième trimestre de 2012–2013.

3.2.1.3 Examen et détection

Nous nous attendions à ce que des processus soient en place pour permettre la surveillance, l’examen et la détection de l’accès non autorisé. Nous nous attendions à ce qu’un processus soit en place pour surveiller les tentatives d’accès non autorisé, l’activité inhabituelle et l’accès à des transactions de nature délicate, au moyen de l’examen des journaux de sécurité ou de rapports produits par les systèmes concernant les tentatives d’accès par les utilisateurs.

CIC n’a pas la responsabilité de surveiller l’accès au CIPC. Par conséquent, nous n’en avons pas examiné le processus de surveillance de l’accès non autorisé.

Pour tous les autres systèmes, nous avons constaté qu’aucun processus n’était en place pour assurer la surveillance de l’accès sur une base régulière. Aucun journal de sécurité ou rapport sur l’accès non autorisé n’est produit ou examiné de façon régulière. Dans le cas du SAP/SIGF, un examen hebdomadaire des comptes bloqués est effectué afin de déterminer si le blocage est dû à trois tentatives d’ouverture de session ratées ou à une inactivité de la part de l’utilisateur.

Comme nous venons de le mentionner, nous avons trouvé des cas de comptes inactifs, des comptes appartenant à d’anciens employés, des comptes génériques et des comptes en double. De plus, les CSA disposaient de peu de directives pour déterminer le niveau d’accès des personnes qui ont besoin de savoir ou qui ont droit à un accès minimal. L’information était ainsi limitée pour faciliter la surveillance et contrôler l’accès.

Recommandation 7

La DGSGI, en collaboration avec les Finances et les RH s’il y a lieu, devrait mettre en œuvre des procédures officielles pour assurer l’examen de l’accès non autorisé à l’ensemble des systèmes de TI.

Réponse de la direction

La DGSGI utilise actuellement le Plan de gestion des incidents du SCT pour examiner l’accès non autorisé à tous les systèmes de TI et en rendre compte. La DGSGI documentera cette procédure pour circulation interne. L’échéance est fixée au quatrième trimestre de 2012–2013.

3.3.2 Personnes

Nous nous attendions à ce que CIC fournisse à ses employés et gestionnaires la formation, les outils, les ressources et l’information nécessaires pour les aider à s’acquitter de leurs responsabilités en matière de contrôle de l’accès aux systèmes.

Dans le cadre de la présente vérification, l’UCA de la Direction des services de technologie de l’information à la DGSGI gère l’accès aux anciens systèmes (SSOBL, SNGC,RC et CIPC), ainsi qu’au SMGC. Les CSA sont des représentants de chaque bureau ou direction générale et ont la responsabilité de coordonner l’accès aux systèmes entre la direction générale et l’UCA.

Nous avons constaté qu’il existe des lignes directrices concernant les rôles des CSA et l’UCA, et que l’UCA possède des procédures normales d’exploitation étayées. Toutefois, aucune directive n’est offerte aux CSA concernant le droit d’accès minimal et l’accès réservé aux personnes qui ont besoin de savoir.

Dans le cas du SAP/SIGF et du SGRH PeopleSoft, les super utilisateurs ont droit à une formation sur place. Dans les bureaux régionaux, les super utilisateurs peuvent débloquer les comptes des utilisateurs et changer les mots de passe. Par contre, ils ne reçoivent aucune formation officielle.

Recommandation 8

La DGSGI devrait fournir des lignes directrices aux CSA pour leur permettre d’exercer leurs rôles dans la gestion de l’accès aux systèmes, en particulier pour ce qui est d’assigner le niveau d’accès qui correspond aux besoins précis de l’utilisateur selon son poste et ses responsabilités.

Réponse de la direction

La DGSGI mettra à jour les directives actuelles détaillées et les transmettra aux CSA. Elle dispose d’une boîte de courriel réservée aux questions. L’échéance est fixée au deuxième trimestre de 2012–2013.

Annexe A : Critères de vérification détaillés

Annexe B : Plan d’action de la direction

Annexe C : Calendrier de la vérification