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 3 - (SECRET / Intégrité moyenne / Disponibilité moyenne) (ITSG-33)

De : Centre canadien pour la cybersécurité

 

Format de rechange : Annexe 4A - Profil 3 - (SECRET / Intégrité moyenne / Disponibilité moyenne) (ITSG-33) (PDF, 1.94 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 - SECRET / Intégrité moyenne / Disponibilité moyenne

Janvier 2015

 

Table des matières

Avant-propos

L’Annexe 4A – Profil 3 (SECRET / 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 SECRET / 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 de chaque ministère et des systèmes d’information qu’ils utilisent. 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.

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

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 SECRET / 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 :

  1. mène les activités appropriées de gestion des risques liés à la sécurité des TI;
  2. soutient 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 de chaque ministèreNote de bas de page 1 et des systèmes d’information qu’ils utilisent (comme il est décrit à la section 2). 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 projets, 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 1 – PROTÉGÉ B / 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é) doivent l’adapter aux besoins de leur ministère et à ses activités opérationnelles.

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 des activités opérationnelles du GC de moyenne sensibilité et criticité qui traitent de l’information cotée SECRET. Ces activités peuvent inclure, sans s’y limiter, la planification d’un nouveau budget fédéral, la gestion de la correspondance diplomatique, l’analyse du renseignement, le déroulement des opérations de commande et de contrôle de la Défense nationale et la tenue d’une enquête criminelle sur le crime organisé.

Les ministères qui optent pour ce profil mènent des activités opérationnelles qui traitent des données secrètes 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 classifiée SECRET cause un préjudice de niveau élevé aux intérêts 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 nationaux ou non nationaux;
  • Disponibilité – On peut raisonnablement s’attendre à ce que toute compromission de la disponibilité des biens de TI connexes cause un niveau de préjudice moyen aux intérêts nationaux et 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 plus en détail les contextes opérationnels pertinents en fonction 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 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 SECRET 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é à la 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
  • Désordre civil ou agitation, p. ex., une émeute ou le sabotage d’une infrastructure essentielle
  • Douleur physique, blessure, traumatisme, difficulté, maladie, invalidité ou décès
  • Stress, détresse, traumatisme psychologique ou maladie mentale
  • Perte financière ayant une incidence sur la qualité de vie ou la situation financière des personnes
  • Perte financière qui réduit la compétitivité ou compromet la viabilité des entreprises canadiennes
  • Atteinte à l’économie canadienne qui réduit le rendement du Canada ou la compétitivité interne dans un secteur économique clé
  • Atteinte à la réputation du Canada (p. ex., embarras), relations fédérales-provinciales compromises
  • Entrave à l’établissement de politiques gouvernementales importantes
  • Entraves à l’application efficace de la loi
  • Cessation des activités du gouvernement
Exemples de processus opérationnels
  • Processus de gestion de la haute direction dont l’interruption pourrait nuire à la prise de décisions efficaces
  • Processus consulaires ou liés à la délivrance de passeports dont l’interruption pourrait nuire à l’aide fournie aux Canadiens à l’étranger
  • Création et échange de rapports et d’analyses diplomatiques
  • Création et échange de rapports et d’analyses sur les risques auxquels sont exposées des infrastructures essentielles
  • Soutien automatisé des interventions d’urgence nationale, incluant l’échange d’information
  • Création, traitement et stockage d’information sur la défense nationale
Exemples de biens d’information
  • Information diplomatique sensible
  • Analyse des risques liés aux infrastructures essentielles
  • Information sur la sûreté et la sécurité nationales
  • Information sur la défense nationale

2.2 Contexte technique

Ce profil de contrôle de sécurité convient aux ministères qui œuvrent dans des environnements de TI bien contrôlés. De manière générale, les systèmes d’information ministériels visés par ce profil peuvent être catégorisés en fonction de leur objectif qui consiste à offrir des services de création, de traitement, de stockage et d’échange d’information secrète.

On suppose que ces systèmes ne seront pas connectés directement à Internet. Ils peuvent être reliés aux systèmes d’information d’autres ministères du GC de posture de sécurité équivalente par des solutions interdomaines très robustes et des liens de communication chiffrés de type 1. On suppose que tout transfert de données entre les systèmes qui traitent de l’information secrète et ceux qui traitent de l’information non classifiée sera contrôlé de manière adéquate par des mécanismes de transfert sécurisés appropriés. Ce profil doit être adapté et inclure les contrôles de sécurité prévus pour la fonctionnalité interdomaine. Ces mesures de protection créent des frontières d’enclave très robustes (voir la section 2.4).

Sans modification majeure, le profil peut ne pas convenir à un contexte opérationnel militaire ou à la mise en œuvre d’un réseau fortement décentralisé.

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 opérationnelles, le profil vise à protéger les systèmes d’information. 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 le besoin de perturber les activités opérationnelles du gouvernement. Ils cherchent plutôt à compromettre les systèmes d’information du GC dans le seul but de commettre un acte criminel, notamment stocker des données illégales (p. ex., 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 ou infecter les systèmes d’information du GC avec des maliciels.

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 donc d’atténuer les risques d’exposition aux agents de menaces délibérées des catégories Md1 à Md4 (à l’intérieur des frontières de l’enclave) jusqu’à la catégorie Md7 (à l’extérieur des frontières, lorsque sont utilisés des solutions interdomaines, des contrôles de frontières et des dispositifs de type 1 appropriés), 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 le 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 des 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 pourraient devoir 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 de contrôle de sécurité.

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
À l'intérieur des frontières d'enclave très robustes :
Md1 Attaquant non malveillant (p. ex., navigation, modification ou 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
À l’extérieur des frontières d’enclave très robustes; inclut tous les niveaux de menace précédents, en plus des suivants :
Md5 Attaquant sophistiqué possédant des ressources moyennes et disposé à prendre de grands risques (p. ex., crime organisé, terroristes internationaux).
  • Corruption d’employés internes pour obtenir de l’information
  • Modification de produits commerciaux ou utilisation de produits frauduleux en vue d’un gain financier (p. ex., trafiquage de guichet automatique ou guichet falsifié)
  • Destruction physique de l’infrastructure
  • Attaques par canal auxiliaire (p. ex., cartes à puce)
Md6 Attaquant extrêmement sophistiqué possédant des ressources abondantes et disposé à prendre de petits risques (p. ex., laboratoires nationaux bien financés, États-nations, organisations internationales).
  • Attaques de type TEMPEST
  • Attaques de la chaîne d’approvisionnement, tel le trafiquage de produits commerciaux ou l’utilisation de produits frauduleux en vue d’activités d’espionnage (p. ex., routeurs de réseau falsifiés)
  • Technologies d’implantation difficiles à détecter dans le matériel ou le logiciel
  • Exploitation de vulnérabilités non publiques
Md7 Attaquant extrêmement sophistiqué possédant des ressources abondantes et disposé à prendre des risques extrêmes (p. ex., États-nations en période de crise).
  • Corruption, chantage ou intimidation d’employés internes en vue de compromettre la sécurité des systèmes
  • Pénétration dans des installations sécurisées en vue de permettre des attaques

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é d’activités opérationnelles du GC de sensibilité élevée et de criticité moyenne, comme la planification d’un nouveau budget fédéral, la gestion de la correspondance diplomatique, l’analyse du renseignement, le déroulement des opérations de commande et de contrôle de la Défense nationale et la tenue d’une enquête criminelle sur le crime organisé. Pour protéger les activités opérationnelles, il faut adopter des approches de sécurité qui font au moins appel aux principales pratiques exemplaires suivantes :

  • Frontières fortement protégées : utilisation de liens de communication à niveau d’assurance élevé (p. ex., équipement cryptographique de type 1) et de solutions interdomaines pour créer une enclave classifiée, et interdiction de connexions à des réseaux externes non sécurisés;
  • Forte sécurité du personnel et forte sécurité physique : vérification du personnel aux niveaux 2 (SECRET) et supérieurs, et utilisation de zones 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 : cette approche 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. Elle réduit le risque qu’une faiblesse d’une partie du système d’information soit exploitée pour contourner les mesures de protection des autres parties (p. ex., une clé USB compromise au niveau de la couche plate-forme et qui contourne la protection des frontières de la couche réseau).

Cet ensemble d’approches de sécurité fait appel à une protection des frontières stricte, une forte sécurité du personnel et une forte sécurité physique comme principales mesures de protection. De ce fait, il pourrait permettre l’utilisation de contrôles internes moins robustes et, ainsi, réduire les coûts et la complexité. En particulier, cet ensemble d’approches exige un mode d’exploitation à niveau dominant de sécurité. Selon ce mode, tous les utilisateurs sont autorisés à traiter l’information dont le niveau classification est le plus élevé (SECRET), même si tous les utilisateurs n’ont pas besoin de connaître toute l’information ou d’y accéder.

Néanmoins, ce profil propose aussi un ensemble équilibré de contrôles de sécurité pour réduire le risque que des éléments internes compromis d’un système d’information soient utilisés pour compromettre facilement d’autres éléments. Il propose également des contrôles de sécurité 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.

L’ensemble d’approches de sécurité exige une forte sécurité du personnel, une forte sécurité physique et une protection robuste des frontières pour être en mesure d’atténuer les risques de manière adéquate. Ces contrôles de sécurité critiques doivent donc être évalués régulièrement pour s’assurer qu’ils continuent de répondre aux objectifs de sécurité. Cette procédure permet de sécuriser les composants internes des systèmes d’information (à l’intérieur des frontières) en utilisant des contrôles semblables à ceux du profil de sécurité des systèmes de la catégorie PROTÉGÉ B / Intégrité moyenne / Disponibilité moyenne.

Il est important de s’assurer que cet ensemble d’approches convient à l’environnement technique du ministère avant de sélectionner le profil. Sinon, il faudra éventuellement y apporter d’importantes modifications. Ce profil ne convient pas aux systèmes d’information multiniveaux.

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 d’un ministère. 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 inopérante (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 aux contrôles de sécurité et les trois objectifs de sécurité qu’un contrôle de sécurité vise 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, la mise en œuvre des mesures de protection des frontières et des contrôles liés à la sécurité du personnel et à la sécurité physique exige un niveau élevé d’effort et de diligence. Pour ce qui est des autres contrôles de sécurité, ils exigent un niveau d’effort et de diligence moyen, comme il est décrit dans cette section, et permettent de s’assurer que le système d’information qui appuie les activités opérationnelles présente au plus des risques résiduels de niveau faible.

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 qu’il faudra consacrer à l’élaboration, à la documentation et à l’évaluation de leur mise en œuvre.

L’Annexe 1 du guide ITSG-33 [Référence 1] 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 d’information. 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é. Les systèmes d’information mettent en œuvre la majorité des contrôles de sécurité techniques de ce profil. 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 de sécurité 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 d’information. 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 sécurité 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. Conséquemment, il faudra peut-être intégrer des dispositifs de niveau d’assurance élevé tels les dispositifs cryptographiques de type 1. Dans un tel cas, les dispositifs eux-mêmes auront déjà été installés et certifiés. Les efforts et la rigueur de l’intégration seront concentrés sur la conduite appropriée des activités d’installation, de configuration, d’exploitation et de test opérationnel des dispositifs.

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], les fournisseurs qui participent à la conception, au développement ou à l’exploitation d’un système d’information de niveau SECRET doivent détenir au moins une attestation de sécurité d’installations de niveau SECRET.

La criticité d’un contrôle de sécurité est liée à la conception spécifique des systèmes d’information et doit être déterminée par les praticiens de la sécurité des projets de TI. Les contrôles de sécurité critiques doivent au moins comprendre la protection des frontières, la sécurité du personnel et la sécurité physique.

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 activités 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. Les recommandations qui suivent visent à faciliter ce processus et à s’assurer que les produits de TI sont évalués en fonction d’exigences de sécurité appropriées.

  1. Pour les produits de TI qui appliquent des contrôles à l’intérieur des frontières de sécurité, 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.
  2. Les produits de TI qui appliquent le chiffrement des communications aux frontières de l’enclave doivent être mis en œuvre au moyen de produits évalués et approuvés par le CST (p. ex., des produits de type 1). De plus, l’organisation doit respecter la doctrine du CST lorsqu’elle utilise ces produits.
  3. Les activités de sélection, de conception et de configuration des produits de TI qui offrent une fonctionnalité interdomaine aux frontières de l’enclave devraient être menées en collaboration avec le CST.

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

Toutes les organisations ne disposent pas 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. Comme cette approche vise les nouveaux systèmes d’information, 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, soit 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, en communiquant avec les Services à la clientèle de la Sécurité des TI.

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 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é. 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 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 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 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. 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 Canada. 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 :