| PREMIER MINISTRE Service Central de la Sécurité des Systèmes d'Information

DOCUMENTATION
Index de la documentation EVALUATION Critères d'évaluation Schéma de certification Guides GARDE Certificats et PP REGLEMENTATION Cryptologie Domaine tempest Systèmes d'information METHODES FICHES DE SYNTHESE
AILLEURS SUR LE SITE
Retour à la page d'accueil Présentation du SCSSI Informations pratiques Rubriques Courrier des lecteurs
## SCSSI : ITSEC v1.2 Classes de fonctionnalité Index de la documentation sur les critères | Index général de la documentation Sommaire | Introduction | Champ d'application | Fonctionnalité Efficacité | Conformité | Conformité E1 | Conformité E2 | Conformité E3 | Conformité E4 | Conformité E5 | Conformité E6 Résultats de l'évaluation | Glossaire | Exemples de classes de Fonctionnalité | "Claims language" |
### ANNEXE A - EXEMPLES DE CLASSES DE FONCTIONNALITE Introduction Classe de fonctionnalité F-C1 Classe de fonctionnalité F-C2 Classe de fonctionnalité F-B1 Classe de fonctionnalité F-B2 Classe de fonctionnalité F-B3 Classe de fonctionnalité F-IN Classe de fonctionnalité F-AV Classe de fonctionnalité F-DI Classe de fonctionnalité F-DC Classe de fonctionnalité F-DX Introduction Cette annexe présente des exemples de classes prédéfinies, telles que définies au chapitre 2. Ces classes constituent une annexe à ces critères car elles sont données comme exemples, et non comme des classes définitives, à utiliser dans des évaluations réelles. On espère qu'elles vont stimuler le débat sur les exigences réelles des fonctionnalités de sécurité. De fait, le besoin de créer des classes prédéfinies définitives a été largement approuvé lors du processus de consultation qui a précédé la publication de cette version des critères. Des travaux sont déjà en cours dans des organismes de normalisation et d'autres organisations industrielles pour développer des normes pour des fonctionnalités de sécurité dans des contextes spécifiques. On s'attend à ce que de tels travaux produisent des définitions de fonctionnalités de sécurité qui feront autorité et qui pourront être adaptées pour être utilisées avec ces critères et incluses ou mises en référence dans la prochaine version définitive de ce document. Les présents exemples fournissent une référence de base et montrent comment des classes prédéfinies peuvent être tirées des critères existants : de fait, ces classes ont été adaptées avec un minimum de modification du [ZSIEC]. Chaque classe consiste en une présentation des objectifs, suivie par les exigences présentées dans des rubriques génériques appropriées. L'absence d'une rubrique générique dans la description d'une classe donnée signifie qu'il n'existe aucune exigence pour cette rubrique. Les classes F-B2 et F-B3 contiennent en outre des informations complémentaires qu'il est nécessaire d'inclure dans une cible de sécurité ; ces informations spécifient les mécanismes par mandats exigés pour la compatibilité avec le TCSEC. Les cinq exemples de classes de fonctionnalité F-C1, F-C2, F-B1, F-B2, et F-B3 forment une hiérarchie puisqu'elles sont issues des exigences fonctionnelles des classes hiérarchiques du TCSEC. Dans la description de ces classes, les parties de chaque classe qui sont nouvelles ou qui ont été changées par rapport aux classes précédentes sont imprimées en gras. D'autres classes de fonctionnalité basées sur une hiérarchie pourront être créées dans le futur, par des organismes de normalisation et des organisations industrielles, pour aborder d'autres types d'objectifs de sécurité (par exemple pour l'intégrité et la disponibilité). En attendant, les classes F-IN, F-AV, F-DI, F-DC, et F-DX ont été incluses pour illustrer la large gamme d'exigences de sécurité qui peuvent être exprimées sous la forme d'une classe de fonctionnalité prédéfinie. ## Exemple de classe de fonctionnalité : F-C1 #### Objectif L'exemple de classe F-C1 est dérivé des exigences fonctionnelles de la classe C1 du TCSEC américain. Elle offre un contrôle d'accès discrétionnaire ("besoin d'en connaître"). #### Identification et authentification La TOE doit identifier et authentifier les utilisateurs. L'identification et l'authentification doivent avoir lieu avant toute autre interaction entre la TOE et l'utilisateur. D'autres interactions ne doivent être possibles qu'après une identification et une authentification réussies. Les informations d'authentification doivent être stockées de façon telle qu'elles soient seulement accessibles par des utilisateurs autorisés. #### Contrôle d'accès La TOE doit pouvoir distinguer et administrer les droits d'accès de chaque utilisateur sur les objets soumis à l'administration des droits, au niveau d'un utilisateur individuel, au niveau de l'appartenance à un groupe d'utilisateurs, ou aux deux niveaux. Il doit être possible de refuser complètement à des utilisateurs ou à des groupes d'utilisateurs l'accès à un objet. Il ne doit pas être possible à quelqu'un qui n'est pas un utilisateur autorisé d'accorder ou de retirer des droits d'accès à un objet. Lors de toute tentative par des utilisateurs ou des groupes d'utilisateurs d'accéder à des objets soumis à l'administration des droits, la TOE doit vérifier la validité de la demande. Les tentatives d'accès non autorisé doivent être rejetées. ## Exemple de classe de fonctionnalité : F-C2 #### Objectif L'exemple de classe F-C2 est dérivé des exigences fonctionnelles de la classe C2 du TCSEC américain. Elle offre un contrôle d'accès discrétionnaire plus fin que la classe C1, en rendant les utilisateurs individuellement responsables de leurs actions à travers des procédures d'identification, l'audit des événements relatifs à la sécurité et l'isolation des ressources.- #### Identification et authentification La TOE doit identifier et authentifier de façon unique les utilisateurs. L'identification et l'authentification doivent avoir lieu avant toute autre interaction entre la TOE et l'utilisateur. D'autres interactions ne doivent être possibles qu'après une identification et une authentification réussies. Les informations d'authentification doivent être stockées de façon telle qu'elles soient seulement accessibles par des utilisateurs autorisés. Pour chaque interaction, la TOE doit pouvoir établir l'identité de l'utilisateur. #### Contrôle d'accès La TOE doit pouvoir distinguer et administrer les droits d'accès de chaque utilisateur sur les objets soumis à l'administration des droits, au niveau d'un utilisateur individuel, au niveau de l'appartenance à un groupe d'utilisateurs, ou aux deux niveaux. Il doit être possible de refuser complètement à des utilisateurs ou à des groupes d'utilisateurs l'accès à un objet. Il doit également être possible de limiter l'accès d'un utilisateur à un objet aux seules opérations qui ne modifient pas cet objet. Il doit être possible d'accorder les droits d'accès à un objet en descendant jusqu'au niveau de granularité de l'utilisateur individuel. Il ne doit pas être possible à quelqu'un qui n'est pas un utilisateur autorisé d'accorder ou de retirer des droits d'accès à un objet. L'administration des droits doit disposer de contrôles pour limiter la propagation des droits d'accès. De même, seuls des utilisateurs autorisés doivent pouvoir introduire de nouveaux utilisateurs, supprimer ou suspendre des utilisateurs existants. Lors de toute tentative par des utilisateurs ou des groupes d'utilisateurs d'accéder à des objets soumis à l'administration des droits, la TOE doit vérifier la validité de la demande. Les tentatives d'accès non autorisé doivent être rejetées. #### Imputabilité La TOE doit comporter un composant d'imputation qui soit capable, pour chacun des événements suivants, d'enregistrer cet événement avec les données exigées :- Utilisation du mécanisme d'identification et d'authentification :- Données exigées : Date ; heure ; identité fournie par l'utilisateur ; identification de l'équipement sur lequel le mécanisme d'identification et d'authentification a été utilisé (par exemple identificateur du terminal) ; réussite ou échec de la tentative.- Actions qui tentent d'exercer des droits d'accès à un objet soumis à l'administration des droits :- Données exigées : Date ; heure ; identité de l'utilisateur ; nom de l'objet ; type de la tentative d'accès ; réussite ou échec de la tentative.- Création ou suppression d'un objet soumis à l'administration des droits :- Données exigées : Date ; heure ; identité de l'utilisateur ; nom de l'objet ; type de l'action.- Actions d'utilisateurs autorisés affectant la sécurité de la TOE :- Données exigées : Date ; heure ; identité de l'utilisateur ; type de l'action ; nom de l'objet sur lequel porte l'action (de telles actions sont l'introduction ou la suppression (suspension) d'utilisateurs ; l'introduction ou le retrait de supports de stockage ; le démarrage ou l'arrêt de la TOE).- Les utilisateurs non autorisés ne doivent pas avoir accès aux données d'imputation. Il doit être possible de mettre sélectivement en oeuvre l'imputation pour un ou plusieurs utilisateurs. Il doit exister des outils pour examiner et maintenir les fichiers d'imputation et ces outils doivent être documentés. Ils doivent permettre d'identifier sélectivement les actions d'un ou de plusieurs utilisateurs.- #### Audit Il doit exister des outils pour examiner les fichiers d'imputation pour les besoins d'audit et ces outils doivent être documentés. Ils doivent permettre d'identifier sélectivement les actions d'un ou de plusieurs utilisateurs.- #### Réutilisation d'objet Tous les objets de stockage rendus à la TOE doivent, avant d'être réutilisés par d'autres sujets, être traités d'une manière telle qu'aucune conclusion ne puisse être tirée concernant leur contenu précédent.- ## Exemple de classe de fonctionnalité : F-B1 #### Objectif L'exemple de classe F-B1 est dérivé des exigences fonctionnelles de la classe B1 du TCSEC américain. En plus du contrôle d'accès discrétionnaire, elle introduit des fonctions pour maintenir des marques de sensibilité et les utilise pour faire respecter un ensemble de règles de contrôle d'accès par mandats à tous les sujets et à tous les objets de stockage sous son contrôle. Il est possible d'attribuer de façon précise un label aux informations exportées.- #### Identification et authentification La TOE doit identifier et authentifier de façon unique les utilisateurs. L'identification et l'authentification doivent avoir lieu avant toute autre interaction entre la TOE et l'utilisateur. D'autres interactions ne doivent être possibles qu'après une identification et une authentification réussies. Les informations d'authentification doivent être stockées de façon telle qu'elles soient seulement accessibles par des utilisateurs autorisés. Pour chaque interaction, la TOE doit pouvoir établir l'identité de l'utilisateur. #### Contrôle d'accès La TOE doit pouvoir distinguer et administrer les droits d'accès de chaque utilisateur sur les objets soumis à l'administration des droits, au niveau d'un utilisateur individuel, au niveau de l'appartenance à un groupe d'utilisateurs, ou aux deux. Il doit être possible de refuser complètement à des utilisateurs ou à des groupes d'utilisateurs l'accès à un objet. Il doit également être possible de limiter l'accès d'un utilisateur à un objet aux seules opérations qui ne modifient pas cet objet. Il doit être possible d'accorder les droits d'accès à un objet en descendant jusqu'au niveau de granularité de l'utilisateur individuel. Il ne doit pas être possible à quelqu'un qui n'est pas un utilisateur autorisé d'accorder ou de retirer des droits d'accès à un objet. L'administration des droits doit disposer de contrôles pour limiter la propagation des droits d'accès. De même, seuls des utilisateurs autorisés doivent pouvoir introduire de nouveaux utilisateurs, supprimer ou suspendre des utilisateurs existants. En outre, la TOE doit donner des attributs à tous les sujets et à tous les objets de stockage sous son contrôle (par exemple les processus, les fichiers, les segments de mémoire, les dispositifs). Les valeurs de ces attributs doivent servir de base pour les droits d'accès par mandats. Des règles doivent spécifier quelles combinaisons de valeurs d'attributs d'un sujet et d'un objet sont nécessaires pour que l'accès à cet objet soit accordé au sujet.- Lorsqu'un objet est exporté, ses attributs doivent être exportés d'une manière telle que celui qui les reçoit puisse reconstituer leur valeur sans ambiguïté.- Les droits d'accès par mandats doivent être conçus de telle manière que le cas spécial suivant puisse être réalisé :- L'attribut comprend deux parties : la première peut prendre des valeurs ordonnées hiérarchiquement, la seconde représente un ensemble. (Dans le domaine gouvernemental, la première partie contient des classifications, par exemple non classifié, confidentiel, secret, très secret. La seconde contient des catégories.)- On dit qu'un attribut A domine un attribut B si :- la première partie de A est hiérarchiquement supérieure ou égale à la première partie de B, et la deuxième partie de B est un sous-ensemble de la deuxième partie de A ou lui est égale.- Les règles suivantes doivent être imposées :- L'accès en lecture d'un sujet à un objet n'est autorisé que si l'attribut du sujet domine celui de l'objet ;- L'accès en écriture d'un sujet à un objet n'est autorisé que si l'attribut de l'objet domine celui du sujet.- Les attributs d'un sujet créé pour agir au nom d'un utilisateur doivent être dominés par l'habilitation et l'autorisation de cet utilisateur telles qu'elles ont été déterminées au moment de l'identification et de l'authentification. Si les données importées n'ont pas d'attribut, un utilisateur autorisé doit pouvoir leur en assigner.- Chaque canal d'exportation doit pouvoir être identifié comme étant soit à niveau unique, soit multi-niveau. Il doit être impossible de transmettre ou de recevoir des données par des canaux désignés comme étant à niveau unique, à moins que les attributs de ces données ne correspondent à un attribut préspécifié déterminé. Les données transmises ou reçues par un canal à niveau unique doivent être communiquées avec un attribut correspondant, sauf s'il est possible à un utilisateur autorisé de spécifier l'attribut du canal d'une façon qui ne puisse pas être imitée. Dans ce cas, l'attribut des données est implicitement spécifié par l'attribut du canal.- Pour les canaux multi-niveaux, le protocole de communication doit garantir que le destinataire pourra complètement et sans ambiguïté reconstituer et mettre en correspondance les données et les attributs reçus.- Des utilisateurs non autorisés ne doivent pas pouvoir modifier les attributs d'un canal qui touchent à la sécurité. Il ne doit pas être possible de modifier ces attributs sans que la modification soit effectuée explicitement.- La TOE doit marquer les sorties lisibles par l'homme avec des valeurs d'attribut. Les valeurs d'attribut doivent être déterminées suivant les règles établies dans la TOE. Des utilisateurs autorisés doivent pouvoir spécifier le libellé imprimable de chaque valeur d'attribut.- Lors de toute tentative d'un utilisateur ou groupe d'utilisateurs pour accéder à des objets soumis à l'administration des droits, la TOE doit vérifier la validité de la demande. Les tentatives d'accès sans autorisation doivent être rejetées. Les valeurs des attributs doivent servir de base aux décisions concernant le contrôle d'accès par mandats. Les règles doivent spécifier sans ambiguïté quand un sujet est autorisé à avoir accès à un objet ainsi protégé. Si des droits d'accès discrétionnaires sont aussi attribués à un objet, l'accès ne doit être autorisé qu'à condition que les droits d'accès par mandats et discrétionnaires le permettent tous les deux. #### Imputabilité La TOE doit comporter un composant d'imputation qui soit capable, pour chacun des événements suivants, d'enregistrer cet événement avec les données exigées : Utilisation du mécanisme d'identification et d'authentification : Données exigées : Date ; heure ; identité fournie par l'utilisateur ; identification de l'équipement sur lequel le mécanisme d'identification et d'authentification a été utilisé (par exemple identificateur du terminal) ; réussite ou échec de la tentative ; autorisation de l'utilisateur. Actions qui tentent d'exercer des droits d'accès à un objet soumis à l'administration des droits : Données exigées : Date ; heure ; identité de l'utilisateur ; nom de l'objet ; type de la tentative d'accès ; réussite ou échec de la tentative ; attribut de l'objet. Création ou suppression d'un objet soumis à l'administration des droits : Données exigées : Date ; heure ; identité de l'utilisateur ; nom de l'objet ; type de l'action ; attribut de l'objet. Actions d'utilisateurs autorisés affectant la sécurité de la TOE : Données exigées : Date ; heure ; identité de l'utilisateur ; type de l'action ; nom et attribut de l'objet sur lequel porte l'action (de telles actions sont l'introduction ou la suppression (suspension) d'utilisateurs ; l'introduction ou le retrait de supports de stockage ; le démarrage ou l'arrêt de la TOE ; l'assignation d'un attribut ; la modification des attributs, des marques ou de la classification d'un canal). Les utilisateurs non autorisés ne doivent pas avoir accès aux données d'imputation. Il doit être possible de mettre sélectivement en oeuvre l'imputation pour un ou plusieurs utilisateurs. Il doit exister des outils pour examiner et maintenir les fichiers d'imputation et ces outils doivent être documentés. Ils doivent permettre d'identifier sélectivement les actions d'un ou de plusieurs utilisateurs. #### Audit Il doit exister des outils pour examiner les fichiers d'imputation pour les besoins d'audit et ces outils doivent être documentés. Ils doivent permettre d'identifier sélectivement les actions d'un ou de plusieurs utilisateurs. #### Réutilisation d'objet Tous les objets de stockage rendus à la TOE doivent, avant d'être réutilisés par d'autres sujets, être traités d'une manière telle qu'aucune conclusion ne puisse être tirée concernant leur contenu précédent. ## Exemple de classe de fonctionnalité : F-B2 #### Objectif L'exemple de classe F-B2 est dérivé des exigences fonctionnelles de la classe B2 du TCSEC américain. Elle étend le contrôle d'accès par mandats à tous les sujets et objets et renforce les exigences d'authentification de la classe B1.- #### Mécanismes obligatoires Cette classe exige que le contrôle d'accès soit implémenté à l'aide d'un mécanisme de validation à référence unique qui implémente le concept de moniteur de référence, c'est à dire que le mécanisme doit être résistant à l'intrusion, systématiquement utilisé et suffisamment petit (ayant une organisation suffisamment simple et une complexité suffisamment faible) pour être soumis à une analyse et à des tests dont la complétude puisse être assurée.- #### Identification et authentification La TOE doit identifier et authentifier de façon unique les utilisateurs. L'identification et l'authentification doivent avoir lieu avant toute autre interaction entre la TOE et l'utilisateur. D'autres interactions ne doivent être possibles qu'après une identification et une authentification réussies. Les informations d'authentification doivent être stockées de façon telle qu'elles soient seulement accessibles par des utilisateurs autorisés. L'identification et l'authentification doivent être traitées à travers un chemin de confiance entre l'utilisateur et la TOE initialisé par l'utilisateur. Pour chaque interaction, la TOE doit pouvoir établir l'identité de l'utilisateur. #### Contrôle d'accès La TOE doit pouvoir distinguer et administrer les droits d'accès de chaque utilisateur sur les objets soumis à l'administration des droits, au niveau d'un utilisateur individuel, au niveau de l'appartenance à un groupe d'utilisateurs, ou aux deux niveaux. Il doit être possible de regrouper des droits d'accès pour servir de base à des rôles. Au minimum, doivent pouvoir être définis les rôles d'opérateur de la TOE et d'administrateur de la TOE. Il doit être possible de refuser complètement à des utilisateurs ou à des groupes d'utilisateurs l'accès à un objet. Il doit être également possible de limiter l'accès d'un utilisateur à un objet aux seules opérations qui ne modifient pas cet objet. Il doit être possible d'accorder les droits d'accès à un objet en descendant jusqu'au niveau de granularité de l'utilisateur individuel. Il ne doit pas être possible à quelqu'un qui n'est pas un utilisateur autorisé d'accorder ou de retirer des droits d'accès à un objet. L'administration des droits doit disposer de contrôles pour limiter la propagation des droits d'accès. De même, seuls des utilisateurs autorisés doivent pouvoir introduire de nouveaux utilisateurs, supprimer ou suspendre des utilisateurs existants. En outre, la TOE doit donner des attributs à tous les sujets et à tous les objets (par exemple les processus, les fichiers, les segments de mémoire, les dispositifs). Les valeurs de ces attributs doivent servir de base pour les droits d'accès par mandats. Des règles doivent spécifier quelles combinaisons de valeurs d'attributs d'un sujet et d'un objet sont nécessaires pour que l'accès à cet objet soit accordé au sujet. Lorsqu'un objet est exporté, ses attributs doivent être exportés d'une manière telle que celui qui les reçoit puisse reconstituer leur valeur sans ambiguïté. Les droits d'accès par mandats doivent être conçus de telle manière que le cas spécial suivant puisse être réalisé : L'attribut comprend deux parties : la première peut prendre des valeurs ordonnées hiérarchiquement, la seconde représente un ensemble. (Dans le domaine gouvernemental, la première partie contient des classifications, par exemple non classifié, confidentiel, secret, très secret. La seconde contient des catégories.) On dit qu'un attribut A domine un attribut B si : la première partie de A est hiérarchiquement supérieure ou égale à la première partie de B, et la deuxième partie de B est un sous-ensemble de la deuxième partie de A ou lui est égale. Les règles suivantes doivent être imposées : L'accès en lecture d'un sujet à un objet n'est autorisé que si l'attribut du sujet domine celui de l'objet ; L'accès en écriture d'un sujet à un objet n'est autorisé que si l'attribut de l'objet domine celui du sujet. Les attributs d'un sujet créé pour agir au nom d'un utilisateur doivent être dominés par l'habilitation et l'autorisation de cet utilisateur telles qu'elles ont été déterminées au moment de l'identification et de l'authentification. Si les données importées n'ont pas d'attribut, un utilisateur autorisé doit pouvoir leur en assigner. Chaque canal d'exportation doit pouvoir être identifié comme étant soit à niveau unique, soit multi-niveau. Il doit être impossible de transmettre ou de recevoir des données par des canaux désignés comme étant à niveau unique, à moins que les attributs de ces données ne correspondent à un attribut préspécifié déterminé. Les données transmises ou reçues par un un canal à niveau unique doivent être communiquées avec un attribut correspondant, sauf s'il est possible à un utilisateur autorisé de spécifier l'attribut du canal d'une façon qui ne puisse pas être imitée. Dans ce cas, l'attribut des données est implicitement spécifié par l'attribut du canal. Pour les canaux multi-niveaux, le protocole de communication doit garantir que le destinataire pourra complètement et sans ambiguïté reconstituer et mettre en correspondance les données et les attributs reçus. Pour les canaux multi-niveaux, il doit être possible de déclarer les attributs maximums et minimums. Aucune donnée ne doit être transmise par un canal multi-niveau à moins que l'attribut de cette donnée domine l'attribut minimum du canal et qu'il soit dominé par l'attribut maximum du canal. Des utilisateurs non autorisés ne doivent pas pouvoir modifier les attributs d'un canal qui touchent à la sécurité. Il ne doit pas être possible de modifier ces attributs sans que la modification soit effectuée explicitement. La TOE doit marquer les sorties lisibles par l'homme avec des valeurs d'attribut. Les valeurs d'attribut doivent être déterminées suivant les règles établies dans la TOE. Des utilisateurs autorisés doivent pouvoir spécifier le libellé imprimable de chaque valeur d'attribut. Un utilisateur doit être informé immédiatement de toute modification apportée au niveau de sécurité qui lui est associé pendant une session interactive. L'utilisateur doit pouvoir à tout moment passer en revue tous les attributs du sujet.- Lors de toute tentative par des utilisateurs ou des groupes d'utilisateurs d'accéder à des objets soumis à l'administration des droits, la TOE doit vérifier la validité de la demande. Les tentatives d'accès non autorisé doivent être rejetées. Les valeurs des attributs doivent servir de base aux décisions concernant le contrôle d'accès par mandats. Les règles doivent spécifier sans ambiguïté quand un sujet est autorisé à avoir accès à un objet ainsi protégé. Si des droits d'accès discrétionnaires sont aussi attribués à un objet, l'accès ne doit être autorisé qu'à condition que les droits d'accès par mandats et discrétionnaires le permettent tous les deux. Il ne doit exister aucun canal de stockage connu qui puisse transférer de l'information entre des processus sans vérification de droits d'accès (c'est à dire de façon cachée) et qui ait une bande passante maximum (déterminée par des mesures réelles ou par une estimation technique) d'un niveau inacceptable. (Se référer au guide pour les canaux cachés du TCSEC [TCSEC] pour les indications d'acceptabilité.)- #### Imputabilité La TOE doit comporter un composant d'imputation qui soit capable, pour chacun des événements suivants, d'enregistrer cet événement avec les données exigées : Utilisation du mécanisme d'identification et d'authentification : Données exigées : Date ; heure ; identité fournie par l'utilisateur ; identification de l'équipement sur lequel le mécanisme d'identification et d'authentification a été utilisé (par exemple identificateur du terminal) ; réussite ou échec de la tentative ; autorisation de l'utilisateur. Actions qui tentent d'exercer des droits d'accès à un objet soumis à l'administration des droits : Données exigées : Date ; heure ; identité de l'utilisateur ; nom de l'objet ; type de la tentative d'accès ; réussite ou échec de la tentative ; attribut de l'objet. Création ou suppression d'un objet soumis à l'administration des droits : Données exigées : Date ; heure ; identité de l'utilisateur ; nom de l'objet ; type de l'action ; attribut de l'objet. Actions d'utilisateurs autorisés affectant la sécurité de la TOE : Données exigées : Date ; heure ; identité de l'utilisateur ; type de l'action ; nom et attribut de l'objet sur lequel porte l'action (de telles actions sont l'introduction ou la suppression (suspension) d'utilisateurs ; l'introduction ou le retrait de supports de stockage ; le démarrage ou l'arrêt de la TOE ; l'assignation d'un attribut ; la modification des attributs, des marques ou de la classification d'un canal). Les utilisateurs non autorisés ne doivent pas avoir accès aux données d'imputation. Il doit être possible de mettre sélectivement en oeuvre l'imputation pour un ou plusieurs utilisateurs. Il doit exister des outils pour examiner et maintenir les fichiers d'imputation et ces outils doivent être documentés. Ils doivent permettre d'identifier sélectivement les actions d'un ou de plusieurs utilisateurs. #### Audit Il doit exister des outils pour examiner les fichiers d'imputation pour les besoins d'audit et ces outils doivent être documentés. Ils doivent permettre d'identifier sélectivement les actions d'un ou de plusieurs utilisateurs. En outre, la TOE doit être capable d'auditer les événements connus qui pourraient être utilisés de façon malveillante pour permettre un flux non autorisé d'informations par exploitation de canaux cachés. #### Réutilisation d'objet Tous les objets de stockage rendus à la TOE doivent, avant d'être réutilisés par d'autres sujets, être traités d'une manière telle qu'aucune conclusion ne puisse être tirée concernant leur contenu précédent. ## Exemple de classe de fonctionnalité : F-B3 #### Objectif L'exemple de classe F-B3 est dérivé des exigences fonctionnelles des classes B3 et A1 du TCSEC américain. En plus des fonctions de la classe B2, elle fournit des fonctions pour permettre la mise en oeuvre de rôles distincts d'administration de la sécurité, et l'audit est étendu pour signaler les événements touchant à la sécurité.- #### Mécanismes obligatoires Cette classe exige que le contrôle d'accès soit implémenté à l'aide d'un mécanisme de validation à référence unique qui implémente le concept de moniteur de référence, c'est à dire que le mécanisme doit être résistant à l'intrusion, systématiquement utilisé et suffisamment petit (ayant une organisation suffisamment simple et une complexité suffisamment faible) pour être soumis à une analyse et à des tests dont la complétude puisse être assurée. #### Identification et authentification La TOE doit identifier et authentifier de façon unique les utilisateurs. L'identification et l'authentification doivent avoir lieu avant toute autre interaction entre la TOE et l'utilisateur. D'autres interactions ne doivent être possibles qu'après une identification et une authentification réussies. Les informations d'authentification doivent être stockées de façon telle qu'elles soient seulement accessibles par des utilisateurs autorisés. L'identification et l'authentification doivent être traitées à travers un chemin de confiance entre l'utilisateur et la TOE initialisé par l'utilisateur ou par la TOE. Pour chaque interaction, la TOE doit pouvoir établir l'identité de l'utilisateur. #### Contrôle d'accès La TOE doit pouvoir distinguer et administrer les droits d'accès de chaque utilisateur sur les objets soumis à l'administration des droits, au niveau d'un utilisateur individuel, au niveau de l'appartenance à un groupe d'utilisateurs, ou aux deux niveaux. Il doit être possible de regrouper des droits d'accès pour servir de base à des rôles. Au minimum, doivent pouvoir être définis les rôles d'opérateur de la TOE et d'administrateur de la TOE. Les rôles d'opérateur de la TOE, d'administrateur de la TOE et d'officier de sécurité de la TOE doivent être séparés. Il doit être possible de refuser complètement à des utilisateurs ou à des groupes d'utilisateurs l'accès à un objet. Il doit également être possible de limiter l'accès d'un utilisateur à un objet aux seules opérations qui ne modifient pas cet objet. Il doit être possible d'accorder les droits d'accès à un objet en descendant jusqu'au niveau de granularité de l'utilisateur individuel. Il ne doit pas être possible à quelqu'un qui n'est pas un utilisateur autorisé d'accorder ou de retirer des droits d'accès à un objet. Pour chaque objet soumis à l'administration des droits, il doit être possible de fournir une liste d'utilisateurs et une liste de groupes d'utilisateurs avec leurs droits sur cet objet. De plus, pour chacun de ces objets, il doit aussi être possible de fournir une liste des utilisateurs et une liste des groupes d'utilisateurs auxquels l'accès à cet objet est interdit. L'administration des droits doit disposer de contrôles pour limiter la propagation des droits d'accès. De même, seuls des utilisateurs autorisés doivent pouvoir introduire de nouveaux utilisateurs, supprimer ou suspendre des utilisateurs existants. En outre, la TOE doit donner des attributs à tous les sujets et à tous les objets (par exemple les processus, les fichiers, les segments de mémoire, les dispositifs). Les valeurs de ces attributs doivent servir de base pour les droits d'accès par mandats. Des règles doivent spécifier quelles combinaisons de valeurs d'attributs d'un sujet et d'un objet sont nécessaires pour que l'accès à cet objet soit accordé au sujet. Lorsqu'un objet est exporté, ses attributs doivent être exportés d'une manière telle que celui qui les reçoit puisse reconstituer leur valeur sans ambiguïté. Les droits d'accès par mandats doivent être conçus de telle manière que le cas spécial suivant puisse être réalisé : L'attribut comprend deux parties : la première peut prendre des valeurs ordonnées hiérarchiquement, la seconde représente un ensemble. (Dans le domaine gouvernemental, la première partie contient des classifications, par exemple non classifié, confidentiel, secret, très secret. La seconde contient des catégories.) On dit qu'un attribut A domine un attribut B si : la première partie de A est hiérarchiquement supérieure ou égale à la première partie de B, et la deuxième partie de B est un sous-ensemble de la deuxième partie de A ou lui est égale. Les règles suivantes doivent être imposées : L'accès en lecture d'un sujet à un objet n'est autorisé que si l'attribut du sujet domine celui de l'objet ; L'accès en écriture d'un sujet à un objet n'est autorisé que si l'attribut de l'objet domine celui du sujet. Les attributs d'un sujet créé pour agir au nom d'un utilisateur doivent être dominés par l'habilitation et l'autorisation de cet utilisateur telles qu'elles ont été déterminées au moment de l'identification et de l'authentification. Si les données importées n'ont pas d'attribut, un utilisateur autorisé doit pouvoir leur en assigner. Chaque canal d'exportation doit pouvoir être identifié comme étant soit à niveau unique, soit multi-niveau. Il doit être impossible de transmettre ou de recevoir des données par des canaux désignés comme étant à niveau unique, à moins que les attributs de ces données ne correspondent à un attribut préspécifié déterminé. Les données transmises ou reçues par un un canal à niveau unique doivent être communiquées avec un attribut correspondant, sauf s'il est possible à un utilisateur autorisé de spécifier l'attribut du canal d'une façon qui ne puisse pas être imitée. Dans ce cas, l'attribut des données est implicitement spécifié par l'attribut du canal. Pour les canaux multi-niveaux, le protocole de communication doit garantir que le destinataire pourra complètement et sans ambiguïté reconstituer et mettre en correspondance les données et les attributs reçus. Pour les canaux multi-niveaux, il doit être possible de déclarer les attributs maximums et minimums. Aucune donnée ne doit être transmise par un canal multi-niveau à moins que l'attribut de cette donnée domine l'attribut minimum du canal et qu'il soit dominé par l'attribut maximum du canal. Des utilisateurs non autorisés ne doivent pas pouvoir modifier les attributs d'un canal qui touchent à la sécurité. Il ne doit pas être possible de modifier ces attributs sans que la modification soit effectuée explicitement. La TOE doit marquer les sorties lisibles par l'homme avec des valeurs d'attribut. Les valeurs d'attribut doivent être déterminées suivant les règles établies dans la TOE. Des utilisateurs autorisés doivent pouvoir spécifier le libellé imprimable de chaque valeur d'attribut. Un utilisateur doit être informé immédiatement de toute modification apportée au niveau de sécurité qui lui est associé pendant une session interactive. L'utilisateur doit pouvoir à tout moment passer en revue tous les attributs du sujet. Lors de toute tentative par des utilisateurs ou des groupes d'utilisateurs d'accéder à des objets soumis à l'administration des droits, la TOE doit vérifier la validité de la demande. Les tentatives d'accès non autorisé doivent être rejetées. Les valeurs des attributs doivent servir de base aux décisions concernant le contrôle d'accès par mandats. Les règles doivent spécifier sans ambiguïté quand un sujet est autorisé à avoir accès à un objet ainsi protégé. Si des droits d'accès discrétionnaires sont aussi attribués à un objet, l'accès ne doit être autorisé qu'à condition que les droits d'accès par mandats et discrétionnaires le permettent tous les deux. Il ne doit exister aucun canal connu de stockage ou de séquencement qui puisse transférer de l'information entre des processus sans vérification de droits d'accès (c'est à dire de façon cachée) et qui ait une bande passante maximum (déterminée par des mesures réelles ou par une estimation technique) d'un niveau inacceptable. (Se référer au guide pour les canaux cachés du TCSEC [TCSEC] pour les indications d'acceptabilité.) #### Imputabilité La TOE doit comporter un composant d'imputation qui soit capable, pour chacun des événements suivants, d'enregistrer cet événement avec les données exigées : Utilisation du mécanisme d'identification et d'authentification : Données exigées : Date ; heure ; identité fournie par l'utilisateur ; identification de l'équipement sur lequel le mécanisme d'identification et d'authentification a été utilisé (par exemple identificateur du terminal) ; réussite ou échec de la tentative ; autorisation de l'utilisateur. Actions qui tentent d'exercer des droits d'accès à un objet soumis à l'administration des droits : Données exigées : Date ; heure ; identité de l'utilisateur ; nom de l'objet ; type de la tentative d'accès ; réussite ou échec de la tentative ; attribut de l'objet. Création ou suppression d'un objet soumis à l'administration des droits : Données exigées : Date ; heure ; identité de l'utilisateur ; nom de l'objet ; type de l'action ; attribut de l'objet. Actions d'utilisateurs autorisés affectant la sécurité de la TOE : Données exigées : Date ; heure ; identité de l'utilisateur ; type de l'action ; nom et attribut de l'objet sur lequel porte l'action (de telles actions sont l'introduction ou la suppression (suspension) d'utilisateurs ; l'introduction ou le retrait de supports de stockage ; le démarrage ou l'arrêt de la TOE ; l'assignation d'un attribut ; la modification des attributs, des marques ou de la classification d'un canal). Les utilisateurs non autorisés ne doivent pas avoir accès aux données d'imputation. Il doit être possible de mettre sélectivement en oeuvre l'imputation pour un ou plusieurs utilisateurs. Il doit exister des outils pour examiner et maintenir les fichiers d'imputation et ces outils doivent être documentés. Ils doivent permettre d'identifier sélectivement les actions d'un ou de plusieurs utilisateurs. #### Audit Il doit exister des outils pour examiner les fichiers d'imputation pour les besoins d'audit et ces outils doivent être documentés. Ils doivent permettre d'identifier sélectivement les actions d'un ou de plusieurs utilisateurs. En outre, la TOE doit être capable d'auditer les événements connus qui pourraient être utilisés de façon malveillante pour permettre un flux non autorisé d'informations par exploitation de canaux cachés. De plus, il doit exister un mécanisme pour surveiller l'apparition d'événements qui, soit touchent particulièrement à la sécurité, soit, en raison de leur fréquence, peuvent devenir une menace critique pour la sécurité de la TOE. Ce mécanisme doit pouvoir notifier sans délai à un utilisateur particulier ou ayant un rôle particulier l'apparition de tels événements. Le mécanisme doit mettre en oeuvre l'action la moins perturbatrice pour mettre fin à de tels événements.- #### Réutilisation d'objet Tous les objets de stockage rendus à la TOE doivent, avant d'être réutilisés par d'autres sujets, être traités d'une manière telle qu'aucune conclusion ne puisse être tirée concernant leur contenu précédent. ## Exemple de classe de fonctionnalité : F-IN #### Objectif L'exemple de classe de fonctionnalité F-IN concerne les TOE pour lesquelles il y a des exigences élevées d'intégrité pour les données et les programmes. De telles exigences peuvent être nécessaires par exemple pour des TOE bases de données. #### Identification et authentification La TOE doit identifier et authentifier de façon unique les utilisateurs. L'identification et l'authentification doivent avoir lieu avant toute autre interaction entre la TOE et l'utilisateur. D'autres interactions ne doivent être possibles qu'après une identification et une authentification réussies. Les informations d'authentification doivent être stockées de façon telle qu'elles soient seulement accessibles pour consultation ou modification par des utilisateurs autorisés. Pour chaque interaction, la TOE doit pouvoir établir l'identité de l'utilisateur. #### Contrôle d'accès La TOE doit pouvoir distinguer et administrer les droits d'accès des utilisateurs, des rôles et des processus aux objets désignés explicitement (le terme rôle désigne des utilisateurs qui ont des attributs spéciaux). Il doit être possible de restreindre l'accès des utilisateurs à ces objets d'une façon telle que cet accès ne soit possible que par l'intermédiaire de processus établis spécialement. De plus, il doit être possible d'affecter des objets à un type prédéfini. Il doit aussi être possible de spécifier pour chaque type d'objet quels sont les utilisateurs, les rôles ou les processus qui peuvent disposer de certains types d'accès à ces objets. Cela devrait permettre de limiter l'accès des utilisateurs aux objets d'un certain type d'une façon telle que cet accès ne soit possible que par l'intermédiaire de processus définis et fixés. Il ne devrait être possible qu'aux utilisateurs autorisés de définir des types nouveaux, d'accorder ou de retirer des droits d'accès à des types. Ces actions doivent être initialisées explicitement par ces utilisateurs. Pour ces actions, toute communication entre l'utilisateur et la TOE doit se faire à travers un chemin de confiance. Les droits d'accès minimum suivants doivent exister : lecture, écriture, ajout, suppression, renommage (pour tous les objets), exécution, suppression, renommage (pour les objets exécutables), création d'objets d'un certain type, suppression d'objets d'un certain type. Lors de toute tentative par des utilisateurs ou des groupes d'utilisateurs d'accéder à des objets soumis à l'administration des droits, la TOE doit vérifier la validité de la demande. Les tentatives d'accès non autorisé doivent être rejetées. #### Imputabilité La TOE doit comporter un composant d'imputation qui soit capable, pour chacun des événements suivants, d'enregistrer cet événement avec les données exigées : Utilisation du mécanisme d'identification et d'authentification : Données exigées : Date ; heure ; identité fournie par l'utilisateur ; identification de l'équipement sur lequel le mécanisme d'identification et d'authentification a été utilisé (par exemple identificateur du terminal) ; réussite ou échec de la tentative. Actions qui tentent d'exercer des droits d'accès à un objet soumis à l'administration des droits : Données exigées : Date ; heure ; identité de l'utilisateur ; nom de l'objet ; type de la tentative d'accès ; réussite ou échec de la tentative. Création ou suppression d'un objet soumis à l'administration des droits : Données exigées : Date ; heure ; identité de l'utilisateur ; nom de l'objet ; type de l'action. Actions d'utilisateurs autorisés affectant la sécurité de la TOE : Données exigées : Date ; heure ; identité de l'utilisateur ; type de l'action ; nom et attribut de l'objet sur lequel porte l'action (de telles actions sont l'introduction ou la suppression (suspension) d'utilisateurs ; l'introduction ou le retrait de supports de stockage ; le démarrage ou l'arrêt de la TOE). Définition ou suppression de types : Données exigées : Date ; heure ; identité de l'utilisateur ; type de l'action ; nom du type. Assignation d'un type à un objet : Données exigées : Date ; heure ; identité de l'utilisateur ; nom de l'objet ; nom du type. Attribution ou révocation de droits d'accès à un objet ou un type d'objet : Données exigées : Date ; heure ; identité de l'utilisateur ; type de l'action ; type du droit d'accès ; nom du sujet ; nom de l'objet ou nom du type d'objet. Les utilisateurs non autorisés ne doivent pas avoir accès aux données d'imputation. Il doit être possible de mettre sélectivement en oeuvre l'imputation pour un ou plusieurs utilisateurs. Il doit exister des outils pour examiner et maintenir les fichiers d'imputation et ces outils doivent être documentés. Ils doivent permettre d'identifier sélectivement les actions d'un ou de plusieurs utilisateurs. La structure des enregistrements d'imputation doit être décrite de façon complète. #### Audit Il doit exister des outils pour examiner les fichiers d'imputation pour les besoins d'audit et ces outils doivent être documentés. Ils doivent permettre d'identifier sélectivement les actions d'un ou de plusieurs utilisateurs. ## Exemple de classe de fonctionnalité : F-AV #### Objectif La classe de fonctionnalité F-AV impose des exigences élevées pour la disponibilité d'une TOE complète ou de fonctions particulières d'une TOE. De telles exigences sont importantes par exemple pour des TOE qui contrôlent des processus industriels. #### Fiabilité de service La TOE doit être capable de se rétablir à la suite d'une panne de certains composants matériels individuels (par exemple une carte d'un processeur particulier dans une TOE multiprocesseur) de façon telle que toutes les fonctions exigées en permanence restent constamment disponibles dans le reste de la TOE. Après réparation du composant défaillant, il doit être possible de le réintégrer dans la TOE de façon telle que la continuité de l'exploitation des fonctions exigées en permanence soit assurée. A la suite de cette réintégration, la TOE doit retrouver son degré originel de tolérance aux pannes. La durée maximum de tels processus de réintégration doit être déclarée. A tout moment et quelle que soit sa charge, la TOE doit pouvoir garantir un temps de réponse maximum pour certaines actions spécifiées. De plus, pour certaines actions spécifiées, il doit être garanti que la TOE ne sera pas sujette à une étreinte fatale. ## Exemple de classe de fonctionnalité : F-DI #### Objectif L'exemple de classe de fonctionnalité F-DI impose des exigences élevées en ce qui concerne la préservation de l'intégrité des données au cours de leur échange. #### Identification et authentification La TOE doit identifier et authentifier de façon unique les utilisateurs. L'identification et l'authentification doivent avoir lieu avant toute autre interaction entre la TOE et l'utilisateur. D'autres interactions ne doivent être possibles qu'après une identification et une authentification réussies. Les informations d'authentification doivent être stockées de façon telle qu'elles soient seulement accessibles pour consultation ou modification par des utilisateurs autorisés. Pour chaque interaction, la TOE doit pouvoir établir l'identité de l'utilisateur. Avant l'établissement d'une connexion, l'entité homologue (ordinateur, processus ou utilisateur) doit être identifiée et authentifiée de façon unique. Les données de l'utilisateur ne doivent être échangées qu'après que l'identification et l'authentification ont été effectuées avec succès. A la réception de données, il doit être possible d'identifier et d'authentifier de façon unique leur émetteur. Toutes les informations d'authentification doivent être protégées contre un accès non autorisé ou une contrefaçon. #### Imputabilité La TOE doit comporter un composant d'imputation qui soit capable, pour chacun des événements suivants, d'enregistrer cet événement avec les données exigées : Utilisation du mécanisme d'identification et d'authentification : Données exigées : Date ; heure ; initiateur de l'identification et de l'authentification ; nom du sujet à identifier ; réussite ou échec de l'action. Erreurs identifiées pendant l'échange de données : Données exigées : Date ; heure ; entité homologue dans l'échange de données ; nature de l'erreur ; réussite ou échec de la tentative de correction. Echange de données : Données exigées : Date ; heure ; identité de l'utilisateur initiateur ; nom de l'entité homologue (ordinateur, processus ou utilisateur) ; paramètres d'établissement de la connexion (s'ils varient). Les utilisateurs non autorisés ne doivent pas avoir accès aux données d'imputation. Il doit être possible de mettre sélectivement en oeuvre l'imputation pour un ou plusieurs utilisateurs. Il doit exister des outils pour examiner et maintenir les fichiers d'imputation et ces outils doivent être documentés. Ils doivent permettre d'identifier sélectivement les actions d'un ou de plusieurs utilisateurs. La structure des enregistrements d'imputation doit être complètement décrite. #### Audit Il doit exister des outils pour examiner les fichiers d'imputation pour les besoins d'audit et ces outils doivent être documentés. Ils doivent permettre d'identifier sélectivement les actions d'un ou de plusieurs utilisateurs. #### Echange de données Intégrité des données Des méthodes de détection et de correction d'erreurs doivent être appliquées en cas d'échange de données. Ces mécanismes doivent être conçus de manière à permettre d'identifier les manipulations intentionnelles des champs d'adresse et des données de l'utilisateur. La connaissance des seuls algorithmes utilisés dans les mécanismes, sans connaissance supplémentaire particulière, ne doit pas permettre une manipulation non reconnue des données précitées. La connaissance supplémentaire indispensable pour le faire doit être protégée de telle façon que seul un nombre restreint d'utilisateurs autorisés puissent y avoir accès. De plus, des mécanismes qui identifient de façon sûre et unique comme une erreur la réémission non autorisée de données doivent être utilisés. ## Exemple de classe de fonctionnalité : F-DC #### Objectif L'exemple de classe de fonctionnalité F-DC est destiné aux TOE très exigeantes en matière de confidentialité des données au cours de leur échange. Un équipement cryptographique est un exemple de candidat pour cette classe. #### Echange de données Confidentialité des données La TOE doit être dotée d'un dispositif destiné à chiffrer l'information de l'utilisateur avant l'échange et (côté réception) à la déchiffrer automatiquement. Un algorithme officiellement approuvé par une autorité de certification doit être utilisé. Il doit être assuré que les valeurs des paramètres (par exemple les clés) nécessaires au déchiffrement sont protégées de telle manière qu'aucune personne non autorisée ne puisse avoir accès à ces données. ## Exemple de classe de fonctionnalité : F-DX #### Objectif L'exemple de classe de fonctionnalité F-DX est destiné aux réseaux très exigeants en matière de confidentialité et d'intégrité des informations à échanger. Par exemple, cela peut être le cas lorsque des informations sensibles doivent être échangées à travers des réseaux non protégés (par exemple des réseaux publics). #### Identification et authentification La TOE doit identifier et authentifier de façon unique les utilisateurs. L'identification et l'authentification doivent avoir lieu avant toute autre interaction entre la TOE et l'utilisateur. D'autres interactions ne doivent être possibles qu'après une identification et une authentification réussies. Les informations d'authentification doivent être stockées de façon telle qu'elles soient seulement accessibles pour consultation ou modification par des utilisateurs autorisés. Pour toute interaction, la TOE doit pouvoir établir l'identité de l'utilisateur. Avant l'échange de données de l'utilisateur, l'entité homologue (ordinateur, processus ou utilisateur) doit être identifiée et authentifiée de façon unique. Les données de l'utilisateur ne doivent être échangées qu'après que l'identification et l'authentification ont été effectuées avec succès. A la réception de données, il doit être possible d'identifier et d'authentifier de façon unique leur émetteur. Toutes les informations d'authentification doivent être protégées contre un accès non autorisé ou une contrefaçon. #### Imputabilité La TOE doit comporter un composant d'imputation qui soit capable, pour chacun des événements suivants, d'enregistrer cet événement avec les données exigées : Utilisation du mécanisme d'identification et d'authentification : Données exigées : Date ; heure ; initiateur de l'identification et de l'authentification ; nom du sujet à identifier ; réussite ou échec de l'action. Erreurs identifiées pendant l'échange de données : Données exigées : Date ; heure ; entités homologues dans l'échange de données ; type de l'erreur ; réussite ou échec de la tentative de correction. Etablissement de la connexion : Données exigées : Date ; heure ; identité de l'utilisateur initiateur ; nom de l'entité homologue (ordinateur, processus ou utilisateur) ; paramètres d'établissement de la connexion (s'ils varient). Transactions d'échange de données spéciales : Données exigées : Date ; heure ; identité de l'utilisateur émetteur ; identité de l'utilisateur récepteur ; informations de l'utilisateur transmises ; date et heure de la réception des données. Les utilisateurs non autorisés ne doivent pas avoir accès aux données d'imputation. Il doit être possible de mettre sélectivement en oeuvre l'imputation pour un ou plusieurs utilisateurs. Il doit exister des outils pour examiner et maintenir les fichiers d'imputation et ces outils doivent être documentés. Ils doivent permettre d'identifier sélectivement les actions d'un ou de plusieurs utilisateurs. La structure des enregistrements d'imputation doit être complètement décrite. #### Audit Il doit exister des outils pour examiner les fichiers d'imputation pour les besoins d'audit et ces outils doivent être documentés. Ils doivent permettre d'identifier sélectivement les actions d'un ou de plusieurs utilisateurs. #### Echange de données Contrôle d'accès Toutes les informations transmises auparavant et pouvant être utilisées pour un déchiffrement non autorisé doivent être protégées de manière telle que seules puissent accéder à ces données les personnes qui en ont absolument besoin pour pouvoir remplir leur tâche. Confidentialité des données La TOE doit offrir la possibilité d'un chiffrement de bout en bout qui garantisse la confidentialité en ce qui concerne le destinataire sur de grandes sections du canal de communication. En outre, la confidentialité du flux de trafic doit aussi être garantie sur des liaisons de données désignées. Intégrité des données La TOE doit être conçue de façon telle qu'une manipulation non autorisée des données des utilisateurs et des données d'imputation, et une réémission de données non autorisée soient identifiées de façon sûre comme des erreurs.
Index de la documentation sur les critères | Index général de la documentation Sommaire | Introduction | Champ d'application | Fonctionnalité Efficacité | Conformité | Conformité E1 | Conformité E2 | Conformité E3 | Conformité E4 | Conformité E5 | Conformité E6 Résultats de l'évaluation | Glossaire | Exemples de classes de Fonctionnalité | "Claims language" |

webmaster@scssi.gouv.fr - Copyright © 1999 Service Central de la Sécurité des Systèmes d'Information
Dernière mise à jour le 17/06/99 à 17:04:24