| 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 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" |
### FONCTIONNALITE #### Introduction Une cible d'évaluation (TOE) qui fournit de la sécurité (une combinaison de confidentialité, d'intégrité et de disponibilité) doit présenter des caractéristiques de sécurité appropriées. Il sera normalement nécessaire de déterminer qu'un degré de confiance approprié peut être accordé à ces caractéristiques. Pour cela, les caractéristiques elles-mêmes doivent être spécifiées. Le ou les documents qui spécifient ces caractéristiques, ainsi que le niveau d'évaluation désiré, constituent la cible de sécurité pour cette TOE. Dans les présents critères, les caractéristiques de sécurité sont considérées à trois niveaux. Le point de vue le plus abstrait est celui des objectifs de sécurité qui représentent la contribution à la sécurité qu'une TOE se propose d'apporter. Pour atteindre ces objectifs, la TOE doit contenir certaines fonctions dédiées à la sécurité. Ces fonctions dédiées à la sécurité doivent, à leur tour, être implémentées grâce à des mécanismes de sécurité spécifiques. Ces trois niveaux peuvent être schématisés comme suit : Objectifs de sécurité - Pourquoi la fonctionnalité est voulue. Fonctions dédiées à la sécurité - Quelle fonctionnalité est réellement fournie. Mécanismes de sécurité - Comment la fonctionnalité est fournie. #### La cible de sécurité La cible de sécurité sert à la fois de spécification des fonctions dédiées à la sécurité, par rapport à laquelle la TOE sera évaluée, et de description des liens entre la TOE et l'environnement dans lequel celle-ci sera exploitée. Sont donc intéressés par la cible de sécurité non seulement les responsables de la production de la TOE et de son évaluation, mais également les responsables de sa gestion, de son achat, de son installation, de sa configuration, de son exploitation et de son emploi. Le contenu exigé d'une cible de sécurité peut être résumé ainsi : Soit une politique de sécurité du système soit un argumentaire du produit. Une spécification des fonctions dédiées à la sécurité requises. Une définition des mécanismes de sécurité requis (optionnelle). La cotation annoncée de la résistance minimum des mécanismes. Le niveau d'évaluation visé. Chacun de ces éléments est décrit plus en détail ci-dessous. Les exigences pour la présentation de la cible de sécurité dépendent du niveau d'évaluation visé. Le niveau d'évaluation détermine également les autres documents de la TOE qui doivent être fournis pour l'évaluation, ainsi que les exigences sur leur contenu et leur présentation, et les exigences concernant les éléments de preuve qui doivent être fournis afin de montrer que la TOE satisfait à la cible de sécurité. La cible de sécurité peut se présenter sous la forme d'un document unique ou de plusieurs documents. Lorsque plusieurs documents sont utilisés, leurs relations doivent être clairement indiquées. Le commanditaire de l'évaluation est responsable de la fourniture et de la fidélité de la cible de sécurité pour l'évaluation. #### Politique de sécurité d'un système Les éléments constituant une cible de sécurité sont différents selon qu'il s'agit d'un système ou d'un produit. Dans le cas d'un système, l'environnement réel dans lequel la TOE sera utilisée est connu, ses objectifs de sécurité peuvent être déterminés, et les menaces réelles et les contre-mesures existantes peuvent être prises en compte. Ces détails sont donnés dans un document de politique de sécurité du système. La politique de sécurité d'un système spécifie l'ensemble des lois, règlements et pratiques qui régissent la façon de gérer, protéger et diffuser les informations et autres ressources sensibles au sein d'un système spécifique. Elle doit identifier les objectifs de sécurité du système et les menaces auxquelles celui-ci devra faire face. Ces objectifs de sécurité doivent être pris en compte par une combinaison de fonctions dédiées à la sécurité du système (implémentées au sein de la TOE), et également par des moyens physiques, relatifs au personnel ou organisationnels, associés au système. La politique de sécurité d'un système doit couvrir tous les aspects de la sécurité relatifs au système, en incluant ces mesures physiques, organisationnelles et relatives au personnel qui lui sont associées. Toutes les organisations auront des normes générales de sécurité qui s'appliqueront à tous les systèmes au sein de l'organisation et qui définiront les relations concernant la sécurité entre l'organisation et le monde extérieur. Ces normes peuvent être considérées comme une politique de sécurité interne : l'ensemble des lois, règlements et pratiques qui régissent la façon de gérer, protéger et diffuser les biens, en particulier les informations sensibles, au sein de l'organisation. Beaucoup d'organisations auront une politique de sécurité interne explicite et écrite, qui spécifiera les règles, les pratiques ainsi que les lois nationales et internationales applicables auxquelles elles doivent se conformer. Dans ce cas, on doit y faire référence dans la politique de sécurité du système. Dans le cas contraire, tous les aspects pertinents doivent être présentés par écrit dans chacune des politiques de sécurité des systèmes de l'organisation. Le premier rôle de la politique de sécurité interne est de fournir le contexte nécessaire à l'identification des objectifs de sécurité du système. Le fait d'identifier les biens propres à prendre en considération, les menaces générales et les résultats des analyses de risques aideront à identifier ces objectifs de sécurité du système. Un débat sur les méthodes d'analyse de risques est hors du champ d'application des présents critères. Dans le cas d'un système individuel, la politique de sécurité du système doit définir les mesures de sécurité à mettre en oeuvre pour satisfaire aux objectifs de sécurité du système en cohérence avec la politique sécurité interne. Les mesures de sécurité requises par la politique de sécurité du système seront réalisées par une combinaison de fonctions dédiées à la sécurité implémentées par la TOE, et par des moyens physiques, relatifs au personnel et organisationnels. La politique de sécurité du système doit indiquer clairement le partage des responsabilités entre les fonctions dédiées à la sécurité et les autres moyens. Les mesures de sécurité des TI d'une politique de sécurité d'un système peuvent être séparées du reste de la politique de sécurité système et définies dans un document séparé : la politique de sécurité technique. Il s'agit de l'ensemble des lois, règlements et pratiques qui régissent le traitement des informations sensibles et l'utilisation des ressources par le matériel et le logiciel d'un système TI. Dans bien des cas il peut être commode d'inclure les spécifications des fonctions dédiées à la sécurité dans la politique de sécurité du système ou dans la politique de sécurité technique. La politique de sécurité du système ou la politique de sécurité technique peuvent servir de base au choix de produits de sécurité des TI qui conviennent pour être incorporés dans le système ; un tel choix de produits est hors du champ d'application des présents critères. #### Argumentaire d'un produit Dans le cas d'un produit, l'environnement précis dans lequel la TOE va être utilisée n'est pas connu de son développeur, puisque le produit peut être incorporé dans différents systèmes spécifiques et différents environnements système. En remplacement, il doit être fourni un argumentaire qui donne les informations nécessaires à un acheteur éventuel pour décider si ce produit va l'aider à satisfaire aux objectifs de sécurité de son système, et pour définir ce qui reste à faire pour les satisfaire complètement. L'argumentaire d'un produit doit identifier la manière dont il est prévu d'utiliser ce produit, l'environnement prévu pour son utilisation et les menaces supposées dans cet environnement. Il doit inclure un résumé des caractéristiques de sécurité du produit, et définir toutes les hypothèses concernant l'environnement et la manière dont le produit sera utilisé. Ceci doit inclure les mesures de sécurité relatives au personnel, physiques, organisationnelles et des TI requises en appui du produit, ainsi que ses dépendances par rapport à des matériels, des logiciels et/ou des microprogrammes du système qui ne sont pas fournis avec le produit. #### Spécification des fonctions dédiées à la sécurité La cible de sécurité doit inclure une spécification des fonctions dédiées à la sécurité que la TOE doit fournir. Ces fonctions peuvent être déclarées explicitement, ou par référence à une ou plusieurs classes de fonctionnalité prédéfinies, ou encore par référence à une norme acceptée qui définit une fonctionnalité de sécurité. Des classes prédéfinies sont exposées plus loin dans ce chapitre. Un ou plusieurs documents normatifs qui concernent la sécurité peuvent faire partie d'une cible de sécurité, soit qu'elle y fasse référence, soit qu'elle les inclue. Lorsque les normes permettent des options, les options choisies doivent être clairement identifiées. Lorsqu'une norme ne fournit pas toutes les informations requises, les informations complémentaires nécessaires doivent être explicitement fournies dans la cible de sécurité. Dans le cas d'un système, les fonctions dédiées à la sécurité doivent être reliées aux objectifs de sécurité, de sorte qu'on puisse voir quelles fonctions satisfont à quels objectifs (une fonction peut satisfaire, ou aider à satisfaire, à plusieurs objectifs). Chacune des fonctions prises en compte dans la spécification des fonctions dédiées à la sécurité doit au minimum aider à satisfaire au moins à un objectif. La spécification des fonctions dédiées à la sécurité doit également montrer pourquoi les fonctions conviennent pour contrer les menaces identifiées ou déclarées contre les objectifs de sécurité. Dans le cas d'un produit, les fonctions dédiées à la sécurité doivent être reliées aux modes prévus d'utilisation du produit et les hypothèses faites concernant l'environnement dans lequel le produit sera installé doivent être données dans l'argumentaire du produit. Cette mise en correspondance doit inclure toutes les dépendances envers d'autres fonctions dédiées à la sécurité et d'autres mesures ne relevant pas de la sécurité des TI, supposées fournies par l'environnement. Du point de vue de l'évaluation, la spécification des fonctions dédiées à la sécurité est la partie la plus importante de la cible de sécurité. Ces fonctions doivent toujours être spécifiées dans un mode informel, en langage naturel. De plus, pour les niveaux supérieurs d'évaluation, elles doivent également être spécifiées suivant un style de présentation semi-formel ou formel. Des détails concernant de tels styles de présentation sont donnés plus loin dans ce chapitre. #### Définition des mécanismes de sécurité requis Une cible de sécurité peut, de façon optionnelle, imposer ou revendiquer l'emploi de mécanismes de sécurité particuliers. Tous les mécanismes de sécurité inclus dans la cible de sécurité doivent être reliés aux fonctions dédiées à la sécurité correspondantes, de sorte qu'on puisse voir quels mécanismes réalisent chaque fonction (un mécanisme peut réaliser plusieurs fonctions, et une fonction peut être réalisée par une combinaison de plusieurs mécanismes). Lorsque des mécanismes de sécurité sont imposés par la cible de sécurité, c'est au développeur d'implémenter les mécanismes requis. Dans le cas contraire, c'est au développeur de développer et réaliser des mécanismes qui, combinés, réalisent les fonctions dédiées à la sécurité requises. #### Cotation annoncée de la résistance minimum des mécanismes Chaque cible de sécurité doit spécifier une cotation annoncée de la résistance minimum des mécanismes de sécurité de la TOE vis à vis d'une attaque directe. Ce doit être l'une des cotations élémentaire, moyenne ou élevée définies au chapitre 3 des présents critères. #### Niveau d'évaluation visé Chaque cible de sécurité doit spécifier le niveau d'évaluation visé pour l'évaluation de la TOE. Ce doit être l'un des niveaux E1, E2, E3, E4, E5, E6 définis au chapitre 4 des présents critères. #### Exemples d'utilisation de documents existants de politique de sécurité Les présents critères visent à permettre l'utilisation de documents existants de politique de sécurité développés pour d'autres critères ou d'autres normes, pour constituer tout ou partie de la cible de sécurité d'un système. En conséquence, le contenu précis des documents qui constituent la cible de sécurité n'est pas imposé. L'information minimum exigée pour une évaluation par rapport aux présents critères a été présentée plus haut. Dans la mesure où une cible de sécurité peut être constituée de plus d'un document, des modèles existants de documents de politique peuvent être adaptés (bien que des documents complémentaires puissent être exigés pour compléter les informations exigées pour une cible de sécurité). Deux exemples sont donnés ci-dessous pour montrer comment des types particuliers de documents de politique de sécurité peuvent satisfaire aux exigences pour une cible de sécurité. Au Royaume Uni il est obligatoire de produire une politique de sécurité système ou SSP (System Security Policy) pour tous les systèmes qui traiteront des informations classifiées au niveau national. Si l'autorité qui donne son autorisation décide qu'une évaluation de la sécurité est nécessaire, une politique de sécurité de l'information dans les systèmes électroniques ou SEISP (System Electronic Information Security Policy) doit également être produite. Pour certains niveaux d'évaluation visés, un modèle de politique de sécurité ou SPM (Security Policy Model) doit aussi être produit. La SSP comprend une définition de l'étendue du système, les objectifs de sécurité du système, les mesures de sécurité à faire respecter et l'attribution des responsabilités pour les faire respecter (c'est à dire qu'elle correspond étroitement à la politique de sécurité du système telle que décrite dans les présents critères). Elle contient également un dérivé du niveau d'évaluation requis pour la cible, basé sur les caractéristiques clés du système et de son environnement. Si nécessaire, une SEISP est élaborée à partir de la SSP. Il s'agit d'une présentation plus détaillée des aspects matériels et logiciels de la SSP, mais encore en style informel : elle correspond à la politique de sécurité technique décrite dans les présents critères. Le SPM est une spécification parallèle des fonctions dédiées à la sécurité rédigée en style formel ou semi-formel. Il est élaboré lorsqu'une telle spécification parallèle est exigée pour le niveau d'évaluation visé. Un "Claims Document" est une liste d'annonces concernant la fonctionnalité dédiée à la sécurité fournie par un produit, élaborée par le développeur du produit, et rédigée en style semi-formel utilisant le "Claims Language" défini dans l'annexe B du présent document. Il inclut les hypothèses et les contraintes concernant la manière dont le produit doit être utilisé pour que ces annonces soient valides. Il inclut également une identification des objectifs de sécurité, une spécification informelle des annonces, une correspondance entre les fonctions dédiées à la sécurité annoncées et ces objectifs de sécurité, ainsi que le niveau d'évaluation désiré, afin de compléter une cible de sécurité de produit telle qu'exigée par les présents critères. #### Rubriques génériques Il sera plus facile de comprendre une cible de sécurité si la spécification de ses fonctions dédiées à la sécurité a été présentée dans un ordre logique. Cela aidera à comparer les cibles de sécurité et simplifiera le travail des évaluateurs. Il existe des regroupements naturels de fonctions dédiées à la sécurité qui donnent un tel ordre, et un ensemble recommandé de huit rubriques génériques pour un tel regroupement figure dans les présents critères. Les rubriques recommandées sont les suivants : Identification et authentification Contrôle d'accès Imputabilité Audit Réutilisation d'objet Fidélité Fiabilité de service Echange de données Il est recommandé d'utiliser ces rubriques standards chaque fois que possible. Leur utilisation simplifiera la comparaison avec d'autres cibles de sécurité et permettra de déterminer plus facilement si une cible de sécurité particulière inclut ou exclut des fonctions d'un certain type. #### Identification et authentification Pour beaucoup de TOE, il y aura des exigences pour la détermination et le contrôle des utilisateurs qui sont autorisés à avoir accès aux ressources contrôlées par la TOE. Cela implique non seulement d'établir l'identité annoncée par un utilisateur, mais aussi de vérifier que cet utilisateur est bien la personne qu'il prétend être. Pour ce faire, l'utilisateur fournira à la TOE une information que la TOE sait être associée à l'utilisateur en question. Cette rubrique doit rassembler toutes les fonctions destinées à établir et vérifier une identité annoncée. Cette rubrique doit inclure toutes les fonctions qui permettent d'ajouter de nouvelles identités et d'éliminer ou d'invalider d'anciennes identités. De même, elle doit inclure toutes les fonctions destinées à créer, modifier ou permettre à des utilisateurs autorisés de contrôler les informations d'authentification nécessaires pour vérifier l'identité d'utilisateurs particuliers. Elle doit aussi inclure des fonctions pour assurer l'intégrité des informations d'authentification ou prévenir leur usage non autorisé. Elle doit inclure toutes les fonctions destinées à limiter la possibilité d'essais répétés d'établissement d'une fausse identité. #### Contrôle d'accès Pour beaucoup de TOE, il y aura des exigences pour garantir que les utilisateurs et les processus qui agissent pour le compte de ceux-ci sont empêchés d'accéder aux informations et aux ressources auxquelles ils ne sont pas autorisés à accéder ou auxquelles ils n'ont pas besoin d'accéder. De même, il y aura des exigences concernant la création ou la modification (y compris la suppression) non autorisées d'informations. Cette rubrique doit rassembler toutes les fonctions destinées à contrôler les flux d'informations entre les utilisateurs, les processus de traitement et les objets, ainsi que l'utilisation qu'ils font des ressources. Ceci inclut l'administration (c'est à dire l'octroi et le retrait) des droits d'accès et leur vérification. Cette rubrique doit inclure les fonctions servant à établir et entretenir toutes les listes ou règles qui régissent les droits d'effectuer différents types d'accès. Elle doit inclure toutes les fonctions relatives aux restrictions temporaires d'accès à des objets simultanément accessibles par plusieurs utilisateurs ou processus, et nécessaires au maintien de la cohérence et de la fidélité de ces objets. Elle doit inclure toutes les fonctions destinées à assurer que, dès leur création, des listes d'accès par défaut ou des règles d'accès par défaut s'appliquent aux objets. Elle doit inclure toutes les fonctions destinées à contrôler la propagation des droits d'accès aux objets. Elle doit inclure également toutes les fonctions destinées à contrôler la déduction d'information par agrégation de données auxquelles on peut légitimement accéder d'une autre manière. #### Imputabilité Pour beaucoup de TOE, il y aura des exigences pour garantir l'enregistrement des informations pertinentes sur les actions soit d'un utilisateur, soit d'un processus agissant pour le compte de celui-ci, de façon que les conséquences de ces actions puissent être ultérieurement associées à l'utilisateur en question et qu'on puisse le tenir pour responsable. Cette rubrique doit rassembler toutes les fonctions destinées à enregistrer l'exercice des droits qui se rapportent à la sécurité. Cette rubrique doit inclure des fonctions relatives au recueil, à la protection et à l'analyse de telles informations. Certaines fonctions peuvent satisfaire à la fois aux exigences d'imputabilité et de capacité à être auditées et relever ainsi des deux rubriques. De telles fonctions peuvent être incluses dans l'une de ces deux rubriques, mais doivent être référencées dans l'autre. #### Audit Pour beaucoup de TOE, il y aura des exigences pour garantir que sont enregistrées suffisamment d'informations sur les événements, aussi bien courants qu'exceptionnels, pour qu'un examen ultérieur puisse déterminer s'il y a effectivement eu violation de la sécurité, et, dans ce cas, quelles informations ou autres ressources ont été compromises. Cette rubrique doit rassembler toutes les fonctions destinées à déceler et à examiner les événements susceptibles de constituer une menace pour la sécurité. Cette rubrique doit inclure des fonctions relatives au recueil, à la protection et à l'analyse de telles informations. Une telle analyse peut également inclure des analyses de tendance pour tenter de détecter des violations potentielles de la cible de sécurité avant que celles-ci ne se produisent. Certaines fonctions peuvent satisfaire à la fois aux exigences d'imputabilité et de capacité à être audité et relever ainsi des deux rubriques. De telles fonctions peuvent être incluses dans l'une de ces deux rubriques, mais doivent être référencées dans l'autre. #### Réutilisation d'objet Pour beaucoup de TOE, il y aura des exigences pour garantir que les ressources telles que la mémoire centrale ou des zones de stockage sur disque peuvent être réutilisées tout en préservant la sécurité. Cette rubrique doit inclure toutes les fonctions destinées à contrôler la réutilisation des objets supports de données. Cette rubrique doit inclure des fonctions destinées à initialiser les objets supports de données non alloués ou à effacer ceux qui sont réalloués. Elle doit inclure toutes les fonctions pour initialiser ou effacer les supports réutilisables tels que les bandes magnétiques, ou pour effacer les périphériques de sortie tels que les écrans de visualisation lorsqu'ils ne sont pas utilisés. #### Fidélité Pour beaucoup de TOE, il y aura des exigences pour garantir que les relations spécifiques entre les différentes données sont correctement maintenues et que les données sont échangées entre processus sans être altérées. Cette rubrique doit rassembler toutes les fonctions destinées à garantir que des données n'ont pas été modifiées d'une manière non autorisée. Cette rubrique doit inclure des fonctions pour déterminer, établir et maintenir la fidélité des relations entre les données qui sont liées. Elle doit aussi inclure des fonctions qui garantissent qu'il est possible, lorsque des données sont échangées entre processus, utilisateurs ou objets, de déceler ou d'empêcher toute perte, ajout ou modification, et qu'il est impossible de modifier la source et la destination, annoncées ou réelles, du transfert de données. #### Fiabilité de service Pour beaucoup de TOE, il y aura des exigences pour garantir que les tâches critiques en temps sont exécutées au moment voulu, ni plus tôt ni plus tard, et que les tâches non critiques en temps ne peuvent pas le devenir. De même, pour beaucoup de TOE il y aura des exigences pour garantir que l'accès aux ressources est possible quand on en a besoin, et que des ressources ne sont pas sollicitées ou conservées inutilement. Cette rubrique doit inclure toutes les fonctions destinées à garantir que les ressources sont accessibles et utilisables à la demande d'une entité autorisée (c'est à dire un utilisateur ou un processus agissant en son nom) et à prévenir ou à limiter les interférences avec les opérations critiques en temps. Cette rubrique doit inclure des fonctions de détection d'erreur et de reprise sur incident destinées à limiter les conséquences d'erreurs sur l'exploitation de la TOE, et ainsi à réduire au minimum l'interruption ou l'arrêt de service. Elle doit également inclure toutes les fonctions de séquencement qui assurent que la TOE répond aux événements externes et produit des résultats dans les délais limites spécifiés. #### Echange de données Pour beaucoup de TOE il y aura des exigences pour la sécurité des données pendant leur transmission à travers des canaux de communication. On parle généralement de sécurité des communications, car elles sont distinctes de la sécurité informatique. Cette rubrique doit couvrir toutes les fonctions destinées à garantir la sécurité des données au cours de leur transmission sur des canaux de communication. Il est recommandé de découper de telles fonctions suivant les sous-rubriques tirées de l'architecture de sécurité OSI : Authentification Contrôle d'accès Confidentialité des données Intégrité des données Non répudiation Les fonctions doivent être regroupées sous ces sous-rubriques d'une manière cohérente avec leur utilisation et leur définition dans l'architecture de sécurité OSI [OSI]. Certaines fonctions peuvent satisfaire aux exigences à la fois de sécurité informatique et de sécurité des communications et ainsi relever d'autres rubriques. Dans ce cas, il doit y avoir une référence aux autres rubriques correspondantes. #### Classes prédéfinies Beaucoup de systèmes auront des objectifs de sécurité similaires ; il sera souvent possible d'identifier des ensembles communs de fonctions dédiées à la sécurité qui satisfont à ces objectifs. De même, beaucoup de produits de sécurité viseront à satisfaire le même besoin du marché et posséderont donc une fonctionnalité similaire. De telles classes prédéfinies de fonctions courantes peuvent être prises pour base de la cible de sécurité d'un système ou d'un produit particulier, ou peuvent servir de lignes directrices pour aider les utilisateurs à choisir la fonctionnalité de sécurité qui convient pour satisfaire à leurs objectifs de sécurité particuliers, et pour aider les constructeurs à choisir les fonctions à inclure dans leurs produits. Pour tirer le maximum de bénéfice de cet aspect commun, il est souhaitable que des normes existent pour des classes de fonctionnalité prédéfinies. Les présents critères ont donc été conçus pour autoriser dans les cibles de sécurité la référence à des classes prédéfinies de fonctions dédiées à la sécurité. Toute cible de sécurité peut faire référence à une ou plusieurs classes prédéfinies pour définir tout ou partie de ses fonctions dédiées à la sécurité. Les organismes de normalisation ou ceux qui représentent des secteurs de marché particuliers ont déjà élaboré de telles définitions normalisées. On s'attend à ce que la mise à disposition des présents critères encourage le développement de classes prédéfinies, sous une forme compatible avec les présents critères. Toutefois, puisque la sécurité des TI va continuer à évoluer rapidement, il sera nécessaire de définir dans l'avenir de nouvelles classes prédéfinies dès que de nouveaux groupes de fonctions deviendront suffisamment courants pour que de telles classes deviennent intéressantes. En même temps que la spécification de ses fonctions de sécurité, chaque classe prédéfinie doit indiquer les objectifs de la classe, en fonction de son utilisation prévue, et les raisons du choix des fonctions particulières qu'elle comporte. Les classes prédéfinies peuvent comprendre également d'autres informations qu'il est nécessaire d'inclure dans une cible de sécurité, telles que le détail de tous les mécanismes obligatoires pour une classe. Dans le cas où les détails du contenu de telles classes sont publiés, il n'est pas nécessaire de les répéter dans chaque cible de sécurité qui y fait référence. L'utilisation de classes prédéfinies n'est pas obligatoire. Il y aura des cas où le commanditaire de l'évaluation souhaitera ne pas les employer, d'autres où il ne le pourra pas, par exemple lorsqu'aucune classe prédéfinie ne décrit les caractéristiques de sécurité qu'il souhaite. Au lieu d'utiliser des classes prédéfinies, il est toujours possible de spécifier individuellement chaque fonction dédiée à la sécurité. Une déclaration de fonctions de sécurité individuelles peut être couplée avec une ou plusieurs classes prédéfinies qui décrivent partiellement, mais non complètement, la cible de sécurité. Toutefois, une classe prédéfinie ne doit être spécifiée comme faisant partie de la cible de sécurité que si tous les aspects de cette classe entrent dans la cible de sécurité. Dix exemples de classes prédéfinies sont données en annexe A. Elles sont toutes dérivées des classes de fonctionnalité données dans [ZSIEC]. Elles sont toutes présentées en style informel, et en version provisoire dans la version actuelle de l'ITSEC : Les exemples de classes de fonctionnalité F-C1,F-C2, F-B1, F-B2 et F-B3 sont les classes de confidentialité ordonnées hiérarchiquement qui correspondent étroitement aux exigences de fonctionnalité des classes C1 à A1 du TCSEC [TCSEC]. 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. L'exemple de classe de fonctionnalité F-AV impose des exigences élevées pour la disponibilité d'une TOE complète ou de fonctions spéciales d'une TOE. De telles exigences sont importantes par exemple pour des TOE qui contrôlent des processus industriels. 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 transmission. L'exemple de classe de fonctionnalité F-DC est destinée aux TOE très exigeantes en matière de confidentialité des données au cours de leur transmission. Un dispositif cryptographique est par exemple un candidat pour cette classe. L'exemple de classe de fonctionnalité F-DX est destinée aux réseaux très exigeants en matière de confidentialité et d'intégrité des informations à transmettre. Par exemple, cela peut être le cas lorsque des informations sensibles doivent être transmises à travers des réseaux non protégés (par exemple des réseaux publics). Il n'existe pas de restriction concernant la fonctionnalité spécifique qui peut être annoncée ou exigée pour une cible de sécurité. Les fonctions dédiées à la sécurité de toute cible de sécurité peuvent donc être entièrement décrites au moyen des formats de spécification disponibles. L'existence de classes prédéfinies ne restreindra donc nullement les fabricants de produits qui cherchent à faire progresser l'état de l'art, mais elle diminuera le travail qu'implique la spécification de produits ou de systèmes analogues aux stéréotypes décrits, et fournira une base de comparaison de la fonctionnalité offerte. Les cibles de sécurité de produit peuvent, même lorsqu'elles revendiquent la conformité à une classe prédéfinie, spécifier des contraintes additionnelles et des détails quant à l'environnement requis pour aider les utilisateurs potentiels à déterminer si le produit pourrait convenir à leur environnement réel. #### Style de spécification Les présents critères n'imposent pas l'emploi de méthodes ou de styles particuliers, qu'ils soient privés ou normalisés, pour la spécification des fonctions de sécurité. Ils n'excluent aucune méthode ni aucun style, dans la mesure où les exigences concernant la présentation et les éléments de preuve pour le niveau d'évaluation visé sont satisfaits. Dans le but d'établir des catégories entre les approches possibles de la spécification, trois types de styles ont été identifiés dans le cadre des présents critères : informel, semi-formel et formel. Chacun de ces types est décrit de façon plus approfondie ci-dessous. Ceux qui auront besoin d'utiliser une cible de sécurité ne seront pas tous familiarisés avec des spécifications rédigées en style semi-formel ou formel. Aussi toutes les cibles de sécurité doivent contenir une spécification des fonctions dédiées à la sécurité rédigée en style informel. Bien que les spécifications informelles ne demandent pas une formation spéciale pour être comprises, elles sont sujettes à ambiguïté et à imprécision. Les spécifications en style semi-formel ou formel réduisent cette possibilité d'ambiguïté et d'imprécision. Aussi, pour les niveaux supérieurs d'évaluation, la spécification informelle des fonctions dédiées à la sécurité doit être appuyée par une spécification parallèle semi-formelle ou formelle. La technique ou le style de spécification utilisé dans une cible de sécurité pour définir les objectifs de sécurité, et pour définir tout mécanisme de sécurité imposé ou annoncé, est hors du champ d'application des présents critères. S'il est exigé qu'une cible de sécurité contienne une spécification des fonctions dédiées à la sécurité dans un style particulier, cette spécification peut être totalement ou partiellement remplacée par une référence à une ou plusieurs classes prédéfinies rédigées dans ce style. Chaque fois qu'une spécification est exigée, quelqu'en soit le style, elle peut se présenter sous forme d'un ou de plusieurs documents. Lorsqu'on utilise plusieurs documents, leurs relations doivent être clairement indiquées. #### Spécification informelle Une spécification informelle est rédigée en langage naturel, plutôt qu'avec une notation exigeant des restrictions ou des conventions particulières. Le terme langage naturel désigne le moyen de communication que constitue toute langue parlée courante (par exemple l'allemand, l'anglais, le français ou le néerlandais). Des spécifications rédigées en langage naturel ne sont soumises à aucune restriction particulière mais doivent se conformer aux conventions usuelles de cette langue (par exemple la grammaire et la syntaxe). Une spécification en langage naturel doit être rédigée avec le souci de minimiser l'ambiguïté, en s'assurant (c'est un minimum) que tous les termes sont utilisés de façon cohérente, et que tout terme ayant une signification particulière (une signification non définie dans un dictionnaire largement utilisé) est défini dans un ou plusieurs glossaires, inclus ou auquel il est fait référence. Il est peu probable que toute ambiguïté puisse être complètement éliminée. L'évaluation cherchera à identifier et à lever toutes les ambiguïtés restantes. #### Spécification semi-formelle Une spécification en style semi-formel exige l'emploi d'une ou plusieurs notations restreintes, conformément à un ensemble de conventions incluses dans la spécification ou auxquelles il est fait référence. Les conventions sont spécifiées de façon informelle. Une telle notation doit permettre de spécifier les effets d'une fonction ainsi que les conditions d'exception ou d'erreur associées à cette fonction. Un style semi-formel peut être soit présenté sous forme graphique soit basé sur un usage restreint du langage naturel (par exemple, une structure de phrase restreinte et des mots-clé ayant une signification particulière). On peut prendre comme exemples de style semi-formel les diagrammes de flux de données, les diagrammes de transition d'états, les diagrammes entité-association, les diagrammes de structure de données, les diagrammes décrivant la structure de processus ou de programme, et la notation SDL recommandée par le CCITT pour les spécifications. Les méthodes de conception structurée et de développement utilisent généralement au moins l'une de ces notations semi-formelles pour l'expression des spécifications, ainsi que des guides méthodologiques (par exemple, des mesures de complexité et des méthodes de gestion de projet) concernant l'utilisation de la notation. A titre d'exemples de méthodes de conception structurée incluant de telles notations on peut citer : la méthode structurée de Yourdon [YSM], la technique d'analyse et de conception structurées [SADT], la méthode d'analyse et de conception structurées de systèmes [SSADM], ainsi que les méthodes Jackson de conception structurée [JSD] et de programmation structurée [JSP]. Un exemple particulier de notation semi-formelle qui a été utilisé avec succès pour définir des cibles de sécurité est le Claims Language. Le Claims Language est un sous-ensemble de l'anglais : son vocabulaire et la forme syntaxique de ses phrases sont tous deux soumis à des restrictions. Il a été conçu (comme son nom l'indique) pour fournir un moyen structuré de faire des annonces concernant les caractéristiques de sécurité de produits TI. Il permet d'utiliser le langage naturel pour exprimer les parties de la définition d'une cible de sécurité qui concernent les fonctions dédiées à la sécurité annoncées. On peut trouver une définition complète, cohérente avec les présents critères, du Claims Language en annexe B. #### Spécification formelle Une spécification en style formel est rédigée avec une notation formelle basée sur des concepts mathématiques bien établis. Les concepts sont utilisés pour définir la syntaxe et la sémantique de la notation, ainsi que les règles de déduction qui soutiennent le raisonnement logique. On doit pouvoir montrer que des spécifications formelles sont construites à partir d'un ensemble d'axiomes déclarés, et ces spécifications doivent pouvoir montrer la validité de propriétés clés, telles que la production d'une sortie valide pour toutes les entrées possibles. Lorsqu'il existe une hiérarchie de niveaux de spécification, il doit être possible de démontrer que chaque niveau maintient les propriétés établies pour le niveau précédent. Les règles syntaxiques et sémantiques qui sous-tendent une notation formelle utilisée dans une cible de sécurité doivent définir comment reconnaître sans ambiguïté des constructions et déterminer leur signification. Lorsque des règles de déduction sont utilisées pour soutenir le raisonnement logique, il doit être prouvé qu'il est impossible d'en déduire des contradictions. Toutes les règles qui sous-tendent la notation doivent être définies ou mises en référence. Toutes les constructions utilisées dans une spécification formelle doivent être complètement définies à l'aide de ces règles. La notation formelle doit permettre de spécifier l'effet d'une fonction ainsi que toutes les conditions d'exception ou d'erreur associées à cette fonction. Parmi les exemples de notation formelle on peut citer VDM, décrit dans [SSVDM], Z, décrit dans [ZRM], le langage de spécification RAISE, décrit dans [RSL], Ina Jo, décrit dans [IJRM], le langage de spécification Gypsy, décrit dans [GYPSY], et le langage de spécification de protocoles de l'ISO [LOTOS]. L'utilisation de constructions à base de logique des prédicats (ou d'autre logique) et de la théorie des ensembles en tant que notation formelle est acceptable, pourvu que les conventions (règles de démonstration) soient documentées ou mises en référence (comme exposé plus haut). #### Cohérence entre des spécifications parallèles en styles différents Les spécifications parallèles doivent être présentées de telle manière que les relations entre ces spécifications soient claires, et que lorsque ces spécifications concernent le même point, ce point soit traité de façon cohérente. Des spécifications parallèles peuvent faire l'objet de documents séparés ou être imbriquées dans un document unique. Quand il existe une ambiguïté dans une spécification informelle, la spécification formelle ou semi-formelle associée doit lever l'ambiguïté. Néanmoins des spécifications parallèles incohérentes entre elles doivent être considérées comme erronées. On doit corriger ce type d'erreur en faisant référence à des informations complémentaires extérieures à la cible de sécurité et on doit modifier l'une des spécifications ou les deux. #### Modèles formels de politique de sécurité Au niveau d'évaluation E4 et au dessus, une TOE doit implémenter un modèle sous-jacent de politique de sécurité, c'est à dire qu'il doit y avoir une présentation abstraite des principes de sécurité importants que la TOE doit faire respecter. Cette présentation doit être rédigée dans un style formel, et constitue un modèle formel de politique de sécurité. Tout ou partie d'un modèle pertinent déjà publié peut être mis en référence, sinon un modèle doit être fourni comme partie intégrante de la cible de sécurité. Tous les styles formels de spécification identifiés ci-dessus peuvent être utilisés pour définir un tel modèle. Il n'est pas nécessaire que le modèle formel couvre toutes les fonctions dédiées à la sécurité spécifiées dans la cible de sécurité. Toutefois, une interprétation informelle du modèle sous l'angle de la cible de sécurité doit être fournie, et doit montrer que la cible de sécurité implémente la politique de sécurité sous-jacente et ne contient aucune fonction en contradiction avec cette politique sous-jacente. Voici des exemples de modèles formels de politique de sécurité qui ont été publiés : Le modèle de Bell-La Padula [BLP] qui modélise les exigences de contrôle d'accès caractéristiques d'une politique nationale de sécurité pour la confidentialité. Le modèle de Clark et Wilson [CWM] qui modélise les exigences d'intégrité des systèmes transactionnels commerciaux. Le modèle de Brewer-Nash [BNM] qui modélise les exigences de contrôle d'accès visant à assurer la confidentialité pour le client, ce qui est typique d'un organisme de services financiers. Le modèle d'Eizenberg [EZBM] qui modélise des droits d'accès qui varient avec le temps. Le modèle de Landwehr [LWM] qui modélise les exigences d'un réseau de traitement de messages en matière d'échange de données.
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:03:30