|
|
|
|
FONCTIONNALITEIntroductionUne 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 :
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 :
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.
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.
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.
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.
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.
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.
Les rubriques recommandées sont les suivants :
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.
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é.
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.
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.
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.
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.
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.
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.
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 :
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.
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 :
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.
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.
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.
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.
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).
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.
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 :
|
![[Début]](/images/top.gif)
![[Précédente]](/images/prev.gif)
![[Suivante]](/images/next.gif)
![[Fin]](/images/bottom.gif)