Exigences de base en matière de sécurité pour les zones de sécurité de réseau (Version 2.0) - ITSP.80.022

Avant-propos

L’ITSP.80.022, Exigences de base en matière de sécurité pour les zones de sécurité de réseau, version 2, Annexe A – Zone d’accès public, est une publication NON CLASSIFIÉ.

La présente version de l’Annexe A de l’ITSP.80.022, version 2, remplace les versions précédentes.

Date d'entrée en vigueur

Le présent document entre en vigueur le 12 janvier 2021.

Historique des modifications

Annexe A Exigences de sécurité de base pour la zone publique (ZP)

1 Introduction

La présente annexe présente les exigences de base en matière de sécurité qui s’appliquent à la zone d’accès public (ZAP). Une ZAP négocie les accès entre les réseaux organisationnels et la ZP. Une ZAP est un domaine étroitement contrôlé qui protège les réseaux et les applications internes de l’environnement hostile de la ZP (p. ex., Internet). Elle joue également le rôle d’un écran qui masque les ressources internes de la ZP et limite leur exposition. Les interfaces à tous les services externes sont réalisées au moyen d’une ZAP.

Une ZAP peut fournir des services, tels que les services mandataires, les mandataires et passerelles de courrier électronique et d’autres formes de messagerie, les applications de prestation de services, l’accès à distance, l’accès extranet et les services de soutien communs.

Les informations sensibles peuvent transiter par une ZAP, ou y être recueillies, mais elles ne devraient pas être stockées dans une ZAP. Pour limiter la quantité de renseignements sensibles exposés advenant une compromission de la sécurité, tous les renseignements sensibles devraient être transférés dans des bases de données situées dans une ZT, ou dans une ZAR par l’entremise de la ZT, et on devrait y accéder au moyen d’applications dans la ZAP.

L’état de sécurité d’une ZAP atténue les menaces posées par des auteurs de menace appartenant aux catégories de niveau Md4 et inférieurs^{Note de bas de page 6}. On suppose toutefois que des auteurs de menace de niveau Md5^{Note de bas de page 7} pourraient arriver à contourner les contrôles de sécurité réseau d’une ZAP. Une ZATR peut être mise en œuvre si une partie ou la totalité des données est susceptible d’être la cible d’auteurs de menace appartenant aux catégories de menace de niveau Md5 et inférieurs.

A.2 Modèle de référence de la ZAP

La présente section décrit le modèle de référence de la ZAP, lequel découle du modèle de référence générique. Une ZAP comprend les composants mentionnés au tableau 5.

Tableau 5 : Composants de la ZAP

Une ZAP peut avoir plus d’un de chacun des composants énumérés plus haut. Par ailleurs, elle peut prendre en charge une partie d’une organisation, une organisation complète ou plusieurs organisations.

La figure 7 illustre la topologie logique d’une ZAP. Une ZP (p. ex. Internet ou autres réseaux externes) est connectée à une ZAP par l’entremise du PIZ de la ZP-ZAP. Les zones internes sont accessibles par un PIZ de la ZAP-ZT qui connecte les ZT internes.

Figure 7 : Topologie logique de la ZAP

Description détaillée

Figure 7 : Topologie logique de la ZAP

A.2.1 Système d’extrémité et hôtes

Les systèmes d’extrémité et les hôtes de la ZAP sont connectés aux interréseaux (se reporter à la sous-section A.2.4). Ils hébergent les ressources des applications qui sont connectées à une ZP (p. ex. les systèmes Internet). Vous ne devriez pas stocker les données essentielles sur un système d’extrémité ou les héberger dans une ZAP. Il convient plutôt d’utiliser des mandataires dans une ZAP pour négocier le contrôle des accès entre les hôtes de la ZP et les services situés dans d’autres zones, qui sont autorisés à offrir un accès externe. Pour négocier les contrôles d’accès, les hôtes utilisés dans une ZAP mettent fin aux sessions TCP/IP démarrées depuis les hôtes de la ZP, puis démarrent de nouvelles sessions TCP/IP sur les services des autres zones.

La ZAP peut prendre en charge les services génériques indiqués dans le tableau 6. Ces dernières ont des objectifs et des exigences qui leur sont propres.

Tableau 6 : Services génériques pris en charge par une ZAP

Une ZAP unique n’a pas à offrir tous les services génériques. En fait, dans la plupart des cas, la ZAP n’offrira qu’un petit sous-ensemble des services ci-dessus. Par exemple, les services d’accès pour les employés (mandataires de sortie, voix sur IP [VoIP] vers le réseau téléphonique public commuté [RTPC] et accès à distance) constituent un regroupement naturel. La prestation de services en ligne au public peut constituer un autre regroupement naturel. Il est donc prévisible que la taille et la complexité de la ZAP et de l’ensemble de la ZAP varieront considérablement selon les besoins opérationnels de l’organisation.

Les services de soutien communs fournissent les fonctions d’infrastructure nécessaires à l’exploitation du réseau. Il peut s’agir de services publics (p. ex. une interface utilisateur de l’infrastructure à clé publique [ICP] ou une interface utilisateur de l’infrastructure de gestion des privilèges), de services privés (p. ex., la détection des intrusions, l’heure réseau) ou un service de frontière (comme DNS ou DSA).

Un extranet constitue une extension contrôlée du réseau privé de l’organisation permettant de partager de l’information et des ressources pour des besoins opérationnels particuliers avec des partenaires spécifiques. Un extranet devrait aboutir dans une ZAP. Son utilisation est régie par des ententes standards donnant à l’organisation un contrôle limité sur la configuration externe. On notera que cet extranet « général » est différent de la ZEAR décrite dans la section 2.1.6. Un tel extranet d’accès restreint, réservé à des partenaires de confiance absolue, peut aboutir dans un PIZ de la ZT contrôlé par l’organisation et serait régi par une entente propre à l’instance extranet, avec des contrôles mutuellement convenus.

La figure 8 illustre une ZD potentielle dont le trafic est acheminé par l’entremise de ces services.

Figure 8 : Exemples de ZD

Description détaillée

Figure 8 : Exemples de ZD

A.3 Objectifs de sécurité d’une ZAP

En général, la ZAP fournit un service de sécurité aux autres zones contrôlées par l’organisation, en protégeant ces zones contre la plupart des menaces qui émanent des ZP.

Chaque objectif ou exigence spécifié dans la présente annexe est identifié suivant les règles de notation suivantes :

• le premier groupe de lettres (PAZ pour Public Access Zone) désigne la ZAP;
• le second groupe de lettres précise s’il s’agit d’un objectif (OBJ) ou d’une exigence (REQ pour Requirement);
• les exigences sont regroupées selon les catégories suivantes, le cas échéant :
  • Interface réseau (NI pour Network Interface);
  • Contrôle du trafic (TC pour Traffic control);
  • Configuration réseau (NC pour Network Configuration);
  • Configuration d’hôte (HC pour Host Configuration);
  • Protection des données (DP pour Data Protection);

• chaque objectif ou exigence est numéroté en séquence dans son groupe.
  Remarque: Les objectifs et les exigences ne sont pas indiqués en ordre séquentiel; certaines exigences ont été supprimées ou modifiées comparativement aux précédentes versions du présent document.

A.3.1 Objectifs de contrôle du trafic

[PAZ-OBJ-100] La ZAP devrait négocier les flux de trafic de tous types entre les réseaux internes et la ZP.

[PAZ-OBJ-101] Tous les types de trafic à destination ou en provenance d’une ZP devraient être contrôlés au moyen des PIZ de ZP.

[PAZ-OBJ-103] La ZAP devrait se protéger elle-même contre les changements non autorisés de la configuration de réseau.

[PAZ-OBJ-104] La ZAP devrait empêcher les utilisateurs autorisés d’utiliser les ressources Internet de façon illégale ou illicite.

[PAZ-OBJ-105] La ZAP devrait empêcher les utilisateurs autorisés d’utiliser les ressources Internet de façon illégale ou illicite.

Remarque: Les mesures de sécurité réseau ont une efficacité limitée pour ce qui est de protéger les systèmes d’extrémité contre les compromissions à partir d’interfaces d’applications valides. Il convient de mettre en place des mesures visant les plateformes, les applications et la sécurité opérationnelle en vue d’atténuer les risques associés à ce type de menace.

[PAZ-OBJ-107] La ZAP devrait permettre de renforcer les mesures de sécurité en réponse à un accroissement du niveau de la menace (p. ex. lors d’une période de crise). Les mesures pourraient comprendre ce qui suit :

• la mise en place de contrôles de trafic souples et dynamiques basés sur les communautés d’intérêt;
• une surveillance accrue de l’infrastructure réseau impartie par les fournisseurs de services réseau.

A.3.2 Objectifs de la disponibilité et l’intégrité du réseau

[PAZ-OBJ-108] Une ZAP devrait protéger l’intégrité et la disponibilité des systèmes d’extrémité qui y sont connectés. Une ZAP devrait effectuer les fonctions suivantes :

• réduire l’incidence des attaques par déni de service sur les systèmes d’extrémité qui sont menées par toutes les autres sources de menace;
• empêcher les auteurs de menace appartenant aux catégories de menace de niveau Md4 et inférieurs de s’introduire dans le réseau (p. ex. en connectant un dispositif non autorisé à une interface existante, en ajoutant une interface de bordure non autorisée) pour accéder aux systèmes d’extrémité;
• réduire l’incidence des intrusions réalisées par toutes les autres sources dans le réseau;
• contenir l’incidence de la compromission d’un système d’extrémité;
• empêcher les auteurs de menace appartenant aux catégories de menace de niveau Md4 et inférieurs d’exploiter les systèmes d’extrémité comme base de lancement pour attaquer les autres systèmes;
• empêcher les autres sources de menace d’utiliser les systèmes d’extrémité comme base de lancement d’attaques contre d’autres systèmes;
• empêcher la propagation de trafic malveillant dans une ZAP depuis d’autres zones;
• prévenir la propagation des maliciels.

A.3.3 Objectifs de la protection des données

[PAZ-OBJ-109] Une ZAP devrait empêcher les auteurs de menace appartenant aux catégories de menace de niveau Md4 et inférieurs d’intercepter le trafic de la zone, et être en mesure de réduire la susceptibilité aux interceptions non détectées de toutes les autres sources.

[PAZ-OBJ-110] Une ZAP devrait prendre en charge les mesures suivantes pour protéger la confidentialité et l’intégrité des données :

• RPVS dans l’interréseau;
• RPVS en tant que service de données facultatif;
• protocoles de sécurité de la couche supérieure.

A.3.4 Objectifs de sécurité pour les services fonctionnels de la ZD

Chaque fonction fournie par la ZD correspond à un ensemble distinct d’objectifs de sécurité. Cette section décrit les objectifs de sécurité de haut niveau que permet d’atteindre la sécurité appliquée à chaque service.

[PAZ-OBJ-111] Les objectifs de sécurité pour les services de courrier électronique fournis par une ZP sont les suivants :

• isoler les réseaux internes de la ZP au moyen de passerelles de messagerie;
• acheminer le trafic de courrier entrant et sortant par des interfaces rigoureusement contrôlées;
• protéger le réseau interne des programmes malveillants;
• protéger les destinataires externes contre le trafic de courrier malveillant provenant de votre organisation;
• protéger le réseau interne et les réseaux externes contre les pourriels et les autres formes d’attaque visant le courrier électronique.

[PAZ-OBJ-112] Les objectifs de sécurité pour les mandataires d’entrée et de sortie utilisés par les services Web sont les suivants :

• isoler les réseaux internes de la ZP au moyen des services de mandataire;
• mettre fin aux connexions établies à l’intérieur de la ZD;
• protéger les réseaux externes des programmes malveillants;
• protéger le réseau interne des programmes malveillants.

[PAZ-OBJ-113] Les objectifs de sécurité pour les services de soutien communs sont les suivants :

• assurer la disponibilité continue des services d’infrastructure, tels que les services de nommage et d’annuaire, à l’appui des services et des applications de haut niveau;
• assurer l’intégrité des services de soutien communs fournis aux services et aux applications de haut niveau;
• protéger l’information privée utilisée et transportée par les services de soutien communs;
• assurer l’authentification des services homologues.

[PAZ-OBJ-114] Les objectifs de sécurité pour les services extranet sont les suivants :

• assurer une authentification mutuelle des interfaces extranet;
• assurer des contrôles d’accès pour restreindre l’accès aux ressources internes de l’organisation;
• se protéger contre le trafic malveillant provenant de partenaires;
• responsabiliser les partenaires extranet;
• protéger le réseau des partenaires du trafic malveillant provenant de votre organisation;
• protéger en cours de transmission les données échangées avec les utilisateurs extranet.

[PAZ-OBJ-115] Les objectifs de sécurité pour l’accès mobile et à distance pour les employés sont les suivants :

• assurer une authentification forte des utilisateurs à distance et des utilisateurs mobiles;
• permettre l’accès aux zones internes de l’organisation à tous les utilisateurs autorisés;
• sécuriser tout le trafic des accès à distance et des accès mobiles au moyen d’un réseau privé virtuel sécurisé.

[PAZ-OBJ-116] Les objectifs de sécurité pour les applications de prestation de services sont les suivants :

• assurer l’authentification d’entité des services homologues et des personnes, selon les besoins;
• assurer la confidentialité et la protection des renseignements personnels correspondant à la sensibilité de l’information et des services livrés par l’organisation;
• se protéger contre le trafic malveillant provenant des homologues et des utilisateurs de la prestation de services;
• protéger les dépôts de données de l’organisation par une séparation des applications de prestation de services exposées au public;
• assurer la disponibilité des services d’infrastructure conformément aux ententes (p. ex., haute disponibilité);
• se protéger contre le trafic malveillant provenant des homologues et des utilisateurs de la prestation de services;
• promouvoir la responsabilisation au niveau de la prestation de services.

Remarque: Les services de sécurité propres aux applications de prestation de services, comme les services de contrôle d’accès et de non-répudiation, devraient être fournis par des composants propres à l’application qui sont déployés dans la ZD.

A.4 Exigences de sécurité

Cette section décrit les exigences de base en matière de sécurité d’une ZAP. Elles sont classées en fonction des exigences opérationnelles (c.-à-d., selon les catégories interface réseau, contrôle du trafic, configuration réseau, configuration d’hôte et protection des données). Chaque catégorie d’exigences opérationnelles comporte les sous-catégories suivantes :

• exigences communes qui s’appliquent à l’ensemble de la ZT;
• exigences relatives à l’interréseau;
• exigences relatives au système de frontière interne (SFI);
• exigences des systèmes d’extrémité.

Pour satisfaire à tous les objectifs de sécurité décrits à la section A.3, il faut mettre en œuvre l’ensemble complet des exigences de sécurité mentionnées dans le tableau 7.

Tableau 7 : Exigences de base en matière de sécurité de la ZAP

Avant-propos

L’ITSP.80.022, Exigences de base en matière de sécurité pour les zones de sécurité de réseau, version 2, Annexe B – Zone de travail, est une publication NON CLASSIFIÉ.

La présente version de l’Annexe B de l’ITSP.80.022, version 2, remplace les versions précédentes.

Date d'entrée en vigueur

Le présent document entre en vigueur le 12 janvier 2021.

Historique des modifications

1 Introduction

Cette annexe présente les exigences de base en matière de sécurité qui s’appliquent à la zone de travail (ZT). Une ZT est l’environnement standard pour les activités courantes et le principal environnement dans lequel sont installés les systèmes à l’intention des utilisateurs finaux. Avec des contrôles de sécurité appropriés au niveau des systèmes d’extrémité, cette zone peut convenir au traitement de l’information sensible. Toutefois, elle ne convient généralement pas aux grands dépôts de données sensibles ni aux applications essentielles. En adoptant une approche de défense en profondeur pour assurer la sécurité de la ZT, il sera possible d’atténuer les menaces allant jusqu’au niveau Md4 inclusivement .^{Note de bas de page 9}

Dans une ZT, le trafic n’est généralement pas restreint et peut provenir de sources internes, à savoir d’une ZEAR, ou d’autres sources externes autorisées par l’intermédiaire de la ZAP. Parmi les exemples de sources de trafic externes, on retrouve l’accès distant, l’accès mobile et les extranets. Le trafic malveillant peut également provenir de sources hostiles internes, de codes hostiles importés de la zone publique ou de nœuds malveillants sur le réseau (p. ex. un hôte compromis, une connexion non autorisée à la zone).

B.2 Modèle de référence de la ZT

La présente section décrit le modèle de référence d’une ZT. Se reporter à la section 4.2 pour plus de renseignements sur le modèle de référence générique d’une zone et de ses composants.

Une ZT offre un environnement de réseau privé non spécialisé sous le contrôle direct ou partagé de votre organisation. La ZT est généralement la zone dans laquelle se trouve la majeure partie des ressources de technologies de l’information. Une ZT permet aux employés d’accéder aux services privés de votre organisation.

En règle générale, une ZT procure des points de connexion pour les stations de travail utilisées par les employés et les entrepreneurs de l’organisation pour accéder aux services privés dans les zones internes, et aux services publics dans la zone publique. La ZT peut également fournir des points de connexion pour les serveurs qui fournissent des services dorsaux à la ZAP et des services privés à une organisation.

Une ZT peut prendre en charge les fonctions indiquées dans le tableau 8. Ces dernières ont des objectifs et des exigences qui leur sont propres.

Tableau 8 : Fonctions prises en charge par une ZT

La ZT convient aux services d’information organisationnelle peu sensibles et courants. Cependant, avec des mesures de sécurité supplémentaires, une ZT peut traiter et distribuer de l’information organisationnelle sensible en utilisant des hôtes configurés à cet effet, des protocoles de sécurité sur les couches supérieures et des contrôles de sécurité au niveau des applications.

En général, les dépôts d’information sensible (p. ex. grandes bases de données d’entreprise ou bases de données contenant de l’information sensible) ne devraient pas être gérés dans la ZT.

Les applications à haute disponibilité sur des systèmes d’extrémité essentiels devraient être situées dans une ZAR ou dans une ZATR pour limiter leur susceptibilité aux attaques par déni de service (DoS). De plus, comme les services réseau de la ZT ne sont généralement pas conçus pour assurer une disponibilité élevée, on ne devrait pas les utiliser comme seule voie de communication pour les applications à disponibilité élevée. Cela n’empêche toutefois pas d’utiliser une ZT comme voie de communication principale pour les applications à disponibilité élevée, dans la mesure où les exigences de disponibilité globale du système sont respectées (p. ex. en prévoyant des voies de communication secondaires).

Les interfaces de tous les services publics sont mises en œuvre au moyen d’une ZAP. Les accès externes d’une ZT à Internet s’effectuent par l’intermédiaire d’une interface entre la ZT et la ZAP. Les interfaces des services et dépôts sensibles sont mises en œuvre au moyen de PIZ rigoureusement contrôlés entre les ZAR et les ZATR.

La structure d’une ZT est celle d’une zone générique (voir la figure 9 ci-dessous). Elle se compose des trois classes de composants décrits dans le tableau 9.

Tableau 9 : Composants de la ZT

La figure 9 présente une vue logique de la ZT et de l’interconnexion de ses composants. Elle offre également une vue de haut niveau de ses interconnexions avec les autres zones. Dans un souci de simplicité, le graphique ne fait pas mention de la ZG et de ses interconnexions. Se reporter à l’Annexe E pour les exigences relatives à la ZG et les recommandations de connexion.

Lorsque deux zones partagent un nœud (comme le système d’extrémité partagé illustré à la figure 9), les deux autorités de zones de sécurité devraient s’entendre sur la gestion et la supervision de ce nœud. Les entités de la ZT communiquent avec les autres zones par l’intermédiaire des PIZ, qui contrôlent les flux de trafic entrants et sortants.

Figure 9 : Topologie logique de la ZT

Description détaillée

La figure 9 présente une vue logique de la ZT et de l’interconnexion de ses composants. Elle offre également une vue de haut niveau de ses interconnexions avec les autres zones. Dans un souci de simplicité, le graphique ne fait pas mention de la ZG et de ses interconnexions.

B.3 Objectifs de sécurité de la ZT

En général, l’état de sécurité ciblée de la ZT est un environnement réseau qui empêche (c.-à-d. élimine la susceptibilité) les attaques provenant des réseaux, qui sont menées par des auteurs de menace de niveau Md4. L’état de sécurité ciblée de la ZT vise également à éviter que des auteurs de menace de niveau Md5 et supérieurs arrivent à exploiter les vulnérabilités de cette zone^{Note de bas de page 10}. On ne peut écarter l’hypothèse qu’un auteur de menace de niveau Md5 puisse contourner les mesures de sécurité d’une ZT. Il est donc nécessaire de prendre des mesures de sécurité supplémentaires pour protéger les biens sensibles se trouvant dans une ZT.

Chaque objectif ou exigence de sécurité mentionné dans la présente annexe est identifié suivant les règles de notation suivantes :

• le premier groupe de lettres (OZ pour Operation Zone) désigne la ZT;
• le second groupe de lettres précise s’il s’agit d’un objectif (OBJ) ou d’une exigence (REQ pour Requirement);
• les exigences (REQ) sont regroupées dans les catégories suivantes, le cas échéant :
  • Interface réseau (NI pour Network Interface);
  • Contrôle du trafic (TC pour Traffic control);
  • Configuration de réseau (NC pour Network Configuration);
  • Configuration d’hôte (HC pour Host Configuration);
  • Protection des données (DP pour Data Protection).

• chaque objectif ou exigence est numéroté en séquence dans son groupe, à partir de 100.
  Remarque : Les objectifs et les exigences ne sont pas indiqués en ordre séquentiel; certaines exigences ont été supprimées ou modifiées comparativement aux précédentes versions du présent document.

B.3.1 Objectifs de contrôle du trafic

[OZ-OBJ-100] Une ZT devrait protéger l’intégrité et la disponibilité des systèmes d’extrémité qui y sont connectés. Ses buts sont les suivants :

• empêcher les auteurs de menace de niveau Md4 de mener des attaques par déni de service (p. ex. inondation de messages SYN, attaque par DdoS) sur les systèmes d’extrémité;
• réduire sensiblement les attaques par déni de service sur les systèmes d’extrémité qui sont menées par toutes les autres sources;
• empêcher les auteurs de menace appartenant aux catégories de menace de niveau Md4 et inférieurs de s’introduire dans le réseau (p. ex. en connectant un dispositif non autorisé à une interface existante, en ajoutant une interface de bordure non autorisée) pour accéder aux systèmes d’extrémité;
• réduire l’incidence des intrusions réalisées par toutes les autres sources dans le réseau;
• contenir l’incidence de la compromission d’un système d’extrémité;
• empêcher les auteurs de menace jusqu’au niveau Md4 d’utiliser les systèmes d’extrémité comme base de lancement d’attaques contre d’autres systèmes;
• empêcher les autres sources de menace d’exploiter les systèmes d’extrémité comme base de lancement pour attaquer les autres systèmes;
• empêcher la propagation de trafic malveillant dans une ZT depuis d’autres zones;
• prévenir la propagation des maliciels.

[OZ-OBJ-102] Une ZT devrait permettre de renforcer les mesures de sécurité en réponse à un accroissement du niveau de la menace (période de crise), notamment :

• au moyen de contrôles de trafic souples et dynamiques;
• en s’assurant que les fournisseurs de services réseau accroissent leur surveillance de l’infrastructure réseau impartie.

Remarque: Les mesures de sécurité réseau ont une efficacité limitée pour la protection des systèmes d’extrémité contre les compromissions à partir d’interfaces d’applications valides. Il convient de mettre en place des mesures visant les plateformes, les applications et la sécurité opérationnelle en vue d’atténuer les risques associés à ce type de menace.

[OZ-OBJ-103] La ZAP met en œuvre des mesures de protection visant à assurer une protection efficace contre le trafic malveillant en provenance des réseaux publics, mais cette protection n’est pas complètement étanche et les risques résiduels devraient être pris en compte au niveau de la ZT. L’objectif de la ZT consiste donc à réduire :

• la vulnérabilité aux attaques découlant de la compromission d’un accès distant et provenant des systèmes d’extrémité sur l’extranet;
• les attaques en provenance d’un hôte compromis qui se trouve dans une ZAP et les lacunes émanant des mesures de contrôle du trafic dans la ZAP;
• le trafic malveillant en provenance des serveurs d’applications compromis qui assurent la prestation de services dans une ZAP.

Remarque : Il est possible d’atténuer la menace d’une piste malveillante émanant de services d’applications utilisés aux fins de prestation de services en limitant l’accès des services aux ressources et aux protocoles désignés.

B.3.2 Objectifs de la disponibilité et l’intégrité du réseau

[OZ-OBJ-104] Une ZT devrait protéger l’intégrité et la disponibilité des services réseau en réduisant leur susceptibilité à divers types d’attaques. Les buts particuliers de la ZT devraient être les suivants :

• empêcher les auteurs de menace appartenant aux catégories de menace de niveau Md4 et inférieurs de mener des attaques par DoS en provenance des réseaux (p. ex. inondation de messages SYN, attaque par DDoS) dans les systèmes d’extrémité;
• réduire l’incidence des attaques par déni de service sur les systèmes d’extrémité qui sont menées par toutes les autres sources;
• empêcher les auteurs de menace appartenant aux catégories de menace de niveau Md4 et inférieurs de s’introduire dans le réseau (p. ex. en connectant un dispositif non autorisé à une interface existante, en ajoutant une interface de bordure non autorisée) pour accéder aux systèmes d’extrémité;
• réduire l’incidence des attaques par déni de service sur les systèmes d’extrémité qui sont menées par toutes les autres sources;
• contenir l’incidence de la compromission d’un système d’extrémité;
• empêcher les auteurs de menace jusqu’au niveau Md4 d’utiliser les systèmes d’extrémité comme base de lancement d’attaques contre d’autres systèmes;
• empêcher les autres sources de menace d’utiliser les systèmes d’extrémité comme base de lancement d’attaques contre d’autres systèmes;
• empêcher la propagation de trafic malveillant dans une ZT depuis d’autres zones;
• prévenir la propagation des maliciels.

B.3.3 Objectifs de la protection des données

[OZ-OBJ-105] Une ZT devrait empêcher les auteurs de menace appartenant aux catégories de menace de niveau Md4 et inférieurs d’intercepter le trafic dans la zone et être en mesure de réduire la susceptibilité aux interceptions non détectées de toutes les autres sources.

[[OZ-OBJ-106] Une ZT devrait prendre en charge les mesures suivantes pour protéger la confidentialité et l’intégrité des données :

• RPVS dans l’interréseau;
• RPVS en tant que service de données facultatif;
• protocoles de sécurité de la couche supérieure.

Remarque : Les employés d’une autre organisation pourraient être tenus d’accéder de façon sécurisée aux services réseau et à leurs réseaux domestiques. Dans de tels cas, il pourrait être nécessaire de fournir un accès temporaire par l’entremise d’un point d’accès situé dans une salle de conférence, ou un accès permanent, aux employés désignés de l’organisation hôte.

B.4 Exigences de base en matière de sécurité de la ZT

Le tableau 10 décrit les exigences de base en matière de sécurité d’une ZT. Elles sont classées en fonction des exigences opérationnelles (c.-à-d. selon les catégories interface réseau, contrôle du trafic, configuration réseau, configuration d’hôte et protection des données). Pour satisfaire à tous les objectifs de sécurité pour cette zone, il faut mettre en œuvre l’ensemble des exigences de base en matière de sécurité.

Au minimum, il est recommandé de mettre en œuvre les exigences de base en matière de sécurité. Vous devriez toutefois consulter les contrôles mentionnés dans l’ITSG-33 [4] pour déterminer s’il est nécessaire de mettre en place des mécanismes techniques, opérationnels et de gestion additionnels pour atténuer les menaces de niveau Md4 prévues.

Tableau 1 : Exigences de base en matière de sécurité de la ZT

Avant-propos

L’ITSP.80.022, Exigences de base en matière de sécurité pour les zones de sécurité de réseau, version 2 : Annexe C – Zone d’accès restreint est une publication NON CLASSIFIÉ.

La présente version de l’annexe C remplace toutes les versions antérieures du document.

Date d'entrée en vigueur

Le présent document entre en vigueur le 12 janvier 2021.

Historique des modifications

Annexe C - Exigences de sécurité de base pour la zone d’accès restreint (ZAR)

Introduction

La présente annexe fait mention des exigences de base en matière de sécurité d’une ZAR, à savoir l’environnement standard pour un ensemble de systèmes d’extrémité. Les parcs de serveurs, les réseaux de stockage et les serveurs de gestion sont principalement installés dans une ZAR. Cette zone peut également comporter des enclaves de systèmes d’extrémité exigeant des niveaux de protection plus élevés que ceux offerts dans une ZT.

La ZAR convient au traitement des informations sensibles, au stockage dans des référentiels volumineux de données sensibles et à l’exécution d’applications essentielles. En adoptant une approche à la sécurité axée sur la défense en profondeur et en renforçant la robustesse des mécanismes de sécurité dans la zone, on peut s’attendre à ce qu’une ZAR arrive à atténuer les menaces correspondant à un niveau pouvant aller jusqu’à Md4 inclusivement ^{Note de bas de page 11}.

Une ZAR prend en charge des interfaces pour des zones contrôlées par l’organisation, des ZT et des ZATR. Les systèmes d’extrémité d’une ZAR peuvent servir aux applications publiques (atténuées par l’intermédiaire d’une ZT et d’une ZAP). Au sein de la ZAR, le trafic devrait être restreint pour limiter les éventuels chevauchements entre les domaines de sécurité de la plateforme et des applications. Il convient de passer en revue les résultats du PASSI pour déterminer s’il est nécessaire d’ajouter des contrôles de sécurité supplémentaires et d’accroître les niveaux de robustesse des dispositifs sélectionnés pour la mise en œuvre de ces contrôles.

C.2 Modèle de référence d’une ZAR

Une ZAR offre un environnement réseau privé et polyvalent, qui relève du contrôle unique ou partagé d’une organisation. Pour plusieurs organisations, une grande partie des ressources TI sensibles seront stockées dans une ZAR.

L’environnement réseau d’une ZAR prend en charge le déploiement d’applications à disponibilité élevée et offre une protection suffisante pour contrer les attaques par déni de service. Toutefois, les conseils formulés dans la présente annexe n’exigent pas que la ZAR soit conçue de manière à assurer une disponibilité ou une intégrité élevée.

Les interfaces de tous les services publics sont mises en œuvre au moyen d’une ZT et d’une ZAP. L’accès externe d’une ZAR par l’intermédiaire d’Internet est fourni par une interface qui achemine le trafic de la ZAR à la ZAP par l’intermédiaire d’une ZT. L’accès à une ZAR à partir d’une autre organisation est assuré par des interfaces entre zones homologues (c.-à-d., ZT, ZAR et ZATR). Les interfaces aux services et dépôts sensibles sont mises en œuvre au moyen d’interfaces rigoureusement contrôlées.

La structure d’une ZAR est similaire à celle d’une zone générique; elle comprend les trois classes de composants décrits dans le tableau 11.

Tableau 11 : Composants de la ZAR

La figure 10 offre une vue logique d’une ZAR et de ses connexions aux autres zones. Pour simplifier le diagramme, la ZG et les connexions à la ZG ne sont pas illustrées à la figure 10. Se reporter à l’annexe E pour les exigences de la ZG et des recommandations concernant les connexions.

Si un nœud chevauche deux zones, comme c’est le cas pour le système d’extrémité partagé illustré à la figure 10, les autorités de ces deux zones de sécurité réseau devront convenir de la façon d’assurer la gestion et la surveillance du nœud en question.

Tel qu’il est décrit à l’annexe F, un PIZ permet aux entités d’une ZAR d’interfacer avec les autres zones. Les PIZ contrôlent les flux de trafic entrants et sortants aux points où la ZAR est connectée avec les autres zones.

Figure 10 : Topologie logique de la ZAR

Description détaillée

La figure 10 offre une vue logique d’une ZAR et de ses connexions aux autres zones. Pour simplifier le diagramme, la ZG et les connexions à la ZG ne sont pas illustrées à la figure 10.

C.3 Objectifs de sécurité

L’état de sécurité ciblée d’une ZAR est de fournir un environnement réseau contrôlé qui convient aux fonctions suivantes :

• les services de plateforme et d’application d’entreprise;
• les enclaves de clients qui exigent des niveaux de protection plus élevés.

Une ZAR se caractérise par des mesures de contrôle plus strictes en ce qui a trait à la configuration de réseau et par une surveillance minutieuse du trafic. Les mesures de contrôle du trafic mises en œuvre dans la ZAR sont conçues pour contenir les défaillances de sécurité.

L’état de sécurité ciblée d’une ZAR vise également à atténuer les menaces posées par des auteurs de menace appartenant aux catégories de niveau Md4 et inférieurs. On suppose toutefois que des auteurs de menace de niveau Md5^{Note de bas de page12} pourraient arriver à contourner les contrôles de sécurité réseau d’une ZAR. Une ZATR peut être mise en œuvre pour atténuer les menaces posées par des auteurs de menace appartenant aux catégories de menace de niveau Md5 et inférieurs.

Chaque objectif ou exigence mentionné dans la présente annexe est identifié suivant les règles de notation suivantes :

• le premier groupe de lettres (RZ pour Restrictive Zone) désigne la ZAR;
• le second groupe de lettres précise s’il s’agit d’un objectif (OBJ) ou d’une exigence (REQ pour Requirement).
• Les exigences sont regroupées selon les catégories suivantes, le cas échéant :
  • Interface réseau (NI pour Network Interface);
  • Contrôle du trafic (TC pour Traffic control);
  • Configuration réseau (NC pour Network Configuration);
  • Configuration d’hôte (HC pour Host Configuration);
  • Protection des données (DP pour Data Protection).

• Chaque objectif ou exigence est numéroté en ordre séquentiel dans son groupe, à partir de 100.
  Remarque : Les objectifs et les exigences ne sont pas indiqués en ordre séquentiel; certaines exigences ont été supprimées ou modifiées comparativement aux précédentes versions du présent document.

C.3.1 Objectifs de contrôle du trafic

[RZ-OBJ-100] Une ZAR devrait protéger l’intégrité et la disponibilité des systèmes d’extrémité qui y sont connectés. Une ZAR devrait réaliser les objectifs suivants :

• empêcher les auteurs de menace appartenant aux catégories de menace de niveau Md4 et inférieurs de mener des attaques par DoS en provenance des réseaux (p. ex. inondation de messages SYN, attaque par DDoS) dans les systèmes d’extrémité;
• limiter l’incidence des attaques sur les systèmes d’extrémité lorsque des attaques par déni de service sont menées par d’autres sources de menace ;^{Note de bas de page 13};
• empêcher les auteurs de menace appartenant aux catégories de menace de niveau Md4 et inférieurs de s’introduire dans le réseau (p. ex. en connectant un dispositif non autorisé à une interface existante, en ajoutant une interface de bordure non autorisée) pour accéder aux systèmes d’extrémité;
• réduire l’incidence des intrusions dans le réseau réalisées par toutes les autres sources de menace;
• contenir l’incidence d’un système d’extrémité compromis;
• empêcher les auteurs de menace appartenant aux catégories de menace de niveau Md4 et inférieurs d’exploiter les systèmes d’extrémité comme base de lancement pour attaquer les autres systèmes;
• empêcher les autres sources de menace d’exploiter les systèmes d’extrémité comme base de lancement pour attaquer les autres systèmes;
• éviter que le trafic malveillant en provenance d’autres zones se propage dans une ZAR;
• prévenir la propagation des maliciels.

[RZ-OBJ-102] Une ZAR devrait permettre de renforcer les mesures de sécurité en réponse à un accroissement du niveau de la menace (p. ex. en temps de crise) en faisant appel, notamment :

• à des contrôles de trafic souples et dynamiques;
• à une surveillance renforcée de l’état de la ZAR.

[RZ-OBJ-103] Les zones et les PIZ mettent en œuvre les mesures de protection visant à assurer une protection contre le trafic malveillant en provenance des réseaux publics. La ZAR devrait toutefois tenir compte de tout risque résiduel en vue de réaliser les objectifs suivants :

• réduire la vulnérabilité aux attaques découlant de la compromission d’un accès distant et provenant des systèmes d’extrémité sur l’extranet;
• réduire la vulnérabilité au trafic malveillant découlant de la compromission des serveurs d’application de prestation de services dans les zones en mettant en place les mesures de protection nécessaires (p. ex. limiter l’accès de ces serveurs aux ressources et protocoles désignés);
• réduire la vulnérabilité aux attaques découlant de la compromission des hôtes, autres qu’un serveur d’application de prestation de services, dans la ZT ou la ZAP;
• réduire la vulnérabilité aux défaillances des mesures de contrôle du trafic dans la ZAR, notamment les intrusions depuis les interréseaux des autres zones.

C.3.2 Objectifs de la disponibilité et de l’intégrité du réseau

[RZ-OBJ-104] Une ZAR devrait protéger l’intégrité et la disponibilité des services réseau en réduisant leur susceptibilité à divers types d’attaques, et permettre de réaliser les objectifs suivants :

• empêcher les auteurs de menace appartenant aux catégories de menace de niveau Md4 et inférieurs de mener des attaques par déni de service en provenant des réseaux en filtrant les attaques malveillantes depuis l’extérieur de la ZAR;
• empêcher les auteurs de menace appartenant aux catégories de menace de niveau Md4 et inférieurs de s’introduire dans le réseau (p. ex. en connectant un dispositif non autorisé à une interface existante, en ajoutant une interface de bordure non autorisée ou en compromettant un système d’extrémité connecté à la zone);
• rendre les réseaux moins vulnérables aux intrusions menées depuis d’autres sources;
• empêcher les auteurs de menace appartenant aux catégories de menace de niveau Md4 et inférieurs d’exploiter les systèmes d’extrémité comme base de lancement pour attaquer les services du réseau;
• empêcher les autres sources de menace d’exploiter les systèmes d’extrémité comme base de lancement pour attaquer les services du réseau.

C.3.3 Objectifs de la protection des données

[RZ-OBJ-105] Une ZAR devrait empêcher les auteurs de menace appartenant aux catégories de menace de niveau Md4 et inférieurs d’intercepter le trafic dans la zone et de détecter toute interception du trafic par d’autres sources.

[RZ-OBJ-106] Une ZAR devrait prendre en charge les mesures suivantes pour protéger la confidentialité et l’intégrité des données :

• RPVS dans l’interréseau;
• RPVS en tant que service de données facultatif;
• protocoles de sécurité de la couche supérieure.

C.4 Exigences de base en matière de sécurité

Cette section décrit les exigences de base en matière de sécurité d’une ZAR. Elles sont classées en fonction des exigences opérationnelles (c.-à-d., selon les catégories interface réseau, contrôle du trafic, configuration réseau, configuration d’hôte et protection des données).

Pour satisfaire à tous les objectifs de sécurité pour cette zone, il faut mettre en œuvre l’ensemble complet des exigences de base en matière de sécurité mentionnées dans le tableau 12. Bien qu’il s’agisse d’exigences de base minimales pour une ZAR, vous devriez consulter les contrôles mentionnés dans l’ITSG-33 [4] afin de déterminer s’il convient de mettre en place des mécanismes techniques, opérationnels et de gestion additionnels pour atténuer les menaces correspondant au niveau Md4 prévu.

Tableau 12 : Exigences de base en matière de sécurité des ZAR

Avant-propos

Le document ITSP.80.022, Exigences de base en matière de sécurité pour les zones de sécurité de réseau (Version 2), Annexe D – Zone d’accès très restreint est une publication NON CLASSIFIÉ.

La présente version remplace toutes les versions précédentes de l’annexe D.

Date d'entrée en vigueur

Le présent document entre en vigueur le 12 janvier 2021.

Historique des modifications

Annexe D Exigences de sécurité de base pour la zone d’accès très restreint (ZATR)

D.1 Introduction

La présente annexe décrit les exigences de base en matière de sécurité d’une ZATR. La ZATR est conçue pour les services de plateforme et d’application d’entreprise et pour les enclaves clients nécessitant les plus hauts niveaux de sécurité.

Elle procure un environnement de réseau rigoureusement contrôlé adapté aux trois types de services suivants :

1. les applications essentielles à la sécurité (c.-à-d., les applications dont les exigences en matière de disponibilité et d’intégrité sont élevées, puisque la compromission des systèmes informatiques pourrait entraîner des risques pour la santé humaine et la sécurité);
2. l’information partiellement sensible (c.-à-d., l’information personnelle ou opérationnelle jusqu’au niveau PROTÉGÉ B) et l’information non classifiée qui est recueillie dans un vaste dépôt dont la compromission pourrait entraîner des risques élevés;
3. l’information hautement sensible (c.-à-d., l’information personnelle ou opérationnelle jusqu’au niveau PROTÉGÉ C) et l’information classifiée (p. ex. l’information de niveau CONFIDENTIEL, SECRET ou TRÈS SECRET d’intérêt national pour le Canada.

La présente annexe fait mention des exigences applicables à une ZATR pour les deux premiers types de services mentionnés précédemment. Pour de l’orientation sur les exigences applicables à une ZATR qui traitent de l’information classifiée et de l’information de nature très sensible (PROTÉGÉ C), prière de communiquer avec le Centre de contact par courriel ou par téléphone.

D.2 Modèle de référence d’une ZATR

Une ZATR offre un environnement de réseau privé non spécialisé sous le contrôle direct ou partagé d’une organisation. Les contrôles de sécurité de réseau d’une ZATR doivent être en mesure de protéger adéquatement les applications à disponibilité élevée contre les attaques par DoS. En adoptant une approche à la sécurité axée sur la défense en profondeur et en renforçant la robustesse des mécanismes de sécurité dans la zone, une ZATR peut atténuer les menaces correspondant à un niveau pouvant aller jusqu’à Md5 inclusivement .^{Note de bas de page14}

Les interfaces de tous les services publics devraient être justifiées par les résultats du PASSI et mises en œuvre au moyen d’une ZAR, puis d’une ZT et d’une ZAP. L’accès aux autres organisations pourrait être fourni par l’entremise d’interfaces vers des ZATR ou ZAR homologues. Les interfaces aux services et dépôts sensibles devraient être mises en œuvre au moyen des interfaces rigoureusement contrôlées fournies par les PIZ.

La présente section décrit le modèle de référence de la ZATR, lequel découle du modèle de référence générique. Une ZATR comprend les composants mentionnés au tableau 13.

Tableau 13 : Composants de la ZATR

La figure 11 offre une vue logique d’une ZATR et de ses connexions aux autres zones. Dans un souci de simplicité, le graphique ne fait pas mention de la ZG et de ses interconnexions. Se reporter à l’Annexe E pour les exigences relatives à la ZG et les recommandations de connexion.

Lorsque deux zones partagent un nœud (comme le système d’extrémité partagé illustré à la figure 11), les deux autorités de zones de sécurité devraient s’entendre sur la gestion et la supervision de ce nœud.

Tel qu’il est décrit à l’annexe F, un PIZ permet aux entités d’une ZATR d’interfacer avec les autres zones. Les PIZ contrôlent les flux de trafic entrants et sortants aux points où la ZATR est connectée avec les autres zones.

Figure 11 : Topologie logique de la ZATR

Description détaillée

La figure 11 offre une vue logique d’une ZATR et de ses connexions aux autres zones. Dans un souci de simplicité, le graphique ne fait pas mention de la ZG et de ses interconnexions.

D.3 Objectifs de sécurité de la ZATR

En règle générale, l’état de sécurité ciblée d’une ZATR est de fournir un environnement réseau contrôlé qui convient aux services de plateforme et d’application d’entreprise et aux enclaves clients nécessitant les plus hauts niveaux de sécurité. Ces objectifs s’appliquent aux deux types de services suivants :

• les applications essentielles à la sécurité (c.-à-d., les applications dont les exigences en matière de disponibilité et d’intégrité sont élevées, puisque la compromission des systèmes informatiques pourrait entraîner des risques pour la santé humaine et la sécurité);
• l’information partiellement sensible (c.-à-d., l’information personnelle ou opérationnelle jusqu’au niveau PROTÉGÉ B) et l’information non classifiée qui est recueillie dans un vaste dépôt dont la compromission pourrait entraîner des risques élevés.

Une ZATR se caractérise par des contrôles de configuration de réseau et d’hôte plus rigoureux et par un flux de trafic soigneusement contrôlé. Les mesures de contrôle du trafic mises en œuvre dans la ZATR sont conçues pour contenir les défaillances de sécurité.

Chaque objectif ou exigence mentionné dans la présente annexe est identifié suivant les règles de notation suivantes :

• le premier groupe de lettres (HRZ pour Highly Restricted Zone) désigne la ZATR;
• le second groupe de lettres précise s’il s’agit d’un objectif (OBJ) ou d’une exigence (REQ pour Requirement);
• les exigences (REQ) sont regroupées dans les catégories suivantes, le cas échéant :
  • Interface réseau (NI pour Network Interface);
  • Contrôle du trafic (TC pour Traffic control);
  • Configuration de réseau (NC pour Network Configuration);
  • Configuration d’hôte (HC pour Host Configuration);
  • Protection des données (DP pour Data Protection).
• chaque objectif ou exigence est numéroté en séquence dans son groupe.

Remarque : Les objectifs et les exigences ne sont pas indiqués en ordre séquentiel; certaines exigences ont été supprimées ou modifiées comparativement aux précédentes versions du présent document.

D.3.1 Objectifs de contrôle du trafic

[HRZ-OBJ-100] Une zone d’accès très restreint (ZATR) devrait protéger l’intégrité et la disponibilité des systèmes d’extrémité qui lui sont rattachés en empêchant le transit de trafic réseau malveillant, y compris le trafic réseau provenant d’un petit nombre de membres du personnel responsable du système ou provenant d’applications compromises. Ses buts sont les suivants :

• empêcher les auteurs de menace jusqu’au niveau Md5 de mener des attaques par déni de service (p. ex. inondation de messages SYN, attaque par DdoS) sur les systèmes d’extrémité;
• réduire sensiblement les attaques par déni de service sur les systèmes d’extrémité qui sont menées par toutes les autres sources^{Note de bas de page15};
• interdire l’accès aux systèmes d’extrémité à la suite d’une intrusion dans le réseau (comme le raccordement d’un dispositif non autorisé à une interface existante ou l’ajout non autorisé d’une interface périphérique) par des auteurs de menace jusqu’au niveau Md5;
• réduire la vulnérabilité des systèmes d’extrémité aux intrusions réalisées par toutes les autres sources;
• contenir l’incidence de la compromission d’un système d’extrémité;
• empêcher les auteurs de menace jusqu’au niveau Md5 d’utiliser les systèmes d’extrémité comme base de lancement d’attaques contre d’autres systèmes;
• empêcher les autres sources de menace d’utiliser les systèmes d’extrémité comme base de lancement d’attaques contre d’autres systèmes;
• empêcher la propagation de trafic malveillant dans une ZATR depuis d’autres zones;
• prévenir la propagation des maliciels.

Les mesures de sécurité réseau ont une efficacité limitée pour ce qui est de protéger les systèmes d’extrémité contre les compromissions à partir d’interfaces d’applications valides. Les mesures de sécurité liées aux plateformes, aux applications et aux opérations peuvent limiter les risques associés à ces types de menaces. Le seul trafic réseau malveillant pouvant transiter par une ZATR proviendrait des membres du personnel ou d’applications compromises.

[HRZ-OBJ-101] Une ZATR devrait permettre l’évaluation continue du trafic d’interface avec les autres zones (p. ex. autres ZATR, ZAR et ZG) et valider les hypothèses sur l’environnement de sécurité que constituent les zones adjacentes.

[HRZ-OBJ-102] Une ZATR devrait permettre de renforcer les mesures de sécurité en réponse à un accroissement du niveau de la menace (période de crise), notamment :

• à des contrôles de trafic souples et dynamiques basés sur les communautés d’intérêt;
• à une surveillance renforcée de l’état de la ZATR.

[HRZ-OBJ-103] La ZT et la ZAR comportent des mesures de protection visant à assurer une protection efficace contre le trafic réseau malveillant en provenance des réseaux publics. Les risques résiduels émanant des autres zones devraient toutefois être atténués dans la ZATR en tenant compte des objectifs suivants :

• réduire la vulnérabilité aux attaques découlant de la compromission d’un accès distant et provenant des systèmes d’extrémité sur l’extranet;
• réduire la vulnérabilité au trafic malveillant découlant de la compromission des serveurs d’application de prestation de services dans les zones en limitant l’accès de ces serveurs aux ressources et protocoles désignés;
• réduire la vulnérabilité aux attaques découlant de la compromission des hôtes dans d’autres zones;
• réduire la vulnérabilité aux défaillances des mesures de contrôle du trafic dans les autres zones, notamment les intrusions depuis les interréseaux.

D.3.2 Objectifs de la disponibilité et l’intégrité du réseau

[HRZ-OBJ-104] Une ZATR devrait protéger l’intégrité et la disponibilité des services réseau en réduisant leur susceptibilité à divers types d’attaques, et permettre de réaliser les objectifs suivants :

• filtrer les attaques malveillantes provenant de l’extérieur d’une ZATR afin de réduire la vulnérabilité des services réseau aux attaques par DoS qui sont menées par des sources de menace;
• empêcher les auteurs de menace appartenant aux catégories de menace de niveau Md5 et inférieurs de s’introduire dans le réseau (p. ex. en connectant un dispositif non autorisé à une interface existante, en ajoutant une interface de bordure non autorisée ou en compromettant un système d’extrémité connecté à la zone);
• rendre les services réseau moins vulnérables aux intrusions menées depuis d’autres sources de menace;
• empêcher les auteurs de menace appartenant aux catégories de menace de niveau Md5 et inférieurs d’utiliser les systèmes d’extrémité comme base de lancement d’attaques contre les services réseau;
• empêcher les autres sources de menace d’utiliser les systèmes d’extrémité comme base de lancement d’attaques contre les services réseau.

D.3.3 Objectifs de la protection des données

[HRZ-OBJ-105] Une ZATR devrait empêcher les auteurs de menace appartenant aux catégories de menace de niveau Md5 et inférieurs d’intercepter le trafic de la zone. Elle devrait également détecter l’interception du trafic par d’autres sources de menace.

[HRZ-OBJ-106] Une ZATR devrait prendre en charge les mesures suivantes pour protéger la confidentialité et l’intégrité des données :

• RPVS dans l’interréseau;
• RPVS en tant que service de données facultatif;
• protocoles de sécurité de la couche supérieure.

Les employés d’une autre organisation pourraient être tenus d’accéder de façon sécurisée aux services réseau et à leurs réseaux domestiques. Dans de tels cas, il pourrait être nécessaire de fournir un accès temporaire par l’entremise d’un point d’accès situé dans une salle de conférence, ou un accès permanent, aux employés désignés de l’organisation hôte.

D.4 Exigences de base en matière de sécurité de la ZATR

Cette section décrit les exigences de base en matière de sécurité d’une ZATR. Elles sont classées dans le tableau 14 en fonction des exigences opérationnelles (c.-à-d., selon les catégories interface réseau, contrôle du trafic, configuration réseau, configuration d’hôte et protection des données). Pour satisfaire à tous les objectifs de sécurité d’une ZATR, tel qu’il est décrit précédemment, il faut mettre en œuvre l’ensemble des exigences de base en matière de sécurité.

Il s’agit des exigences de sécurité minimales pour cette zone. Vous devriez consulter les contrôles mentionnés dans l’ITSG 33 [4] afin de déterminer s’il convient de mettre en place des mécanismes techniques, opérationnels et de gestion additionnels pour atténuer les menaces correspondant au niveau Md5 prévu.

Tableau 14 : Exigences de base en matière de sécurité de la ZATR

Avant-propos

L’ITSP.80.022, Exigences de base en matière de sécurité pour les zones de sécurité de réseau, version 2, Annexe E – Zone de gestion, est une publication NON CLASSIFIÉ.

La présente version remplace toutes les versions précédentes de l’annexe E.

Date d'entrée en vigueur

Le présent document entre en vigueur le 12 janvier 2021.

Historique des modifications

Annexe E Exigences de sécurité de base pour la zone de gestion (ZG)

E.1 Introduction

La présente annexe fait mention des exigences de base en matière de sécurité d’une ZG), à savoir l’environnement propre à un ensemble de systèmes de gestion d’extrémité. Cette zone sert à séparer les activités et les services de gestion de ceux de l’organisation.

Une ZG est une zone isolée physiquement dont la robustesse est équivalente à celle d’une ZAR ou d’une ZATR, selon ce qui a été déterminé dans le cadre du PASSI. La ZG offre aux administrateurs de TI et de la sécurité un réseau d’administration dédié et isolé au moyen duquel ils peuvent configurer et surveiller les infrastructures et les services informatiques du réseau. Elle procure également l’infrastructure, la plateforme et les applications nécessaires pour que les administrateurs et opérateurs de la sécurité puissent gérer les réseaux connexes de manière à atténuer le risque que survienne une éventuelle interception ou compromission.

La présente annexe décrit les deux approches architecturales à la mise en place d’une ZG :

• Approche de la ZG isolée : Mise en place de plusieurs ZG, chacune d’entre elles étant dédiée à la gestion d’une zone donnée et n’ayant aucune connexion directe aux autres ZG;
• Approche de la ZG consolidée : Mise en place d’une seule ZG qui permet de gérer plusieurs zones.

Les résultats du PASSI permettront de déterminer s’il est préférable d’utiliser une architecture isolée ou consolidée pour la ZG. Selon les résultats, les instances de la ZG pourraient être virtualisées si les deux conditions suivantes sont satisfaites :

• le niveau d’assurance offert par la séparation logique est satisfaisant;
• les intervenants reconnaissent et acceptent les risques associés à la possible compromission des ZG virtualisées.

Une ZG offre un environnement de réseau unique et isolé sous le contrôle direct ou partagé d’une organisation ou d’une entité contractuelle.

Une ZG procure un environnement de sécurité réseau offrant une protection suffisante pour prendre en charge le déploiement de services de gestion à disponibilité élevée.

E.2 Modèle de référence de la ZG

La présente section décrit le modèle de référence de la ZG, lequel découle du modèle de référence générique. Une ZG sépare les activités et les services de gestion de ceux de l’organisation. L’exécution des activités de gestion dans un environnement distinct donne lieu aux avantages suivants :

• il y moins de risque que des vulnérabilités (y compris les menaces internes) mènent à la compromission de la ZG;
• les autorités de zone de sécurité de réseau peuvent détecter plus facilement les compromissions sur le réseau, ce qui simplifie les enquêtes subséquentes;
• les administrateurs de TI peuvent maintenir, récupérer et rétablir les services de TI plus rapidement.

Une ZG se compose des trois classes de composants mentionnés dans le tableau 15.

Tableau 15 : Composants de la ZG

E.3 Approches architecturales de la ZG

La présente section décrit les deux approches architecturales liées à la mise en œuvre d’une ZG :

• approche de la ZG isolée :
• approche de la ZG consolidée.

Selon l’approche de la ZG isolée, plusieurs ZG sont mises en œuvre et chacune d’entre elles gère un type de zone. Cette approche est recommandée pour les secteurs d’une organisation qui sont tenus de traiter de l’information sensible dans le cadre de leurs activités opérationnelles. Selon l’approche de la ZG consolidée, une ZG est mise en œuvre pour gérer plusieurs zones dans un environnement de TI. Vous devriez utiliser les résultats du PASSI pour déterminer s’il convient d’adopter l’approche de la ZG consolidée.

Figure 12 : Approches architecturales de la ZG

Description détaillée

Figure 12 illustre les deux approches architecturales liées à la mise en œuvre d’une ZG : approche de la ZG isolée et approche de la ZG consolidée. Selon l’approche de la ZG isolée, plusieurs ZG sont mises en œuvre et chacune d’entre elles gère un type de zone. Selon l’approche de la ZG consolidée, une ZG est mise en œuvre pour gérer plusieurs zones dans un environnement de TI.

E.3.1 Architecture de la zone de gestion isolée

Le modèle de ZG isolée est l’approche recommandée pour assurer la sécurité des systèmes d’information qui traitent l’information sensible. En règle générale, le niveau de robustesse d’une ZG isolée est plus élevé que celui d’une ZG consolidée.

Selon l’approche de la ZG isolée, des instances distinctes de la ZG sont mises en œuvre pour gérer la sécurité du réseau. Les ZG distinctes interagissent avec les zones (c.-à-d., la ZAP, la ZT, la ZAR ou la ZATR) par l’entremise des PIZ qui ont été déployés pour soutenir les fonctions de gestion. Par exemple, la ZT-ZG communique avec la ZT par l’entremise du PIZ de la ZT-ZG, et la ZAR-ZG communique avec la ZAR par l’entremise du PIZ de la ZAR-ZG. Ces PIZ connectés à la ZG ne sont pas les mêmes que les déploiements de PIZ qui prennent en charge les communications entre les zones de sécurité de réseau (p. ex. PIZ de la ZT-ZAP, PIZ de la ZAR-ZT). Les PIZ connectés à la ZG contrôlent les flux de trafic entrants et sortants aux points où les ZG sont connectées avec leurs zones respectives.

Le trafic de gestion entre les ZG et les autres zones devrait être isolé physiquement du trafic de données (c.-à-d., avoir recours à une infrastructure réseau distincte et à la gestion hors bande). Les ZG ne devraient jamais avoir un accès direct à la connectivité réseau d’une ZP.

La figure 13 illustre les ZG, et les PIZ respectifs, dans une approche isolée. Par exemple, la ZAP-ZG interface avec une ZAP par l’entremise du PIZ de la ZAP-ZG. La ZAR interface avec une ZT par l’entremise du PIZ de la ZAR-ZT.

Figure 13 : Approche de la ZG isolée

Description détaillée

La figure 13 illustre les ZG, et les PIZ respectifs, dans une approche isolée. Par exemple, la ZAP-ZG interface avec une ZAP par l’entremise du PIZ de la ZAP-ZG. La ZAR interface avec une ZT par l’entremise du PIZ de la ZAR-ZT.

Selon l’approche de la ZG isolée, la virtualisation des ZG (p. ex. ZAP-ZG, ZT-ZG et ZAR-ZG), tel qu’il est illustré à la figure 14, devrait être envisagée si l’assurance d’une séparation logique offerte par la plateforme sous-jacente répond au niveau d’assurance déterminé lors du PASSI.

Les PIZ connectés à la ZG devraient être virtualisés selon les résultats du PASSI. Les PIZ des chemins de données devraient également être virtualisés. La virtualisation des PIZ connectés à la ZG et les PIZ des chemins de données devrait toutefois être effectuée sur des plateformes séparées physiquement (voir l’annexe F pour des conseils détaillés sur les PIZ).

Figure 14 : Virtualisation de la ZG

Description détaillée

Figure 14 illustre la virtualisation des ZG selon l’approche de la ZG isolée.

E.4 Séparation des rôles administratifs

L’approche de la ZG consolidée consiste à mettre en place une ZG qui s’étend sur plusieurs zones (voir la partie gauche de la figure 14 ci-dessus).

La ZAP contient les services Internet et est la zone la plus vulnérable pour ce qui est de l’établissement des zones de sécurité dans un réseau. La ZAP est plus susceptible d’être compromise par des auteurs de menace délibérée. Ces auteurs de menace pourraient obtenir accès à la zone et compromettre les services de gestion de la ZG consolidée en vue de prendre le contrôle des autres zones. L’examen des résultats du PASSI permettra de déterminer s’il convient d’utiliser une architecture de ZG consolidée.

E.4 Séparation des rôles administratifs

La gestion des réseaux, la virtualisation, les bases de données et les applications soulèvent des préoccupations particulières en matière de sécurité, puisqu’elles pourraient accorder un accès sans précédent à de grandes quantités de données sensibles et de privilèges administratifs. Les auteurs de menace sophistiqués qui ne peuvent obtenir un accès logique (p. ex. par l’entremise d’Internet) cherchent à exploiter d’autres modes d’accès, notamment les représentants de la direction et les réseaux de gestion.

Les rôles de gestion devraient être identifiés, et la portée de leur contrôle et des accès devrait être limitée, particulièrement s’ils permettent d’accéder à de grandes quantités de données sensibles. La séparation des rôles et des tâches prévient l’abus des privilèges autorisés et réduit le risque que survienne une activité malveillante. Le principe du droit d’accès minimal devrait également être considéré pour veiller à ce que les rôles, les comptes système et les processus ne disposent que des niveaux de privilège nécessaires à l’exercice de leurs fonctions.

Figure 15 : Rôles de gestion

Description détaillée

La figure 15 décrit certains des rôles clés qui exigent un accès de gestion à l’environnement de TI. Les rôles de gestion de l’infrastructure, gestion des applications et des systèmes d’exploitation, gestion de la sécurité, et gestion des hyperviseurs.

La figure 15 décrit certains des rôles clés qui exigent un accès de gestion à l’environnement de TI. Ces rôles sont décrits dans le tableau 16.

Tableau 16 : Rôles de gestion

L’interface de gestion des hyperviseurs est l’une des interfaces les plus essentielles à l’infrastructure virtualisée. En utilisant cette interface et le logiciel de gestion qui lui associé, il est possible d’arrêter physiquement et virtuellement les serveurs, de migrer les machines virtuelles, de prendre un instantané de ces dernières et d’ajouter des machines virtuelles aux opérations de TI. Comparativement aux opérations de TI traditionnellement basées sur le matériel, le déploiement d’une infrastructure virtuelle peut s’effectuer rapidement et facilement. Cela dit, ces caractéristiques font également de la fonction administrative des hyperviseurs une cible de choix pour les auteurs de menace, et peuvent faire en sorte qu’il est difficile de détecter les accès non autorisés à l’information ou l’insertion de contenu malveillant.

La gestion des hyperviseurs devrait être un rôle strictement séparé (c.-à-d., un seul système de gestion des hyperviseurs dédié par zone de gestion de sécurité de réseau). Une séparation plus rigoureuse des rôles pourrait également être nécessaire. La séparation des rôles permet de limiter le contrôle exercé par chaque système de gestion des hyperviseurs. Chacune des autorités de zone de sécurité de réseau correspondante doit approuver les activités de gestion des hyperviseurs dans plusieurs zones.

On retrouve également des rôles de gestion additionnels, notamment ceux associés à la gestion du stockage, des services et des comptes. Votre organisation devrait définir les rôles de gestion en fonction de ses besoins en matière de sécurité et de sa reconnaissance des menaces et des risques qui pèsent sur ses environnements de TI. Les rôles de gestion identifiés devraient être attribués à des entités distinctes qui ont les privilèges nécessaires pour effectuer leurs tâches administratives conformément aux limites de responsabilités clairement imposées par l’environnement de TI.

E.5 Isolation des ZG

Pour assurer la disponibilité des services de gestion et mieux protéger les ZG des tentatives d’interférence et de trafiquage qui émanent des zones qu’elles gèrent, il convient de tenir compte des facteurs suivants :

• les ZG ne devraient pas partager leur infrastructure de couche réseau avec les autres zones, y compris celles qu’elles gèrent;
• les ZG ne devraient pas partager leur infrastructure de couche liaison de données avec les autres zones, y compris celles qu’elles gèrent;
• les ZG ne devraient pas partager leur infrastructure de couche physique avec les autres zones.

Les ZG devraient être mises en œuvre sur une infrastructure qui est séparée physiquement des zones gérées et des autres ZG (c.-à-d., chaque ZG se trouve sur une infrastructure physique distincte). Par contre, selon les résultats du PASSI, les architectes de sécurité pourraient choisir de mettre en place des ZG, autres que les ZAP-ZG, sur la même infrastructure physique et avoir recours à des technologies de virtualisation pour les séparer.

Selon l’approche de la ZG isolée (voir la figure 12), la ZAP-ZG est toujours séparée physiquement des autres ZG en raison de sa proximité avec la ZP.

Dans le cas des architectures de ZG qui utilisent des technologies de virtualisation pour séparer les ZG, les évaluations de la sécurité doivent démontrer que la robustesse des mécanismes de séparation est suffisante.

Que les ZG soient séparées physiquement ou logiquement, chaque ZG propre à la zone ne devrait communiquer qu’avec la zone dont elle assure la gestion et n’accepter que les connexions en provenance de celle-ci. Par exemple, une ZT-ZG peut communiquer avec sa ZG, mais pas avec une ZAR ou une ZAP. Une ZT-ZG accepte les communications en provenance de sa ZG, mais pas celles provenant d’une ZAR ou d’une ZAP.

E.6 Approches à la gestion

La présente section traite des différentes approches à la gestion décrites dans la figure 16.

Figure 16 : Approches à la gestion

Description détaillée

Figure 16 illustre des différentes approches à la gestion, gestion intrabande, gestion hors bande, gestion directe de la console, et télégestion.

E.6.1 Gestion intrabande

La gestion de l’infrastructure du réseau est effectuée à partir du réseau de données. Le trafic de gestion traverse le même réseau que le trafic de données opérationnelles, et se rend jusqu’aux cartes réseau qui sont configurées pour les données opérationnelles. On peut faire appel au chiffrement pour protéger la confidentialité et l’intégrité du trafic de gestion. Toutefois, si des problèmes surviennent sur le réseau, la disponibilité du trafic de gestion jusqu’à l’infrastructure pourrait être touchée. Par exemple, advenant un problème de congestion sur le réseau provoqué par une erreur de configuration ou une attaque par DoS, il pourrait être difficile d’intervenir et de reconfigurer l’infrastructure du réseau, puisque les composants de ce dernier sont occupés et la bande passante est saturée. Le trafic de gestion est essentiellement bloqué. Les administrateurs n’arrivent plus à se connecter à l’infrastructure du réseau afin d’en faire la gestion.

E.6.2 Gestion hors bande

Des infrastructures de réseau de gestion séparées et des cartes réseau dédiées devraient être mises en œuvre pour permettre la gestion hors bande de l’infrastructure de réseau dans les zones. Le trafic de gestion du réseau et de la sécurité lancé provenant des ZG est acheminé vers les zones depuis les infrastructures des réseaux de gestion distinctes et se rend jusqu’aux cartes réseau dédiées qui sont configurées aux fins de gestion. En ce qui concerne les environnements virtualisés au sein desquels aucune carte réseau dédiée n’est disponible, l’isolation de la gestion devrait être appliquée logiquement dans la pile réseau. La disponibilité du trafic de gestion pourrait toutefois être à risque.

La gestion hors bande ne dépend pas du réseau de données lié aux activités opérationnelles. Les systèmes de gestion hors bande ne sont pas touchés par les défaillances des réseaux de données ou la congestion de ces derniers. Ces systèmes sont moins vulnérables aux compromissions provenant des réseaux non liés à la gestion. Des autorités de zone de sécurité de réseau sont ajoutées à ces réseaux pour détecter plus facilement les compromissions sur le réseau et simplifier les enquêtes subséquentes. Ils permettent également aux administrateurs de TI d’assurer plus efficacement la maintenance, la récupération et le rétablissement des services de TI.

E.6.3 Gestion directe de la console

La gestion directe de la console, parfois appelée l’accès au terminal de la console, consiste à assurer la gestion des ressources par l’entremise d’une connexion directe plutôt qu’un réseau. La connexion directe peut être effectuée par l’intermédiaire d’un port KVM (Keyboard-Video-Mouse), d’un commutateur KVM, d’un port série, du port de la console ou de la carte réseau des systèmes informatiques au moyen d’un câble croisé.

La gestion directe de la console peut être effectuée depuis une console ou une station de travail administrative pleinement fonctionnelle. Cette approche exige un accès physique aux systèmes de TI qui se trouvent dans les zones. La gestion directe de la console peut servir de mécanisme de gestion de rechange si le réseau de données ou les réseaux de gestion ne sont pas accessibles. La sécurité physique devrait également être prise en compte pour empêcher les auteurs de menace d’utiliser la gestion directe de la console pour compromettre des systèmes TI essentiels.

E.6.4 Télégestion

Par télégestion, on entend la gestion hors site des systèmes TI. La télégestion devrait être effectuée de manière à ce que les hôtes de gestion approuvés, dédiés et renforcés s’authentifient sur une ZG (c.-à-d., par l’authentification de dispositifs et des rôles administratifs) depuis des emplacements approuvés et par des moyens autorisés. Les décisions quant aux systèmes de télégestion à utiliser devraient être basées sur les résultats du PASSI.

Les hôtes de télégestion devraient se connecter et s’authentifier par l’entremise d’une ZAT, tel qu’il est illustré dans la figure 17 ci-dessous. Une ZAT comporte les mêmes composants réseau et les mêmes caractéristiques qu’une ZAP, mais elle s’exécute sur une infrastructure isolée physiquement. Les services compris dans la ZAT sont dédiés à l’authentification et à la gestion des connexions à une ZG. Si la télégestion est utilisée dans plus d’une zone, on devra mettre en place une ZAT distincte pour chaque zone gérée.

Figure 17 : Architecture logique de la ZG avec télégestion de la ZAP

Description détaillée

Figure 17 illustre architecture logique de la ZG avec télégestion de la ZAP. Les icônes et les couleurs sont utilisées pour distinguer les différents déploiements physiques des ZIP.

E.7 Objectifs de sécurité d’une ZG

Une ZG est une zone isolée physiquement qui forme un environnement unique pour l’ensemble des systèmes de gestion d’extrémité. Une ZG se caractérise par des mesures de contrôle plus strictes en ce qui a trait à la configuration de réseau et par une surveillance minutieuse du trafic. L’état de la sécurité ciblée pour toutes les instances de la ZG (c.-à-d., ZAP-ZG, ZT ZG, ZAR-ZG et ZATR-ZG) est de limiter les attaques menées par les auteurs de menace appartenant aux catégories de menace de niveau Md5 et inférieurs.^{Note de bas de page 16} Les mesures de sécurité des ZG devraient également réduire l’incidence des attaques menées par les auteurs de menace appartenant aux catégories de menace de niveau Md6 ^{Note de bas de page 17} et supérieurs.

Chaque objectif ou exigence mentionné dans la présente annexe est identifié suivant les règles de notation suivantes :

• le premier groupe de lettres (MZ pour Management Zone) désigne la ZG;
• le second groupe de lettres précise s’il s’agit d’un objectif (OBJ) ou d’une exigence (REQ pour Requirement);.
• les exigences sont regroupées selon les catégories suivantes, le cas échéant :
  • Interface réseau (NI pour Network Interface);
  • Contrôle du trafic (TC pour Traffic control);
  • Configuration réseau (NC pour Network Configuration);
  • Configuration d’hôte (HC pour Host Configuration);
  • Protection des données (DP pour Data Protection).
• chaque objectif ou exigence est numéroté en séquence dans son groupe, à partir de 100.

Remarque : Les objectifs et les exigences ne sont pas indiqués en ordre séquentiel; certaines exigences ont été supprimées ou modifiées comparativement aux précédentes versions du présent document.

E.7.1 Objectifs de contrôle du trafic

[MZ-OBJ-100] Une ZG devrait protéger l’intégrité et la disponibilité des systèmes de gestion d’extrémité connectés à la zone en réduisant le trafic malveillant sur le réseau. Ses objectifs en ce qui a trait au contrôle du trafic sont les suivants :

• empêcher les auteurs de menace jusqu’au niveau Md5 de mener des attaques par déni de service (p. ex., inondation de messages SYN, attaque par DdoS) sur les systèmes de gestion d’extrémité;
• réduire la vulnérabilité des systèmes de gestion d’extrémité aux attaques par DoS à commande réseau réalisées par toutes les autres sources ^{Note de bas de page 18};
• interdire l’accès aux systèmes de gestion d’extrémité à la suite d’une intrusion dans le réseau (comme le raccordement d’un dispositif non autorisé à une interface existante ou l’ajout non autorisé d’une interface périphérique) par des auteurs de menace jusqu’au niveau Md5;
• réduire la vulnérabilité des systèmes de gestion d’extrémité aux intrusions réalisées par toutes les autres sources;
• contenir l’incidence de la compromission d’un système de gestion d’extrémité;
• empêcher les auteurs de menace jusqu’au niveau Md5 d’utiliser les systèmes de gestion d’extrémité comme base de lancement d’attaques contre d’autres systèmes;
• empêcher les autres sources de menace d’utiliser les systèmes de gestion d’extrémité comme base de lancement d’attaques contre d’autres systèmes;
• prévenir la propagation des maliciels.

Les mesures de sécurité réseau ont une efficacité limitée pour la protection des systèmes d’extrémité contre les compromissions à partir d’interfaces d’applications valides. Il convient de mettre en place des mesures de sécurité visant les plateformes, les applications et les opérations en vue d’atténuer les risques associés à ces types de menaces.

[MZ-OBJ-102] Une ZG devrait permettre de renforcer les mesures de sécurité en réponse à un accroissement du niveau de la menace (p. ex. en temps de crise) en faisant appel, notamment :

• à de contrôles de trafic souples et dynamiques;
• à une surveillance renforcée de l’état de la ZATR.

[MZ-OBJ-103] Les zones et les PIZ mettent en œuvre les mesures de protection visant à assurer une protection contre le trafic malveillant en provenance des réseaux publics. La ZG devrait toutefois tenir compte de tout risque résiduel en vue de réaliser les objectifs suivants :

• réduire la vulnérabilité aux attaques découlant de la compromission d’un accès distant et provenant des systèmes d’extrémité sur l’extranet;
• réduire la vulnérabilité au trafic malveillant découlant de la compromission des serveurs d’application de prestation de services dans les zones en limitant l’accès de ces serveurs aux ressources et protocoles désignés;
• réduire les vulnérabilités aux attaques résultant de la compromission des hôtes dans les zones et aux défaillances des mesures de contrôle du trafic, notamment les intrusions depuis les interréseaux des autres zones.

E.7.2 Objectifs de la disponibilité et l’intégrité du réseau

[MZ-OBJ-104] Une ZG devrait protéger l’intégrité et la disponibilité des services de gestion en réduisant leur susceptibilité à divers types d’attaques. Elle devrait avoir les objectifs suivants en ce qui concerne la disponibilité et l’intégrité du réseau :

• réduire la vulnérabilité des services de gestion aux attaques par DoS réalisées par toutes les sources de menace (p. ex. des adversaires sophistiqués, des initiés de l’infrastructure et des utilisateurs du réseau) en filtrant les attaques malveillantes depuis l’extérieur de la ZG;
• empêcher les auteurs de menace appartenant aux catégories de menace de niveau Md5 et inférieurs de s’introduire dans le réseau (p. ex. en connectant un dispositif non autorisé à une interface existante, en ajoutant une interface de bordure non autorisée ou en compromettant un système de gestion d’extrémité connecté à la zone);
• rendre les réseaux moins vulnérables aux intrusions menées depuis d’autres sources de menace;
• empêcher les auteurs de menace jusqu’au niveau Md5 d’utiliser les systèmes de gestion d’extrémité comme base de lancement d’attaques contre d’autres systèmes de gestion;
• empêcher les autres sources de menace d’utiliser les systèmes de gestion d’extrémité comme base de lancement d’attaques contre d’autres systèmes de gestion;
• prévenir la propagation des maliciels.

E.7.3 Objectifs de la protection des données

[MZ-OBJ-105] Une ZG devrait empêcher les auteurs de menace appartenant aux catégories de menace de niveau Md5 et inférieurs d’intercepter le trafic de la zone. Elle devrait également détecter l’interception du trafic par d’autres sources de menace.

[MZ-OBJ-106] Une ZG devrait prendre en charge les mesures suivantes pour protéger la confidentialité et l’intégrité des données :

• RPVS dans l’interréseau;
• RPVS en tant que service de données facultatif;
• protocoles de sécurité de la couche supérieure.

E.8 Exigences de base en matière de sécurité de la ZG

Cette section décrit les exigences de base en matière de sécurité d’une ZG. Elles sont classées en fonction des exigences opérationnelles (c.-à-d. selon les catégories interface réseau, contrôle du trafic, configuration réseau, configuration d’hôte et protection des données).

Pour satisfaire à tous les objectifs de sécurité pour cette zone, il faut mettre en œuvre l’ensemble complet des exigences de sécurité mentionnées dans le tableau 17. Vous devriez toutefois consulter les contrôles mentionnés dans l’ITSG-33 [4] pour déterminer s’il est nécessaire de mettre en place des mécanismes techniques, opérationnels et de gestion additionnels pour atténuer les menaces de niveau Md5 prévues.

Tableau 17 : Exigences de base en matière de sécurité de la ZG

Avant-propos

L’ITSP.80.022, Exigences de base en matière de sécurité pour les zones de sécurité de réseau, version 2, Annexe F – Point d’interface de zone, est une publication NON CLASSIFIÉ.

La présente version de l’annexe F remplace toutes les versions antérieures du document.

Date d'entrée en vigueur

Le présent document entre en vigueur le 12 janvier, 2021.

Historique des modifications

F.1 introduction

La présente annexe comprend un modèle de référence, les objectifs de sécurité et un ensemble d’exigences de base en matière de sécurité pour les points d’interface de zone (PIZ), à savoir les systèmes qui appliquent les stratégies de communication entre deux zones. Un PIZ est un système bidirectionnel entre deux zones qui contient les systèmes de frontière. Il peut se trouver dans une zone adjacente ou dans un emplacement distant, selon les ententes avec les autorités de zone de sécurité de réseau des zones adjacentes.

Comme deux zones sont connectées au moyen d’un PIZ partagé, la gestion du PIZ incombe aux autorités de zone de sécurité de réseau de ces zones. Dans la présente, cette responsabilité commune est désignée en tant qu’autorité conjointe des PIZ (ACP).

Le nom des PIZ est déterminé en fonction des zones auxquelles ils se connectent. Par exemple, un PIZ qui connecte la ZT à la ZAP portera le nom PIZ de la ZT-ZAP.

F.2 Modèle de référence d’un PIZ

Le PIZ est le concept logique servant à décrire l’interface contrôlée qui relie deux zones. Il procure une interface réseau et la sécurité du périmètre entre les zones. Un PIZ applique également les stratégies de communication interzones; toutes les communications entre les zones doivent transiter par un PIZ.

Un PIZ est un système (composé d’au moins un sous-système) qui implémente les services de protection à la frontière. Les routeurs de filtrage, les pare-feux, les gardiens et les systèmes de détection des intrusions sont des exemples de sous-systèmes.

Un PIZ filtre les paquets de données selon des caractéristiques définies. Il assure les services de mandataire et devrait rejeter toute demande de service mal formulée. Le PIZ doit offrir uniquement les services nécessaires à la communication entre les deux zones.

La figure 18 ci-dessous illustre deux chemins d’accès distincts entre la zone A et la zone B. Ces deux chemins d’accès sont requis pour gérer les différentes stratégies de sécurité entrantes et sortantes entre les zones connectées. Par exemple, la prévention de la perte de données peut être réservée au trafic sortant, alors que le trafic entrant est soumis à des listes d’applications interdites.

Figure 18 : Représentation logique d’un PIZ

Description détaillée

Figure 18 illustre deux chemins d’accès distincts entre la zone A et la zone B. Ces deux chemins d’accès sont requis pour gérer les différentes stratégies de sécurité entrantes et sortantes entre les zones connectées. Par exemple, la prévention de la perte de données peut être réservée au trafic sortant, alors que le trafic entrant est soumis à des listes d’applications interdites.

Le tableau 18 donne des exemples des fonctions de sécurité d’un PIZ.

Tableau 18 : Fonctions de sécurité d’un PIZ

La conception du déploiement d’un PIZ entre une ZP et une ZAP diffère légèrement de celle d’une zone interne vers un PIZ de zone interne. Ces différences reposent sur des exigences uniques qui permettent d’obscurcir la structure du réseau interne et l’adressage (voir la section 2.1 de l’annexe F pour plus de détails).

F.2.1 PIZ de ZP

Un PIZ de ZP contrôle tous les types de trafic entre la ZP et la ZAP. Un PIZ de ZP devrait filtrer les paquets de données selon les caractéristiques déterminées. Il dissimule le détail des services réseau de la ZP pour ne présenter que les services requis aux fins des communications avec la ZP.

F.2.2 PIZ de zone interne

On utilise un PIZ de zone interne pour contrôler et filtrer tous les types de trafic entre la ZAP et les zones internes. Un PIZ de zone interne devrait filtrer les paquets de données selon les caractéristiques déterminées et prendre en charge la mise en œuvre des services de mandataire. Il devrait également être capable de rejeter toute demande de service mal formulée. Il dissimule le détail des services réseau des zones internes pour ne présenter que les services requis aux fins des communications avec les zones internes.

F.3 Considérations liées à la mise en œuvre d’un PIZ

Il existe deux types de déploiement de PIZ (voir la figure 19) :

• les PIZ sont déployés dans le chemin d’accès aux données de manière à prendre en charge la communication entre les zones;
• les PIZ sont déployés dans le chemin de gestion de manière à prendre en charge les fonctions administratives.

Figure 19 : Options de déploiement du PIZ

Description détaillée

Il existe deux types de déploiement de PIZ illustre dans figure 19 : les PIZ sont déployés dans le chemin d’accès aux données de manière à prendre en charge la communication entre les zones et les PIZ sont déployés dans le chemin de gestion de manière à prendre en charge les fonctions administratives. La figure 19 illustre la distinction entre les PIZ connectés à la ZG et les PIZ des chemins d’accès aux données. Par exemple, une ZG interfacerait avec une ZAP par l’intermédiaire du PIZ de la ZAP-ZG, tandis qu’une ZAR interfacerait avec une ZT par l’intermédiaire du PIZ de la ZAR-ZT.

La figure 19 illustre la distinction entre les PIZ connectés à la ZG et les PIZ des chemins d’accès aux données. Par exemple, une ZG interfacerait avec une ZAP par l’intermédiaire du PIZ de la ZAP-ZG, tandis qu’une ZAR interfacerait avec une ZT par l’intermédiaire du PIZ de la ZAR-ZT.

Les PIZ connectés à la ZG sont gérés depuis leur ZG respective, tel qu’il est décrit dans les exemples suivants :

• la ZAR-ZG gère le PIZ de la ZAR-ZG;
• la ZT-ZG gère le PIZ de la ZT-ZG;
• la ZAP-ZG gère le PIZ de la ZAP-ZG.

Les PIZ des chemins d’accès aux données devraient être gérés par la ZG de la zone de sécurité la plus élevée ou comme entendu avec l’ACP des zones connectées, tel qu’il est expliqué dans les exemples suivants :

• la ZT-ZAP gère les PIZ de la ZT-ZAP et de la ZT-ZT;
• la ZAR-ZG gère les PIZ de la ZAR-ZT et de la ZAR-ZAR.

Comme illustré à la figure 19, la séparation des diverses fonctions du PIZ pourrait être virtualisée. Une instance virtualisée unique ne devrait pas contenir à la fois les PIZ connectés à la ZG et les PIZ des chemins de données. On peut envisager de procéder à la virtualisation des PIZ connectés à la ZG ou des PIZ des chemins de données si l’assurance offerte par les mécanismes de séparation, qui sont fournis par la plateforme sous-jacente, répond aux exigences indiquées dans le PASSI.

Un PIZ devrait être conçu et mis en œuvre de manière à fournir, à tout le moins, un niveau d’assurance de la sécurité équivalent au niveau d’assurance le plus élevé des deux zones qu’il connecte.

F.4 Objectifs de sécurité d’un PIZ

Un PIZ est une collection de mécanismes de sécurité visant à empêcher les attaques provenant des réseaux (c.-à-d., réduire les vulnérabilités à de telles attaques) de se propager d’une zone à l’autre.

On ne peut écarter l’hypothèse qu’un auteur de menace sophistiqué puisse contourner les mesures de sécurité d’un PIZ. Il est donc nécessaire de prendre des mesures de sécurité supplémentaires pour protéger les biens sensibles se trouvant dans de telles zones.

Le niveau de menace que chaque PIZ doit atténuer varie selon les résultats du PASSI.

Chaque objectif ou exigence de sécurité mentionné dans la présente annexe est identifié suivant les règles de notation suivantes :

• le premier groupe de lettres (ZIP pour Zone Interface Point) désigne le PIZ;
• le second groupe de lettres précise s’il s’agit d’un objectif (OBJ) ou d’une exigence (REQ pour Requirement).
• Les exigences sont regroupées selon les catégories suivantes, le cas échéant :
  • Interface réseau (NI pour Network Interface);
  • Contrôle du trafic (TC pour Traffic control);
  • Configuration réseau (NC pour Network Configuration);
  • Configuration d’hôte (HC pour Host Configuration);
  • Protection des données (DP pour Data Protection).

• Chaque objectif ou exigence est numéroté en ordre séquentiel dans son groupe, à partir de 100.
  Remarque : Les objectifs et les exigences ne sont pas indiqués en ordre séquentiel; certaines exigences ont été supprimées ou modifiées comparativement aux précédentes versions du présent document.

F.4.1 Objectifs de contrôle du trafic

[ZIP-OBJ-100] Un ZIP devrait protéger l’intégrité et la disponibilité du trafic réseau en réduisant le trafic malveillant. Ses objectifs en ce qui a trait au contrôle du trafic sont les suivants :

• empêcher les sources de menace d’accéder aux zones en cas d’intrusion dans le réseau;
• empêcher les sources de menace d’exploiter les PIZ comme bases de lancement pour attaquer les zones;
• prévenir la propagation des maliciels.

[ZIP-OBJ-102] Un PIZ devrait permettre de renforcer les mesures de sécurité en réponse à un accroissement du niveau de la menace (p. ex. en temps de crise) en faisant appel, notamment :

• à des contrôles de trafic souples et dynamiques;
• à une surveillance renforcée de l’état des PIZ.

[ZIP-OBJ-103] Un PIZ devrait mettre en œuvre les mesures de protection suivantes pour empêcher le trafic réseau malveillant de passer d’une zone à l’autre :

• réduire la vulnérabilité d’une zone au trafic malveillant provenant d’hôtes et de nœuds compromis dans les zones adjacentes;
• réduire la vulnérabilité d’une zone à la défaillance des mesures de contrôle du trafic appliquées à celle-ci.

F.4.2 Objectifs de la disponibilité et de l’intégrité du réseau

[ZIP-OBJ-104] Un PIZ devrait protéger l’intégrité et la disponibilité des services réseau en réduisant leur susceptibilité à divers types d’attaques, et permettre de réaliser les objectifs suivants :

• réduire les attaques par DoS provenant des réseaux (p. ex. inondation de messages SYN, attaque par DDoS) dans les zones;
• réduire les vulnérabilités aux intrusions touchant les services du réseau (p. ex. connecter un dispositif non autorisé à une interface existante);
• empêcher les sources de menace d’exploiter les zones comme bases de lancement pour attaquer les autres services du réseau.

F.4.3 Objectifs de la protection des données

[ZIP-OBJ-105] Un PIZ devrait empêcher les auteurs de menace appartenant aux catégories de menace de niveau Md3^{Note de bas de page 19} et inférieurs d’intercepter le trafic d’une zone. Un PIZ devrait également détecter si d’autres sources de menace interceptent le trafic.

[ZIP-OBJ-105] Un PIZ empêche les adversaires d’intercepter le trafic d’une zone.

[ZIP-OBJ-106] Un PIZ devrait prendre en charge les mesures suivantes pour protéger la confidentialité et l’intégrité des données :

• RPVS dans le PIZ;
• protocoles de sécurité de la couche supérieure.

F.5 Exigences de base en matière de sécurité des PIZ

La présente section décrit les exigences de base en matière de sécurité des PIZ. Elles sont classées en fonction des exigences opérationnelles (c.-à-d., selon les catégories interface réseau, contrôle du trafic, configuration réseau, configuration d’hôte et protection des données). Pour satisfaire à tous les objectifs de sécurité pour cette zone, il faut mettre en œuvre l’ensemble complet des exigences de sécurité mentionnées dans le tableau 19.

Tableau 19 : Exigences de base en matière de sécurité des PIZ