Sélection de la langue

Government of Canada / Gouvernement du Canada

Avis aux lectrices et aux lecteurs

Cette publication ne répond pas actuellement aux normes Web du gouvernement du Canada. Les informations restent valables.

Annexe 1 - Activités de gestion des risques liés à la sécurité des TI (ITSG-33)

De : Centre canadien pour la cybersécurité

 

Format de rechange : Annexe 1 - Activités de gestion des risques liés à la sécurité des TI (ITSG-33) (PDF, 1.72 Mo)

Une méthode axée sur le cycle de vie - Activités de gestion des risques liés à la sécurité des TI

Novembre 2012

 

Table des matières

Liste des figures

Liste des tableaux

Liste des abréviations et sigles

AI
Assurance de l’information
ASM
Agent de sécurité du ministère
CEI
Commission électrotechnique internationale
CID
Confidentialité, Intégrité, Disponibilité
CONOPS
Concept des opérations
CGR
Cadre de gestion des risques
CSTC
Centre de la sécurité des télécommunications Canada
CSTI
Coordonnateurs de la sécurité des technologies de l’information
DDPI
Direction du dirigeant principal de l’information
DGI
Directive sur la gestion de l'identité
DGSM
Directive sur la gestion de la sécurité ministérielle
DPI
Dirigeant principal de l’information
DPT
Dirigeant principal de la technologie
EM
Évaluation des menaces
EMR
Évaluation des menaces et des risques
ENS
Entente sur les niveaux de service
GC
Gouvernement du Canada
GSTI
Gestion de la sécurité des technologies de l’information
ISO
Organisation internationale de normalisation
ITSG
Conseils en matière de sécurité des technologies de l’information
MRSG
Modèle de référence stratégique du gouvernement du Canada
PASSI
Processus d’application de la sécurité dans les systèmes d’information
PCA
Planification de la continuité des activités
PDARR
Prévention, Détection, Analyse, Réponse, Récupération
PE
Protocole d’entente
PFTO
Programme de facilitation de la transformation opérationnelle
PSG
Politique sur la sécurité du gouvernement
PSM
Plan de sécurité ministérielle
SCT
Secrétariat du Conseil du Trésor du Canada
SPC
Services partagés Canada
STI
Sécurité des technologies de l’information
TI
Technologie de l’information
TPSGC
Travaux publics et Services gouvernementaux Canada

Avant-propos

L’Annexe 1 (Activités de gestion des risques liés à la sécurité des TI) de La gestion des risques liés à la sécurité des TI : Une méthode axée sur le cycle de vie (ITSG-33) est un document non classifié publié avec l’autorisation du chef du Centre de la sécurité des télécommunications Canada (CSTC).

Les propositions de modification devraient être envoyées au représentant des Services à la clientèle de la Sécurité des TI du CSTC par l’intermédiaire des responsables de la sécurité des TI du ministère.

Les demandes de copies supplémentaires ou de modification de la distribution devraient être soumises au représentant des Services à la clientèle de la Sécurité des TI du CSTC.

Pour de plus amples renseignements, prière de communiquer avec les Services à la clientèle de la Sécurité des TI du CSTC, par courriel à l’adresse itsclientservices@cse-cst.gc.ca, ou par téléphone au 613-991-7654.

Date d’entrée en vigueur

Cette publication entre en vigueur le 1er novembre 2012.

Chef adjointe, Sécurité des TI,

Signé initialement par

Toni Moffa

Résumé

La présente annexe fait partie d’une suite de directives sur la gestion des risques liés à la sécurité des technologies de l’information (TI) que le Centre de la sécurité des télécommunications Canada (CSTC) publie dans le numéro 33 de la série Conseils en matière de sécurité des technologies de l’information (guide ITSG-33) pour aider les ministères et organismes du gouvernement du Canada (GC) à mettre en œuvre, exploiter et maintenir des systèmes d’information fiables.

Les lignes directrices du guide ITSG-33 décrivent un processus de gestion des risques liés à la sécurité des TI qui inclut les activités menées à deux niveaux distincts : niveau du ministère et niveau du système d’information.

L’annexe propose aux ministères et organismes des lignes directrices relatives aux activités de gestion des risques liés à la sécurité des TI qui doivent être menées par une fonction de sécurité des TI dans le cadre d’un programme de sécurité ministérielle. Ces activités visent quatre objectifs :

  • Identifier et comprendre les besoins en matière de sécurité des TI des programmes et services ministériels et définir les contrôles de sécurité qui répondent à ces besoins;
  • Déployer les contrôles de sécurité qui répondent aux besoins de sécurité des TI et aux exigences des instruments de politique du Secrétariat du Conseil du Trésor (SCT) en matière de gestion des risques liés à la sécurité des TI;
  • Surveiller et évaluer en permanence le rendement des contrôles de sécurité ministériels dans le but de détecter les incidents liés à la sécurité et d’identifier les vulnérabilités et les lacunes en temps opportun;
  • Mettre à jour les contrôles de sécurité existants à partir des résultats des activités de surveillance et d’évaluation continues afin d’être en mesure d’intervenir dans les cas d’incidents, de corriger les vulnérabilités et d’améliorer en permanence la posture de sécurité des systèmes d’information ministériels.

Le respect des lignes directrices énoncées dans le guide ITSG-33 procure plusieurs avantages aux ministères, notamment la capacité de se conformer à la stratégie et aux objectifs de la gestion globale des risques établis par le SCT, de traiter de manière efficace les principaux aspects de la sécurité des TI et de gérer de manière uniforme et rentable les risques liés à la sécurité des TI.

1 Introduction

1.1 Contexte

Tel qu’énoncé dans la Norme opérationnelle de sécurité : Gestion de la sécurité des technologies de l’information (GSTI) [Référence 1], le Secrétariat du Conseil du Trésor du Canada (SCT) assigne aux coordonnateurs de la sécurité des technologies de l’information (CSTI) la responsabilité d’établir et de gérer une fonction de sécurité des TI dans le cadre d’un programme coordonné de sécurité ministérielle.

La GSTI attribue aux coordonnateurs de la sécurité des TI les responsabilités suivantes :

  • Collaborer étroitement avec les gestionnaires de la prestation de programmes et services pour s’assurer que leurs besoins en matière de sécurité des TI sont satisfaits;
  • Donner des conseils relativement aux contrôles et aux solutions de sécurité des TI;
  • Informer les gestionnaires de la prestation de programmes et services des incidences éventuelles des menaces existantes et nouvelles;
  • Informer les gestionnaires de la prestation de programmes et services du risque résiduel lié aux programmes et services ministériels du GC dont ils ont la charge.

Pour permettre l’atteinte de ces objectifs, le Centre de la sécurité des télécommunications Canada (CSTC) a publié dans le guide ITSG-33 (Conseils en matière de sécurité des technologies de l’information) des lignes directrices qui décrivent un processus de gestion des risques liés à la sécurité des TI.

1.2 But et champ d’application

La présente annexe propose aux ministères des lignes directrices relatives aux activités de gestion des risques liés à la sécurité des TI qui doivent être menées par une fonction de sécurité des TI dans le cadre d’un programme de sécurité ministérielle. L’Annexe 2 du guide [Référence 2] inclut des lignes directrices sur les activités qui doivent être menées par les équipes de projet TI et les groupes responsables des opérations de TI.

Ces lignes directrices s’appliquent aux ministères assujettis à la Politique sur la sécurité du gouvernement (PSG) [Référence 3] qui recourent à des systèmes d’information pour soutenir leurs activités opérationnelles (de non essentielles à essentielles) dans des environnements non classifiés, protégés et classifiés.

Le respect des lignes directrices procure plusieurs avantages aux ministères, notamment la capacité de se conformer à la stratégie et aux objectifs de la gestion globale des risques établis par le SCT, de traiter de manière efficace les principaux aspects de la sécurité des TI et de gérer de manière uniforme et rentable les risques liés à la sécurité des TI.

1.3 Auditoire cible

La présente annexe concerne les agents de sécurité des ministères (ASM), les coordonnateurs de la sécurité des TI et les praticiens de la sécurité chargés de soutenir les activités de gestion des risques liés à la sécurité des TI.

1.4 Définitions et terminologie

Pour connaître les définitions des principaux termes utilisés dans le présent document, consultez l’Annexe 5 du guide ITSG-33 [Référence 4].

Pour simplifier la discussion, les principaux termes, sauf indication contraire, sont définis comme suit :

  • « ministères » désigne les ministères, organismes et autres organisations du GC assujettis à la PSG [Référence 3];
  • « évaluation des menaces » désigne l’évaluation des menaces liées à la sécurité des TI;
  • « contrôle de sécurité » désigne les contrôles définis à l’Annexe 3 du guide ITSG-33 (Catalogue des contrôles de sécurité) [Référence 5];
  • « profil de contrôle de la sécurité de domaine » désigne le profil de contrôle de la sécurité des domaines opérationnels.

1.5 Conformité aux lois du GC et aux instruments de politique du SCT

Les lignes directrices du présent guide incluent des consignes qui aident les ministères à satisfaire aux principales exigences des instruments de politique du SCT en matière de sécurité des TI et de gestion des risques liés à la sécurité des TI. Elles aident également les praticiens de la sécurité à protéger les systèmes d’information en conformité avec les lois applicables du GC et les politiques, les directives et les normes connexes du SCT.

1.6 Structure de la publication

La présente annexe fait partie d’une suite de documents sur la gestion des risques liés à la sécurité des TI au sein du GC. Les autres documents sont les suivants :

  • ITSG-33, Aperçu – La gestion des risques liés à la sécurité des TI : Une méthode axée sur le cycle de vie;
  • ITSG-33, Annexe 2 – Activités de gestion des risques liés à la sécurité des systèmes d’information;
  • ITSG-33, Annexe 3 – Catalogue des contrôles de sécurité;
  • ITSG-33, Annexe 4 – Profils de contrôle de sécurité;
  • ITSG-33, Annexe 5 – Glossaire.

2 Processus de gestion des risques liés à la sécurité des TI

Pour assurer une gestion efficace et rentable des risques liés à la sécurité des TI, les présentes lignes directrices décrivent une approche que les ministères peuvent adapter à leur culture, leur mission et leurs objectifs opérationnels ainsi qu’à leurs besoins opérationnels en matière de sécurité et aux menaces qui pèsent sur leurs activités opérationnelles.

La Figure 1 décrit le processus de gestion des risques liés à la sécurité des TI proposé dans le présent guide. Elle montre que les activités de gestion des risques liés à la sécurité des TI s’appliquent à deux niveaux distincts de l’organisation : niveau du ministère et niveau du système d’information.

Figure 1 : Processus de gestion des risques liés à la sécurité des TI

Figure 1 : Processus de gestion des risques liés à la sécurité des TI

Au niveau du ministère, sur lequel porte essentiellement la présente annexe, les activités de gestion des risques sont menées par la fonction de sécurité des TI du ministère (consulter la section 4). Les objectifs de ces activités sont les suivants :

  • Définir les besoins en matière de sécurité des TI et les contrôles de sécurité du ministère;
  • Déployer les contrôles de sécurité;
  • Surveiller et évaluer en permanence le rendement des contrôles de sécurité déployés;
  • Identifier les mises à jour qui doivent être appliquées aux contrôles de sécurité (à la suite de changements apportés à des contrôles existants ou à l’ajout de nouveaux contrôles) à partir des résultats de la surveillance et de l’évaluation continues et des activités de maintien de l’autorisation, et en surveiller la mise en œuvre.

Au niveau du système d’information, les activités de gestion des risques sont menées équipes de projet TI et les groupes responsables des opérations de TI. Elles suivent les phases de mise en œuvre, d’exploitation et d’élimination des systèmes d’information (voir l’Annexe 2 du guide ITSG-33 [Référence 2]). Les objectifs de ces activités sont les suivants :

  • Définir les besoins en matière de sécurité des TI et les contrôles de sécurité des systèmes d’information dans le cadre des activités de la fonction de sécurité des TI;
  • Concevoir et développer des systèmes d’information qui répondent à des contrôles de sécurité précis;
  • Intégrer, tester et installer les systèmes d’information, incluant la sécurité;
  • Exploiter, surveiller et maintenir la sécurité des systèmes d’information durant la phase d’exploitation et de maintenance;
  • Éliminer de manière sécuritaire les biens de TI lorsque les systèmes d’information sont mis hors service.

3 Relations avec les processus externes

Pour être en mesure de tirer le maximum des avantages du processus de gestion des risques liés à la sécurité des TI, les ministères doivent connaître les relations importantes qui existent entre les activités de gestion des risques liés à la sécurité des TI et les autres processus clés de gestion des risques et des TI. Les relations sont les suivantes :

  • Gestion intégrée des risques – Les activités de gestion des risques liés à la sécurité des TI peuvent soutenir la gestion intégrée des risques du ministère, tel qu’indiqué dans le Cadre de gestion des risques (CGR) [Référence 6] du SCT; elles constituent un processus continu, proactif et systématique qui permet de comprendre, de gérer et de communiquer les risques à l’échelle de l’organisation.
  • Analyses des répercussions sur les opérations – Les résultats des analyses des répercussions sur les opérations que les gestionnaires de la prestation de programmes et services peuvent effectuer dans le cadre de leurs activités opérationnelles peuvent être utiles afin de déterminer les besoins opérationnels en matière de sécurité et la sensibilité et la criticité des activités opérationnelles. Les besoins opérationnels (incluant les exigences en matière de protection de la vie privée) et la sensibilité et la criticité permettent d’établir la catégorie de sécurité des activités opérationnelles.
  • Architecture d’entreprise – La fonction d’architecture d’entreprise, dans les ministères qui en sont dotés, contribue à faire en sorte que les exigences de l’organisation en matière de sécurité des TI soient prises en compte au moment de la définition, du déploiement et de la mise à jour des contrôles de sécurité.

4 Activités de gestion des risques liés à la sécurité des TI

Cette section décrit les activités de gestion des risques liés à la sécurité des TI que l’on recommande d’intégrer à un programme de sécurité ministérielle, et inclut des lignes directrices sur la façon de les mener efficacement à terme.

Nota : Le guide ITSG-33 ne prévoit aucune ligne directrice relativement à l’établissement d’une fonction de sécurité des TI dans le cadre d’un programme de sécurité ministérielle, ni aucune directive sur la façon d’intégrer les activités proposées ici dans une telle fonction. Les ministères qui désirent mettre en place cette fonction peuvent s’en remettre aux directives habituelles de leur ministère ou du SCT concernant les programmes du GC. Avant d’intégrer les activités du guide ITSG-33 à leur programme de sécurité ministérielle, les ministères doivent s’assurer d’harmoniser leur structure de gouvernance (rôles, responsabilités et pouvoirs décisionnels) à celle définie dans les plus récents instruments de politique du SCT. Les lignes directrices du présent guide s’harmonisent avec la plus récente structure de gouvernance, comme il est indiqué à la section 5.

4.1 Aperçu

La Figure 2 décrit les activités du processus de gestion des risques liés à la sécurité des TI menées au niveau du ministère. Le but principal de ces activités est de déployer et tenir à jour un ensemble de contrôles de sécurité adaptés aux besoins et aux objectifs spécifiques de chaque ministère en matière de sécurité.

Les principaux résultats des activités de gestion des risques liés à la sécurité des TI sont les profils de contrôle de sécurité ministériels et les rapports sur l’évaluation des menaces liées à la sécurité des TI du ministère, lesquels servent de fondement principal au processus de gestion des risques liés à la sécurité des TI pour le déploiement des contrôles de sécurité dans les systèmes d’information.

Figure 2 : Activités de gestion des risques liés à la sécurité des TI

Figure 2 : Activités de gestion des risques liés à la sécurité des TI

Les activités de gestion des risques liés à la sécurité des TI visent l’atteinte des objectifs suivants :

  • Déterminer et documenter les besoins opérationnels en matière de sécurité des activités opérationnelles;
  • Définir et déployer les contrôles de sécurité ministériels communs qui assurent le soutien de la fonction de sécurité des TI (p. ex., évaluation des risques, gestion des incidents, surveillance du rendement) et les contrôles qui serviront aux systèmes d’information (p. ex., l’authentification centrale);
  • Effectuer des évaluations continues des menaces dont les responsables et les praticiens de la sécurité peuvent se servir pour mettre en œuvre des systèmes d’information fiables et aptes à traiter les risques liés à la sécurité des TI de manière plus substantielle et uniforme;
  • Développer des profils de contrôle de sécurité ministériels adaptés aux besoins opérationnels en matière de sécurité dont les équipes de projet TI peuvent se servir pour la mise en œuvre et la mise à jour des systèmes d’information ministériels;
  • Coordonner les autres fonctions de sécurité ministérielle (p. ex., sécurité matérielle, sécurité du personnel) afin de s’assurer d’une approche uniforme pour la création et l’exploitation de systèmes d’information fiables;
  • Surveiller et évaluer, à l’échelle du ministère, le rendement des contrôles existants relativement à la protection des activités opérationnelles;
  • Identifier les vulnérabilités, les faiblesses et les inefficacités;
  • Concevoir et mettre en œuvre des mesures correctives pour améliorer le rendement et la posture de sécurité globale du ministère.

4.2 Besoins du ministère en matière de sécurité des TI et de contrôles de sécurité

Cette section décrit le processus qui permet de définir les besoins du ministère en matière de sécurité des TI et de contrôles de sécurité. Le processus inclut les sous-activités suivantes :

  • Définir la portée des activités de gestion des risques liés à la sécurité des TI (section 4.2.1);
  • Déterminer les besoins opérationnels en matière de sécurité des activités opérationnelles (section 4.2.2);
  • Catégoriser la sécurité des activités opérationnelles du ministère (section 4.2.3);
  • Définir la méthodologie d’EMR du ministère relativement à la sécurité des TI (section 4.2.4);
  • Effectuer une évaluation ministérielle des menaces relativement à la sécurité des TI (section 4.2.5);
  • Préciser les objectifs en matière de contrôles de sécurité (section 4.2.6);
  • Développer des profils de contrôle de sécurité ministériels (section 4.2.7).

Chacune de ces activités est décrite dans les sections suivantes. Dans un premier temps, les activités sont menées au moment de l’application initiale des lignes directrices énoncées dans le présent document, puis, au besoin, selon l’évaluation de la posture de sécurité des systèmes d’information du ministère (voir la section 4.6).

4.2.1 Définir la portée des activités de gestion des risques liés à la sécurité des TI

L’objectif de cette activité est de définir la portée des activités de gestion des risques liés à la sécurité des TI. La portée peut être caractérisée en tenant compte des éléments suivants :

  • Programmes, services et activités opérationnelles qui doivent être protégés;
  • Biens de TI importants (p. ex., applications administratives, systèmes d’information, centres de données, réseaux locaux, données traitées et stockées) et leurs emplacements géographiques;
  • Technologies de base utilisées dans les systèmes d’information

La portée doit clairement définir les activités opérationnelles et les biens de TI couverts et les éléments exclus, incluant une justification de l’exclusion. Elle doit également indiquer les dépendances externes tels les services de TI assurés par des fournisseurs de services de l’extérieur.

Le produit de cette activité est une définition de la portée des activités de gestion des risques liés à la sécurité des TI.

4.2.2 Déterminer les besoins opérationnels en matière de sécurité

L’objectif de cette activité est de déterminer les besoins opérationnels en matière de sécurité des activités opérationnelles. Dans le contexte de la gestion des risques liés à la sécurité des TI, ces besoins sont liés à la nécessité de protéger les activités opérationnelles contre le risque que représente l’utilisation de systèmes d’information. Les besoins peuvent découler des éléments suivants :

  • Exigences stipulées dans les règlements, les politiques, les directives, les normes et les objectifs qui sous-tendent les activités opérationnelles et la gestion de l’information (p. ex., l’architecture d’activités de programmes d’une organisation);
  • Expositions aux menaces généralement reconnues des systèmes d’information;
  • Obligations contractuelles (p. ex., les protocoles d’entente [PE] et les ententes sur les niveaux de services [ENS]).

Les besoins opérationnels incluent les exigences liées au respect de la vie privée qui doivent être prises en compte par les contrôles de sécurité aux fins de gestion des risques liés à la protection des renseignements personnels.

Les besoins opérationnels en matière de sécurité expriment, en termes opérationnels, la nécessité de protéger les activités opérationnelles contre tout événement hostile lié aux systèmes d’information susceptible d’influer sur la capacité des ministères à remplir leur mission, leurs objectifs et leurs obligations. Lorsqu’un règlement énonce une exigence relative à la protection des systèmes d’information, un besoin opérationnel correspondant doit répondre à cette exigence. Les besoins opérationnels sont à l’origine du développement d’objectifs de sécurité plus formels qui peuvent nécessiter une terminologie plus technique.

Les exemples de besoins opérationnels en matière de sécurité incluent les suivants :

  • Limiter l’accès des renseignements sensibles aux employés responsables d’exécuter les actions autorisées;
  • Vérifier l’identité des citoyens avant de divulguer des renseignements qui les concernent;
  • S’assurer que seuls les employés autorisés peuvent approuver le versement de prestations aux bénéficiaires d’un programme.

Les ministères doivent déterminer les besoins opérationnels en matière de sécurité avec l’aide des analystes des opérations et un architecte de système ou un architecte de la sécurité ministérielle (personne ou groupe, si ce poste existe). Les éléments utiles pour cette activité incluent la documentation des processus opérationnels (p. ex., descriptions, scénarios d’utilisation, concept d’opérations) et les évaluations de répercussions (p. ex., évaluation de l’incidence sur l’organisation ou sur la vie privée).

Le produit de cette activité est un ensemble d’énoncés de besoins opérationnels en matière de sécurité concernant les activités opérationnelles du ministère.

4.2.3 Catégoriser la sécurité des activités opérationnelles

L’objectif de cette activité est de déterminer les catégories de sécurité des activités opérationnelles. Une catégorie de sécurité exprime les niveaux les plus élevés de préjudices prévus causés par des menaces de compromission relativement aux objectifs de sécurité liés à la confidentialité, l’intégrité et la disponibilité. Les activités opérationnelles sont catégorisées d’abord d’après la détermination des préjudices prévus causés par des menaces de compromission des TI aux intérêts nationaux et non nationaux qu’elles servent, puis d’après la détermination du niveau de ces préjudices.

Les ministères peuvent catégoriser leurs activités opérationnelles selon le processus indiqué à la section 6.

Le produit de cette activité est un rapport sur la catégorisation de la sécurité des activités opérationnelles.

4.2.4 Définir la méthodologie d’EMR liée à la sécurité des TI

L’objectif de cette activité est de définir la méthodologie d’évaluation des menaces et des risques de la sécurité des TI à l’échelle du ministère. Cette méthodologie doit être définie à ce stade-ci puisque le ministère utilisera la composante d’évaluation pour mesurer les menaces auxquelles sont exposées les activités opérationnelles. De plus, les équipes de projet TI utiliseront la méthodologie pour mener les activités d’EMR.

Le produit de cette activité est une définition de la méthodologie d’EMR liée à la sécurité des TI utilisée par le ministère.

4.2.5 Effectuer une évaluation des menaces liées à la sécurité des TI

L’objectif de cette activité est d’effectuer une évaluation initiale, à l’échelle de l’organisation, des menaces liées à la sécurité des TI qui permettra de sélectionner les contrôles de sécurité et dont les équipes de projet TI pourront se servir pour mettre en œuvre des systèmes d’informationNote de bas de page 1. Cette activité permet de cerner et de qualifier les menaces posées aux activités opérationnelles visées dans la portée.

Les ministères peuvent, à partir de l’ensemble des menaces potentielles, préciser un sous-ensemble de menaces contre lesquelles ils souhaitent protéger leurs activités opérationnelles. Cette sélection signifie que certaines menaces ont été identifiées et envisagées, mais ont été jugées hors de la portée définie pour différentes raisons. Par exemple, un ministère peut juger trop onéreuse ou complexe la protection contre une menace particulière, ou que la protection pourrait limiter dans une trop large mesure les fonctions de soutien d’une activité opérationnelle. L’information sur les menaces, incluant les décisions et les justifications menant à l’exclusion de menaces particulières, est documentée dans un rapport ministériel d’évaluation des menaces.

Une évaluation des menaces à l’échelle de l’organisation est un outil utile que les ministères peuvent utiliser pour définir, déployer, mettre à jour ou améliorer les contrôles de sécurité existants. Les résultats de cette évaluation, combinés aux besoins opérationnels en matière de sécurité, constituent une base solide pour l’établissement des objectifs en matière de contrôles de sécurité et le développement de profils de contrôle de sécurité ministériels.

Il est possible de produire des rapports d’évaluation des menaces par secteur d’activités durant le développement des profils de contrôle de sécurité ministériels pour documenter plus en détail les menaces qui concernent ces secteurs.

Les équipes multidisciplinaires, en collaboration avec l’ASM et les organismes responsables de la sécurité du GC, sont les mieux en mesure d’effectuer les évaluations ministérielles des menaces.

Une évaluation ministérielle doit évaluer et documenter :

  • les activités opérationnelles clés;
  • les catégories de sécurité des activités opérationnelles;
  • les menaces liées aux TI qui concernent les activités opérationnelles;
  • toute exposition aux menaces de nature générale susceptible d’influer sur les activités opérationnelles (p. ex., un emplacement exposé aux tremblements de terre) et les options stratégiques pour y remédier.

Le principal produit de cette activité est un rapport ministériel d’évaluation des menaces qui documente les menaces liées aux TI et les risques auxquels sont exposées les activités opérationnelles clés.

4.2.6 Préciser les objectifs en matière de contrôles de sécurité

Cette activité vise à préciser les objectifs du ministère en matière de contrôles de sécurité qui permettront de sélectionner les contrôles. Ces objectifs servent de base à la sélection et à l’adaptation des contrôles. Les contrôles doivent protéger adéquatement les systèmes d’information ministériels et gérer les risques liés à la sécurité des TI. Les besoins opérationnels en matière de sécurité sont habituellement rédigés en fonction des activités du ministère et peuvent utiliser une terminologie variée. Un ministère peut normaliser les objectifs et les associer aux différents besoins opérationnels en utilisant une terminologie normalisée commune.

Les exemples d’objectifs (associés aux exemples utilisés à la section 4.2.2) incluent les suivants :

  • Assurer la sécurité des services de TI accessibles en ligne et sécuriser leur utilisation;
  • Empêcher l’accès non autorisé aux services, aux données et aux ressources réseau de TI;
  • Empêcher la création et la modification non autorisées ou la mauvaise utilisation de l’information traitée par les applications, et détecter les activités non autorisées de traitement des données.

Vous trouverez la définition d’un ensemble d’objectifs à l’Appendice C de la DGSM [Référence 7]. Les praticiens de la sécurité, avec l’aide des groupes opérationnels de leur ministère, peuvent définir d’autres objectifs en matière de contrôles de sécurité. Ils peuvent également tirer avantage des objectifs provenant d’autres sources telle l’Annexe A de la publication ISO 27001 [Référence 8]. Des paramètres qui permettent de mesurer le rendement des contrôles sont définis dans la spécification des objectifs en matière de contrôle de sécurité. Les praticiens peuvent tirer avantage de paramètres de mesure des objectifs obtenus d’autres sources telle la publication ISO 27004 [Référence 9].

Cette activité doit notamment tenir compte de la définition de la portée, des besoins opérationnels et des résultats de l’évaluation ministérielle des menaces. Les ministères qui peuvent déjà compter sur une fonction d’architecture d’entreprise doivent également tenir compte de tout élément d’architecture de sécurité d’entreprise pertinent (p. ex., les exigences relatives à la sécurité d’entreprise).

Le produit de cette activité est la liste des objectifs ministériels en matière de contrôle de sécurité qui concernent les systèmes d’information qui appuient les activités opérationnelles.

4.2.7 Développer des profils de contrôle de sécurité ministériels

L’objectif de cette activité est de créer des profils de contrôle de sécurité ministériels adaptés aux besoins de chaque ministère en matière de sécurité. Selon leur mission (p. ex., prestation d’un seul programme plutôt que de programmes multiples) et la complexité de leurs activités opérationnelles, les ministères peuvent utiliser un seul profil, au niveau ministériel, ou plusieurs profils de domaine appelés « profils ministériels de contrôle de sécurité de domaine » ou simplement « profils de contrôle de sécurité de domaine ».

L’utilisation de plusieurs processus ministériels clés de gestion de l’information et des TI est le meilleur moyen de développer les profils de contrôle. Bien qu’ils soient hors de la portée du processus de gestion des risques liés à la sécurité des TI, ces processus organisationnels peuvent aider à bien sélectionner et adapter les contrôles de sécurité. Ces processus de soutien sont les suivants :

  • Définition des activités opérationnelles essentielles au soutien des missions des ministères;
  • Priorisation des activités opérationnelles en fonction des buts et des objectifs stratégiques;
  • Définition des types de biens d’information essentiels à la réussite des activités opérationnelles, de leur criticité et de leur sensibilité, et de leurs déroulements internes et externes;
  • Intégration des exigences en matière de sécurité de l’information aux processus de mission et aux processus opérationnels;
  • Définition d’une architecture d’entreprise qui inclut les exigences en matière de sécurité des TI.

Quatre étapes permettent de développer les profils de contrôle de sécurité ministériels :

  • Définir les domaines d’activités;
  • Définir les approches en matière de sécurité des TI;
  • Développer des profils de contrôle de sécurité ministériels;
  • Approuver les profils de contrôle de sécurité ministériels.

Ces étapes sont décrites aux sections suivantes.

4.2.7.1 Définir les domaines d’activités

L’objectif de cette activité est de définir les domaines d’activités d’un ministère pour appuyer les activités de développement des profils de contrôle de sécurité ministériels requis. Un domaine d’activités est caractérisé par les catégories de sécurité de ses activités opérationnelles et les menaces liées à la sécurité des TI qui leur sont associées. Les domaines d’activités ont donc des besoins de protection différents et, par conséquent, des profils de contrôle de sécurité différents.

À titre d’exemple, considérons un premier ensemble d’activités opérationnelles axé sur la distribution de publications non sensibles du GC et un deuxième qui concerne des transactions financières critiques à valeur élevée. Dans le deuxième cas, les activités financières sont confrontées à des menaces plus graves et se verront donc attribuer une catégorie de sécurité supérieure. Cette analyse permet de définir deux domaines qui exigent deux profils de contrôle différents.

Les ministères disposent d’une certaine souplesse dans la façon de définir leurs domaines d’activités. Peu importe la manière dont les domaines sont définis, les catégories de sécurité des activités opérationnelles et l’importance de l’environnement de menace doivent être bien documentées. Il importe de noter que les activités doivent avoir été définies antérieurement (en tout ou en partie) durant l’activité de catégorisation de la sécurité (voir la section 4.2.3).

Les produits de cette activité sont les définitions des domaines d’activités. La définition de chaque domaine doit inclure l’information suivante :

  • Description des objectifs opérationnels, des processus et des biens d’information du domaine;
  • Catégorie de sécurité du domaine;
  • Caractérisation de l’environnement de menace propre au domaine;
  • Énoncé du niveau de risque que les utilisateurs jugent acceptable lorsqu’ils acceptent que les systèmes d’information assurent le soutien des activités opérationnelles du domaine.
4.2.7.2 Définir les approches en matière de sécurité des TI

L’objectif de cette activité est de définir un ensemble d’approches pour sélectionner des contrôles de sécurité qui respectent la philosophie, la culture, les objectifs et les priorités du ministère en matière de sécurité.

Au niveau du ministère, les approches servent de guide de sélection des contrôles pour les profils de contrôle de sécurité ministériels. Au niveau du système d’information, les approches jouent un rôle tout aussi important et servent de guide pour adapter les contrôles de sécurité des profils aux besoins spécifiques des systèmes d’information et pour déterminer les conceptions de sécurité appropriées.

Lorsqu’ils définissent les approches en matière de sécurité des TI, les ministères doivent tenir compte des éléments suivants :

  • Besoins opérationnels en matière de sécurité (section 4.2.2);
  • Catégories de sécurité des activités opérationnelles (section 4.2.3);
  • Menaces documentées dans l’évaluation ministérielle des menaces (section 4.2.5);
  • Objectifs en matière de contrôles de sécurité documentés (section 4.2.6); and
  • Principes et meilleures pratiques généralement acceptés en matière de sécurité des TI (p. ex., les guides ITSG-38 [Référence 10] et ITSG-22 [Référence 11], le document Enterprise Security Architecture: A Business-Driven Approach [Référence 12], les documents NIST SP800-27 Engineering Principles for Information Technology Security: A Baseline for Achieving Security [Référence 13] et NIST SP800-14 Generally Accepted Principles and Practices for Securing Information Technology Systems [Référence 14]).

Voici quelques exemples d’approches qui influent sur la sélection des contrôles et la spécification des conceptions de sécurité que les ministères peuvent utiliser pour développer leurs profils de contrôle :

  • Approche globale ou approche détaillée de la conception de la sécurité. Une approche globale tient compte de la sécurité des différentes couches d’un système d’information (p. ex., application, gestion des données, intergiciel, plate-forme et communication);
  • Défense en profondeur multicouche ou protection ciblée monocouche;
  • Approches de conception de types coquille d’œuf (périmètre rigide et centre mou), nid d'abeilles ou protection de point terminal;
  • Modes appropriés de fonctionnement de la sécurité (spécialisé, système, compartimenté, multiniveau);
  • Traitement multiniveau des incidents pour permettre la prévention, la détection, l’analyse, l’intervention et la reprise en cas d’attaques, ou approche avant tout préventive;
  • Architecture d’application à plusieurs paliers (présentation, logique opérationnelle, dépôts de données) faisant appel aux zones de sécurité, ou architecture système monolithique;
  • Utilisation de services de sécurité communs avec une interface de programmation d’application standard (p. ex., un système d’authentification ministériel), ou mise en œuvre de services de sécurité personnalisés;
  • Sécuriser l’infrastructure ou sécuriser les ressources de données (p. ex., gestion des droits d’auteur numériques);
  • Tenir compte des facteurs sociétaux (p. ex., surveillance par rapport au respect de la vie privée de l’employé), ou imposer des contrôles de sécurité difficiles à utiliser, mais plus sécuritaires;
  • Échec sans danger (échec-fermeture) ou fonctionnement en cas de défaillance (échec-ouverture).

Les profils de contrôle documentés à l’Annexe 4 du guide ITSG-33 [Référence 15] contiennent des exemples de définitions d’approche de sécurité des TI.

4.2.7.3 Développer des profils de contrôle de sécurité ministériels

L’objectif de cette activité est de développer des profils de contrôle de sécurité ministériels. Les ministères développent un profil de contrôle pour chacun de leurs domaines d’activités définis. Si un ministère définit plusieurs domaines d’activités, il peut développer les profils graduellement, en commençant par le plus urgent, puis en développant les autres au fil du temps.

Les profils documentent les contrôles de sécurité communs qui sont ou seront développés par la fonction de sécurité des TI du ministère et les contrôles obligatoires qui seront intégrés à chaque système d’information ministériel.

La fonction de sécurité des TI utilise les profils pour coordonner le déploiement des contrôles communs dans l’ensemble de l’organisation. Les profils servent également à informer les équipes de projet TI des contrôles qui sont ou seront intégrés automatiquement à leurs systèmes d’information, et des contrôles qu’elles devront mettre en œuvre dans le cadre de leurs projets pour protéger les systèmes d’information qu’elles développent ou mettent à jour.

Au moment du développement des profils de contrôle, les ministères sélectionnent les contrôles dans le catalogue à l’Annexe 3 du guide ITSG-33 [Référence 5] et les adaptent à leurs besoins en matière de sécurité (section 4.2.2) et à leurs objectifs en matière de contrôle (section 4.2.6). La sélection et l’adaptation des contrôles s’appuient sur les résultats des évaluations ministérielles des menaces (section 4.2.5) et les approches définies en matière de sécurité des TI (section 4.2.7.2). Dans le cas des ministères dotés d’une fonction d’architecture d’entreprise, les praticiens de la sécurité doivent également tenir compte des artefacts liés à la sécurité des TI lorsqu’ils sélectionnent et adaptent les contrôles propres à leurs systèmes d’information.

Les profils de contrôle de sécurité ministériels doivent également documenter le contexte opérationnel et les hypothèses de développement. À cette fin, ils doivent décrire :

  • les activités opérationnelles incluses dans la portée et les besoins opérationnels connexes;
  • les catégories de sécurité des activités opérationnelles incluses dans la portée;
  • le contexte de menace;
  • la définition des approches en matière de sécurité des TI;
  • toute autre contrainte technique ou hypothèse susceptible d’influer sur la sélection des contrôles de sécurité des systèmes d’information.

Un élément clé du processus de développement des profils est le rapport ministériel d’évaluation des menaces (voir la section 4.2.5). Pendant le développement des profils de contrôle de sécurité de domaine, les ministères peuvent préciser davantage les définitions de menace en tenant compte de renseignements supplémentaires propres aux activités opérationnelles de chaque domaine. Ainsi, ils peuvent documenter ces définitions plus précises dans les rapports d’évaluation des menaces axés sur les domaines.

Plusieurs des contrôles de sécurité inclus dans le catalogue peuvent être retenus et déployés comme contrôles de sécurité communs. Une liste de contrôles communs potentiels se trouve à la section 7. Ces contrôles sont également mis en évidence dans les profils mentionnés à l’Annexe 4 du guide ITSG-33 [Référence 15]. Certains peuvent être appliqués en utilisant des solutions techniques et exploités par les groupes responsables des opérations de TI. D’autres peuvent relever de la responsabilité opérationnelle de la fonction de sécurité des TI du ministère ou d’autres fonctions de soutien.

Voici quelques exemples de contrôles de sécurité communs :

  • Programme ministériel de vérification de la sécurité qui permet d’effectuer des enquêtes de sécurité sur le personnel des TI;
  • Programme de sécurité matérielle qui permet de protéger les installations de TI;
  • Gestion des incidents de sécurité intégrée à la fonction de sécurité des TI qui permet de dégager une vue d’ensemble des incidents liés à la sécurité du ministère;
  • Système d’information exploité par un groupe responsable des opérations de TI qui offre une solution commune d’authentification des utilisateurs;
  • Système ministériel de surveillance électronique des journaux, exploité par une équipe de la fonction de sécurité des TI, qui assure la séparation des tâches entre les opérations de TI et la fonction de sécurité des TI;
  • Programme de formation et de sensibilisation à la sécurité des TI, administré par le centre d’apprentissage du ministère.

Pour développer leurs profils de contrôle de sécurité ministériels, les ministères peuvent tirer avantage des profils indiqués à l’Annexe 4 du guide ITSG-33 [Référence 15] qui s’appliquent à leur situation. Ces profils sont tirés du Catalogue des contrôles de sécurité du guide ITSG-33 [Référence 5].

Le produit de cette activité est un profil de contrôle de sécurité ministériel ou un ensemble de profils de contrôle de sécurité de domaine.

4.2.7.4 Approuver les profils de contrôle de sécurité ministériels

Une fois que le ou les profils de contrôle de sécurité sont terminés, le coordonnateur de la sécurité des TI doit les examiner et les faire approuver par les autorités du ministère (p. ex., le gestionnaire de la prestation de programmes et services, l’ASM, l’administrateur général, selon le cas). Durant ce processus, le coordonnateur doit s’assurer que les contrôles précisés dans les profils répondent aux besoins de sécurité et aux objectifs de contrôle et qu’ils protègent adéquatement l’information contre les menaces. Il doit également s’assurer du juste équilibre entre la mise en œuvre des contrôles et les niveaux de risque résiduel que le ministère est prêt à accepter.

Conformément à la DGSM [Référence 7], les agents de sécurité du ministère (ASM) doivent inclure dans leur PSM, aux fins d’approbation par leur administrateur général, les besoins opérationnels de sécurité, les objectifs en matière de contrôle de sécurité et l’ensemble de contrôles requis pour atteindre ces objectifs.

Les produits de cette activité sont des profils de contrôle de sécurité ministériels approuvés.

4.3 Déployer les contrôles de sécurité

Après que l’administrateur général a approuvé les profils de contrôle de sécurité ministériels, les coordonnateurs de la sécurité des TI et leur personnel peuvent commencer à coordonner le déploiement des contrôles. Les activités de déploiement sont menées au moment de l’application initiale des lignes directrices énoncées dans ce document puis, au besoin, selon l’évaluation de la posture de sécurité des systèmes d’information du ministère (consulter les sections 4.4, 4.5 et 4.6).

4.3.1 Déployer et exploiter les contrôles de sécurité communs

Plusieurs options s’offrent aux ministères pour déployer les contrôles de sécurité communs :

  • Ils peuvent être déployés par la fonction de sécurité des TI et exploités par le personnel de la fonction;
  • Ils peuvent être déployés par le groupe responsable des opérations de TI d’un ministère;
  • Ils peuvent être déployés par d’autres groupes du ministère ou impartis à un autre ministère ou un fournisseur de services du secteur privé;
  • Ils peuvent être assurés par un service de TI commun ou partagé existant du GC.

Le Tableau 1 donne des exemples de la façon de déployer les contrôles de sécurité communs.

Tableau 1 : Exemples de déploiement de contrôles de sécurité communs

Contrôle de sécurité commun Option de déploiement sélectionnée par les responsables de la sécurité des TI Autorité opérationnelle
CA-7 Surveillance continue Mise en place d’une infrastructure automatisée de surveillance Responsables de la sécurité des TI (à titre de composant de la fonction de sécurité des TI)
SC-7 Protection des frontières Mise en place d’une infrastructure de protection des frontières Groupe responsable des opérations de TI – Exploitation des réseaux
CP-7 Site de traitement de secours Contrat de services Fournisseur de services du secteur privé
IA-2 Identification et authentification (utilisateurs organisationnels) Abonnement à un service partagé existant d’identification et d’authentification du GC Services partagés Canada (SPC)Note de bas de page 2

Le déploiement d’un contrôle de sécurité commun peut exiger la mise en œuvre d’un système d’information de soutien; les ministères doivent effectuer la mise en œuvre de ces systèmes dans le cadre de projets TI, en suivant le processus décrit à l’Annexe 2 du guide ITSG-33 [Référence 2].

4.3.2 Déployer les contrôles de sécurité dans les systèmes d’information

Pour déployer les contrôles obligatoires dans les systèmes d’information, le coordonnateur de la sécurité des TI exige des équipes de projet TI et des groupes responsables des opérations de TI qu’ils utilisent les profils de contrôle de sécurité ministériels. À cette fin, les coordonnateurs mettent en place un processus de diffusion des profils et des rapports ministériels d’évaluation des menaces aux groupes de leur organisation qui sont responsables de la mise en œuvre et de l’exploitation des systèmes d’information. Cette activité peut être communiquée par différents moyens (bulletins mensuels sur la sécurité des TI, comité directeur des TI ou de la sécurité des TI, ou comité d’examen).

De plus, les coordonnateurs informent les gestionnaires de la prestation de programmes et services et les évaluateurs de la sécurité de la disponibilité des profils de contrôle de sécurité ministériels. Les gestionnaires et les évaluateurs peuvent ensuite exiger des équipes de projet TI et des groupes responsables des opérations de TI qu’ils utilisent les profils de contrôle appropriés à leur secteur de responsabilité.

Les équipes de projet TI et les groupes responsables des opérations de TI mettent en œuvre et exploitent les contrôles de sécurité intégrés aux systèmes d’information en exécutant les activités de gestion des risques liés à la sécurité des TI décrites à l’Annexe 2 du guide ITSG-33 [Référence 2].

4.4 Surveiller et évaluer le rendement des contrôles de sécurité

Les ministères surveillent et évaluent le rendement des contrôles de sécurité communs existants et de ceux intégrés aux systèmes d’information, en collectant, regroupant et analysant en permanence les paramètres de rendement. Plusieurs des tâches de surveillance et d’évaluation sont exécutées par les groupes responsables des opérations de TI, et les rapports sommaires sont transmis à la fonction de sécurité des TI aux fins d’analyse à l’échelle du ministère. Certaines tâches de surveillance sensibles peuvent être effectuées par la fonction de sécurité des TI (si un profil de contrôle de sécurité l’exige) lorsqu’il doit y avoir séparation des tâches.

Les tâches d’évaluation continueNote de bas de page 3 vont au-delà du simple rendement des contrôles de sécurité et doivent inclure :

  • L’examen des changements apportés à la sécurité et des dossiers de gestion de problèmes;
  • L’examen des rapports d’incidents de sécurité;
  • L’exécution des tests de sécurité, qui peuvent inclure les tests fonctionnels de la sécurité, les évaluations des vulnérabilités et les tests de pénétration;
  • L’examen de la configuration de la sécurité des composants du système d’information.

Les résultats de la surveillance et de l’évaluation indiquent aux autorités ministérielles l’état actuel de la posture de sécurité de leurs systèmes d’information. Une posture stable et adéquate permet de maintenir l’autorisation d’exploitation d’un système d’information. Toute détérioration de la posture peut amener les autorités à révoquer l’autorisation jusqu’à la mise en place de mesures d’atténuation (voir les sections 4.5 et 4.6).

4.5 Maintenir l’autorisation

Conformément au processus proposé de gestion des risques liés à la sécurité des TI, les ministères autorisent initialement l’exploitation de leurs systèmes d’information, comme il est indiqué dans le processus de mise en œuvre décrit l’Annexe 2 du guide ITSG-33 [Référence 2]. Ensuite, la surveillance, l’évaluation et la tenue à jour continues des contrôles leur permettent de maintenir l’état d’autorisation de leurs systèmes d’information.

Le processus de maintien de l’autorisation inclut les activités suivantes :

  • Examen périodique de la catégorie de sécurité des activités opérationnelles prises en charge;
  • Réévaluation de l’environnement de menace et du rendement en matière de sécurité des environnements techniques;
  • Examen des résultats des évaluations du rendement des contrôles de sécurité;
  • Examen des activités des groupes responsables des opérations de TI pour confirmer qu’ils ont maintenu adéquatement la posture de sécurité de leurs systèmes d’information en conformité avec les dispositions de leurs plans opérationnels en matière de sécurité.

Lorsque les résultats des activités de maintien de l’autorisation indiquent qu’un système d’information a cessé de fonctionner dans les limites des niveaux acceptables de risque résiduel, les ministères disposent de divers moyens pour remédier à la situation, notamment :

  • Mettre en œuvre des mesures de sécurité temporaires pour protéger les activités opérationnelles touchées (p. ex., débrancher le système d’information du réseau Internet, activer une partie du plan d’urgence);
  • Mettre à jour les contrôles existants pour corriger les lacunes et ramener l’exploitation du système d’information à l’état d’autorisation (voir la section 4.6); et/ou
  • Accepter le nouveau niveau de risque résiduel.

Si le niveau de risque résiduel demeure inacceptable après l’application des mesures initiales, les autorisateurs peuvent choisir de révoquer l’autorisation d’exploitation jusqu’à la prise d’autres mesures correctives. La révocation de l’autorisation donne lieu à d’autres activités d’analyse de la sécurité qui permettent de cerner des lacunes particulières du contexte opérationnel; cette procédure est suivie par l’application de mesures correctives ou des améliorations des contrôles existants visant à restaurer l’état d’autorisation du système d’information.

Les ministères doivent établir dans leur plan de sécurité la fréquence des activités périodiques d’évaluation et d’examen de la sécurité (p. ex., examen des rapports d’incidents de sécurité, de l’environnement de menace, des activités de sécurité du groupe responsable des opérations de TI). D’autre part, les autorisateurs peuvent établir la fréquence de ces activités durant la mise en œuvre initiale du système en tenant compte de facteurs tels la catégorie de sécurité, les menaces, les niveaux de risque résiduel et les lacunes de sécurité non réglées.

Les produits des activités de maintien de l’autorisation incluent de nouvelles évaluations du risque résiduel et la mise à jour des dispositions du plan opérationnel en matière de sécurité. Ces dispositions doivent inclure des plans et des calendriers d’atténuation pour toute lacune de sécurité non réglée relevée au cours des activités d’évaluation de la sécurité (voir la section 4.6).

4.6 Déterminer les mises à jour des contrôles de sécurité

L’objectif de cette activité est de faire en sorte que la posture de sécurité des systèmes d’information demeure adéquate en assurant la tenue à jour des contrôles de sécurité existants (contrôles communs et contrôles intégrés aux systèmes d’information) et, selon les exigences, en ajoutant des contrôles qui permettent d’améliorer la posture.

Les ministères doivent mettre à jour leurs contrôles existants pour différentes raisons, notamment dans les situations où l’on constate :

  • un changement dans les missions ou les objectifs du ministère;
  • un changement dans une activité opérationnelle (p. ex., la collecte de renseignements nouveaux et plus sensibles dans le cadre d’un programme ministériel existant);
  • un changement dans les besoins opérationnels (p. ex., à la suite d’un changement législatif ou de politiques);
  • un changement exigé à l’issue d’une nouvelle évaluation ministérielle des menaces (p. ex., lorsque des agents de menace plus sophistiqués ciblent un programme particulier);
  • un changement exigé à l’issue de la surveillance du rendement (p. ex., lorsqu’il s’avère qu’un contrôle n’arrive pas à protéger adéquatement les systèmes d’information visés).

Cette activité est principalement fondée sur les profils de contrôle de sécurité ministériels existants, les rapports d’évaluation des menaces, les résultats de la surveillance et de l’évaluation du rendement et les activités de maintien de l’autorisation (voir les sections 4.4 et 4.5). Cette activité peut déterminer le besoin d’amélioration des contrôles existants ou d’ajout de nouveaux contrôles; elle peut renvoyer à une activité antérieure de la fonction de sécurité des TI pour redéfinir les contrôles requis, produire un rapport à jour sur le profil de contrôle et l’évaluation des menaces (voir, par exemple, les sections 4.2.3, 4.2.5 et 4.2.7), déployer de nouveaux contrôles (voir la section 4.3) ou effectuer une surveillance et une évaluation plus poussées du rendement (voir la section 4.4).

5 Rôles et responsabilités connexes

Cette section résume les responsabilités des rôles ministériels associés aux activités de gestion des risques liés à la sécurité du ministère et des systèmes d’information.

Pour appuyer la gestion des risques liés à la sécurité des TI, les instruments de politique du SCT attribuent aux cadres supérieurs, aux gestionnaires et aux employés des ministères des responsabilités liées à la sécurité des TI et à la gestion des risques. Ces instruments, qui régissent la sécurité des TI au sein du GC (voir la Figure 3), traitent de l’organisation de la sécurité aux deux niveaux du processus proposé de gestion des risques liés à la sécurité des TI en établissant les rôles principaux associés à la sécurité ministérielle et à celle des TI et en attribuant les responsabilités pertinentes à l’échelle du ministère.

Les lignes directrices du guide ITSG-33 respectent cette structure axée sur les rôles. Elles proposent également des rôles plus ciblés pour aider les employés affectés à ces rôles à s’acquitter de manière adéquate de leurs responsabilités de gestion des risques liés à la sécurité des TI.

Pour chaque rôle du GC défini dans cette section, un tableau indique les correspondances entre les responsabilités de gestion des risques liés à la sécurité des TI attribuées par les instruments de politique du SCT et les activités ministérielles prévues dans le processus proposé de gestion des risques. Ces tableaux incluent d’autres directives sur les tâches associées aux activités ministérielles qui doivent être effectuées et qui sont décrites à la section 4.

Figure 3 : Instruments de politique du SCT en matière de sécurité des TI

Figure 3 : Instruments de politique du SCT en matière de sécurité des TI

5.1 Administrateurs généraux

La PSG [Référence 3, section 6.1.1] attribue aux administrateurs généraux la responsabilité globale de mettre sur pied un programme de sécurité afin d’assurer la coordination et la gestion des activités ministérielles liées à la sécurité générale et des TI. Conformément à la PSG, les administrateurs doivent s’assurer que leur programme de sécurité ministérielle repose sur une structure de gouvernance assortie de responsabilités claires, qu’il comporte des objectifs précis qui cadrent avec les politiques, les priorités et les plans ministériels et pangouvernementaux, et qu’il est suivi, évalué et fait l’objet de rapports afin de mesurer les efforts de la direction, les ressources et les réussites à l’égard de l’atteinte des résultats escomptés.

Conformément à la PSG, les administrateurs généraux doivent nommer un ASM pour gérer le programme de sécurité du ministère. Ils doivent également s’assurer que les gestionnaires de tous les niveaux intègrent les exigences relatives à la sécurité aux plans, aux programmes, aux activités et aux services.

Le CGR [Référence 6] attribue aux administrateurs généraux la responsabilité de :

  • gérer les risques auxquels leur organisation est exposée et mettre en œuvre des pratiques efficaces de gestion des risques;
  • s’assurer que les principes et les pratiques de gestion des risques sont compris et intégrés aux diverses activités de leur organisation;
  • surveiller les pratiques de gestion des risques de leur organisation.

Le Tableau 2 indique les responsabilités des administrateurs généraux qui s’inscrivent dans le processus de gestion des risques liés à la sécurité des TI, et établit les correspondances entre ces responsabilités et les activités connexes.

Tableau 2 : Mise en correspondance des responsabilités des administrateurs généraux en matière de gestion des risques liés à la sécurité des TI

Instruments de politique du SCT Processus de gestion des risques liés à la sécurité des TI (Annexe 1)
Titre Section Responsabilité Section Activité Tâche connexe
PSG 6.1.4 Approuver le PSM qui détaille les décisions en matière de gestion de risques liés à la sécurité et expose les stratégies, les buts, les objectifs et les échéanciers élaborés en vue d’améliorer la sécurité ministérielle et de favoriser sa mise en œuvre. 4.2.7.4 Approuver les profils de contrôle de sécurité ministériels. S’assurer d’intégrer les objectifs en matière de contrôles de sécurité et les contrôles de sécurité du ministère dans le plan de sécurité ministérielle.
PSG 6.1.5 S’assurer que les gestionnaires de tous les niveaux intègrent les exigences relatives à la gestion de la sécurité et de l’identité aux plans, aux programmes, aux activités et aux services. 4.2.2 Déterminer les besoins opérationnels en matière de sécurité. S’assurer que les gestionnaires indiquent leurs besoins opérationnels en matière de sécurité pour aider au développement des profils de contrôle de sécurité ministériels.
PSG 6.3 S’assurer que l’on procède à des examens périodiques pour déterminer si le programme de sécurité ministérielle est efficace, si les buts, les objectifs stratégiques et les objectifs de contrôle précisés dans leur plan de sécurité ministérielle ont été atteints, et si ce plan continue de répondre aux besoins du ministère et du gouvernement dans son ensemble. 4.4 Surveiller et évaluer le rendement des contrôles de sécurité. S’assurer que les responsables de la sécurité du ministère ont mis en œuvre l’activité ministérielle qui permet de surveiller et d’évaluer en permanence le rendement des contrôles de sécurité mis en place.
CGR 6 Gérer les risques auxquels leur organisation est exposée et mettre en œuvre des pratiques efficaces de gestion du risque, qu’elles soient formelles ou informelles. 4 Toutes les activités de gestion des risques liés à la sécurité des TI. Mettre en œuvre les activités de gestion des risques liés à la sécurité des TI.
CGR 6 S’assurer que les principes et les pratiques de gestion du risque sont compris et intégrés aux diverses activités de leur organisation.
CGR 6 S’assurer que les questions qui influent sur les démarches de gestion des risques entreprises par l’organisation, qu’il s’agisse de risques relevés lors d’évaluations et d’activités de surveillance interne ou externe, sont examinées et réglées.

5.2 Agents de sécurité du ministère

Conformément à la PSG [Référence 3, section 6.1.2], les administrateurs généraux doivent nommer un agent de sécurité du ministère (ASM) pour gérer le programme de sécurité ministérielle. La Directive sur la gestion de la sécurité ministérielle (DGSM) [Référence 7, section 6.1.1] attribue aux ASM la responsabilité d’élaborer, de mettre en œuvre, de surveiller et d’actualiser un plan de sécurité ministérielle (PSM) qui :

  • renferme une vision commune des exigences de sécurité ministérielle;
  • définit les menaces à la sécurité, les risques et les vulnérabilités afin de fixer un ensemble approprié d’objectifs de contrôle;
  • définit et établit des mesures de contrôle minimales supplémentaires en vue d’atteindre les objectifs en matière de contrôle et d’en arriver à un niveau acceptable de risque résiduel;
  • énonce des stratégies, des objectifs, des priorités et des délais de sécurité pour améliorer la posture de sécurité du ministère.

L’ASM doit coordonner, avec les praticiens de la sécurité, la mise en œuvre des mesures de contrôle de sécurité et des autres activités nécessaires à la réalisation des objectifs et des priorités du PSM. Les ASM doivent mettre à jour le PSM à la lumière des résultats de la mesure du rendement, de l’évaluation ainsi que des évaluations des risques.

Conformément à la DGSM, les ASM doivent :

  • veiller à ce que les responsabilités, les délégations, les rapports hiérarchiques ainsi que les rôles et responsabilités des employés du ministère à l’égard des responsabilités de sécurité soient définis, documentés et communiqués aux personnes concernées;
  • établir des mécanismes de gouvernance de la sécurité (p. ex., mettre sur pied des comités, des groupes de travail) pour assurer la coordination et l’intégration des activités de sécurité dans les opérations, les plans, les priorités et les fonctions du ministère afin de faciliter la prise de décisions;
  • mesurer le degré de réalisation des objectifs énoncés dans le PSM et rendre compte des résultats aux comités de gouvernance responsables.

Le Tableau 3 indique, les responsabilités des ASM qui s’inscrivent dans le cadre du processus de gestion des risques liés à la sécurité des TI, et établit les correspondances entre ces responsabilités et les activités connexes.

Tableau 3 : Mise en correspondance des responsabilités des ASM en matière de gestion des risques liés à la sécurité des TI

Instruments de politique du SCT Processus de gestion des risques liés à la sécurité des TI (Annexe 1)
Titre Section Responsabilité Section Activité Tâches connexes
DGSM 6.1.1.1 S’assurer que le PSM renferme une vision commune des exigences de sécurité ministérielle. 4.2.2 Déterminer les besoins opérationnels en matière de sécurité. Intégrer les besoins opérationnels en matière de sécurité au PSM aux fins d’approbation par l’administrateur général concerné.
DGSM 6.1.1.2 S’assurer que le PSM définit les menaces à la sécurité, les risques et les vulnérabilités afin de fixer un ensemble approprié d’objectifs de contrôle. 4.2.5 Effectuer l’évaluation ministérielle des menaces à la sécurité des TI. Intégrer au PSM les résultats de l’évaluation ministérielle des menaces à la sécurité des TI aux fins d’approbation par l’administrateur général concerné.
4.2.6 Préciser les objectifs en matière de contrôles de sécurité. Intégrer au PSM les objectifs des ministères en matière de contrôles de sécurité aux fins d’approbation par l’administrateur général concerné.
DGSM 6.1.1.3 S’assurer que le PSM définit et établit des mesures de contrôle minimales supplémentaires en vue d’atteindre les objectifs en matière de contrôle et d’en arriver à un niveau acceptable de risque résiduel. 4.2.7 Développer des profils de contrôle de sécurité ministériels. Superviser le développement des profils de contrôle de sécurité ministériels.

Intégrer au PSM les contrôles de sécurité ministériels aux fins d’approbation par l’administrateur général concerné.
DGSM 6.1.2 Coordonner, avec les praticiens de la sécurité, la mise en œuvre des contrôles de sécurité et des autres activités nécessaires à la réalisation des objectifs et des priorités du PSM. 4.3.1 Déployer les contrôles de sécurité communs. Coordonner avec les praticiens de la sécurité le déploiement des contrôles de sécurité communs.
DGSM 6.1.4 Mettre à jour le PSM à la lumière des résultats de la mesure du rendement, de l’évaluation ainsi que des évaluations de risque. 4.6 Déterminer les mises à jour des contrôles de sécurité. Mettre le PSM à jour pour refléter les changements apportés aux besoins opérationnels en matière de sécurité et aux objectifs et exigences en matière de contrôles de sécurité.
DGSM 6.1.7 Élaborer, documenter, mettre en œuvre et actualiser les processus de gestion systématique des risques pour la sécurité afin d’assurer une adaptation continue aux besoins changeants du ministère et au contexte de menace. 4 Toutes les activités de gestion des risques liés à la sécurité des TI. Surveiller la mise en œuvre des activités proposées de gestion des risques liés à la sécurité des TI.
DGSM 6.2.1 Surveiller la mise en œuvre des activités de sécurité au ministère et recommander des mesures correctives appropriées à l’administrateur général ou au comité de la haute direction (selon ce qui s’applique) en vue de corriger toute lacune.
DGSM 6.1.9 Surveiller l’efficacité des mesures de contrôle de sécurité pour faire en sorte qu’elles demeurent à jour et qu’elles satisfont aux exigences de sécurité mentionnées dans les évaluations du risque. 4.4 Surveiller et évaluer le rendement des contrôles de sécurité. S’assurer de surveiller et d’évaluer les contrôles de sécurité mis en place (contrôles communs et système).
DGSM 6.1.10 En coopération avec les praticiens de la sécurité, surveiller les changements dans les contextes de menace et de vulnérabilité afin de s’assurer que les mesures de contrôle de sécurité demeurent pertinentes et que des mesures correctives soient prises au besoin.
DGSM 6.1.11 Mesurer le rendement sur une base continue afin de veiller à ce qu’un niveau acceptable de risque résiduel soit atteint et maintenu.

5.3 Coordonnateurs de la sécurité des TI

Conformément à la GSTI [Référence 1], les coordonnateurs de la sécurité des TI sont responsables de mettre en place et gérer, au nom de leur ASM, une fonction de sécurité des TI dans le cadre d’un programme ministériel de sécurité. Le coordonnateur doit :

  • examiner les politiques et normes de sécurité des TI du ministère et toutes les politiques qui contiennent des implications pour la sécurité des TI, et recommander à l’ASM de les approuver;
  • veiller à ce que soient vérifiées les sections liées à la sécurité des TI de la demande de propositions et de toute autre documentation sur la passation de marchés, y compris les listes de vérification des exigences relatives à la sécurité;
  • recommander l’approbation de tous les contrats destinés aux fournisseurs externes de services de sécurité des TI.

La GSTI attribue aux coordonnateurs la responsabilité de :

  • collaborer étroitement avec les gestionnaires de la prestation de programmes et services pour s’assurer que leurs besoins de sécurité des TI soient satisfaits;
  • donner des conseils sur les contrôles de sécurité et leur mise en œuvre;
  • informer les gestionnaires de la prestation de programmes et services des incidences potentielles.

Le Tableau 4 indique les responsabilités des coordonnateurs de la sécurité des TI qui s’inscrivent dans le cadre du processus de gestion des risques liés à la sécurité des TI, et établit les correspondances entre ces responsabilités et les activités connexes.

Tableau 4 : Mise en correspondance des responsabilités des coordonnateurs de la sécurité des TI en matière de gestion des risques liés à la sécurité des TI

Instruments de politique du SCT Processus de gestion des risques liés à la sécurité des TI (Annexe 1)
Titre Section Responsabilité Section Activité Tâches connexes
GSTI 9.1 Mettre en place et gérer un programme ministériel de sécurité des TI dans le cadre d’un programme ministériel de sécurité coordonné. 4.2 Définir les besoins en matière de sécurité des TI et les contrôles de sécurité du ministère. Coordonner les activités de définition des besoins en matière de sécurité des TI et des contrôles de sécurité du ministère.
4.3.1 Déployer et exploiter les contrôles de sécurité communs. Coordonner le déploiement et gérer l’exploitation des contrôles de sécurité communs.
GSTI 9.1 Mettre en place un processus efficace de gestion des incidents liés à la sécurité des TI et veiller à ce que tous s’y conforment. 4.4 Surveiller et évaluer le rendement des contrôles de sécurité. Coordonner l’établissement du processus de surveillance et d’évaluation du ministère et surveiller son fonctionnement.
GSTI 9.1 Examiner les politiques et normes de sécurité des TI du ministère et toutes les politiques qui contiennent des implications pour la sécurité des TI, et recommander à l’ASM de les approuver. 4.2.7.4 Approuver les profils de contrôle de sécurité ministériels. Examiner les profils de contrôle de sécurité ministériels et en recommander l’approbation.
GSTI 9.1 Collaborer étroitement avec les gestionnaires de la prestation de programmes et services pour s’assurer que leurs besoins de sécurité des TI soient satisfaits. 4.2.2 Déterminer les besoins opérationnels en matière de sécurité. Coordonner la détermination des besoins opérationnels en matière de sécurité ministérielle.
GSTI 9.4 S’assurer que des mesures de sécurité appropriées soient mises en place à l’égard de toutes les activités et de tous les processus et biens de GI et de TI. 4.3.2 Promulguer les profils de contrôle de sécurité ministériels. Promulguer l’utilisation dans les projets TI des profils de contrôle de sécurité ministériels pour la mise en œuvre des systèmes d’information du ministère.
GSTI 9.1 Conseiller les gestionnaires de la prestation de programmes et services sur les incidences éventuelles des menaces existantes et nouvelles et sur le risque résiduel lié à un programme ou service. 4.2.5 Effectuer l’évaluation ministérielle des menaces à la sécurité des TI. Diffuser les résultats des évaluations ministérielles des menaces aux collectivités opérationnelles à l’échelle du ministère.

5.4 Coordonnateurs de la PCA et DPI

Conformément à la GSTI [Référence 1], les coordonnateurs de la planification de la continuité des activités (PCA) et les dirigeants principaux de l’information (DPI) doivent maintenir une approche uniforme de la prestation continue des services. À cette fin, les coordonnateurs de la PCA et les DPI, en collaboration avec le coordonnateur de la sécurité des TI de leur ministère, peuvent tirer avantage du processus de gestion des risques liés à la sécurité des TI afin de s’assurer que les exigences relatives à la sécurité de l’information et à la continuité des activités du ministère soient reflétées dans les besoins opérationnels en matière de sécurité ministérielle (section 4.2.2), et qu’elles soient prises en compte adéquatement dans les profils de contrôle de sécurité ministériels (section 4.2.7).

5.5 Gestionnaires

Conformément à la DGSM [Référence 7], les gestionnaires doivent veiller à ce que les exigences en matière de sécurité soient intégrées à la planification des activités, aux programmes, aux services et aux autres activités de gestion. Pour appuyer la gestion des risques, les gestionnaires doivent :

  • évaluer les risques en matière de sécurité;
  • accepter officiellement les risques résiduels ou en recommander l’acceptation (ces risques sont définis dans le PSM);
  • réévaluer périodiquement les risques à la lumière des changements apportés aux programmes, aux activités ou aux services;
  • prendre des mesures correctives pour corriger les lacunes relevées.

Le Tableau 5 indique, les responsabilités des gestionnaires qui s’inscrivent dans le cadre du processus de gestion des risques liés à la sécurité des TI, et établit les correspondances entre ces responsabilités et les activités connexes.

Tableau 5 : Mise en correspondance des responsabilités des gestionnaires en matière de gestion des risques liés à la sécurité des TI

Instruments de politique du SCT Processus de gestion des risques liés à la sécurité des TI (Annexe 1)
Titre Section Responsabilité Section Activité Tâches connexes
DGSM 6.1.22 Veiller à ce que les exigences en matière de sécurité soient intégrées à la planification des opérations, aux programmes, aux services et aux autres activités de gestion. 4.2.2 Déterminer les besoins opérationnels en matière de sécurité. Fournir leurs exigences en matière de sécurité de l’information pour faciliter la détermination des besoins opérationnels en matière de sécurité.
4.2.3 Catégoriser la sécurité des activités opérationnelles du ministère. Indiquer la catégorisation de sécurité de leurs biens d’information pour faciliter la catégorisation des activités opérationnelles.
DGSM 6.1.23 Évaluer les risques en matière de sécurité, accepter officiellement les risques résiduels, définis dans le plan de sécurité ministérielle, ou en recommander l’acceptation, et réévaluer périodiquement les risques à la lumière des changements apportés aux programmes, aux activités ou aux services et prendre des mesures correctives pour corriger les lacunes relevées. 4.2.5 Effectuer l’évaluation ministérielle des menaces à la sécurité des TI. Informer le coordonnateur de la sécurité des TI de leur ministère des risques qui menacent leurs activités opérationnelles.
DGSM 6.1.24 Surveiller la mise en œuvre et l’efficacité des mesures de contrôle de sécurité et faire rapport à cet égard à l’ASM ou aux praticiens de la sécurité, le cas échéant. 4.4 Surveiller et évaluer le rendement des contrôles de sécurité. Informer le coordonnateur de la sécurité des TI de leur ministère de l’efficacité des contrôles de sécurité intégrés aux systèmes d’information qui appuient leurs activités opérationnelles.

5.6 Gestionnaires de la prestation de programmes et services

Conformément à la GSTI [Référence 1], les gestionnaires de la prestation de programmes et servicesNote de bas de page 4 doivent assurer un niveau de sécurité approprié pour leurs programmes et services. Ils doivent collaborer avec les responsables de la sécurité des TI du ministère et gérer en permanence les risques qui menacent leurs programmes et services. Les gestionnaires doivent déterminer les besoins en matière de sécurité des TI de leurs programmes et services.

Comme il est décrit à la section 5.13, les gestionnaires sont, de manière générale, responsables d’autoriser l’exploitation des systèmes d’information qui soutiennent leurs programmes et services conformément à un ensemble particulier de conditions de sécurité. En vertu de cette autorisation, les gestionnaires assument la responsabilité de leur confiance en ces systèmes d’information et en acceptent donc les risques inhérentsNote de bas de page 5.

Le Tableau 6 indique les responsabilités des gestionnaires de la prestation de programmes et services qui s’inscrivent dans le cadre du processus de gestion des risques liés à la sécurité des TI, et établit les correspondances entre ces responsabilités et les activités connexes.

Tableau 6 : Mise en correspondance des responsabilités des gestionnaires de la prestation de programmes et services en matière de gestion des risques liés à la sécurité des TI

Instruments de politique du SCT Processus de gestion des risques liés à la sécurité des TI (Annexe 1)
Titre Section Exigence Section Activité Tâches connexes
DGSM 6.1.23 Évaluer les risques en matière de sécurité, accepter officiellement les risques résiduels, définis dans le plan de sécurité ministérielle, ou en recommander l’acceptation, et réévaluer périodiquement les risques à la lumière des changements apportés aux programmes, aux activités ou aux services et prendre des mesures correctives pour corriger les lacunes relevées. 4.5 Maintenir l’autorisation. Maintenir l’autorisation d’exploiter les systèmes d’information dont ils sont les gestionnaires responsables ou les autorisateurs en participant activement à toutes les activités de maintien de l’autorisation.
GSTI 9.6 Fournir un niveau de sécurité approprié pour leurs programmes et services. 4.2 Définir les besoins en matière de sécurité des TI et les contrôles de sécurité du ministère. Participer à la définition des besoins en matière de sécurité et de contrôles de sécurité afin de :
  • fournir les besoins opérationnels en matière de sécurité pour les activités opérationnelles dont ils sont responsables (section 4.2.2);
  • fournir, en collaboration avec les gestionnaires, les exigences en matière de sécurité de l’information associées aux activités opérationnelles dont ils sont responsables (section 4.2.3);
  • contribuer à l’évaluation ministérielle des menaces (section 4.2.5);
  • Contribuer à la spécification des objectifs en matière de contrôles de sécurité (section 4.2.6).
GSTI 9.6 Déterminer les exigences de sécurité des TI pour leurs programmes et services. 4.2.7 Développer des profils de contrôle de sécurité ministériels. Participer au développement des profils de contrôle de sécurité ministériels associés à leurs activités opérationnelles.
GSTI 9.6 Collaborer avec les spécialistes de la sécurité du ministère afin de gérer les risques liés à leurs programmes ou services.
GSTI 9.6 S’assurer que, dans leurs champs de responsabilité, les exigences énoncées dans la présente norme, dans la Politique sur la sécurité du gouvernement et dans d’autres politiques, normes et documentation technique connexes, sont satisfaites.

5.7 Fournisseurs de contrôles de sécurité communs

Un fournisseur de contrôles de sécurité communs est un gestionnaire de la prestation de programmes et services qui met en œuvre et exploite au nom du ministère un contrôle qui touche ou soutient plusieurs systèmes d’information. Les contrôles de sécurité communs sont décrits à la section 4.2.7.3..

Ces fournisseurs contribuent aux activités de gestion des risques liés à la sécurité des TI de la façon suivante :

  • Ils participent aux évaluations ministérielles des menaces (section 4.2.5);
  • Ils participent au développement des profils de contrôle de sécurité ministériels (section 4.2.7);
  • Ils mettent en œuvre et exploitent les contrôles de sécurité communs (section 4.3.1);
  • Ils participent à la surveillance et à l’évaluation des contrôles de sécurité (section 4.4); and
  • Ils participent à la mise à jour des contrôles de sécurité (section 4.6).

5.8 Gestionnaires de projets de TI

Conformément à la GSTI [Référence 1], les gestionnaires de projet TI doivent s’assurer de répondre aux exigences liées à la sécurité des projets. L’Annexe 2 du guide ITSG-33 [Référence 2] renferme les directives qui permettent aux gestionnaires de projet TI d’atteindre cet objectif.

5.9 Praticiens de la sécurité

La DGSM [Référence 7] attribue aux praticiens de la sécurité la responsabilité de la sélection, de la mise en œuvre et de la maintenance des contrôles de sécurité qui touchent leur domaine afin de s’assurer que les contrôles de sécurité atteignent leurs objectifs. La DGSM stipule que les praticiens de la sécurité, selon la structure du programme de sécurité du ministère, doivent maintenir un lien hiérarchique fonctionnel ou direct avec l’ASM afin d’assurer la coordination et l’intégration des activités de sécurité ministérielle.

Conformément à la DGSM, les praticiens de la sécurité doivent :

  • évaluer la mise en œuvre et l’efficacité des contrôles de sécurité, faire rapport à l’ASM sur la réalisation des objectifs de contrôle et recommander des mesures correctives pour régler les lacunes relevées dans la mesure et les évaluations du rendement;
  • fournir à l’ASM, aux gestionnaires de tous niveaux et aux employés, des conseils d’expert relativement à l’application et à l’efficacité des contrôles de sécurité liés à leur domaine de compétence;
  • prendre part aux activités d’évaluation des menaces et des risques (EMR) et contribuer à l’élaboration du PSM au besoin.

Le Tableau 7 indique les responsabilités des praticiens de la sécurité qui s’inscrivent dans le cadre du processus de gestion des risques liés à la sécurité des TI, et établit les correspondances entre ces responsabilités et les activités connexes.

Tableau 7 : Mise en correspondance des responsabilités des praticiens de la sécurité en matière de gestion des risques liés à la sécurité des TI

Instruments de politique du SCT Processus de gestion des risques liés à la sécurité des TI (Annexe 1)
Titre Section Responsabilité Section Activité Tâches connexes
DGSM 6.1.17 Sélectionner, mettre en œuvre et maintenir des contrôles de sécurité liés à leur champ de responsabilité afin d’assurer la réalisation des objectifs de contrôle. 4.2 Définir les besoins en matière de sécurité des TI et les contrôles de sécurité du ministère. Participer à la définition des besoins en matière de sécurité des TI et de contrôles de sécurité :
  • en aidant le coordonnateur de la sécurité des TI de leur ministère à définir la portée des activités de gestion des risques liés à la sécurité des TI du ministère (section 4.2.1);
  • en participant à la détermination des besoins opérationnels en matière de sécurité (section 4.2.2);
  • en catégorisant la sécurité des activités opérationnelles (section 4.2.3);
  • en définissant la méthodologie d’EMR liée à la sécurité des TI du ministère (section 4.2.4);
  • en précisant les objectifs en matière de contrôles de sécurité (section 4.2.6);
  • • en développant les profils de contrôle de sécurité ministériels (section 4.2.7).
4.3.1 Déployer et exploiter les contrôles de sécurité communs. Participer au déploiement et à l’exploitation des contrôles de sécurité communs.
4.6 Déterminer les mises à jour des contrôles de sécurité. Déterminer les mises à jour des contrôles de sécurité et participer à leur mise en œuvre.
4.2.7 Développer des profils de contrôle de sécurité ministériels. S’assurer que la sélection des contrôles de sécurité répond aux besoins opérationnels en matière de sécurité.
DGSM 6.1.18 Évaluer la mise en œuvre et l'efficacité des contrôles de sécurité, faire rapport à l'ASM sur la réalisation des objectifs de contrôle et recommander des mesures correctives pour corriger les lacunes relevées dans la mesure et les évaluations du rendement. 4.4 Surveiller et évaluer le rendement des contrôles de sécurité. Surveiller et évaluer le rendement de la mise en œuvre des contrôles de la sécurité (ministériels et des systèmes d’information).
DGSM 6.1.21 Prendre part aux évaluations des menaces et des risques et contribuer à l’élaboration du PSM au besoin. 4.2.5 Effectuer l’évaluation ministérielle des menaces à la sécurité des TI. Effectuer l’évaluation ministérielle des menaces.

5.10 Évaluateurs de la sécurité (internes et externes)

Le rôle de l’évaluateur de la sécurité consiste à mener les activités d’évaluation de la sécuritéNote de bas de page 6 du processus de gestion des risques liés à la sécurité des TI. Il doit également participer de manière proactive aux autres activités liées à la sécurité des TI pour s’assurer que les principaux extrants répondent dès le début aux besoins et aux objectifs du ministère en matière de sécurité, plutôt que de s’en remettre aux évaluations de sécurité ultérieures pour cerner les lacunes et les manques de conformité. Les professionnels de la sécurité des différents domaines peuvent remplir ce rôle.

Les évaluateurs appuient le processus de gestion des risques liés à la sécurité des TI :

  • en participant aux évaluations ministérielles des menaces (section 4.2.5);
  • en participant au développement des profils de contrôle de sécurité ministériels (section 4.2.7);
  • en évaluant le rendement des contrôles de sécurité (section 4.4); and
  • en participant à la mise à jour des contrôles de sécurité (section 4.6).

Les évaluateurs exécutent également des activités d’évaluation de sécurité au niveau du système d’information durant le processus de gestion des risques liés à la sécurité des TI. Ces activités sont décrites à l’Annexe 2 du guide ITSG-33 [Référence 2].

Les activités opérationnelles ou les systèmes d’information plus sensibles ou critiques peuvent exiger un niveau d’indépendance plus élevé par rapport aux activités d’évaluation de la sécurité que celui offert par un projet TI ou par les ressources internes du ministère. Le cas échéant, un responsable du ministère ou un autorisateur peut nommer un évaluateur externe pour effectuer les activités d’évaluation de la sécurité. L’évaluateur peut être un employé d’un autre secteur de l’organisation ou un contractuel d’une entreprise externe qualifiée.

Le rôle d’un évaluateur externe est différent de celui d’une autorité de certification, qui n’est qu’un autre type d’évaluateur de la sécurité. Lorsqu’un ministère ou un organisme confie à une autorité de certification le rôle d’évaluateur externe pour des projets TI, l’autorité est responsable de mener les activités d’évaluation et d’autorisation de la sécurité en collaboration avec les praticiens de la sécurité, les autorisateurs et les gestionnaires de projets TI.

5.11 Architectes de sécurité d’entreprise

L’architecte de sécurité d’entreprise est responsable de s’assurer que les exigences en matière de sécurité de l’information nécessaires pour protéger les activités opérationnelles sont prises en compte de manière adéquate à toutes les étapes de la conception d’un système d’information. Bien qu’elle ne soit pas incluse dans la portée des lignes directrices du guide ITSG-33, le CSTC recommande que les ministères mettent en place une fonction d’architecte en sécurité d’entreprise pour appuyer la gestion des risques liés à la sécurité des TI. Certains ministères peuvent compter parmi leurs employés un architecte de sécurité d’entreprise. La fonction peut également relever d’un cadre supérieur tel un DPI ou un dirigeant principal de la technologie (DPT).

Pour appuyer la gestion des risques liés à la sécurité des TI, les architectes doivent fournir des directives et des conseils sur une vaste gamme de problèmes liés à la sécurité à leur ASM, leur coordonnateur de la sécurité des TI, aux gestionnaires, aux gestionnaires de la prestation de programmes et services et aux gestionnaires des opérations de TI (p. ex., l’établissement des frontières du système d’information, l’évaluation de la gravité des faiblesses et des lacunes des systèmes d’information ministériels, les dispositions relatives à la sécurité des plans opérationnels, les approches concernant l’atténuation des risques, les alertes de sécurité et les effets négatifs éventuels des vulnérabilités connues).

Les architectes peuvent apporter une contribution utile aux activités suivantes de gestion des risques liés à la sécurité des TI :

  • Conduite des évaluations ministérielles des menaces (section 4.2.5);
  • Spécification des objectifs en matière de contrôles de sécurité (section 4.2.6);
  • Développement des profils de contrôle de sécurité ministériels (section 4.2.7); and
  • Mise à jour des contrôles de sécurité (section 4.6).

5.12 Gestionnaires et personnel des opérations de TI

Un gestionnaire des opérations de TI est un gestionnaire de la prestation de programmes et services responsable de l’exploitation, de la maintenance et de l’élimination d’un ou de plusieurs systèmes d’information. Sur le plan de la gestion des risques liés à la sécurité des TI, ce gestionnaire est généralement responsable de voir au respect des intérêts opérationnels de la collectivité des utilisateurs (c. à d. les utilisateurs qui doivent accéder aux systèmes d’information dans le cadre de leurs activités opérationnelles ou pour satisfaire à des exigences opérationnelles) et de s’assurer du respect permanent des exigences en matière de sécurité des TI.

Les gestionnaires et le personnel des opérations de TI participent aux activités de gestion des risques liés à la sécurité des TI en appliquant des contrôles de sécurité communs (section 4.3.1) et en établissant des paramètres de rendement des contrôles de sécurité intégrés aux systèmes d’information dont il assument la responsabilité opérationnelle (section 4.4).

Les gestionnaires et le personnel sont également responsables de sécuriser l’exploitation et la maintenance des systèmes d’information et l’élimination des biens de TI. Ces activités sont décrites à l’Annexe 2 du guide ITSG-33 [Référence 2].

De manière générale, les gestionnaires et le personnel, en coordination avec le coordonnateur de la sécurité des TI de leur ministère, doivent :

  • participer à l’élaboration de plans opérationnels de sécurité pour leurs systèmes d’information;
  • appliquer et tenir à jour les plans opérationnels de sécurité;
  • s’assurer que leurs systèmes d’information sont mis en œuvre et exploités en conformité avec les contrôles de sécurité convenus;
  • déterminer, en coordination avec les gestionnaires de la prestation de programmes et services, qui doit avoir accès aux ressources du système d’information ainsi que les types de privilèges ou de droits d’accès qui doivent être accordés à ces personnes;
  • s’assurer que les utilisateurs du système d’information et le personnel de soutien reçoivent la formation de sécurité requise (p. ex., directives concernant les règles de conduite);
  • informer, après avoir consulté les autorisateurs, les gestionnaires concernés du besoin d’effectuer des évaluations continues, de s’assurer de la disponibilité des ressources requises pour les tâches à accomplir, de collaborer avec les évaluateurs de la fonction de sécurité des TI et, le cas échéant, de fournir aux évaluateurs de la sécurité l’information et la documentation sur le système d’information ainsi que le moyen d’accéder à ce système.

5.13 Autorisateurs

L’autorisateur est la personne qui accorde l’« autorisation d’exploiter » un système d’information et qui, de ce fait même, accepte le risque associé à son exploitation dans le contexte opérationnel actuel. Selon l’importance ou l’ampleur de la portée du système opérationnel, un cadre de niveau supérieur peut être nommé autorisateur puisque le niveau de l’autorisateur doit être à la mesure du risque résiduel accepté et du niveau de responsabilité à l’égard du programme et du succès de sa prestation. Dans le cas des systèmes d’information ministériels, l’autorisateur est normalement le gestionnaire de la prestation de programmes et services (consulter la section 5.6 ci-dessus). Pour ce qui est des systèmes ou services communs (incluant les services de Services partagés Canada) utilisés à l’échelle du gouvernement du Canada, le DPI du GC (c.-à-d., le DPI de la Direction du dirigeant principal de l’information [DDPI] du SCT) joue le rôle d’autorisateur et remplit, à l’échelle du GC, les mêmes fonctions que celles du gestionnaire de la prestation de programmes et services. Pour les systèmes ou services partagés par deux ou plusieurs organisations, le gestionnaire du programme ou du service joue le rôle d’autorisateur.

6 Processus de catégorisation de la sécurité

6.1 Introduction

Cette section décrit la façon dont les ministères peuvent catégoriser la sécurité de leurs activités opérationnelles (c.-à-d., les processus opérationnels et leurs biens d’information) pour harmoniser la définition de leurs profils de contrôle aux politiques, aux directives et aux normes applicables du SCT.

La catégorisation de la sécurité est un outil qui permet d’établir l’importance relative des activités opérationnelles. Au niveau du ministère, ces catégories sous-tendent les évaluations des menaces, la spécification des objectifs en matière de contrôles de sécurité et le développement des profils de contrôle de sécurité. Au niveau des systèmes d’information, elles aident à établir les exigences en matière d’assurance de la sécurité, à sélectionner et à adapter les contrôles de sécurité et à mener des activités d’EMR.

Cette proposition de processus de catégorisation respecte le Cadre de gestion des risques (CGR) [Référence 6].

6.2 Concepts

Lorsque des activités opérationnelles sont compromises par des menaces liées aux TI, des préjudices peuvent être causés aux intérêts nationauxNote de bas de page 7 ou non nationauxNote de bas de page 8 liés à ces activités. Ces préjudices peuvent être dus à l’utilisation, la divulgation, la modification ou la destruction non autorisées, ou à l’altération ou l’interruption de processus opérationnels. Les préjudices liés à l’utilisation ou la divulgation non autorisées d’information ont une incidence sur l’objectif de sécurité des TI lié à la confidentialité. Ceux liés à la modification de l’information ou à l’altération des processus opérationnels ont une incidence sur l’objectif de sécurité des TI lié à l’intégrité (c.-à-d., précision, exhaustivité, authenticité, utilisation prévue). Les préjudices liés à la destruction d’information ou à l’interruption des processus opérationnels ont une incidence sur l’objectif de sécurité des TI lié à la disponibilité.

La catégorisation de la sécurité est un processus qui permet de déterminer les préjudices prévus causés par des menaces de compromission ainsi que le niveau de ces préjudices relativement aux objectifs de sécurité liés à la confidentialité, à l’intégrité et à la disponibilité. Le résultat du processus est l’attribution à une activité opérationnelle d’une catégorie de sécurité qui exprime les niveaux les plus élevés de préjudices prévus pour les trois objectifs liés à la sécurité des TI.

6.3 Processus de catégorisation de la sécurité

Tel qu’illustré à la Figure 4, le processus de catégorisation de la sécurité d’une activité opérationnelle peut se résumer en quatre étapes :

  • Déterminer les processus opérationnels et les biens d’information associés à l’activité opérationnelle;
  • Pour chaque processus opérationnel et les biens d’information connexes, déterminer les préjudices causés par des menaces de compromission aux intérêts nationaux et non nationaux liés à cette activité, et déterminer les niveaux de ces préjudices par rapport aux objectifs de confidentialité, d’intégrité et de disponibilité;
  • Déterminer la catégorie de sécurité de l’activité opérationnelle en établissant les niveaux les plus élevés de préjudices prévus relativement aux objectifs de confidentialité, d’intégrité et de disponibilité (CID);
  • Préparer un rapport sur la catégorisation de la sécurité.

Figure 4 : Processus de catégorisation de la sécurité

Figure 4 : Processus de catégorisation de la sécurité

6.4 Description du processus de catégorisation de la sécurité

6.4.1 Déterminer le processus opérationnel et les biens d’information connexes

La première étape du processus consiste à déterminer les processus opérationnels et les biens d’information associés à l’activité opérationnelle.

Plusieurs sources permettent de déterminer et de décrire les processus opérationnels et les biens d’information. Ces sources incluent les suivantes :

  • Analyses de rentabilisation;
  • Concept des opérations (CONOPS);
  • Spécifications opérationnelles fonctionnelles;
  • Documentation de l’architecture d’entreprise qui inclut normalement une description suffisamment détaillée des processus opérationnels et des biens d’information;
  • Discussions ou entrevues avec des analystes fonctionnels et d’autres représentants des collectivités opérationnelles concernées;
  • Patrons de référence de services du Modèle de référence stratégique des gouvernements canadiens (MRSG) du SCT [Référence 16], qui peuvent également être utiles pour déterminer et décrire les processus opérationnels.

Tel qu’il est illustré à la Figure 4, le résultat de cette étape est une brève description des processus et des biens d’information pertinents.

6.4.2 Évaluer les préjudices associés aux menaces de compromission

La deuxième étape du processus est l’évaluation des préjudices.

L’objectif de l’évaluation des préjudices est de déterminer les préjudices prévus liés aux menaces de compromission pour chaque processus opérationnel et chaque bien d’information déterminé à l’étape précédente. Pour y parvenir, on doit d’abord déterminer, à l’aide du Tableau 8, les préjudices probables associés aux menaces de compromission de la confidentialité, de l’intégrité et de la disponibilité des processus opérationnels et des biens d’information, puis attribuer les niveaux appropriés aux préjudices. La confidentialité, l’intégrité et la disponibilité s’appliquent aux biens d’information, tandis que l’intégrité et la disponibilité s’appliquent aux processus opérationnels.

Idéalement, les ministères doivent évaluer les préjudices associés à leurs processus opérationnels et aux biens d’information connexes en recourant à un processus auquel participent des équipes multidisciplinaires qui regroupent des représentants des domaines opérationnels, juridiques, de l’accès à l’information et du respect de la vie privée.

Tableau 8 : Exemples de types et de niveaux de préjudice

Type de préjudice Description et niveau
Très faible Faible Moyen Élevé Très élevé
Agitation ou désordre civil Préjudice négligeable ou aucun préjudice raisonnable prévu Désobéissance civile, entraves publiques Émeute Actes de sabotage à l’égard de biens essentiels (p. ex. infrastructure essentielle) Émeute générale ou actes de sabotage nécessitant l’imposition de la loi martiale
Préjudice physique causé aux personnes Préjudice négligeable ou aucun préjudice raisonnable prévu Inconfort physique Douleurs physiques, blessures, traumatisme, difficultés, maladie Incapacité physique, décès Lourdes pertes de vie
Préjudice psychologique causé aux personnes Préjudice négligeable ou aucun préjudice raisonnable prévu Stress Détresse, traumatisme psychologique Maladie mentale ou physique Traumatisme psychologique généralisé
Perte financière pour des particuliers Préjudice négligeable ou aucun préjudice raisonnable prévu Stress ou inconfort Incidence sur la qualité de vie Sécurité financière compromise s. o.
Perte financière pour des entreprises canadiennes Préjudice négligeable ou aucun préjudice raisonnable prévu Incidence sur le rendement Réduction de la compétitivité Viabilité compromise s. o.
Perte financière pour le gouvernement du Canada Préjudice négligeable ou aucun préjudice raisonnable prévu Incidence sur le rendement des programmes Incidence sur les résultats des programmes Viabilité des programmes compromise Viabilité des programmes essentiels compromise
Préjudice causé à l’économie canadienne s. o. s. o. Incidence sur le rendement Perte de compétitivité à l’échelle internationale Secteurs économiques clés compromis
Préjudice causé à la réputation du Canada Préjudice négligeable ou aucun préjudice raisonnable prévu Perte de la confiance du public Embarras (au Canada ou à l’étranger) Relations fédérales-provinciales compromises Relations diplomatiques et internationales compromises
Perte de la souveraineté canadienne s. o. s. o. Entrave à l’établissement de politiques gouvernementales importantes Entraves à l’application efficace de la loi

Cessation des activités du gouvernement

 Perte de la souveraineté territoriale

Les niveaux de préjudice applicables aux activités opérationnelles peuvent être déjà documentés dans les produits livrables du ministère telles les analyses des répercussions sur les opérations, les évaluations des répercussions sur la vie privée, les énoncés de sensibilité, les évaluations des risques opérationnels et les évaluations des menaces et des risques. L’examen des instruments réglementaires, tels les lois, les politiques et les règlements, susceptibles de s’appliquer à des processus opérationnels ou à des biens d’information particuliers peut également s’avérer utile puisque la non-conformité à des exigences réglementaires, dans certaines circonstances, peut entraîner des pénalités ou des sanctions pouvant mener à un accroissement des préjudices. Les ministères peuvent se servir de cette information au moment d’évaluer les préjudices liés à une défaillance de leurs activités opérationnelles.

Il est possible que ces produits livrables représentent les niveaux de préjudice sur une échelle à trois niveaux (faible, moyen et élevé) plutôt que sur l’échelle à cinq niveaux prévue dans les lignes directrices du guide ITSG-33. Dans un tel cas, les ministères peuvent utiliser le Tableau 9 pour effectuer la conversion des niveaux de préjudice de leur échelle à trois niveaux à celle à cinq niveaux du guide ITSG 33. Ce tableau de conversion est dérivé du tableau élargi que vous trouverez dans la Méthodologie harmonisée d’évaluation des menaces et des risques [Référence 17].

Tableau 9 : Conversion des niveaux de préjudice d’une échelle de trois à cinq niveaux

Confidentialité – Intérêt non national (Protégé)

Échelle à trois niveaux Échelle à cinq niveaux
Très faible Faible Moyen Élevé Très élevé
Aucun préjudice prévu (Non classifié) X        
Faible – Préjudice prévu (Protégé A)   X      
Moyen – Préjudice grave prévu (Protégé B)     X    
Élevé – Préjudice extrêmement grave prévu (Protégé C)       X  

Confidentialité – Intérêt national (Classifié)

Échelle à trois niveaux Échelle à cinq niveaux
Très faible Faible Moyen Élevé Très élevé
Aucun préjudice prévu – Non classifié X        
Faible – Préjudice prévu (Confidentiel)     X    
Moyen – Préjudice grave prévu (Secret)       X  
Élevé – Préjudice exceptionnellement grave prévu (Très secret)         X

Intégrité et disponibilité

Échelle à trois niveaux Échelle à cinq niveaux
Très faible Faible Moyen Élevé Très élevé
Aucun préjudice prévu X        
Faible – Préjudice prévu Très faible ou faible, après une réévaluation      
Moyen – Préjudice grave prévu     X    
Élevé – Préjudice extrêmement grave prévu       Élevé ou très élevé, selon la réévaluation

Au cours de l’évaluation des préjudices, les praticiens de la sécurité doivent tenir compte de plusieurs facteurs susceptibles d’influer sur les résultats, incluant les suivants :

  • Regroupement – On peut attribuer un niveau de préjudice à chaque processus opérationnel et bien d’information individuel. Toutefois, le niveau d’un préjudice résultant de la compromission d’un ensemble de processus et de biens d’information, considérés globalement, peut être supérieur à celui attribué à chaque préjudice individuel;
  • Inférence – Dans certains cas, l’analyse de renseignements catégorisés à un niveau de sensibilité donné peut faire en sorte qu’un individu informé tire des conclusions de l’analyse et leur donnent suite sans se douter qu’il peut compromettre des renseignements plus sensibles. Par exemple, des dossiers de personnel catégorisés Protégé B aux fins de confidentialité peuvent contenir de l’information qui donne certaines indications sur le rôle de l’employé et, par le fait même, sur la mission ou la capacité opérationnelle de l’organisme d’attache – information qui, dans certaines circonstances, peut compromettre l’intérêt national;
  • Interdépendance – Les interdépendances font en sorte que la perte ou la dégradation d’un processus opérationnel et de son information peut influer sur les autres processus et biens d’information. Le but de l’analyse des interdépendances est de déterminer s’il est possible qu’un effet de cascade important résultant de la compromission d’un processus opérationnel ou d’une information ait une incidence sur un autre processus et une autre information. Comme dans le cas du regroupement mentionné précédemment, le niveau d’un préjudice résultant de la perte en cascade d’un élément peut être supérieur à celui attribué à n’importe lequel des éléments individuels. Les types d’interdépendance incluent les interdépendances matérielles (p. ex., le produit matériel d’une infrastructure utilisée par quelqu’un d’autre), géographiques (p. ex., un corridor commun) et logiques (p. ex., une dépendance associée à des marchés financiers).

Tel qu’il est indiqué dans la Figure 4, le résultat de cette étape est une liste, par processus opérationnel et bien d’information connexe, des préjudices prévus et des niveaux de préjudice sur le plan de la confidentialité, de l’intégrité et de la disponibilité. Aux fins d’uniformité à l’échelle des ministères, les praticiens de la sécurité doivent adopter un schéma de pointage commun. À titre indicatif, on recommande d’exprimer les catégories de sécurité en utilisant le format de notation suivant :

(Niveau Protégé/Classifié, Intégrité très faible/faible/moyenne/élevée/très élevée, Disponibilité très faible/faible/moyenne/élevée/très élevée).

6.4.3 Déterminer la catégorie de sécurité de l’activité opérationnelle

La troisième étape du processus de catégorisation de la sécurité consiste à déterminer la catégorie de sécurité de l’activité opérationnelle.

En situations normales, la catégorie de sécurité d’une activité opérationnelle doit exprimer, pour tous les processus opérationnels et biens d’information connexes, les niveaux de préjudice les plus élevés pour chacun des objectifs de sécurité. On peut attribuer à chaque élément individuel différents niveaux de préjudice pour un objectif de protection donné. Par exemple, une activité peut comporter un type d’information dont le niveau évalué de préjudice sur le plan de la confidentialité est faible et un autre type d’information dont le niveau est moyen pour le même objectif de sécurité (intérêt non national dans les deux cas). Ces valeurs individuelles sont importantes et doivent être documentées. Toutefois, la catégorie de sécurité de l’activité doit refléter le niveau de préjudice le plus élevé. Dans l’exemple précédent, la confidentialité de l’activité serait cotée Protégé B.

Quoi qu’il en soit, dans certaines circonstances, il faudra effectuer une analyse plus poussée pour déterminer la catégorie de sécurité la plus appropriée. Par exemple, les praticiens de la sécurité peuvent attribuer un niveau plus élevé que le niveau élevé actuel dans le cas d’un regroupement de menaces de compromission, ou d’une interdépendance avec un processus critique situé à l’extérieur du champ d’application d’une activité donnée.

Le résultat de cette étape est la catégorie de sécurité de l’activité opérationnelle, qui peut être exprimée suivant le même format de notation que celui utilisé pour les processus opérationnels et les biens d’information individuels.

6.4.4 Préparer le rapport sur la catégorisation de la sécurité

La quatrième étape du processus de catégorisation de la sécurité est la préparation du rapport sur la catégorisation de la sécurité.

Les praticiens de la sécurité doivent regrouper les résultats de l’évaluation des préjudices qui serviront à la production du rapport et appuieront deux processus subséquents (définition de la fonction de sécurité des TI et développement des profils de contrôle de sécurité ministériels). Le rapport sur la catégorisation de la sécurité doit inclure, pour chaque processus et bien d’information :

  • Une brève description;
  • Une description des préjudices prévus pour les menaces de compromission;
  • Les niveaux des préjudices prévus sur le plan de la confidentialité, de l’intégrité et de la disponibilité;
  • La justification de l’attribution des niveaux de préjudice.

6.5 Exemples

Le Tableau 10, le Tableau 11 et le Tableau 12 montrent des exemples simples qui aident à illustrer le processus de catégorisation de la sécurité des activités opérationnelles.

Tableau 10 : Catégorisation de la sécurité d’une activité de publication d’une campagne de vaccination

Processus opérationnel Biens d’information
Nom Description Nom Description
Préparer le matériel de sensibilisation Processus de développement de la documentation de sensibilisation à la campagne de vaccination. Information de sensibilisation à la campagne de vaccination Information non classifiée concernant la disponibilité du vaccin et ses avantages pour la santé des familles canadiennes.
Favoriser la sensibilisation Favoriser la sensibilisation à la campagne de vaccination en mettant la documentation de sensibilisation à la disposition des Canadiens. Information de sensibilisation à la campagne de vaccination Comme ci-dessus.
Exemple d’échec d’une activité opérationnelle Exemple de conséquences de l’échec Préjudices éventuels vraisemblables Niveau de préjudice
Modification malveillante de l’information publiée dans le cadre du programme. Les citoyens visés par la campagne prennent la mauvaise décision en raison de l’information erronée et de la non-disponibilité des renseignements nécessaires, et ne se font pas vacciner. Maladie physique
  • Confidentialité = Très faible (Non classifié)
  • Intégrité = Moyenne
  • Disponibilité = Moyenne

Catégorie de sécurité de l’activité = (Information non classifiée, Intégrité moyenne, Disponibilité moyenne)

Tableau 11 : Catégorisation de la sécurité d’une activité de paiement d’un programme de rénovation domiciliaire pour des personnes à mobilité réduite

Processus opérationnel Biens d’information
Nom Description Nom Description
Déterminer l’admissibilité Accepter les demandes de participation au programme et déterminer l’admissibilité des demandeurs aux prestations. Information sur le demandeur Information sur le demandeur cotée Protégé B; inclut le nom complet, l’adresse du domicile, le numéro de téléphone, la date de naissance, la citoyenneté, le NAS et l’information sur le compte bancaire utilisé pour le dépôt direct.
Information concernant la mobilité réduite Information médicale cotée Protégé B; décrit la nature de la mobilité réduite.
Information sur les prestations Montant autorisé de la prestation et calendrier des paiements.
Offre de versement des paiements par dépôt direct Émission des paiements par dépôt direct selon le calendrier Information sur les paiements Information sur les paiements cotée Protégé B; inclut le numéro du compte bancaire, la date du paiement et le montant du paiement.
Exemple d’échec d’une activité opérationnelle Exemple de conséquences de l’échec Préjudices éventuels vraisemblables Niveau de préjudice
Activité de paiement interrompue pendant plusieurs semaines. Les travaux requis de rénovation sont retardés pendant que les bénéficiaires attendent leur paiement.
  • Inconfort physique
  • Stress
 Disponibilité = Faible
Les prestations versées aux bénéficiaires sont inférieures à celles autorisées en raison d’erreurs de traitement. Les bénéficiaires doivent compenser leurs pertes financières en pigeant dans leurs économies. Perte financière causant un stress psychologique Intégrité = Faible
Les dossiers de bénéficiaires, qui incluent le NAS, la date de naissance et l’adresse postale, sont volés par des criminels spécialisés dans le vol d’identité. La vie privée des bénéficiaires a été violée et leur sécurité financière peut être menacée.
  • Pertes financières Incidence sur la qualité de vie
  • Détresse
 Confidentialité = Moyen (Protégé B)

Catégorie de sécurité de l’activité = (Information cotée Protégé B, Intégrité faible, Disponibilité faible)

Tableau 12 : Catégorisation de la sécurité d’une activité de gestion de déploiement de troupes

Processus opérationnel Biens d’information
Nom Description Nom Description
Collecte d’information Collecte de renseignement de sécurité de différentes sources Renseignement de sécurité Information concernant l’emplacement et les intentions des forces hostiles.
Exécution de l’analyse Analyse du renseignement de sécurité et détermination des cibles. Renseignement de sécurité Comme ci-dessus.
Information sur les cibles Information sur les cibles d’attaque, incluant la nationalité, les coordonnées et les capacités de défense.
Fournir les instructions de déploiement Communiquer les instructions de déploiement aux troupes sur le terrain. Information sur les cibles Comme ci-dessus.
Exemple d’échec d’une activité opérationnelle Exemple de conséquences de l’échec Préjudices éventuels vraisemblables Niveau de préjudice
Certains renseignements sur le déploiement sont interceptés par les forces hostiles. Les forces de combat s’exposent à une embuscade. Perte de vie Confidentialité = Élevée (Secret)
Les forces de combat ne reçoivent aucune information ou reçoivent de l’information inexacte concernant une frappe contre des cibles civiles. Les forces prennent la mauvaise décision ou ignorent qu’une attaque est imminente et sont incapables de protéger les civils. Perte de vie
  • Intégrité = Élevée
  • Disponibilité = Élevée

Catégorie de sécurité de l’activité = (Information cotée Secret, Intégrité élevée, Disponibilité élevée)

7 Contrôles de sécurité communs potentiels

Le Tableau 13 inclut la liste des contrôles de sécurité, tirée du Catalogue des contrôles de sécurité de l’Annexe 3 du guide ITSG-33 [Référence 5], que les organisations peuvent envisager d’utiliser, en tout ou en partie, comme contrôles de sécurité communs. Cette liste n’est pas exhaustive et d’autres contrôles peuvent être retenus comme contrôles de sécurité communs (consulter les lignes directrices pertinentes à la section 4.2.7.3)

Les profils à l’Annexe 4 du guide ITSG-33 [Référence 15] incluent d’autres propositions de contrôles de sécurité communs qui peuvent être déployés et exploités par la fonction de sécurité des TI du ministère, par des groupes responsables des opérations de TI, et par différents autres groupes pour soutenir les systèmes d’information ministériels (consulter les lignes directrices pertinentes à la section 4.3).

Tableau 13 : Contrôles de sécurité communs potentiels

Classe Contrôles de sécurité techniques

Numéro Famille Titre
AC-1 Contrôle d’accès Politiques et procédures de contrôle d’accès
AC-2 Gestion des comptes
AC-17 Accès à distance
AC-18 Accès sans fil
AU-1 Vérification et responsabilisation Politiques et procédures de vérification et de responsabilisation
AU-6 Examen, analyse et rapports de vérification
AU-11 Conservation des enregistrements de vérification
AU-13 Surveillance de la divulgation d’information
IA-1 Identification et authentification Politiques et procédures d’identification et d’authentification
IA-4 Gestion des identificateurs
IA-5 Gestion des authentifiants
SC-1 Protection des systèmes et des communications Politiques et procédures de protection des systèmes et des communications
SC-12 Établissement et gestion des clés cryptographiques
SC-17 Certificats d’infrastructure à clé publique

Classe Contrôles de sécurité opérationnels

Numéro Famille Titre
AT-1 Formation et sensibilisation Politiques et procédures de formation et de sensibilisation à la sécurité
AT-2 Sensibilisation à la sécurité
AT-3 Formation à la sécurité
AT-4 Dossiers de formation à la sécurité
AT-5 Contacts avec les groupes et associations de sécurité
CM-1 Gestion des configurations Politiques et procédures de gestion des configurations
CM-2 Configuration de références
CM-3 Contrôle des changements de configuration
CM-4 Analyse des répercussions sur la sécurité
CM-5 Restrictions d’accès associées aux changements
CM-6 Paramètres de configuration
CM-7 Fonctionnalité minimale
CM-8 Inventaire des composants des systèmes d’information
CM-9 Plan de gestion des configurations
CP-1 Planification d’urgence Politiques et procédures de planification d’urgence
CP-2 Plan d’urgence
CP-3 Formation en mesures d’urgence
CP-4 Tests et exercices relatifs au plan d’urgence
CP-6 Site de stockage de secours
CP-7 Site de traitement de secours
CP-8 Services de télécommunications
CP-9 Sauvegarde des systèmes d’information
CP-10 Reprise et reconstitution du système d’information
IR-1 Intervention en cas d’incident Politiques et procédures d’intervention en cas d’incident
IR-2 Formation sur les interventions en cas d’incident
IR-3 Tests et exercices relatifs aux interventions en cas d’incident
IR-4 Traitement des incidents
IR-5 Surveillance des incidents
IR-6 Signalement des incidents
IR-7 Assistance en cas d’incident
IR-8 Plan d’intervention en cas d’incident
MA-1 Maintenance Politiques et procédures de maintenance des systèmes
MA-2 Maintenance contrôlée
MA-3 Outils de maintenance
MA-4 Télémaintenance
MA-5 Personnel de maintenance
MA-6 Maintenance opportune
MP-1 Protection des supports Politiques et procédures de protection des supports
PE-1 Protection physique et environnementale Politiques et procédures de protection physique et environnementale
PE-2 Autorisations d’accès physique
PE-3 Contrôle d’accès physique
PE-4 Contrôle d’accès aux supports de transmission
PE-5 Contrôle d’accès aux dispositifs de sortie
PE-6 Surveillance de l’accès physique
PE-7 Contrôle des visiteurs
PE-8 Registre des accès
PE-9 Équipement et câblage d’alimentation
PE-10 Arrêt d’urgence
PE-11 Alimentation d’urgence
PE-12 Éclairage de sécurité
PE-13 Protections contre l’incendie
PE-14 Contrôle de la température et de l’humidité
PE-15 Protection contre les dégâts d’eau
PE-16 Livraison et retrait
PE-17 Autres lieux de travail
PE-18 Emplacement des composants du système d’information
PE-19 Fuites d’information
PS-1 Sécurité du personnel Politiques et procédures de sécurité du personnel
PS-2 Catégorisation des postes
PS-3 Enquête de sécurité sur le personnel
PS-4 Cessation d’emploi
PS-5 Transfert du personnel
PS-6 Ententes d’accès
PS-7 Sécurité du personnel de tierces parties
PS-8 Sanctions imposées au personnel
SI-1 Intégrité de l’information et des systèmes Politiques et procédures liées à l’intégrité de l’information et des systèmes
SI-2 Corrections des défauts
SI-3 Protection contre les codes malveillants
SI-4 Surveillance des systèmes d’information
SI-5 Alertes, avis et directives de sécurité
SI-8 Protection antipourriel

Classe Contrôles de sécurité de gestion

Numéro Famille Titre
CA-1 Évaluation et autorisation de sécurité Politiques et procédures d’évaluation et d’autorisation de sécurité
CA-2 Évaluations de la sécurité
CA-6 Autorisation de sécurité
CA-7 Surveillance continue
PL-1 Planification Politiques et procédures de planification de la sécurité
RA-1 Évaluation des risques Politiques et procédures d’évaluation des risques
RA-2 Catégorisation de la sécurité
RA-3 Évaluation des risques
RA-5 Analyse des vulnérabilités
SA-1 Acquisition des systèmes et des services Politiques et procédures d’acquisition des systèmes et des services
SA-2 Affectation des ressources
SA-3 Soutien du cycle de vie
SA-4 Acquisitions
SA-9 Services de système d’information externes

8 References

[Référence 1]
Secrétariat du Conseil du Trésor du Canada. Norme opérationnelle de sécurité : Gestion de la sécurité des technologies de l’information (GSTI). 31 mai 2004.
[Référence 2]
Centre de la sécurité des télécommunications Canada. La gestion des risques liés à la sécurité des TI : Une méthode axée sur le cycle de vie – Activités de gestion des risques liés à la sécurité des systèmes d’information. ITSG-33, Annexe 2. 1er novembre 2012.
[Référence 3]
Secrétariat du Conseil du Trésor du Canada. Politique sur la sécurité du gouvernement. 1er juillet 2009.
[Référence 4]
Centre de la sécurité des télécommunications Canada. La gestion des risques liés à la sécurité des TI : Une méthode axée sur le cycle de vie – Glossaire. ITSG-33, Annexe 5. 1er novembre 2012.
[Référence 5]
Centre de la sécurité des télécommunications Canada. La gestion des risques liés à la sécurité des TI : Une méthode axée sur le cycle de vie – Catalogue des contrôles de sécurité. ITSG-33, Annexe 3. 1er novembre 2012.
[Référence 6]
Secrétariat du Conseil du Trésor du Canada. Cadre de gestion des risques. 19 août 2010.
[Référence 7]
Secrétariat du Conseil du Trésor du Canada. Directive sur la gestion de la sécurité ministérielle. 1er juillet 2009.
[Référence 8]
Organisation internationale de normalisation (ISO)/Commission électrotechnique internationale (CEI). Information Technology – Security Techniques – Information Security Management Systems – Requirements. No de référence ISO/CEI 27001:2005. Octobre 2005.
[Référence 9]
Organisation internationale de normalisation (ISO)/Commission électrotechnique internationale (CEI). Information Technology – Security Techniques – Information Security Management Systems – Measurements. No de référence ISO/CEI 27004:2009. Décembre 2009.
[Référence 10]
Centre de la sécurité des télécommunications Canada. Conseils en matière de sécurité des technologies de l’information (ITSG). Établissement des zones de sécurité dans un réseau – Considérations de conception relatives au positionnement des services dans les zones. ITSG-38. Mai 2009.
[Référence 11]
Centre de la sécurité des télécommunications Canada. Conseils en matière de sécurité des technologies de l’information (ITSG). Exigences de base en matière de sécurité pour les zones de sécurité de réseau au sein du gouvernement du Canada. ITSG-22. Juin 2007.
[Référence 12]
John Sherwood, Andy Clark, David Lynas. Enterprise Security Architecture: A Business-Driven Approach. San Francisco, CMP Books, 2005.
[Référence 13]
National Institute of Standards and Technology. Computer Security. Engineering Principles for Information Technology Security: A Baseline for Achieving Security. Special Publication 800-27, révision A. Juin 2004.
[Référence 14]
National Institute of Standards and Technology. Generally Accepted Principles and Practices for Security Information Technology Systems. Special Publication 800-14. Septembre 1996.
[Référence 15]
Centre de la sécurité des télécommunications Canada. La gestion des risques liés à la sécurité des TI : Une méthode axée sur le cycle de vie – Profils de contrôle de sécurité. ITSG-33, Annexe 4. 1er novembre 2012.
[Référence 16]
Conseil du Trésor du Canada. Programme de transformation opérationnelle (PTO). MRSG – Patrons de référence de services. Septembre 2004.
[Référence 17]
Centre de la sécurité des télécommunications Canada et Gendarmerie royale du Canada. Méthodologie harmonisée d’évaluation des menaces et des risques (EMR). 23 octobre 2007.

Remarques

Date de modification :