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" |

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.

Identification et authentification

Contrôle d'accès

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.

Identification et authentification

Contrôle d'accès

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é

• 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

Réutilisation d'objet

Identification et authentification

Contrôle d'accès

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é

• 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

Réutilisation d'objet

Mécanismes obligatoires

Identification et authentification

Contrôle d'accès

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é

• 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

Réutilisation d'objet

Mécanismes obligatoires

Identification et authentification

Contrôle d'accès

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é

• 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

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

Identification et authentification

Contrôle d'accès

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é

• 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

Fiabilité de service

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.

Identification et authentification

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é

• 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

Echange de 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.

Echange de 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.

Identification et authentification

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é

• 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

Echange de données

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" |