Guide de sécurité pour les solutions de système d’information

1.1 But

Le présent document est un « Guide » à l’intention des ministères et des organismes fédéraux, qui décrit un ensemble de tâches de sécurité à prendre en considération lors de la conception et de la mise en œuvre de solutions visant les systèmes d’information du gouvernement du Canada dans les environnements d’informatique en nuage.

Voici le but du présent Guide :

• contribuer à établir dans le cadre des projets, un niveau raisonnable d’assurance de la sécurité, lors de la mise en œuvre d’une solution de système d’information;
• contribuer à faciliter les activités liées à l’évaluation et à l’autorisation de sécurité (EAS);
• veiller à ce que les considérations en matière de sécurité qui ont fait l’objet d’une mise en œuvre dans le cadre des projets soient conformes à ce qui suit :
  • Directive sur la gestion de la sécurité
  • Orientation sur l’utilisation sécurisée des services commerciaux d’informatique en nuage : Avis de mise en œuvre de la Politique sur la sécurité (AMOPS) 2017‑01

Le présent Guide :

• met l’accent sur un ensemble de mesures de sécurité de base préliminaires en tant que point de départ;
• est fondé sur les principes agiles et de gestion allégée;
• est harmonisé avec les conseils dans le document La gestion des risques liés à la sécurité de la TI : Une méthode axée sur le cycle de vie (ITSG-33);
• ne prescrit pas une méthode de développement de système.

1.2 Portée

Le présent Guide :

• met l’accent sur les solutions de système d’information déployées dans des environnements d’informatique en nuage;
• traite de la portée précise de la responsabilité liée aux composants d’application des solutions de système d’information qu’on met en œuvre dans le cadre des projets en plus des services d’informatique en nuage;
• suppose que les mesures de sécurité à la couche de l’infrastructure ont été mises en œuvre en plus de l’environnement du fournisseur de services d’informatique en nuage (FSIN); il s’ensuit que la solution de système d’information hérite de ces mesures.

Les équipes de projet doivent valider toute hypothèse liée aux mesures de sécurité héritées, auprès de leurs responsables de la sécurité de la TI du ministère.

1.3 Intervenants

Le présent Guide doit être utilisé par les personnes qui participent aux activités décrites dans le Guide et qui assument les rôles suivants :

• propriétaire du produit^{Voir la note en bas de page 1};
• personne autorisée (si différente du propriétaire du produit);
• chef d’équipe de projet;
• propriétaire de l’architecture;
• propriétaire de l’architecture de sécurité (si différent du propriétaire de l’architecture)
• membres de l’équipe de projet;
• évaluateur de la sécurité;
• gestionnaire des opérations.

Les définitions de ces rôles se trouvent sur le site Web de Disciplined Agile (en anglais) ainsi qu’à l’annexe 1 de la ligne directrice ITSG-33.

2.1 Mesures de sécurité de base

Le présent Guide porte sur un ensemble préliminaire de mesures de sécurité de base qui conviennent aux composants d’application des solutions de système d’information ayant une catégorie de sécurité jusqu’au niveau Protégé B, intégrité moyenne et disponibilité moyenne (PBMM), inclusivement. Le choix des mesures de sécurité présenté à l’annexe fournit un point de départ aux équipes de projet; la sélection a été effectuée en vue d’atteindre les objectifs suivants :

• être conforme avec les procédures obligatoires applicables énoncées dans la Directive sur la gestion de la sécurité;
• remplir les exigences de l’Orientation sur l’utilisation sécurisée des services commerciaux d’informatique en nuage : Avis de mise en œuvre de la Politique sur la sécurité (AMOPS) ;
• aborder les 10 meilleures mesures de sécurité du Centre de la sécurité des télécommunications (CST);
• s’harmoniser avec le Profil des mesures de sécurité pour les services du GC fondés sur l’informatique en nuage ;
• se concentrer sur la sélection de mesures de sécurité identique à celles mise en œuvre dans des composants logiciels des solutions de système d’information;
• réaliser les objectifs liés à la protection contre les menaces, énoncés dans le profil PBMM générique ITSG-33 et le Profil des mesures de sécurité pour les services du GC fondés sur l’informatique en nuage .

Les équipes de projet devront adapter le profil applicable aux fins de leur solution de système d’information. Cette personnalisation du profil peut entraîner la sélection et la mise en œuvre d’autres mesures de sécurité ou améliorations, afin de répondre aux exigences en matière de sécurité du ministère ou d’augmenter l’atténuation de menaces précises.

Dans le répertoire des mesures de sécurité, on peut réaliser des niveaux croissants de force dans les mécanismes de sécurité en mettant en œuvre des améliorations aux mesures de sécurité de base. En règle générale, pour une mesure de sécurité donnée, le nombre d’améliorations mises en œuvre est directement proportionnel à la solidité du mécanisme de sécurité. Par exemple, la mise en œuvre de l’amélioration 1 liée à la mesure de sécurité de base IA-2 accroît la force du mécanisme d’identification et d’authentification, notamment en appliquant un deuxième facteur d’authentification aux fins des comptes privilégiés.

2.2 Mesures de sécurité héritées

Le National Institute of Standards and Technology des États-Unis définit les mesures de sécurité communes comme « des mesures de sécurité dont la mise en œuvre entraîne une capacité de sécurité qui est héréditaire par un ou plusieurs systèmes d’information organisationnels ». Les mesures de sécurité sont réputées héréditaires par des systèmes d’information ou des composants de système d’information lorsque les systèmes ou les composants reçoivent une protection de la part des mesures mises en œuvre qui ont été élaborées, mises en œuvre, évaluées, autorisées et surveillées par des entités autres que celles responsables des systèmes ou des composants. Voici des exemples de mesures de sécurité pouvant être héritées par des systèmes d’information et des composants :

• politiques sur la sécurité en matière de TI;
• sensibilisation et formation en matière de sécurité;
• plans d’intervention en cas d’incident;
• accès physiques aux installations;
• sécurité du personnel;
• règles de comportement.

Il existe également diverses mesures de sécurité technologiques qui sont habituellement mises en œuvre comme des mesures de sécurité communes et peuvent être utilisées dans des systèmes d’information. Voici des exemples de mesures de sécurité technologiques communes :

• systèmes d’infrastructure à clé publique (ICP);
• systèmes de contrôle de l’accès;
• systèmes de protection des limites.

2.3 Processus du cycle de vie de développement des systèmes

Les équipes de projet qui utilisent des méthodes agiles ou plus traditionnelles en cascades doivent être en mesure d’utiliser le présent Guide. Peu importe la méthode utilisée, le présent Guide appuie l’intégration des activités de sécurité dans un projet et tout au long du processus du cycle de vie de développement des systèmes (CVDS), en fournissant un ensemble de tâches que les équipes de projet peuvent ajouter à leurs arriérés ou à leur calendrier de travail.

Si des renseignements personnels sont en cause, les équipes de projet doivent veiller à ce que les exigences liées à la protection de la vie privée soient déterminées et traitées de façon appropriée dans leurs solutions, en consultation avec le bureau d’accès à l’information et de la protection des renseignements personnels (AIPRP) de leur ministère.

Les équipes de projet peuvent en apprendre davantage sur la sécurité dans les projets de la TI en consultant le document Applying ITSG‑33 guidance to IT projects [Application du guide à l’intention des projets de la TI ITSG‑33] (Guide à l’intention des projets de la TI ITSG‑33), qui est disponible sur la page GCpédia des outils et des modèles de l’ASI (accessible uniquement sur le réseau du gouvernement du Canada).

2.4 Harmonisation organisationnelle

Les équipes de projet doivent consulter les équipes d’architecture intégrée et de sécurité de la TI ou d’architecture intégrée de sécurité de leur ministère aux fins suivantes :

• déterminer les normes de sécurité applicables et les possibilités de réutilisation des solutions de sécurité;
• assurer l’harmonisation organisationnelle.

2.5 Modélisation des menaces

Les équipes de projet doivent effectuer la modélisation des menaces pour veiller à ce que toutes les expositions de menaces dans leurs solutions de système d’information soient couvertes par les conceptions et les mécanismes de sécurité appropriés. Les liens suivants sont des ressources qui fournissent une introduction à la modélisation des menaces :

• Security Threat Models: An Agile Introduction (en anglais) d’Agile Modeling;
• Introduction to Microsoft’s Security Development Lifecycle (SDL) Threat Modelling (en anglais) – présentation.

En outre, les autorités responsables de la sécurité du ministère pourraient vouloir consigner les risques résiduels liés à la solution de système d’information qu’un projet met en œuvre par rapport aux menaces ministérielles. Au GC, la méthode préférée à cette fin est la Méthodologie harmonisée d’EMR (TRA-1). En général, les méthodes de modélisation des menaces ne conviennent pas à l’évaluation des risques résiduels, en raison de ce qui suit :

• ces méthodes ont tendance à miser sur les menaces et leur atténuation;
• elles ne comprennent pas la qualification ou la quantification des risques.

Toutefois, les évaluations de risques et la modélisation des menaces peuvent fonctionner ensemble pour satisfaire aux exigences au niveau du projet et du ministère. La figure 1 présente un exemple de ces méthodes fonctionnant ensemble dans l’harmonisation avec la ligne directrice ITSG‑33.

Figure 1 - Version textuelle

La figure  1 montre la relation entre les activités au niveau du ministère et les activités au niveau du projet dans le cadre des évaluations de menaces.

Au niveau du ministère, l’évaluation ministérielle des menaces et les profils de mesures de sécurité de domaine sont des éléments entrant dans une évaluation générique des menaces et des risques.

L’évaluation générique des menaces et des risques réalise ce qui suit :

• génère des données sur les menaces, qui sont utilisées afin d’exécuter la modélisation des menaces au niveau du projet;
• appuie l’évaluation et la documentation des risques résiduels;
• est appliquée aux résultats d’atténuation des menaces.

Les profils des mesures de sécurité de domaine sont utilisés afin de mener à bien les étapes au niveau du projet. Voici ces étapes :

• sélectionner le profil des mesures de sécurité qui s’applique;
• adapter les mesures de sécurité dont dérivent les mesures de sécurité propres au système;
• exécuter l’ingénierie et la conception de la solution;
• exécuter la modélisation des menaces, qui éclaire les résultats d’atténuation des menaces.

Dans la figure 1, les autorités responsables de la sécurité du ministère utilisent une évaluation de la menace et des risques (EMR) en vue d’évaluer les risques résiduels liés au système d’information. L’équipe de projet réalise ce qui suit :

• sélectionne un profil de mesures de sécurité applicable et adapte les mesures de sécurité aux fins du système d’information;
• modélise les menaces dans le cadre du processus d’ingénierie et de conception afin de veiller à ce que des modèles de conception de sécurité soient adoptés et que des mécanismes de sécurité appropriés soient sélectionnés et mis en œuvre;
• adapte son modèle de menace en fonction des données sur les menaces dans l’EMR générique.

À mesure que les processus d’ingénierie et de conception liés à la solution progressent :

• l’équipe de projet informe les autorités responsables de la sécurité du ministère des résultats d’atténuation des menaces;
• les autorités responsables de la sécurité du ministère utilisent ces résultats afin d’évaluer et de consigner les risques résiduels.

La bonne méthode de modélisation des menaces à utiliser et le moment exact où la modélisation des menaces se produit dans un projet font l’objet d’une discussion. Les équipes de projet doivent utiliser une méthode qu’elles comprennent et qui fonctionne bien avec leurs processus de CVDS.

2.6 Assurance de la sécurité

Les équipes de projet doivent être préoccupées par l’« assurance de la sécurité »^{Voir la note en bas de page 2} de ce qui suit :

• les solutions de système d’information qu’elles mettent en œuvre;
• les services d’informatique en nuage sous-jacents.

Pour les solutions de système d’information, les équipes de projet peuvent établir l’assurance comme suit :

• en intégrant la sécurité dans les documents du projet;
• en effectuant des tâches de vérification et de validation de la sécurité.

Les équipes de projets doivent également produire des résultats vérifiables comme des plans d’essai et des résultats afin d’appuyer l’évaluation et l’autorisation de sécurité (EAS). Pour obtenir de plus amples renseignements sur ces sujets, consulter le document Applying ITSG‑33 guidance to IT projects [Application des lignes directrices ITSG-33 aux projets de la TI] (Guide à l’intention des projets de la TI, ITSG‑33), qui est disponible à la page GCpédia des outils et des modèles de l’ASI (accessible uniquement sur le réseau du gouvernement du Canada).

Pour les services d’informatique en nuage sous-jacents, les équipes de projet peuvent obtenir l’assurance de la sécurité en demandant des preuves d’EAS, soit directement auprès des fournisseurs de services à l’interne (par exemple, au ministère ou à Services partagés Canada), soit au moyen des exigences de demande de propositions (DP) ou de clauses contractuelles pour les fournisseurs de services d’informatique en nuage commerciaux. Voir le document Gouvernement du Canada Approche et procédures de gestion des risques à la sécurité de l’informatique en nuage afin d’obtenir de plus amples renseignements sur le processus d’EAS pour les services d’informatique en nuage commerciaux.

On suppose que tout service sous-jacent ou externe utilisé par une solution a été établi au moyen d’un processus approuvé d’assurance de la sécurité.

2.7 Considérations de sécurité liées à la conception

Même si ces mesures de sécurité de base fournissent une base solide pour la protection de la plupart des solutions de système d’information du GC ayant une catégorie de sécurité maximale de PBMM, les équipes de projet doivent tenir compte d’autres facteurs lors de la conception et de l’élaboration de leurs solutions. Voici ces facteurs :

• les besoins opérationnels pour les exigences en matière de sécurité et autres exigences liées aux opérations pour lesquelles des mesures de sécurité précises sont prescrites;
• les contraintes de conception comme le zonage de sécurité réseau, les structures d’application à plusieurs niveaux, les modèles de conception de sécurité, et d’autres exigences architecturales;
• l’exigence pour des mesures de sécurité supplémentaires en vue de se conformer aux normes de sécurité du ministère ou de régler des menaces précises;
• la nécessité de sélectionner des mécanismes de sécurité solides pour répondre à des niveaux croissants des capacités ou incidences des menaces.

4.1 Instruments de politique connexes

• Directive sur la gestion de la sécurité
• Orientation sur l’utilisation sécurisée des services commerciaux d’informatique en nuage : Avis de mise en œuvre de la Politique sur la sécurité (AMOPS) 2017-01

4.2 Références supplémentaires

• Profil des mesures de sécurité du gouvernement du Canada pour les services du GC fondés sur l’informatique en nuage
• Approche et procédures de gestion des risques à la sécurité de l’informatique en nuage
• Guide et outil de catégorisation de la sécurité (accessible uniquement sur le réseau du gouvernement du Canada)
• Plan de gestion des événements de cybersécurité du gouvernement du Canada (PGEC GC) 2018
• Cas conceptuel relatif aux projets numériques
• Guides pour les modèles de l’architecture de sécurité intégrée (ASI) (accessible uniquement sur le réseau du gouvernement du Canada)
• Ligne directrice sur la définition des exigences en matière d’authentification
• Ligne directrice sur l’assurance de l’identité
• Considérations relatives à la cryptographie dans les services d’informatique en nuage commerciaux (accessible uniquement sur le réseau du gouvernement du Canada)
• La gestion des risques liés à la sécurité de la TI : Une méthode axée sur le cycle de vie (ITSG‑33)
• Conseils sur la configuration sécurisée des protocoles réseau (ITSP.40.062)
• Exigences de base en matière de sécurité pour les zones de sécurité de réseau au sein du gouvernement du Canada (ITSG-22)
• Établissement des zones de sécurité dans un réseau – Considérations de conception relatives au positionnement des services dans les zones (ITSG-38)

Abréviations

DGS : Directive sur la gestion de la sécurité
AMOPS : Avis de mise en œuvre de la Politique sur la sécurité
OWASP : Open Web Application Security Project