Annexe 5 - Glossaire (ITSG-33)

Table des matières

• Avant-propos
• Date d'entrée en vigueur
• Liste des abréviations et des sigles
• 1 Introduction
  • 1.1 Objet
  • 1.2 Structure de la publication
• 2 Glossaire
• 3 Références

Date d'entrée en vigueur

Cette publication entre en vigueur le 1^er novembre 2012.

La chef adjointe, Sécurité des TI,

Signé initialement par

Toni Moffa

Liste des abréviations et des sigles

ASM

Agent de sécurité du ministère

CC

Critères communs

CDS

Cycle de développement des systèmes

CSTC

Centre de la sécurité des télécommunications Canada

DGSM

Directive sur la gestion de la sécurité ministérielle

EMR

Évaluation des menaces et des risques

GC

Gouvernement du Canada

GSTI

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

ITSG

Conseils en matière de sécurité des technologies de l’information

NIST

National Institute of Standards and Technology

PASSI

Processus d’application de la sécurité dans les systèmes d’information

PSG

Politique sur la sécurité du gouvernement

PFTO

Programme de facilitation de la transformation opérationnelle

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 d’une suite de documents d’orientation sur la gestion des risques liés à la sécurité des technologies de l’information (IT) publiés par le Centre de la sécurité des télécommunications Canada (CSTC) pour aider les ministères et les organismes du gouvernement du Canada (GC) à mettre en œuvre, à exploiter et à maintenir des systèmes d’information fiables. La présente annexe comprend le glossaire de la suite de documents d’orientation.

1.2 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 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 3 – Catalogue des contrôles de sécurité;
• ITSG-33, Annexe 4 – Profils de contrôle de sécurité.

2 Glossaire

a

activité opérationnelle
[business activity]

Toute activité effectuée par un ministère dans le cadre de son fonctionnement pour offrir ses programmes et services ou en faciliter la prestation. Une activité opérationnelle inclut un ou plusieurs processus opérationnels et des biens d’information.

Nota : Une activité opérationnelle peut être un programme du GC (p. ex., l’assurance-emploi), un processus opérationnel appliqué à des biens d’information particuliers (p. ex., la comptabilité) ou un ensemble de processus opérationnels et de biens d’information connexes, visant des objectifs organisationnels communs (p. ex., la gestion des ressources humaines). Les activités opérationnelles peuvent également viser des objectifs plus larges, p. ex., la mission, l’image et la réputation.

agent de menace
[threat agent]

Organisation, individu ou type d’individu qui représentent des menaces délibérées, ou type spécifique de menace accidentelle ou de risque naturel. [EMR harmonisée, Référence 1]

amélioration des contrôles de sécurité
[security control enhancement]

Énoncé sur la capacité, sur le plan de la sécurité : (i) d’intégrer des fonctions additionnelles, mais complémentaires, à un contrôle de base ou (ii) d’accroître la force de la sécurité d’un contrôle de sécurité de base. [NIST SP800-39, Référence 7]

architecture d’entreprise
[enterprise architecture]

Description de la structure d’une entreprise qui comprend les composants de l’entreprise (entités opérationnelles), leurs propriétés extérieures visibles et leurs interrelations (p. ex., leur conduite). L’architecture d’entreprise décrit la terminologie, la composition des composants et leurs interrelations avec l’environnement extérieur ainsi que les principes directeurs qui justifient le besoin, la conception et l’évolution de l’entreprise. La description est exhaustive et inclut les buts, les processus opérationnels, les rôles, les structures et les conduites organisationnelles, l’information opérationnelle, les applications logicielles et les systèmes d’information. [Wikipedia, Mars 2011, adaptée]

architecture de sécurité
[security architecture]

Éléments d’une architecture d’entreprise associés à la sécurité des TI.

assurance de la sécurité
[security assurance]

Tâches de mise en confiance qui visent à confirmer qu’un contrôle de sécurité a été conçu et mis en œuvre correctement et qu’il fonctionne tel que prévu. L’assurance de la sécurité inclut également des tâches dont le but est de confirmer la capacité de tous les contrôles de sécurité (conception de la sécurité, mise en œuvre et exploitation) d’un système d’information de répondre aux exigences de sécurité.

autorisation
[authorization]

Processus continu qui consiste à obtenir et à maintenir une décision de gestion officielle, prise par un cadre supérieur, qui autorise à exploiter un système d’information et à accepter explicitement le risque inhérent à son utilisation pour mener un ensemble d’activités opérationnelles en s’appuyant sur l’application d’un ensemble convenu de contrôles de sécurité et sur les résultats d’une évaluation de sécurité continue. [NIST SP800-39, Référence 7, adaptée]

b

besoin opérationnel en matière de sécurité
[business need for security]

Toute protection ou exigence de conformité associée à une activité opérationnelle à laquelle peuvent répondre les contrôles de sécurité. Les besoins opérationnels en matière de sécurité tirent leur origine des lois (p. ex., Loi sur l’assurance-emploi, Loi sur la gestion des finances publiques), des politiques (p. ex., Politique sur la gestion financière des ressources, l’information et les rapports financiers) et de tout autre instrument réglementaire telles les directives et les normes qui régissent les activités opérationnelles du GC. Ils peuvent également découler des missions, des objectifs et des priorités des ministères, du besoin de préserver l’image et la réputation d’une organisation, et de différents engagements contractuels potentiels.

bien de TI
[IT asset]

Terme générique utilisé pour désigner les applications administratives, les représentations électroniques d’information (données), ainsi que le matériel, les logiciels et les données système qui composent un système d’information.

bien de TI classifié
[classified IT asset]

Un bien de TI qui contient, stocke, traite ou transmet des données représentant de l’information et qui peut faire l’objet d’une exception ou d’une exclusion en vertu de la Loi sur l’accès à l’information ou de la Loi sur la protection des renseignements personnels lorsque sa divulgation peut vraisemblablement causer des préjudices aux intérêts nationaux.

bien de TI essentiel
[critical IT asset]

Bien de TI qui satisfait à une activité opérationnelle possédant un certain niveau de criticité.

bien de TI protégé
[protected IT asset]

Bien de TI qui contient, stocke, traite ou transmet des données représentant de l’information et qui peut faire l’objet d’une exception ou d’une exclusion en vertu de la Loi sur l’accès à l’information ou de la Loi sur la protection des renseignements personnels lorsque sa divulgation peut vraisemblablement causer des préjudices aux intérêts non nationaux. [DGSM, Référence 6, adaptée]

c

catégorie de sécurité
[security category]

Une catégorie de sécurité caractérise une activité opérationnelle selon la gravité des préjudices (niveau de préjudice) possibles qui résultent d’une compromission en tenant compte des objectifs de sécurité (confidentialité, intégrité et disponibilité).

catégorisation de la sécurité
[security categorization]

Processus qui consiste à déterminer la catégorie de sécurité des activités opérationnelles, des systèmes d’information et des biens de TI.

Nota :

1. On établit la catégorisation de la sécurité en évaluant le préjudice aux intérêts nationaux et non nationaux qui découlerait de l’incapacité des activités opérationnelles de répondre à leurs objectifs de sécurité liés à la confidentialité, à l’intégrité et à la disponibilité. Les systèmes d’information et les biens de TI héritent généralement de la catégorie de sécurité des activités opérationnelles qu’ils soutiennent;
2. Au niveau du ministère, la catégorisation de la sécurité est une activité continue qui vise les activités opérationnelles afin d’appuyer l’élaboration des profils de contrôle de sécurité. Au niveau du système d’information, la catégorisation de la sécurité s’inscrit dans le PASSI et vise les systèmes d’information et les biens de TI connexes. La catégorisation de la sécurité est effectuée tôt dans le cycle de développement des systèmes d’information, tandis que dans le cas des biens de TI, elle est effectuée plus tard au cours de l’étape de conception lorsque les biens ont été définis.

compromission
(compromettre)
[compromise]

Accès, divulgation, destruction, suppression, modification, interruption ou utilisation non autorisés de biens de TI entraînant une perte de confidentialité, d’intégrité et (ou) de disponibilité. [PSG, Référence 2, adaptée]

compromettre : exploiter des vulnérabilités en vue de causer une compromission.

Nota : Cette perte peut mener à la défaillance d’une activité opérationnelle et au non-respect de ses exigences. La défaillance peut à son tour causer des préjudices aux intérêts nationaux ou non nationaux.

confidentialité
[confidentiality]

Fait d’être divulgué uniquement aux mandants autorisés. [PSG, Référence 2, adaptée]

Nota : La confidentialité concerne normalement les biens d’information. Elle peut également s’appliquer, habituellement à un niveau classifié, à certaines activités opérationnelles, telles les missions militaires et les activités de collecte de renseignements dont l’existence et les détails d’exécution sont classifiés. La sécurité des opérations (OPSEC), qui repose normalement sur la sécurité des TI, est une des techniques utilisées pour protéger la confidentialité des activités opérationnelles. De plus, la confidentialité peut également être appliquée à d’autres types de biens de TI tels l’équipement COMSEC de type 1 et SIGINT ou les systèmes d’armes. Dans de tels cas, elle signifie que l’équipement doit être fourni à du personnel autorisé, détenant la cote de sécurité appropriée, et habilité à le recevoir, le manipuler et l’éliminer. Un adversaire qui s’empare d’un équipement classifié peut appliquer des méthodes de rétroingénierie et être en mesure d’obtenir, par déduction, de l’information classifiée sur sa conception, sa configuration et ses faiblesses.

confirmer
[confirm]

Déclarer qu’une chose a été examinée en détail et déterminée adéquate à l’issue d’une activité de détermination indépendante. [CC, Référence 5]

contexte de menace
[threat context]

Caractéristique d’un profil de contrôle de sécurité d’un domaine ou d’un ministère. Un contexte de menace définit certaines menaces qui concernent les activités opérationnelles du domaine.

contexte opérationnel
[business context]

Composant d’un profil de contrôle de sécurité d’un domaine ou d’un ministère. Un contexte opérationnel définit les activités opérationnelles prévues dans la portée d’un profil : processus opérationnels, biens d’information connexes, besoins opérationnels en matière de sécurité et catégories de sécurité.

contexte technique
[technical context]

Composant d’un profil de contrôle de sécurité d’un domaine ou d’un ministère. Un contexte technique définit en termes généraux l’environnement technique susceptible d’influer sur le choix de contrôles de sécurité du profil.

contrôle de sécurité de gestion
[management security control]

Contrôle de sécurité axé sur la gestion de la sécurité des TI et des risques liés à la sécurité des TI. [NIST FIPS 200, Référence 11, adaptée]

contrôle de sécurité opérationnel
[operational security control]

Contrôle de sécurité essentiellement mis en œuvre et exécuté par des personnes et fondé habituellement sur l’utilisation de la technologie, par exemple, un logiciel de soutien. [NIST FIPS 200, Référence 11, adaptée]

contrôle de sécurité technique
[technical security control]

Contrôle de sécurité mis en œuvre et exécuté par des systèmes d’information principalement par l’application des mécanismes de sécurité intégrés aux composants matériels, logiciels et micrologiciels. [NIST FIPS 200, Référence 11, adaptée]

Nota : Un contrôle de sécurité technique efficace est tributaire du bon fonctionnement du système d’information. De plus, certains éléments opérationnels peuvent contribuer à la mise en œuvre du contrôle (p. ex., évaluation manuelle des résultats de la surveillance des journaux).

contrôle de sécurité (contrôle de sécurité des TI)
[security control, IT security control]

Exigence de haut-niveau technique, opérationnelle ou de gestion relative à la sécurité et prescrite pour un système d’information afin de protéger la confidentialité, l'intégrité et la disponibilité de ses biens de TI. Les contrôles de sécurité sont mis en œuvre par l’application de différents types de solutions de sécurité qui incluent les produits, les politiques, les pratiques et les procédures de sécurité. [NIST SP800-39, Référence 7, adaptée]

contrôles de sécurité de base
[baseline security control]

Contrôles de sécurité obligatoires, définis dans les instruments de politiques du Secrétariat du Conseil du Trésor du Canada (SCT), que les ministères doivent appliquer à leurs fonctions de sécurité des TI et à leurs systèmes d’information. [GSTI, Référence 3]

criticité
[criticality]

Capacité relative importante d’une activité opérationnelle à promouvoir ou maintenir la santé, la sûreté, la sécurité ou le bien-être économique des Canadiens, ou à favoriser le fonctionnement efficace du GC. [PSG, Référence 2, adaptée de la notion de service essentiel]

cycle de développement des systèmes
[system development lifecycle]

Étapes successives de mise en œuvre (c.-à-d. mise en service ou mise en place) des systèmes d’information.

Nota : Le cycle de référence utilisé dans les documents de l’ITSG-33 inclut les étapes suivantes : 1) mobilisation des intervenants, 2) concept, 3) planification, 4) analyse des besoins, 5) conception de haut niveau, 6) conception détaillée, 7) développement, 8) intégration et test, et 9) installation.

cycle de vie des systèmes
[system lifecycle]

Étapes successives que franchissent les systèmes d’information, de leur création à leur fin de vie.

Nota : Le cycle de référence utilisé dans les documents de l’ITSG-33 inclut les étapes suivantes : 1) lancement, 2) développement et acquisition, 3) intégration et installation, 4) exploitation et maintenance, et 5) élimination.

d

décrire
[describe]

Fournir des détails spécifiques. [CC, Référence 5]

démontrer
[demonstrate]

En arriver à une conclusion fondée sur une analyse plus rigoureuse qu’une trace, mais moins rigoureuse qu’une preuve. Pour démontrer une corrélation, il faut une analyse rigoureuse et une preuve informelle d’une correspondance plus détaillée entre des éléments de spécifications successives. [CC, Référence 5]

déterminer
[determine]

Affirmer une conclusion particulière à la suite d’une analyse indépendante dont l’objectif est d’en arriver à une conclusion précise. [CC, Référence 5]

disponibilité
[availability]

Fait d’être accessible et utilisable de manière ponctuelle et fiable. [PSG, Référence 2, adaptée]

Nota :

1. Le concept de disponibilité s’applique généralement à l’information, aux logiciels d’application et au matériel (infrastructure et ses composants). La disponibilité s’applique également aux processus opérationnels et au personnel.
2. La définition établit implicitement que l’intégrité des objets auxquels on a accès n’a pas été compromise (p. ex., les données ou les processus opérationnels altérés sont jugés non disponibles puisqu’ils sont inutilisables).

doit
[must, shall]

Indique qu’un énoncé représente une exigence obligatoire. [RFC 2119, Référence 8, adaptée]

domaine opérationnel
[business domain]

Environnement opérationnel dans lequel un ministère mène des activités opérationnelles qui soutiennent des objectifs organisationnels communs.

données
[data]

Représentation électronique d’information. Quantités, caractères ou symboles sur lesquels un ordinateur effectue des opérations et qui sont stockés et transmis sous forme de signaux électriques et enregistrés sur des supports magnétiques, optiques ou mécaniques. [Oxford, Référence 9, adaptée]

e

énoncé d’évaluation
[statement of assessment]

Toute attestation ou confirmation que le processus d’évaluation a été effectué et que les résultats obtenus sont acceptables. Il peut s’agir d’un simple compte rendu de décisions du procès-verbal d’une réunion technique ou de projet ou d’un document plus formel tel un certificat d’évaluation signé par un évaluateur de la sécurité.

environnement de développement
[development environment]

Environnement dans lequel le système d’information est développé. [CC, Référence 5, adaptée]

évaluation de sécurité
[security assessment]

Processus continu d’évaluation du rendement des contrôles de sécurité des TI durant tout le cycle de vie des systèmes d’information dans le but d’établir la mesure dans laquelle les contrôles sont mis en œuvre correctement, fonctionnent comme prévu et produisent les résultats souhaités conformément aux besoins opérationnels en matière de sécurité définis par le ministère. L’évaluation appuie la fonction d’autorisation en démontrant la présence d’un lien de confiance à l’égard de la sécurité du système d’information. [NIST SP800-39, Référence 7, adaptée de la notion d’évaluation des contrôles de sécurité]

évaluation des menaces et des risques (EMR liée aux TI)
[threat and risk assessment, IT-related TRA]

Processus qui consiste à déterminer et à qualifier les menaces et les risques liés aux biens de TI et à mettre en œuvre ou à recommander des contrôles de sécurité supplémentaires pour atténuer les risques jugés inacceptables.

évaluation des menaces (évaluation des menaces liées à la sécurité des TI)
[threat assessment, IT-related threat assessment]

Processus qui consiste à déterminer et à qualifier les menaces auxquelles sont confrontés les activités opérationnelles d’une organisation et les systèmes d’information mis à contribution.

Nota : L’évaluation permet de déterminer toutes les menaces auxquelles une organisation doit faire face. Les menaces sélectionnées sont celles à l’égard desquelles l’organisation choisit d’intervenir et sont documentées de manière explicite. Les menaces auxquelles une organisation peut être confrontée, mais dont on ne traite pas ici pour différentes raisons (telles les contraintes financières, techniques ou opérationnelles), sont également documentées de manière explicite (c.-à-d., les menaces non sélectionnées).

évaluation des vulnérabilités
[vulnerability assessment]

Détermination de l’existence des vulnérabilités d’un système d’information. [GSTI, Référence 3]

évaluation du risque résiduel
[residual risk assessment]

Évaluation effectuée à la fin du cycle de développement des systèmes pour ajuster les conclusions de l’évaluation détaillée des menaces et des risques afin de tenir compte des lacunes de sécurité non résolues cernées durant les étapes de conception, de développement, de test et d’installation.

exigence de sécurité
[security requirement]

Tout besoin, énoncé dans un langage normalisé, auquel doit répondre un système d’information pour permettre la satisfaction d’un besoin opérationnel en matière de sécurité. [CC, Référence 5, adaptée]

exigence de sécurité ministérielle
[departmental security requirement]

Toute exigence de sécurité prescrite par les cadres supérieurs d’un ministère et qui concerne de manière générale les systèmes d’information du ministère. Les exigences de sécurité ministérielle peuvent être reliées aux processus opérationnels, aux biens d’information, aux menaces liées aux TI, aux niveaux de robustesse, aux profils de contrôle de sécurité, aux exigences d’assurance de la sécurité, aux besoins opérationnels en matière de sécurité, à l’architecture de sécurité, à la conception de la sécurité, aux contrôles de sécurité communs et à des solutions de sécurité particulières.

f

fonction de sécurité des TI
[IT security function]

Éléments d’un programme de sécurité ministérielle destinés à la protection des biens de TI d’un ministère.

force de la sécurité
[security strength]

Caractérisation de la capacité d’un contrôle de sécurité existant à protéger des biens de TI contre toute compromission découlant de menaces.

Nota : Au fur et à mesure qu’augmente la force de la sécurité, l’ampleur des efforts et des coûts que doit déployer un agent de menace pour contourner le contrôle de sécurité en question augmente également. Le potentiel de protection d’un contrôle de sécurité peut se matérialiser uniquement s’il est appliqué avec une assurance de la sécurité adéquate.

g

gestion des risques liés à la sécurité des TI
[IT security risk management]

Processus en vertu duquel les organisations gèrent les risques liés à la sécurité des TI. Ce processus s’appuie sur les règles de sécurité des TI et d’autres processus de gestion des risques.

i

incident
[threat event]

Incident réel au cours duquel un agent de menace exploite une vulnérabilité susceptible d’avoir un effet préjudiciable sur un bien de TI de valeur. [EMR harmonisée, Référence 1, adaptée]

incident lié à la sécurité des TI
[IT security incident]

Tout événement imprévu ou indésirable susceptible de compromettre des biens de TI. [GSTI, Référence 3, adaptée]

information (biens d’information)
[information, information asset]

Toute suite de symboles ou de sons à laquelle on peut attribuer une signification. [EMR harmonisée, Référence 1]

intégrité
[integrity]

État de ce qui est précis, complet, authentique et intact. [DGSM, Référence 6]

Nota : Le concept d’intégrité s’applique généralement à l’information. L’intégrité s’applique également aux processus opérationnels, la logique des logiciels d’application, le matériel et le personnel.

intérêts nationaux
[national interests]

La sécurité et la stabilité sociopolitique et économique du Canada. [PSG, Référence 2]

intérêts non nationaux
[non-national interests]

Sûreté, santé et bien-être des personnes et situation financière et réputation des citoyens et des entreprises canadiennes. [PSG, Référence 2, OSS, Référence 10, adaptée]

j

justifier (justification)
[justify]

En arriver à une conclusion fondée sur une analyse plus rigoureuse qu’une démonstration, mais moins rigoureuse qu’une preuve. La justification exige une grande rigueur et l’explication méticuleuse et détaillée chaque étape d’un argument logique. [CC, Référence 5, adaptée de la notion de justification]

m

mandant
[principal]

Entité participante à un système d’information (personne physique ou morale, rôle, équipement, canal, processus automatisé).

mécanisme de sécurité
[security mechanism]

Catégorie de solutions de sécurité évaluées en fonction de la force de la sécurité (sur le plan de la protection) et de l’assurance de la sécurité (sur le plan de la mise en oeuvre) pour répondre à des menaces spécifiques.

Nota : Exemples de catégories de solutions de sécurité : biométrie, signature numérique, veille active, anti-trafiquage, contrôle d’accès discrétionnaire et filtrage des paquets. Chacune de ces catégories peut être mise en œuvre grâce à différentes solutions de sécurité (p. ex., produits). Par exemple, la biométrie peut utiliser les empreintes digitales, la reconnaissance de l'iris ou les empreintes rétiniennes.

menace
[threat]

Voir la définition de menace liée à la sécurité des TI.

menace accidentelle
[accidental threat]

Menace sans préméditation causée par une personne. [EMR harmonisée, Référence 1]

menace délibérée
[deliberate threat]

Menace planifiée ou préméditée par une personne. [EMR harmonisée, Référence 1]

menace sélectionnée
(menace sélectionnée liée à la sécurité des TI)
[selected threat, selected IT threat]

Toute menace liée à la sécurité des TI qui, à l’issue d’une évaluation des menaces, est jugée pertinente pour une activité opérationnelle ou un système d’information et contre laquelle un ministère prévoit protéger ses biens de TI.

Nota : Certains facteurs peuvent influencer la sélection de menaces. Par exemple, les ressources et savoir-faire mis à la disposition de l’organisation pour contrer efficacement une menace; le budget limité alloué à la sécurité des TI; l’évaluation que certaines compromissions ne causent pas de préjudices; etc. Voir la définition de l’évaluation des menaces pour plus de détails.

menace liée à la sécurité des TI
[IT threat]

Toute action ou tout événement potentiel, délibéré ou accidentel, ou tout risque naturel susceptible de compromettre des biens de TI. [EMR harmonisée, Référence 1, adaptée]

mesure de protection de la sécurité
[security safeguard]

Voir la définition de solution de sécurité.

mesure de sécurité
[security measure]

Voir la définition de solution de sécurité.

ministères
(ministères du GC)
[departments, GC departments]

Ministères et organismes du GC et autres organisations assujetties à la Politique sur la sécurité du gouvernement.

mise en œuvre (mettre en œuvre)
[implementation, implement, implementing]

Terme utilisé pour désigner les étapes du cycle de vie des systèmes qui permettent la mise en place d’un système d’information. La mise en œuvre comprend l’étape initiale et les étapes de développement ou d’acquisition, d’intégration et d’installation du cycle, mais exclut les étapes d’exploitation et de maintenance ainsi que l’étape d’élimination. 

n

niveau d’assurance de la sécurité
[security assurance level]

Niveau d’assurance obtenu à la suite de l’exécution d’un ensemble prédéfini de tâches liées à l’assurance de la sécurité.

niveau de préjudice
[injury level]

Gravité d’un préjudice. Cinq niveaux ont été définis : très faible, faible, moyen, élevé et très élevé.

niveau de risque
[risk level]

Ampleur du risque.

Nota : Les niveaux sont normalement définis comme suit : très faible, faible, moyen, élevé et très élevé. La définition de ces niveaux est liée à la méthodologie d’évaluation des risques.

niveau de risque résiduel (niveau de risque résiduel lié à la sécurité des TI)
[residual risk level]

Ampleur du risque résiduel.

niveau de robustesse
[robustness level]

Niveau qui tient compte de la force de la sécurité et de l’assurance de la sécurité. Ces deux composantes définissent les exigences qu’il faut respecter au moment de la mise en œuvre et de l’application d’un contrôle de sécurité pour répondre aux objectifs définis en matière de contrôles de sécurité.

Nota : Un contrôle de sécurité dont le niveau de robustesse est plus élevé est en mesure de contrer les agents de menace ayant des fonctions plus complexes ou de parer des menaces accidentelles et des risques naturels d’une plus grande magnitude.

o

objectif de sécurité
[security objective]

Voir les définitions suivantes : objectif de sécurité lié à la confidentialité, objectif de sécurité lié à l’intégrité et objectif de sécurité lié à la disponibilité.

objectif de sécurité lié à l’intégrité
[integrity security objective]

Assurer l’intégrité d’une activité opérationnelle ou d’un bien de TI contre un ensemble défini de menaces afin de prévenir tout préjudice aux intérêts nationaux ou non nationaux.

objectif de sécurité lié à la confidentialité
[confidentiality security objective]

Assurer la confidentialité des activités opérationnelles et des biens de TI contre un ensemble défini de menaces afin de prévenir tout préjudice aux intérêts nationaux ou non nationaux.

objectif de sécurité lié à la disponibilité
[availability security objective]

Assurer la disponibilité d’une activité opérationnelle ou d’un bien de TI contre un ensemble défini de menaces afin de prévenir tout préjudice aux intérêts nationaux ou non nationaux.

objectif en matière de contrôles de sécurité
[security control objective]

Énoncé, formulé en langage normalisé, qui établit formellement ce que doit accomplir un contrôle de sécurité pour répondre aux besoins opérationnels en matière de sécurité.

Nota : Cet objectif doit être rédigé de manière spécifique et être mesurable, atteignable, axé sur les résultats et associé à un échéancier. Il doit être mesurable par différents mécanismes : paramètres de rendement, surveillance continue et évaluation de sécurité.

Le but de la mise en œuvre des contrôles de sécurité est d’atteindre leurs objectifs pour satisfaire aux besoins opérationnels en matière de sécurité. Par exemple, le versement de prestations adéquates à un bénéficiaire autorisé (citoyen) est un besoin opérationnel en matière de sécurité. Les objectifs en matière de contrôles de sécurité liés à ce besoin opérationnel peuvent être définis comme une fonction des éléments suivants : authentification obligatoire du bénéficiaire (avec un taux d’erreur prédéterminé), autorisation obligatoire du bénéficiaire (avec un taux d’erreur prédéterminé) à recevoir les versements, et préservation, avec un niveau de confiance élevé, de l’intégrité de l’évènement relatif au paiement (journal des évènements liés au processus opérationnel) et des dossiers de paiement (journal des paiements approuvés et tous les renseignements pertinents).

Les paramètres exacts (p. ex., taux d’erreur et niveau confiance) associés aux objectifs doivent être définis en fonction des préjudices potentiels causés au bénéficiaire dans l’éventualité du non-respect du besoin opérationnel.

Les paramètres peuvent être peu rigoureux lorsque les préjudices sont mineurs (montant de paiement inexact causant certains inconvénients) ou très rigoureux en cas de préjudices graves (montant de paiement inexact occasionne du stress et une perte financière).

p

posture de sécurité
[security posture]

Caractéristique d’un système d’information qui représente la résistance de ce dernier à un ensemble particulier d’attaques délibérées, de menaces accidentelles et de risques naturels (c.-à-d. les menaces sélectionnées).

Nota : La résistance se rapporte non seulement à la capacité de prévention des menaces du système d’information, mais aussi à sa capacité de détection, d’intervention et de reprises en cas de compromission. Les menaces non sélectionnées ne sont pas prises en compte dans l’évaluation de la posture de sécurité.

posture de sécurité (très faible)
[security posture (very weak)]

Cette cote signifie que l’éventualité que les menaces sélectionnées compromettent les biens de TI d’un système d’informationest grave. Elle indique que le système d’information n’a pas été construit adéquatement afin d’assurer la prévention, la détection, la réaction ou la reprise en cas de compromission. Le ministère n’a pas mis en place les mécanismes nécessaires pour gérer les incidents et les compromissions ou pour mettre en œuvre les améliorations requises.

posture de sécurité (faible)
[security posture (weak)]

Cette cote signifie que l’éventualité que les menaces sélectionnées compromettent les biens de TI d’un système d’information est considérable. Un système d’information ayant une faible posture de sécurité a généralement plusieurs des caractéristiques suivantes :

1. Les besoins opérationnels en matière de sécurité ne sont pas entièrement compris et sont mal documentés;
2. Les contrôles et les exigences de sécurité ne sont pas entièrement définis et sont mal documentés;
3. Les menaces ne sont pas entièrement comprises et sont mal documentées;
4. Les solutions de sécurité mises en œuvre ne répondent que partiellement aux contrôles et aux exigences de sécurité et n’apportent pas une assurance adéquate;
5. Le système d’information ne fonctionne pas de manière à maintenir la posture de sécurité;
6. La fonction de sécurité des TI du ministère n’effectue pas une surveillance et une évaluation de sécurité adéquates;
7. Le ministère n’a pas mis en place de mécanismes qui lui permettent de tirer des leçons des incidents et compromissions et de mettre en œuvre les améliorations nécessaires.

Ces éléments augmentent le risque que des menaces compromettent les biens de TI étant donné l’accroissement du nombre des vulnérabilités exploitables par les menaces ou de leur importance. En cas de compromission, le système d’information, le groupe responsable des opérations des TI et la fonction de sécurité des TI du ministère sont incapables de la détecter, d’y réagir ou de reprendre les activités efficacement.

posture de sécurité (moyenne)
[security posture (average)]

Cette cote signifie que l’éventualité que les menaces sélectionnées compromettent les biens de TI d’un système d’information est importante. Un système d’information ayant une faible posture de sécurité a généralement plusieurs des caractéristiques suivantes :

1. Les besoins opérationnels en matière de sécurité ne sont pas entièrement compris et sont mal documentés;
2. Les contrôles et les exigences de sécurité ne sont pas entièrement définis et sont mal documentés;
3. Les menaces ne sont pas entièrement comprises et sont mal documentées;
4. Les solutions de sécurité mises en œuvre ne répondent que partiellement aux contrôles et aux exigences de sécurité et n’apportent pas une assurance adéquate;
5. Le système d’information ne fonctionne pas de manière à maintenir la posture de sécurité;
6. La fonction de sécurité des TI du ministère n’effectue pas une surveillance et une évaluation de sécurité adéquates;
7. Le ministère n’a pas mis en place de mécanismes évolués qui lui permettent de tirer des leçons des incidents et compromissions et de mettre en œuvre les améliorations nécessaires.

Ces éléments augmentent le risque que des menaces compromettent les biens de TI étant donné l’accroissement du nombre des vulnérabilités exploitables par les menaces ou de leur importance. En cas de compromission, le système d’information, le groupe responsable des opérations des TI et la fonction de sécurité des TI du ministère sont incapables de la détecter, d’y réagir ou de reprendre les activités aisément.

posture de sécurité (solide)
[security posture (strong)]

Cette cote signifie que l’éventualité que les menaces sélectionnées compromettent les biens de TI d’un système d’information est mineure. Un système d’information ayant une posture de sécurité solide inclut la plupart ou toutes les caractéristiques suivantes :

1. Les besoins opérationnels en matière de sécurité sont bien compris et bien documentés;
2. Les contrôles et les exigences de sécurité sont bien définis et bien documentés;
3. Les menaces sont bien comprises et bien documentées;
4. Les solutions de sécurité mises en œuvre répondent aux contrôles et aux exigences de sécurité et apportent une assurance adéquate;
5. Le système d’information fonctionne de manière à maintenir la posture de sécurité au fil du temps;
6. La fonction de sécurité des TI du ministère effectue une surveillance et des évaluations de sécurité adéquates des contrôles de sécurité en place;
7. En cas de compromission, le système d’information, le groupe responsable des opérations des TI et la fonction de sécurité des TI du ministère sont capables de détecter les incidents, d’intervenir ou de reprendre les activités avec aisance. On réduit ainsi au minimum la possibilité que des préjudices surviennent ou la sévérité des préjudices;
8. Le ministère tire des leçons des incidents et compromissions et met en œuvre toute amélioration nécessaire.

Cette cote indique que le système d’information a été construit adéquatement afin d’assurer qu’on puisse détecter les incidents, intervenir ou reprendre les activités avec aisance en cas de compromission.

posture de sécurité (très solide)
[security posture (very strong)]

Cette cote signifie que l’éventualité que les menaces sélectionnées compromettent les biens de TI d’un système d’information est très faible. Le système d’information répond pleinement aux besoins opérationnels en matière de sécurité, il a été construit de manière adéquate pour prévenir et détecter les incidents, réagir et reprendre les activités avec aisance en cas de compromission et il est entièrement documenté. Le ministère a mis en place des mécanismes évolués qui lui permettent de gérer les incidents et les compromissions, de tirer des leçons et de mettre en œuvre les améliorations nécessaires rapidement.

préjudice
[injury]

Dommage causé aux intérêts nationaux et non nationaux par les activités opérationnelles mises à leur service et qui résulte de la compromission des biens de TI. [EMR harmonisée, Référence 1, adaptée]

processus d’application de la sécurité dans les systèmes d’information (PASSI)
[Information System Security Implementation Process (ISSIP)]

Processus de détermination des besoins en matière de sécurité et de création de systèmes d’information capables de répondre à ces besoins dans un environnement opérationnel réel. Le PASSI recouvre les domaines de conception technique de la sécurité des systèmes d’information, l’évaluation de la sécurité et l’autorisation de mettre en place un processus détaillé pour la mise en œuvre de systèmes d’information fiables.

processus opérationnel
[business process]

Le processus opérationnel renvoie au travail nécessaire à la transformation d’intrants en extrants. [PTO, Référence 4, adaptée du processus de service]

profil de contrôle de sécurité de domaine opérationnel (profil de contrôle de sécurité de domaine)
[business domain security control profile]

Profil de contrôle de sécurité ministériel associé à un domaine opérationnel particulier plutôt qu’à l’ensemble d’un ministère.

profil de contrôle de sécurité ministériel
[departmental security control profile]

Ensemble des contrôles de sécurité qu’un ministère établit comme exigences minimales obligatoires pour sa fonction de sécurité des TI et ses systèmes d’information. Un profil doit répondre aux contrôles de sécurité de base du SCT et aux besoins opérationnels en matière de sécurité du ministère concerné, tout en tenant compte de son contexte de menace et de son contexte technique.

programme d’architecture d’entreprise
[enterprise security architecture]

Ensemble des ressources, plans, politiques, processus, procédures et outils qu’un ministère alloue et met en œuvre afin de coordonner et de gérer le développement et la maintenance d’une architecture d’entreprise.

programme de sécurité ministérielle
[departmental security program]

Ensemble des activités et des ressources liées à la sécurité et gérées par les agents de sécurité d’un ministère (ASM) afin de répondre aux besoins de l’organisme tout en atteignant les objectifs énoncés dans les instruments de politique sur la sécurité du SCT. [DGSM, Référence 6, adaptée de la notion de programme de sécurité]

r

recommandé(e)
[should]

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.

représentation de la mise en œuvre
[implementation representation]

Représentation la moins abstraite d’un système d’information. Elle inclut le code source, le matériel et les produits logiciels, les diagrammes de réseau physique, la documentation de configuration tels les manuels de construction, etc. Collectivement, ces éléments permettent de construire le système d’information sans qu’il soit nécessaire de prendre toute autre décision relativement à la conception ou à la mise en œuvre.

risque
[risk]

Voir la définition de risque lié à la sécurité des TI.

risque lié à la sécurité des TI
[IT security risk]

Possibilité qu’une menace donnée compromette des biens de TI et cause un préjudice. [EMR harmonisée, Référence 1, adaptée]

risque naturel
[natural hazard]

Menace attribuable aux forces de la nature. [EMR harmonisée, Référence 1]

risque résiduel (risque résiduel lié à la sécurité des TI)
[residual risk, IT security residual risk]

Risque qui demeure une fois que les contrôles de sécurité ont été sélectionnés, approuvés et mis en œuvre. [EMR harmonisée, Référence 1, adaptée]

Nota : Généralement, les responsables opérationnels ont besoin d’un système d’information dont la posture de sécurité correspond aux risques qu’ils soient prêts à tolérer. Ainsi, s’ils tolèrent peu les risques, ils auraient besoin d’un système d’information ayant une posture de sécurité solide. Toutefois, ce n’est pas toujours le cas. Par exemple, il pourrait être acceptable de déployer des troupes en théâtre d’opérations pour sauver des vies en étant appuyé de biens de TI dont la posture de sécurité est plus faible que celle normalement requise, si les répercussions du non-déploiement des troupes (c.-à-d. la mort de nombreux civils) sont (relativement) pires que celles de l’utilisation de ces biens de TI pour appuyer la mission (c.-à-d. la perte d’équipement militaire).

robustesse
[robustness]

Caractérisation de la force de la sécurité et de l’assurance de la sécurité d’un contrôle de sécurité mis en oeuvre.

 

s

sécurité des TI
[IT security]

Discipline qui consiste à appliquer les contrôles de sécurité, les solutions de sécurité, les outils et les techniques pour protéger les biens de TI contre les menaces de compromission durant tout leur cycle de vie en tenant compte de la catégorie de sécurité des activités opérationnelles visées et en conformité avec les politiques, les directives, les normes et les lignes directrices des ministères et du GC.

Nota : La protection des biens de TI permet de protéger les activités opérationnelles du ministère et, par conséquent, sa mission et ses objectifs.

solution de sécurité
[security solution]

Tout produit ou toute fonction, pratique ou procédure de sécurité que l’on peut intégrer à un système d’information pour appliquer un contrôle de sécurité.

surveiller (surveillance)
[monitor, monitoring]

Processus continu d’observation des opérations des systèmes d’information dans le but de détecter tout écart par rapport à la conduite planifiée ou prévue.

système d’information
[information system]

Un système d’information est généralement composé de données, de plates-formes informatiques, de réseaux de communications, d’applications administratives, de personnes et de processus organisés pour permettre la collecte, le traitement, la maintenance, l’utilisation, le partage, la diffusion ou l’élimination d’information. [NIST SP800-39, Référence 7, adaptée]

t

tâche liée à l’assurance de la sécurité
[security assurance task]

Activité effectuée par un praticien de la sécurité ou un évaluateur pour établir l’assurance (confiance) d’un aspect particulier de la sécurité d’un système d’information. Il y a deux types de tâches : technique et d’évaluation. Les tâches techniques incluent la production de la documentation et devraient satisfaire aux exigences en matière de contenu.

test de sécurité
[security testing]

Test effectué durant l’étape de développement et l’étape d’intégration et de test du cycle de développement des systèmes (CDS) et qui contribue à l’établissement de l’assurance de la sécurité.

Nota : Durant l’étape de développement, le test de sécurité inclut des tests fonctionnels des solutions de sécurité personnalisées (p. ex., test d’unité fonctionnelle) et peut également inclure d’autres formes de test, tels les tests fonctionnels par inversion des fonctions non liées à la sécurité (p. ex., test à données aléatoires d’une URL dans une application Web) et les tests de procédures opérationnelles pour en déterminer la convivialité et la maintenabilité. Durant l’étape d’intégration et de test, le test de sécurité inclut des tests de sécurité fonctionnels et peut également inclure des évaluations de vulnérabilité et des tests de pénétration, selon les exigences de l’assurance de la sécurité.

tracer (traçabilité)
[trace, tracing]

Analyse informelle de correspondances entre deux entités en appliquant un niveau de rigueur minimal. Il s’agit de documenter une mise en correspondance de base entre les éléments de spécifications de conception successives.

v

vulnérabilité
[vulnerability]

Attribut d’un bien de TI ou de son environnement (incluant les solutions de sécurité) qui accroît la vraisemblance d’un incident, la probabilité d’une compromission ou la gravité de l’incidence. Les vulnérabilités sont inversement proportionnelles à l’efficacité des solutions de sécurité. [EMR harmonisée, Référence 1, adaptée]

3 Références

[Référence 1]

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.

[Référence 2]

Secrétariat du Conseil du Trésor du Canada. Politique sur la sécurité du gouvernement. 1^er juillet 2009.

[Référence 3]

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. 31 mai 2004.

[Référence 4]

Secrétariat du Conseil du Trésor du Canada. Programme de facilitation de la transformation opérationnelle (PTO). Glossaire. Avril 2006.

[Référence 5]

Critères communs pour l’évaluation de la sécurité des technologies de l’information, Partie 3 : Exigences d’assurance de sécurité. CCMB-2009-07-001, version 3.1, révision 3. Juillet 2009.

[Référence 6]

Secrétariat du Conseil du Trésor du Canada. Directive sur la gestion de la sécurité ministérielle. 1^er juillet 2009.

[Référence 7]

National Institute of Standards and Technology. Information Security. Managing Information Security Risk: Organization, Mission, and Information System View. NIST Special Publication 800-39, mars 2011.

[Référence 8]

Internet Engineering Task Force. RFC2119 Key words for use in RFCs to Indicate Requirement Levels. Mars 1997.

[Référence 9]

Oxford Dictionaries Online (ODO).

[Référence 10]

Secrétariat du Conseil du Trésor du Canada. Norme de sécurité relative à l’organisation et l’administration. 1^er juin 1995.

[Référence 11]

National Institute of Standards and Technology. Minimum Security Requirements for Federal Information and Information Systems, FIPS PUB 200. Mars 2006.