ANNEXE B - Le "Claims Language"
Introduction
Dans le contexte des critères d'évaluation de la sécurité des TI, il est commode de disposer d'un moyen pour décrire en style semi-formel les fonctions de sécurité annoncées par un produit de sécurité TI, mais encore exprimées en langage naturel. Le Claims Language défini dans la présente annexe a été développé pour satisfaire ce besoin.
Les avantages de l'utilisation de ce langage pour spécifier la fonctionnalité de sécurité sont les suivants :
- il fournit un style semi-formel de spécification, mais qui, comme il est basé sur le langage naturel, peut être lu et compris sans connaissance particulière d'une notation ou d'un ensemble de règles ;
- il indique les liaisons et les regroupements nécessaires entre les annonces ;
- il réduit les risques d'ambiguïté dans l'interprétation des annonces ;
- il permet d'exprimer les annonces concernant une TOE d'une manière adaptée au processus d'évaluation.
Le Claims Language facilite une extension contrôlée de la notation prédéfinie dans le maniement de concepts pour lesquels il n'existe pas d'élément adapté. Dans un Claims Document, le langage naturel normal peut être utilisé pour décrire des mécanismes et des hypothèses lorsqu'une approche plus formelle n'est pas nécessaire. Le Claims Language est assez souple pour permettre de définir tout ensemble d'annonces propre à une TOE spécialisée sans s'écarter aucunement des règles du langage : ainsi les commanditaires d'une évaluation ne sont nullement astreints à adapter leurs annonces au langage.
Vue d'ensemble
Dans l'utilisation du Claims Language, les fonctions de sécurité sont exprimées au moyen d'un ensemble de règles pour produire des Modèles d'Expression d'Action dont chacun fournit l'ossature d'un type particulier d'annonce. Chaque Modèle d'Expression d'Action est alors combiné avec un élément d'un ensemble d'Expressions de Cible pour créer l'ébauche d'une annonce. Des noms et des expressions spécifiques au produit, à la fonction ou au fournisseur sont alors substitués dans cette ébauche pour créer une annonce réelle. Un exemple de génération d'une annonce figure dans les paragraphes B.30 à B.34 de la présente annexe.
Il est possible d'inclure dans la déclaration d'une annonce une référence au mécanisme qui l'implémente.
Il est permis d'omettre ou de modifier les mots de liaison utilisés dans les ébauches d'annonces afin d'en faciliter la lecture ou d'en améliorer la justesse grammaticale.
Voici des exemples de modifications autorisées :
- remplacer le pluriel par le singulier et vice versa ;
- insérer ou retirer les articles définis et indéfinis ;
- modifier les prépositions.
Il est permis d'introduire de nouvelles expressions d'action ou de cible lorsqu'il n'existe pas d'expression appropriée, à condition qu'elles aient été discutées avec l'organisme de certification et approuvées par lui.
Une présentation normalisée doit être utilisée pour les Claims Documents contenant des annonces en Claims Language, comme il est indiqué dans les paragraphes B.38 à B.44 de la présente annexe. Les annonces doivent être regroupées sous une rubrique normalisée basée sur les rubriques génériques pour la fonctionnalité. Cela facilite la compréhension et la comparaison avec d'autres TOE.
Avertissements
Il faudra prendre des précautions pour formuler les annonces qui dépendent de la configuration. Il est peut-être possible de configurer une TOE d'une manière non sûre (c'est-à-dire que certaines annonces sont invalidées). Si c'est le cas, des restrictions propres à exclure de telles options ou combinaisons d'options non sûres devraient être présentées comme des contraintes d'environnement (voir le paragraphe B.41 plus loin dans cette annexe).
Il faudra aussi prendre des précautions pour que les annonces soient formulées au niveau voulu de granularité. Si une des annonces proposées semble englober plusieurs rubriques génériques ou si elle exige plus de substitutions que ne le permet l'emploi du modèle approprié, c'est que l'annonce est d'un niveau trop élevé et qu'elle a besoin d'être fragmentée en une série d'annonces plus simples.
Modèles d'Expression d'Action
Les Modèles d'Expression d'Action doivent être réalisés à partir de l'ossature ci-dessous, dans laquelle les caractères italiques indiquent des mots ou des expressions, dans le modèle, qui doivent être remplacés, dans l'annonce réelle, par des substitutions spécifiques en rapport avec l'annonce, [] désignant les parties facultatives et <> un choix parmi les options pertinentes de la liste qui suit.
This TOE [<qualifier>] <verb> <action> ... [time] [using the mechanism defined in paragraph n].
Où <qualifier> peut être :
contains a function that
ou must be used in an environment that
et <verb> peut être :
will
ou will not
ou can be configured to
ou can be configured to not
ou cannot be configured to
et <action> peut être :
establish
ou detect
ou control
ou permit
ou prevent
ou ensure
ou record in object
et <time> peut être :
before security-relevant-event
ou after security relevant-event
L'option "environment" de <qualifier> n'est utilisée que pour définir les contraintes d'environnement lorsqu'une grande précision est exigée.
Lorsque les détails de mécanismes spécifiques font partie de la cible de sécurité, ils doivent être définis comme faisant partie du Claims Document à l'aide d'un paragraphe associé de spécification du mécanisme. Si une telle association n'est pas incluse, c'est que les détails du mécanisme ne font pas partie de la cible de sécurité et seront traités comme une information interne. L'option "function" du <qualifier> est facultative. Elle sert à nommer le mécanisme particulier d'un produit qui implémente une annonce particulière. Ce nom n'est inclus que dans un but explicatif.
Voici quelques exemples de Modèles d'Expression d'Action :
This product will ensure ....
This product contains an audit utility that will establish ...
This product can be configured to permit ...
-
This add-in board will record in its audit trail ...
This product will prevent ... before completion of secure startup.
Expressions de Cible
L'ensemble autorisé d'Expressions de Cible est le suivant, [] désignant les parties facultatives de l'expression :
- ... audit-information concerning security-relevant-events
- ... the identity of a process requested
- ... the identity of the {user,process} requesting a process
- ... the identity of the {user,process} requesting access-type to an object
- ... the identity of a process executed
- ... the rejection of a process request
- ... the identity of an object to which access-type was requested
- ... the identity of an object to which access-type was granted
- ... the identity of an object to which access-type was refused
- ... the access-set of a user
- ... the access-set of a process
- ... the access-set of a {user,process}
- ... the access-set of an object
- ... the access-type granted to a {user,process} in respect of an object
- ... access-type by {user,process} in respect of an object
- ... the action performed by a {user,process} in respect of an object
- ... the factors affecting the access-set of a user
- ... the factors affecting the access-set of a process
- ... the factors affecting the access-set of a {user,process}
- ... the factors affecting the access-set of an object
- ... clearing of information from an object
- ... the security-attributes of an object
- ... the correctness of the security-attributes of an object
- ... the security-attributes of an object formed by combining a number of objects
- ... the security-attributes of a set of objects formed by partitioning a single object
- ... the granting of access-type to an object cannot cause deadlock through {user,process}es using access-type to objects
- ... the {user,process}es using access-type to an object which has caused deadlock
- ... the granting of access-type to an object cannot cause livelock through {user,process}es using access-type to objects
- ... the {user,process}es using access-type to an object which has caused livelock
- ... security-attribute of object is identical to that of object
- ... claim [not] to become time-critical
- ... claim [not] to become accelerated or delayed
- ... claim [not] to become time-dependant
- ... claim [not] to be by-passed
- ... claim [not] to be deactivated
- ... claim [not] to be corrupted
Substitutions
Des substitutions doivent être faites pour les noms et expressions ci-après (mis en italique dans les Modèles d'Expression d'Action et les Expressions de Cible ci-dessus) :
access-set ; access-type ; audit-information ; claim ; factors ; function ; n ; object ; product ; process ; security-attribute ; security-relevant-event ; use ; {user,process}
Toutes les substitutions doivent être expliquées en utilisant le langage naturel, soit dans une section séparée du Claims Document (voir le paragraphe B.39 de la présente annexe), soit aussitôt après l'annonce où la substitution est employée.
Voici quelques exemples de possibilités de substitution :
access-set remplacé par read/write access to IO ports
access-type remplacé par read permission
access-type remplacé par read/write/delete permission
audit-information remplacé par date and time
audit-information remplacé par terminal number
claim remplacé par (a cross-reference to another claim)
factors remplacé par number of incorrect responses
function remplacé par password system
n remplacé par (a paragraphe number)
object remplacé par file
object remplacé par resource control block
object remplacé par hard disc storage (i.e. a type of object)
TOE remplacé par operating system
TOE remplacé par PC security board
process remplacé par unprivileged task
security-attribute remplacé par integrity of data
security-attribute remplacé par actual destination
security-attribute remplacé par apparent source
security-relevant-event remplacé par attempted privilege violation
security-relevant-event remplacé par user logoff
security-relevant-event remplacé par change of security level
user remplacé par data entry clerk
user remplacé par security administrator
{user,process} remplacé par job (i.e. implying any user)
Certaines parties des Expressions d'Action et des Expressions de Cible sont mises entre crochets [] ; ce sont des expressions ou des mots facultatifs qui peuvent être inclus ou omis suivant les besoins dans l'annonce du fournisseur.
La plupart des substitutions de noms et d'expressions s'expliquent d'elles-mêmes. Toutefois il existe quelques conventions particulières qui sont expliquées ci-après.
La définition d'un domaine d'accès (access-set) varie suivant qu'il est en rapport avec :
- un objet ; dans ce cas il représente la liste des utilisateurs (user), des processus (process) et des groupes {user,process} à chacun desquels est associé un type d'accès (access-type) et qui sont capables d'utiliser un objet (object) ;
- un processus, un utilisateur ou un groupe {user, process} ; auquel cas il représente la liste des objets à chacun desquels est associé un type d'accès et qui sont à la disposition d'un utilisateur, d'un processus ou d'un groupe {user, process}.
Ainsi un domaine d'accès est une liste (conceptuelle) de tous les objets auxquels un utilisateur peut avoir accès, ainsi que de ce que cet utilisateur peut faire à chacun de ces objets et à travers quels processus, ou une liste (conceptuelle) de tous les utilisateurs qui peuvent accéder à un objet, à travers quels processus et ce qu'ils peuvent faire à cet objet.
Le type d'accès (access-type) est la série des modes d'utilisation d'un objet et il est défini par le fournisseur. Les expressions create, read, write, delete, execute ou une combinaison de ces mots, ou encore none, en sont des exemples représentatifs.
Un exemple spécifique pourrait être donné par l'ensemble suivant :
- "Amend" permet de mettre à jour un enregistrement, mais pas d'en ajouter un nouveau dans le fichier,
- "Create" permet d'ajouter de nouveaux enregistrements au fichier, mais pas de modifier ceux qui existent,
- "Delete" permet de retirer des enregistrements du fichier,
- "Execute" permet de charger le fichier en mémoire, puis de le mettre en attente d'exécution en tant que programme,
- "Read" permet de recopier dans la mémoire de travail des données contenues dans des enregistrements.
Beaucoup d'objets possèderont des attributs de sécurité identiques. Aussi lorsqu'une annonce s'appliquera à tous les objets d'un type particulier, c'est généralement en termes de type d'objet que la substitution sera le mieux exprimée plutôt qu'en énumérant tous les objets possibles de ce type.
Mécanismes
Il est possible d'inclure dans une annonce la description du mécanisme utilisé pour implémenter cette annonce. Cela se fait à l'aide de l'option "using" du Modèle d'Expression d'Action de l'annonce, en donnant une référence à un paragraphe du Claims Document qui spécifie ou explique le mécanisme employé. L'évaluation comportera alors la confirmation du fait que le mécanisme déclaré est bien le mécanisme utilisé.
Toute méthode appropriée pourra être utilisée pour définir ou décrire le mécanisme pourvu que les explications soient suffisantes pour que l'évaluation détermine, à un niveau de confiance correspondant au niveau d'évaluation visé, que :
- le mécanisme annoncé est bien présent dans le produit,
- son fonctionnement correspond à la spécification annoncée,
- c'est le mécanisme réellement utilisé pour implémenter l'annonce.
Dans beaucoup de cas, il peut être plus facile et plus clair de définir un mécanisme en se référant à une norme publiée, ou de présenter un tableau des types d'entrée et des résultats correspondants, plutôt que de fournir des détails de l'algorithme utilisé en se servant soit du langage naturel, soit d'un langage de spécification ou de programmation.
Exemple
A titre d'exemple, le modèle d'Expression d'Action suivant peut être généré en se servant des règles spécifiées :
This TOE will establish ....
où le mot en italique peut être remplacé par un terme spécifique.
De même, une Expression de Cible peut être choisie, comme par exemple :
... the identity of an object to which access-type was requested.
La réunion des deux donne le texte :
This TOE will establish the identity of an object to which access-type was requested.
dans lequel des substitutions possibles sont :
add-in security board pour TOE
any file pour object
write or delete permission pour access-type
Ainsi une annonce complète pourra être :
This add-in security board will determine the identity of any file to which write or delete permission was requested.
Evidemment cet exemple est tout à fait artificiel. En pratique, pour les TOE réelles, on fait des annonces extrêmement spécifiques, souvent liées à un environnement particulier, réel ou supposé.
Structure du Claims Document
Utilisation des rubriques génériques relatives à la fonctionnalité
Les annonces doivent être regroupées sous les rubriques génériques exposées au chapitre 2 des présents critères. Toutes les TOE ne feront pas des annonces entrant dans toutes les rubriques ; lorsque cela se présente, le fait qu'il n'y a pas d'annonce dans telle rubrique particulière doit être déclaré. Des annonces doivent être incluses pour tous les événements ou actions qui doivent être empêchées.
Le tableau B.1 identifie les Expressions de Cible qui apparaîtront souvent dans certaines rubriques génériques particulières. Il est destiné seulement à servir de guide général ; la souplesse du Claims Language signifie que souvent d'autres Expressions de Cible seront également appropriées.
Le tableau B.2 fait correspondre les Expressions de Cible et les possibilités de substitution qu'elles comportent.
Plan du Claims Document
Une cible de sécurité utilisant le Claims Language doit être présentée suivant la structure suivante :
- les objectifs de sécurité de la cible, y compris toute contrainte ou hypothèse concernant l'environnement réel ou présumé de la TOE, sous forme d'un argumentaire du produit (ou une politique de sécurité du système dans le cas d'un système) ;
- une spécification informelle des annonces en langage naturel, ou une référence à un autre document contenant cette spécification informelle (ce peut être la référence à une classe de fonctionnalité définie en style informel), et une correspondance entre ces annonces informelles et les objectifs de sécurité ;
- les substitutions globales ;
- les annonces entrant successivement sous chaque rubrique générique ;
- le détail des mécanismes de sécurité ;
- la cotation annoncée de la résistance minimum des mécanismes ;
- le niveau d'évaluation visé.
Dans la rubrique "Substitutions Globales", toutes les substitutions générales utilisées dans les Expressions d'Action ou de Cible d'une ou de plusieurs annonces doivent être définies et expliquées.
On ne doit pas tenir compte de ces substitutions lorsque des substitutions différentes (généralement plus spécifiques) sont données comme faisant partie d'annonces particulières.
Si une TOE compte sur certaines propriétés de son environnement réel ou supposé pour fonctionner correctement, ces propriétés doivent être spécifiées dans la section argumentaire ou politique du Claims Document. Le processus d'évaluation supposera que ces contraintes ou ces hypothèses existeront dans l'environnement réel.
Chacune de ces contraintes ou de ces hypothèses devront être exprimées soit en langage naturel soit en Claims Language (en utilisant le qualificatif d'environnement de l'Expression d'Action). Lorsqu'il existe une ambiguïté (parce que le langage naturel a été utilisé) les évaluateurs interpréteront de telles contraintes ou hypothèses de façon cohérente avec les autres hypothèses ou annonces.
Certaines annonces peuvent rester valides même si une assertion particulière est inexacte. Lorsque tel est le cas, le langage naturel doit être utilisé pour indiquer quelles sont les annonces qui restent exactes quand cette affirmation est erronée.
Voici un exemple d'affirmation (exprimée en langue naturelle) :
Il ne faut pas retirer la batterie de secours de la mémoire vive de la carte de sécurité ni la laisser se décharger au-dessous de sa tension minimale de fonctionnement.
Format des annonces individuelles
Chaque substitution, dans les Expressions d'Action ou de Cible, utilisée pour construire une annonce qui n'est pas identifiée et définie dans la section des substitutions globales du Claims Document doit être définie et exprimée en langage naturel immédiatement après l'annonce où elle apparaît.
Tableau B.1 - Expressions de Cible des annonces et rubriques génériques
Identification et authentification
| Contrôle d'accès
| | Imputabilité
| | | Audit
| | | | Réutilisation d'objet
| | | | | Fidélité
| | | | | | Fiabilité de service
| | | | | | | Echange de données
| | | | | | | |
1 Audit information X X X X X X X X
2 Identity of process requested X X X X X X
3 Identity of {u,p} requesting a process X X X X X X
4 Identity of {u,p} requesting an object X X X X X X
5 Identity of process executed X X X X X X
6 Rejection of process request X X X X X X
7 Identity of object requested X X X X X X
8 Identity of object granted X X X X X X X
9 Identity of object refused X X X X X X
10 Access-set of user X X
11 Access-set of process X X
12 Access-set of {u,p} X X
13 Access-set of object X X
14 Object access granted to {u,p} X X X X X
15 Object access by {u,p} X X X X X
16 Object actions performed by {u,p} X X X X
17 Factors affecting user access-set X X
18 Factors affecting process access-set X X
19 Factors affecting {u,p} access-set X X
20 Factors affecting object access-set X X
21 Clearing information from object X X
22 Security-attributes of object X X X X X X X X
23 Correctness of security-attributes of object X X
24 Security-attributes of combinaison object X X X
25 Security-attributes of partitioned object X X X
26 Granting access causes no deadlock X X
27 Deadlock can be detected X X
28 Granting access causes no livelock X X
29 Livelock can be detected X X
30 Objects have identical security-attributes X X X
31 Time-critical claim X
32 Accelerated or delayed claim X
33 Time-dependant claim X
34 By-pass claim X X X X X X X X
35 Deactivate claim X X X X X X X X
36 Corrupt claim X X X X X X X X
Tableau B.2 - Expressions de Cible des annonces et substitutions autorisées
access-set
| access-type
| | audit-information
| | | claim
| | | | object
| | | | | process
| | | | | | security-attribute
| | | | | | | security-relevant-event
| | | | | | | | user
| | | | | | | | | {user,process}
| | | | | | | | | |
1 Audit information X X
2 Identity of process requested X
3 Identity of {u,p} requesting a process X X
4 Identity of {u,p} requesting an object X X X
5 Identity of process executed X
6 Rejection of process request X
7 Identity of object requested X X
8 Identity of object granted X X
9 Identity of object refused X X
10 Access-set of user X X
11 Access-set of process X X
12 Access-set of {u,p} X X
13 Access-set of object X X
14 Object access granted to {u,p} X X X
15 Object access by {u,p} X X X
16 Object actions performed by {u,p} X X
17 Factors affecting user access-set X X
18 Factors affecting process access-set X X
19 Factors affecting {u,p} access-set X X
20 Factors affecting object access-set X X
21 Clearing information from object X
22 Security-attributes of object X X
23 Correctness of security-attributes of object X X
24 Security-attributes of combinaison object X X
25 Security-attributes of partitionned object X X
26 Granting access causes no deadlock X X X
27 Deadlock can be detected X X X
28 Granting access causes no livelock X X X
29 Livelock can be detected X X X
30 Objects have identical decurity-attributes X X
31 Time-critical claim X
32 Accelerated or delayed claim X
33 Time-dependant claim X
34 By-pass claim X
35 Deactivate claim X
36 Corrupt claim X
| 
![[Début]](/images/top.gif)
![[Précédente]](/images/prev.gif)
![[Suivante]](/images/nextg.gif)
![[Fin]](/images/bottomg.gif)