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 4A - Profil 1 - (Protégé B / Intégrité moyenne / Disponibilité moyenne) (ITSG-33)

De : Centre canadien pour la cybersécurité

 

Format de rechange : Annexe 4A - Profil 1 - (Protégé B / Intégrité moyenne / Disponibilité moyenne) (ITSG-33) (PDF, 1.88 Mo)

Proposition de profil de contrôle de sécurité organisationnel pour les ministères et les organismes qui doivent protéger des activités opérationnelles de catégorie - Protégé B / Intégrité moyenne / Disponibilité moyenne

Janvier 2015

 

Table des matières

Liste des tableaux

Liste des abréviations et des sigles

ASM
Agent de sécurité du ministère
CC
Critères communs
CST
Centre de la sécurité des télécommunications
GC
Governement du Canada
ITSG
Conseils en matière de sécurité des technologies de l’information
NAS
Niveau d'assurance de la sécurité
PASSI
Processus d’application de la sécurité dans les systèmes d’information
PDARR
Prévention, Détection, Analyse, Réaction, Reprise
PVMC
Programme de validation des modules cryptographiques
SCT
Secrétariat du Conseil du Trésor du Canada
TI
Technologie de l'information

Avant-propos

L’Annexe 4A – Profil 1 (Protégé B / Intégrité moyenne / Disponibilité moyenne) 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 (CST).

Les propositions de modification devraient être envoyées au représentant des Services à la clientèle de la Sécurité des TI du CST 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 CST.

Pour de plus amples renseignements, prière de communiquer avec les Services à la clientèle de la Sécurité des TI du CST, 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 20 janvier 2015.

Signé initialement par

Toni Moffa

Chef adjointe, Sécurité des TI

Résumé

La présente annexe fait partie de la suite de documents La gestion des risques liés à la sécurité des TI : Une méthode axée sur le cycle de vie (ITSG-33) de la série Conseils en matière de sécurité des technologies de l’information publiée par le Centre de la sécurité des télécommunications (CST).

L’annexe propose une sélection de contrôles et d’améliorations de sécurité collectivement désignés sous le nom de profil de contrôle de sécurité. Les autorités responsables de la sécurité ministérielle peuvent utiliser ce profil comme document de référence pour créer des profils ministériels qu’elles peuvent retenir pour protéger la confidentialité, l’intégrité et la disponibilité des biens de technologie de l’information (TI) contre les menaces susceptibles de causer des préjudices aux activités opérationnelles de la catégorie Protégé B / Intégrité moyenne / Disponibilité moyenne. Le profil a été élaboré à partir de l’Annexe 3A du guide ITSG-33, Catalogue des contrôles de sécurité [Référence 1].

Les contrôles de sécurité dans ce profil sont un point de départ et doivent être adaptés au contexte (opérationnel, technique, de menace et de risque) des activités opérationnelles et des systèmes d’information de chaque ministère. La sélection des contrôles est basée sur les pratiques exemplaires gouvernementales et de l’industrie et, sous réserve de certaines hypothèses de menace, est dérivée de l’analyse du CST de l’environnement de menace avec lequel doivent composer les systèmes d’information dans le contexte opérationnel décrit dans le présent document.

Ce profil, créé comme outil, contribue aux efforts déployés par les praticiens de la sécurité pour assurer la protection des systèmes d’information en conformité avec les lois du Gouvernement du Canada (GC) et les politiques, les directives et les normes du Secrétariat du Conseil du Trésor du Canada (SCT).

Il incombe aux autorités responsables de la sécurité ministérielle, lorsqu’elles élaborent leurs profils de contrôle de sécurité, de s’assurer que ceux-ci sont conformes à l’ensemble des exigences en matière de sécurité des règlements du GC et des instruments de politique du SCT qui concernent leurs activités opérationnelles, et à toute autre obligation contractuelle.

1 Introduction

1.1 Objet

La présente annexe fait partie de la suite de documents La gestion des risques liés à la sécurité des TI : Une méthode axée sur le cycle de vie (ITSG-33) de la série Conseils en matière de sécurité des technologies de l’information publiée par le Centre de la sécurité des télécommunications (CST).

L’annexe propose une sélection de contrôles et d’améliorations de sécurité collectivement désignés sous le nom de profil de contrôle de sécurité. Les autorités responsables de la sécurité ministérielle peuvent utiliser ce profil comme document de référence pour créer des profils ministériels qu’elles peuvent retenir pour protéger la confidentialité, l’intégrité et la disponibilité des biens de technologie de l’information (TI) contre les menaces susceptibles de causer des préjudices aux activités opérationnelles de la catégorie Protégé B / Intégrité moyenne / Disponibilité moyenne. Le profil a été élaboré à partir de l’Annexe 3A du guide ITSG-33, Catalogue des contrôles de sécurité [Référence 1].

Les profils de contrôle des ministères permettent de s’assurer que la fonction de sécurité des TI d’un programme de sécurité ministérielle effectue ce qui suit :

  1. mener les activités appropriées de gestion des risques liés à la sécurité des TI;
  2. appuyer de manière adéquate les équipes de projet TI.

1.2 Portée et champ d'application

Les contrôles de sécurité dans ce profil sont un point de départ et doivent être adaptés au contexte (opérationnel, technique, de menace et de risque) des activités opérationnelles et des systèmes d’information (détaillés à la section 2) de chaque ministèreNote de bas de page 1. La sélection des contrôles est basée sur les pratiques exemplaires gouvernementales et de l’industrie et, sous réserve de certaines hypothèses de menace, est dérivée de l’analyse du CST de l’environnement de menace avec lequel doivent composer les systèmes d’information dans le contexte opérationnel décrit dans le présent document.

Le profil ne fournit aucun détail concernant la mise en œuvre ou l’utilisation des contrôles de sécurité au sein d’un ministère ou dans ses systèmes d’information. Le guide ITSG-33, à l’Annexe 1 – Activités de gestion des risques liés à la sécurité des TI [Référence 2] et à l’Annexe 2 – Activités de gestion des risques liés à la sécurité des systèmes d’information [Référence 3], formule des directives plus détaillées à cet égard. La liste à jour des guides supplémentaires est disponible dans le site Web du CST.

1.3 Auditoire

La présente annexe vise plus particulièrement :

  • Les agents de sécurité du ministère (ASM), les coordonnateurs de la sécurité des TI et les praticiens de la sécurité qui appuient les activités de gestion des risques liés à la sécurité des TI;
  • Les personnes qui participent à la définition, à la conception, au développement, à l’installation et à l’exploitation des systèmes d’information et plus particulièrement les autorisateurs, les gestionnaires de projet, les architectes de sécurité, les praticiens de la sécurité, les évaluateurs de la sécurité et les membres des groupes responsables des opérations de TI.

1.4 Structure de la publication

La présente annexe fait partie d’une série de documents sur la gestion des risques liés à la sécurité des TI au sein du GC. Les autres documents de la série 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 1 – Activités de gestion des risques liés à la sécurité des TI;
  • ITSG-33, Annexe 2 – Activités de gestion des risques liés à la sécurité des systèmes d’information;
  • ITSG-33, Annexe 3A – Catalogue des contrôles de sécurité;
  • ITSG-33, Annexe 4A – Profil 3 – SECRET / Intégrité moyenne / Disponibilité moyenne;;
  • ITSG-33, Annexe 5 – Glossaire

1.5 Définitions

doit
Indique qu’un énoncé représente une exigence obligatoire
recommandé(e)
Ce terme indique un objectif à atteindre ou une alternative suggérée. Il peut exister des raisons acceptables dans des situations particulières pour ignorer un énoncé, par contre les conséquences doivent être bien comprises et soupesées avant de choisir une alternative différente.

Pour obtenir les définitions des principaux termes utilisés dans la présente annexe, prière de consulter l’annexe 5 du guide ITSG-33 [Référence 4].

2 Contexte et hypothèses

Cette section caractérise le contexte opérationnel, le contexte technique, le contexte de menace et les approches de sécurité auxquels convient le profil de contrôle de sécurité présenté. Lorsqu’elles choisissent ce profil comme point de départ, les autorités responsables de la sécurité ministérielle (appuyées par les praticiens de la sécurité) devront l’adapter aux besoins de leur ministère et à ses activités opérationnelles de sorte à créer des profils de contrôle de sécurité sur mesure.

2.1 Contexte opérationnel

Ce profil de contrôle de sécurité convient aux ministères qui utilisent des systèmes d’information pour soutenir une vaste gamme d’activités opérationnelles de moyenne sensibilité et criticité qui traitent de l’information cotée Protégé B particulièrement sensible. Ces activités peuvent inclure, sans s’y limiter, les activités liées à la prestation de services sociaux, à la fiscalité, aux fonctions du receveur général, aux services financiers et administratifs ministériels, aux ressources humaines, à la rémunération et aux avantages sociaux et à l’offre de services de TI communs et partagés à une vaste clientèle.

Les ministères qui optent pour ce profil mènent des activités opérationnelles qui traitent des données cotées Protégé B exigeant une disponibilité et une intégrité de niveau moyen, comme il est défini dans le guide ITSG-33, Annexe 1, section 6 [Référence 2]. Ces activités possèdent les caractéristiques générales suivantes :

  • Confidentialité – On peut raisonnablement s’attendre à ce que toute compromission de la confidentialité de cette information Protégé B cause un préjudice de niveau moyen aux intérêts non nationaux;
  • Intégrité – On peut raisonnablement s’attendre à ce que toute compromission de l’intégrité des biens de TINote de bas de page 2 connexes cause un préjudice de niveau moyen aux intérêts non nationaux;
  • Disponibilité – On peut raisonnablement s’attendre à ce que toute compromission de la disponibilité des biens de TI connexes cause un préjudice de niveau moyen aux intérêts non nationaux;
  • Risques résiduels acceptablesNote de bas de page 3 – Les activités opérationnelles requièrent le soutien d’un système d’information présentant au maximum un niveau faible de risque résiduel relativement aux objectifs de sécurité liés à la confidentialité, à l’intégrité et à la disponibilité.

Le Tableau 1 caractérise, de manière plus détaillée, les contextes opérationnels convenables au moyen des objectifs de confidentialité, d’intégrité et de disponibilité. Il comprend également des exemples de conséquences de compromission, de processus opérationnels et d’information connexe.

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

Ce profil, conçu pour servir d’outil, contribue aux efforts que déploient les praticiens de la sécurité pour assurer la protection des systèmes d’information en conformité avec les lois du GC et les politiques, les directives et les normes du Secrétariat du Conseil du Trésor du Canada (SCT).

Il incombe aux autorités responsables de la sécurité ministérielle, au moment d’élaborer des profils de contrôle de sécurité, de s’assurer que ceux-ci sont conformes à l’ensemble des exigences en matière de sécurité des règlements du GC et des instruments de politique du SCT qui concernent leurs activités opérationnelles, et à toute autre obligation contractuelle.

Tableau 1: Caractérisation des contextes opérationnels applicables

Caractéristiques Descriptions et exemples
Objectif de confidentialité Les activités opérationnelles concernent le traitement, la transmission et le stockage d’information cotée Protégé B qui doit être protégée adéquatement contre toute compromission.
Objectifs d’intégrité et de disponibilité On évalue au niveau moyen la gravité de tout préjudice potentiel lié à une compromission de l’intégrité et de la disponibilité des biens de TI. L’intégrité et la disponibilité de ces biens doivent donc être protégées adéquatement contre toute compromission.
Risques résiduels acceptables Les activités opérationnelles doivent être prises en charge par un système d’information présentant, au maximum, des risques résiduels faibles pour les objectifs de confidentialité, d’intégrité et de disponibilité.
Exemples de préjudices
  • Agitation ou désordre civil grave;
  • Douleur physique, blessure, traumatisme, difficulté ou maladie touchant des personnes;
  • Détresse psychologique ou traumatisme causés à des personnes;
  • Perte financière ayant une incidence sur la qualité de vie des personnes;
  • Perte financière qui réduit la compétitivité des entreprises canadiennes;
  • Incapacité à mener des enquêtes criminelles ou autres obstacles à l’application efficace de la loi;
  • Perturbation des activités opérationnelles gouvernementales pouvant causer de graves inconvénients aux Canadiens.
Exemples de processus opérationnels
  • Paiements de prestations, à des Canadiens, dont la perturbation et le retard peuvent causer des dommages psychologiques
  • Services policiers dont la perturbation peut causer des blessures physiques aux personnes ou mener à une agitation ou un désordre civil
  • Processus financiers ou de production de rapports dont la perturbation peut mener à des pertes financières graves pour les personnes ou les entreprises canadiennes
  • Traitement d’opérations financières et de paiements importants
  • Processus liés aux dossiers médicaux
Exemples de biens d’information
  • Renseignements médicaux et financiers personnels
  • Renseignements de l’impôt sur le revenu des particuliers
  • Opérations financières et paiements importants
  • Renseignements pouvant servir à des fins criminelles (p. ex., fausse identité ou usurpation d'identité)
  • Renseignements recueillis dans le cadre d’une enquête criminelle
  • Renseignements concernant l’admissibilité de personnes à des avantages sociaux

2.2 Contexte technique

Ce profil de contrôle de sécurité convient aux ministères qui exploitent une vaste gamme d’environnements de TI. De manière générale, les systèmes d’information ministériels visés par ce profil peuvent être catégorisés selon leurs objectifs, comme suit :

  • Systèmes qui offrent des services en ligne (p. ex., sur Internet) aux bénéficiaires de programmes ou de service ministériels;
  • Systèmes qui offrent des services de soutien opérationnels aux employés des ministères ou aux fournisseurs (p. ex., réseau d’entreprise);
  • Systèmes qui offrent des services communs ou partagés à l’intérieur et à l’extérieur des ministères.

On présume que ces systèmes seront connectés aux autres ministères et à Internet.

2.3 Contexte de menace

Ce profil de contrôle de sécurité a été élaboré pour protéger les activités opérationnelles contre les menaces liées aux TI qui touchent les contextes tant opérationnels que techniques.

En plus d’assurer la protection des activités, le profil vise à protéger les systèmes. Cette approche est essentielle puisque les menaces peuvent cibler les biens de TI du GC aux seules fins de compromettre les composants techniques et de tirer avantage de leurs ressources, quel que soit le type d’activité opérationnelle prise en charge.

Par exemple, plusieurs attaquants ne sont intéressés ni par les renseignements du GC, ni par la capacité de perturber les activités opérationnelles du gouvernement. Au contraire, ils ne visent qu’à compromettre les systèmes d’information du GC afin de commettre un acte criminel, notamment stocker des données illégales (comme des images ou des films) et les échanger clandestinement avec d’autres criminels, mener des attaques par déni de service contre des sites Web commerciaux, extorquer de l’argent, distribuer des pourriels et infecter les systèmes d’information du GC avec des programmes malveillants.

L’information sur les menaces qui a été analysée provient de plusieurs sources, y compris les rapports d’incidents et de menaces des ministères et du SCT, et s’ajoute aux analyses du CST. Ce profil, lorsqu’il est appliqué correctement (voir la section 4), permet d’atténuer les risques d’exposition aux agents de menaces délibérées des catégories Md1 à Md4, ainsi qu’aux menaces accidentelles et aux risques naturels des catégories Ma1 à Ma3, tels qu’ils sont définis dans le Tableau 2 et Tableau 3. Le profil sera mis à jour au fil de l’évolution des capacités des agents de menace afin d’ajuster de manière appropriée la sélection de contrôles et d’atténuer l’incidence de ces nouvelles capacités.

Avant de sélectionner et d’adapter le profil, les ministères doivent s’assurer que le contexte de menace correspond à leur environnement. Selon le contexte de menace, ils devront éventuellement entreprendre des travaux importants d’adaptation ou, dans le cas où le contexte de menace est très différent, sélectionner un autre profil, le cas échéant. S’il n’existe aucun profil approprié, les ministères devront créer leur propre profil en respectant les contrôles documentés dans le document ITSG-33, Annexe 3A, Catalogue des contrôles de sécurité [Référence 1]. L’Annexe 1 du guide ITSG-33 [Référence 2] renferme plus de détails sur la création des profils et les évaluations ministérielles de menaces.

Tableau 2: Catégories de menace délibérée applicables

Catégorie de menace Description de l'agent de menace Exemples de capacités croissantes des agents de menace
Md1 Attaquant non malveillant (p. ex., navigation, modification et destruction d’information interdites non malveillantes dues à un manque de formation, de sensibilisation ou d’attention)
  • Capacités de base de l’utilisateur d’accéder aux systèmes d’information et au contenu.
Md2 Attaquant occasionnel et passif possédant un minimum de ressources et disposé à prendre de petits risques (p. ex., écoute clandestine, pirates ados).
  • Exécution d’un scanneur de vulnérabilité accessible au public
  • Exécution de scripts d’attaque de serveurs
  • Tentatives de suppression aléatoire de fichiers système
  • Modification des paramètres de fichiers de configuration
Md3 Attaquant possédant un minimum de ressources et disposé à prendre des risques importants (p. ex., pirates peu sophistiqués).
  • Utilisation d’outils de piratage accessibles au public pour effectuer différents exploits
  • Employés qui installent des chevaux de Troie et des enregistreurs de frappe dans les systèmes non protégés
  • Utilisation d’attaques par hameçonnage simples pour compromettre les cibles avec du maliciel
  • Exécution de programmes dans le but de faire planter les ordinateurs et les applications
Md4 Attaquant sophistiqué possédant des ressources moyennes et disposé à prendre de petits risques (p. ex., crime organisé, pirates sophistiqués, organisations internationales).
  • Utilisation experte d’outils de piratage accessibles au public, incluant les attaques du jour zéro
  • Capacité de créer ses propres outils d’attaque dans le logiciel
  • Attaques par ingénierie sociale de base
  • Capacité d’assemblage de matériel avec des composants grand public pour faciliter les attaques
  • Attaques par hameçonnage pour accéder aux cartes de crédit ou aux renseignements personnels

Tableau 3: Catégories de menace accidentelle et de risque naturel applicables

Catégorie de menace Ampleur des événements
Ma1
  • Événements accidentels mineurs (p. ex., trébucher sur un câble d’alimentation, entrer des données erronées)
Ma2
  • Événements accidentels moyens (p. ex., rendre un serveur inutilisable, corrompre une base de données, divulguer de l’information à une mauvaise personne ou organisation)
  • Pannes matérielles ou logicielles mineures (p. ex., panne de disque dur)
  • Pannes mécaniques mineures (p. ex., panne de courant dans une section d’une installation)
  • Risques naturels mineurs (p. ex., inondation locale ou tremblement de terre qui compromettent une partie d’une installation)
Ma3
  • Événements involontaires ou accidentels graves (p. ex., sectionnement des câbles de télécommunications ou d’alimentation d’une installation, incendie dans l’installation, compromission d’information à grande échelle)
  • Pannes mécaniques moyennes (p. ex., panne de courant prolongée dans une installation)
  • Risques naturels moyens (p. ex., inondation locale ou tremblement de terre qui compromettent une installation)

2.4 Approches de sécurité

En plus des contextes opérationnels, techniques et de menace documentés dans les sections précédentes, la sélection de contrôles de sécurité, documentée à la section 4, a été également influencée par le choix de pratiques exemplaires d’ingénierie de sécurité utilisées pour la mise en œuvre de systèmes d’information fiables. Ce profil vise à répondre aux besoins en matière de sécurité de TI d’une vaste gamme d’activités opérationnelles, du travail de bureau quotidien en passant par les applications de prestation de services aux citoyens jusqu’au soutien de l’infrastructure des services communs. Pour protéger les activités opérationnelles, il faut adopter des approches de sécurité qui, à tout le moins, appliquent les pratiques exemplaires principales suivantes en matière de technique de sécurité :

  • Défense en profondeur : utilisation collaborative des contrôles de sécurité techniques, opérationnels (incluant la sécurité du personnel et la sécurité physique) et de gestion pour atténuer les risques (p. ex., contrôles d’accès techniques pour protéger les bases de données sensibles et sécurité physique supplémentaire pour empêcher le personnel non autorisé d’accéder physiquement aux serveurs de base de données);
  • Droit d’accès minimal : attribution aux utilisateurs du droit d’accès minimal nécessaire à l’exécution de leurs tâches (p. ex., exécution des tâches quotidiennes avec des comptes d’utilisateur à usage restreint et non avec des comptes administratifs);
  • Prévention, détection, analyse, réaction et reprise (PDARR) : cette approche permet de veiller à la détection et au confinement des attaques réussies, à la restauration des biens de TI à un état sûr et authentique, ainsi qu’à la documentation et à l’utilisation des leçons apprises pour améliorer la posture de sécurité des systèmes d’information;
  • Sécurité par couches : permet de s’assurer que les différentes couches d’un système d’information (applications, bases de données, plates-formes, intergiciels et communications) sont protégées de manière adéquate. Cette approche réduit le risque qu’une faiblesse d’une partie du système soit exploitée pour contourner les mesures de protection des autres parties (p. ex., attaques par injection SQL de la couche application pour contourner les mécanismes de protection de frontières de la couche réseau).

Le vaste champ d’application de ce profil ne se prête pas facilement à l’utilisation d’un ensemble d’approches de sécurité dont les principales mesures de protection s’appuient sur un contrôle strict des frontières, une forte sécurité du personnel et une forte sécurité physique (cette approche pourrait éventuellement utiliser des contrôles de sécurité internes moins stricts). Le profil propose toutefois un ensemble équilibré de contrôles pour réduire le risque que des éléments internes compromis d’un système soient utilisés pour compromettre facilement d’autres éléments. Le profil propose également des contrôles qui permettent la détection, l’intervention et la reprise en douceur des activités à la suite d’incidents de sécurité. Plusieurs de ces contrôles sont des contrôles opérationnels que tout groupe expérimenté responsable des opérations de TI devrait instaurer, non seulement aux fins de sécurité, mais également pour assurer l’efficacité et la rentabilité de la gestion quotidienne des systèmes d’information.

Nota : Bien que la sélection des contrôles soit plutôt subjective, nous avons fait le maximum pour inclure des contrôles qui atténuent les menaces réelles et qui peuvent être mis en œuvre au moyen de produits commerciaux. Les contrôles qui offrent des capacités spécialisées ou évoluées non requises par l’ensemble des systèmes ont été exclus du profil suggéré. Nous avons en plus tout mis en œuvre pour établir un juste équilibre entre la convivialité et la sécurité.

2.4.1 Relations entre les contrôles de sécurité et les objectifs de confidentialité, d’intégrité et de disponibilité

Les contrôles de sécurité sélectionnés pour ce profil visent à atténuer de manière appropriée les menaces susceptibles de compromettre la confidentialité, l’intégrité ou la disponibilité des biens de TI utilisés pour soutenir les activités opérationnelles. Le profil ne documente pas la mise en correspondance exacte des contrôles et des objectifs spécifiques qu’ils visent à atteindre. Certains contrôles sont associés plus clairement à un objectif particulier (p. ex., le contrôle CP-7, Site de traitement de secours, est associé à un objectif de disponibilité). Toutefois, la majorité des contrôles visent plus d’un objectif. Par exemple, la plupart des contrôles de la famille « Contrôle d’accès » visent directement ou indirectement les trois objectifs de confidentialité, d’intégrité et de disponibilité des biens de TI. L’application adéquate du contrôle d’accès permet d’atténuer les situations de compromission où un agent de menace :

  • exfiltre des documents sensibles (objectif de confidentialité);
  • modifie des documents ou des enregistrements de base de données (objectifs d’intégrité et, habituellement, de disponibilité);
  • trafique une application administrative pour nuire à son bon fonctionnement (objectifs d’intégrité et, éventuellement, de disponibilité);
  • supprime des enregistrements d’une base de données (objectif de disponibilité);
  • altère une application administrative pour la rendre non fonctionnelle (objectif de disponibilité).

L’adaptation de ce profil pour répondre aux besoins ministériels ou opérationnels doit tenir compte des relations complexes et subtiles entre la protection accordée par les contrôles de sécurité et les trois objectifs de sécurité que les contrôles de sécurité visent habituellement à atteindre.

3 Directive pour une mise en œuvre adéquate

3.1 Assurance de la sécurité

Les contrôles de sécurité doivent être mis en œuvre d’une manière proportionnée aux menaces et aux préjudices éventuels. Ce profil a été élaboré en tenant compte de certaines hypothèses énoncées à la section 2. De ce fait, comme le stipule cette section, la mise en œuvre des contrôles de sécurité exige un niveau moyen d’effort et de diligence afin de s’assurer que le système qui appuie les activités opérationnelles présente au plus des risques résiduels de niveau faible. Toutefois, si les menaces et les préjudices associés à certains contrôles sont jugés plus importants (p. ex., le contrôle d’accès aux bases de données sensibles), il faut alors ajuster la façon de les mettre en œuvre.

Pour satisfaire aux exigences des contrôles de sécurité documentés dans ce profil, les ministères doivent définir le niveau d’effort qui devra être consacré à l’élaboration, à la documentation et à l’évaluation de leur mise en œuvre.

L’Annexe 1 du guide ITSG-33 [Référence 2] décrit les activités proposées pour la mise en place ou la mise à jour des contrôles qui concernent la gestion des risques liés à la sécurité des TI et de ceux qui ne sont pas déployés dans les systèmes. Le document ne donne aucune directive quant au niveau d’effort qu’il faut déployer pour la mise en œuvre des contrôles de sécurité communs (p. ex., gestion des incidents, évaluations des risques, programme de sélection du personnel, programme de sécurité physique). Le SCT fournit des directives sur l’établissement de pratiques de gestion bien établies et produit des outils d’évaluation pour mesurer le niveau de maturité actuel de ces pratiques.

L’Annexe 2 du guide ITSG-33 [Référence 3] propose et décrit un processus d’application de la sécurité dans les systèmes d’information. Ce processus permet de concevoir, de développer, de tester, d’installer et d’exploiter de manière plus rentable des systèmes fiables qui répondent aux besoins opérationnels en matière de sécurité. L’annexe 2 du guide ITSG-33 [Référence 3] inclut à l’intention des gestionnaires de projet TI, des praticiens et des évaluateurs de la sécurité et des autorisateurs des directives sur le niveau d’effort que requièrent les travaux d’ingénierie de sécurité et les tâches d’évaluation pour s’assurer que les mesures de sécurité des TI mises en œuvre dans les systèmes d’information répondent aux objectifs du profil.

Dans le cas des contrôles de sécurité intégrés aux systèmes, le niveau d’effort approprié que requièrent les travaux d’ingénierie de sécurité et les tâches d’évaluation est défini en termes d’exigences d’assurance de la sécurité. Ces exigences concernent spécifiquement les tâches que les concepteurs, les développeurs et les responsables de la mise en œuvre des contrôles de sécurité doivent exécuter pour avoir la certitude que les travaux et la documentation de l’ingénierie de sécurité sont adéquats et que les contrôles sont appliqués correctement, qu’ils fonctionnent comme prévu, produisent les résultats souhaités et répondent aux objectifs de sécurité définis pour les systèmes. On suggère aux équipes de projet TI d’utiliser un Niveau d’assurance de la sécurité 2 (NAS2), comme il est défini dans le guide ITSG-33, Annexe 2, section 8 [Référence 3], pour la mise en œuvre de la majorité des contrôles de ce profil.

Dans le cas des contrôles de sécurité critiques, plus particulièrement ceux qui concernent les frontières d’un système d’information et ceux prévus pour contrer des capacités d’agent de menace plus importantes, une mise en œuvre adéquate permettra de s’assurer que l’on a consacré davantage d’effort à la conception, au développement, aux tests, à l’installation et à l’exploitation de ces contrôles. On suggère aux équipes de projet TI d’utiliser un Niveau d’assurance de la sécurité 3 (NAS3), comme il est défini dans le guide ITSG-33, Annexe 2, section 8 [Référence 3], pour la mise en œuvre des contrôles de sécurité critiques de ce profil. La criticité d’un contrôle est liée spécifiquement à la conception des systèmes informatiques auxquels le contrôle est appliqué et doit être déterminée par les praticiens de la sécurité des projets TI.

En outre, conformément à ce qui est décrit dans le guide ITSG-33, Annexe 2, section 7.3.2.1 [Référence 3] concernant les niveaux d’assurance NAS1 à NAS3, les fournisseurs qui participent à la conception, au développement ou à l’exploitation d’un système d’information doivent détenir au moins une vérification d’organisation désignée.

Il faut noter que le niveau d’assurance prévu pour la mise en œuvre appropriée de ce profil ne permet pas d’assurer la protection adéquate d’un système contre les agents de menace ayant des capacités supérieures (c.-à-d. ceux associés aux niveaux de menace Md5, Md6 et Md7 et qui sont très qualifiés, motivés et équipés).

Le guide ITSG-33, Annexe 2 [Référence 3], fournit aux équipes de projet TI des directives plus détaillées sur les exigences d’assurance de la sécurité et sur les tâches requises de développement, de documentation et d’évaluation requises pour y répondre.

De plus, on recommande d’évaluer les produits commerciaux de TI sélectionnés et dotés de fonctions de sécurité afin de s’assurer qu’ils fonctionnent de la manière prévue et sont suffisamment résilients pour cerner les menaces. Pour faciliter ce processus et veiller à ce que les produits de TI soient évalués en fonction d’exigences de sécurité appropriées, le CST offre aux ministères une trousse de produits disponibles dans le commerce qu’ils peuvent utiliser à leur discrétion. Le CST a évalué ces produits en partenariat avec certains laboratoires commerciauxNote de bas de page 4. Les ministères qui choisissent de tirer avantage de cette trousse validée par le CST doivent préciser dans leurs outils d’approvisionnement que les produits de sécurité de TI doivent être vérifiés par le programme des Critères communs (CC) selon une cible de sécurité appropriée ou un profil de protectionNote de bas de page 5 des CC (défini dans les normes de sécurité de l’organisation ou déterminé par les praticiens de la sécurité des projets TI conformément aux exigences des sections 2 et 3). Les produits qui contiennent un module cryptographique doivent également être vérifiés par le Programme de validation des modules cryptographiquesNote de bas de page 6 (PVMC) en fonction de la norme FIPS 140-2.

3.2 Directive concernant la priorité de la mise en œuvre

Les organisations ne disposent pas toutes du budget nécessaire à la mise en œuvre simultanée de tous les contrôles et améliorations de sécurité requis. En fait, elles doivent étaler ce processus dans le temps et selon le budget qui leur est alloué. Pour les aider à décider des contrôles et des améliorations qu’elles peuvent initialement instaurer, le CST a attribué à ces éléments trois niveaux distincts de priorité, comme il est indiqué dans le Tableau 4. Cette approche vise essentiellement les nouveaux systèmes d’information, et l’accent est mis davantage sur la prévention que sur la détection ou l’intervention. Les priorités seraient différentes dans le cas des systèmes existants. Cette priorisation de la mise en œuvre permet d’atténuer les menaces les plus courantes et de planifier l’instauration des autres contrôles. Pour protéger un système de manière appropriée et obtenir des risques résiduels faibles, tous les contrôles et toutes les améliorations spécifiés dans le profil doivent être instaurés.

3.3 Format

Le Tableau 4 donne la liste des contrôles de sécurité et des améliorations de contrôle proposés pour le profil. Chaque contrôle inclut un identifiant ainsi que les renseignements suivants :

  • le nom du contrôle de sécurité;
  • une liste des améliorations proposées;
  • des suggestions de groupes responsables de la mise en œuvre (R) ou du soutien (S) des exigences du contrôle de sécurité (le groupe responsable de la fonction de sécurité des TI [Fonction STI], le groupe responsable des opérations de TI [Opér. TI], l’équipe de projet TI [Projet TI], le groupe responsable de la sécurité physique [Séc. phys.], le groupe responsable de la sécurité du personnel [Séc. du pers.] et le centre de formation [Formation];
  • des conseils généraux sur l’adaptation et la mise en œuvre;
  • le niveau de priorité de mise en œuvre suggéré;
  • les valeurs des paramètres substituables documentés dans chaque contrôle de sécurité du profil;
  • des notes supplémentaires sur les contrôles et les améliorations dans le contexte du profil.

La description complète des contrôles et des améliorations ainsi que des paramètres substituables se trouve à l’Annexe 3A du guide ITSG-33 (Catalogue des contrôles de sécurité) [Référence 1].

Nota: Afin de se faciliter la tâche, les praticiens de la sécurité qui désirent créer leur propre profil de contrôle de sécurité ministériel peuvent obtenir une feuille de calcul qui contient les contrôles de sécurité qui figurent à la section 4. Veuillez communiquer avec les Services à la clientèle de la Sécurité des TI pour obtenir une copie de la feuille de calcul.

4 Contrôles de sécurité et améliorations de contrôle suggérés

Tableau 4: Contrôles de sécurité et améliorations de contrôle suggérés :

5 Références

[Référence 1]
Centre de la sécurité des télécommunications. 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é. Conseils en matière de sécurité des technologies de l’information, publication 33 (ITSG-33), Annexe 3A. Le 30 décembre 2014.
[Référence 2]
Centre de la sécurité des télécommunications. 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 TI. Conseils en matière de sécurité des technologies de l’information, publication 33 (ITSG-33), Annexe 1. 1er novembre 2012.
[Référence 3]
Centre de la sécurité des télécommunications. 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. Conseils en matière de sécurité des technologies de l’information, publication 33 (ITSG-33), Annexe 2. 1er novembre 2012.
[Référence 4]
Centre de la sécurité des télécommunications. La gestion des risques liés à la sécurité des TI : Une méthode axée sur le cycle de vie – Glossaire. Conseils en matière de sécurité des technologies de l’information, publication 33 (ITSG-33), Annexe 5. 1er novembre 2012.

Remarques

Date de modification :