SCSSI : ITSEC v1.2 Champ d'application 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" |

Les présents critères ont été conçus pour être dans leur plus grande partie également applicables aux mesures techniques de sécurité implémentées au moyen de matériel, de logiciel ou de microprogrammes. Lorsque des aspects particuliers de l'évaluation ne sont destinés à s'appliquer qu'à certains modes de réalisation, cela est indiqué dans le texte des critères correspondants.

Les présents critères ne sont pas destinés à couvrir les aspects physiques de la sécurité matérielle tels que la fourniture d'enceintes résistant à l'intrusion ou le contrôle des signaux parasites compromettants.

Systèmes et Produits

Du point de vue de la sécurité, la principale différence entre systèmes et produits tient à ce qui est certain quant à leur environnement opérationnel. Un système est conçu pour satisfaire les besoins d'un groupe particulier d'utilisateurs finals. Son environnement est réel, il peut être défini et observé dans ses moindres détails ; en particulier les caractéristiques et les besoins de ses utilisateurs finals seront connus, et les menaces contre sa sécurité sont des menaces réelles, qui peuvent être déterminées. Un produit doit être apte à être incorporé dans un grand nombre de systèmes ; le concepteur du produit ne peut faire que des hypothèses générales sur l'environnement opérationnel d'un système dont ce produit pourrait devenir un composant. Il revient à celui qui achète le produit et construit le système de s'assurer que ces hypothèses sont cohérentes avec l'environnement véritable du système.

Il est important, pour des raisons de cohérence, d'utiliser les mêmes critères de sécurité pour les produits et les systèmes : il sera ainsi plus facile et moins coûteux d'évaluer les systèmes qui contiennent des produits déjà évalués avec succès. C'est pourquoi les présents critères traitent de l'évaluation de la sécurité à la fois pour les produits et les systèmes TI. Dans le reste de ce document, l'expression cible d'évaluation ou TOE (Target Of Evaluation) est utilisée pour désigner un produit ou un système à évaluer.

Une TOE peut être construite à partir de plusieurs composants. Certains composants ne contribueront pas à satisfaire aux objectifs de sécurité de la TOE. D'autres contribueront à satisfaire aux objectifs de sécurité ; ces derniers composants sont appelés dédiés à la sécurité. Enfin il peut y avoir des composants qui ne sont pas dédiés à la sécurité mais qui doivent cependant fonctionner correctement pour que la TOE puisse faire respecter la sécurité ; ils sont appelés touchant à la sécurité. La combinaison de composants dédiés à la sécurité et de composants touchant à la sécurité à l'intérieur d'une TOE est souvent appelée base informatique de confiance ou TCB (Trusted Computing Base) (voir les figures 1 et 2).

La plus grande partie du travail d'évaluation sera concentrée sur les composants d'une TOE dont il est établi qu'ils sont dédiés à la sécurité ou touchant à la sécurité, mais tous les autres devront être examinés au cours de l'évaluation et il devra être démontré qu'ils ne sont ni dédiés à la sécurité ni touchant à la sécurité.

Fonctionnalité et Assurance, Classes et Niveaux

Ces fonctions doivent être définies d'une façon claire et compréhensible tant pour le commanditaire de l'évaluation que pour l'évaluateur indépendant. Elles peuvent être soit spécifiées individuellement, soit définies par référence à une classe de fonctionnalité prédéfinie. Dix exemples de classes de fonctionnalité sont inclus dans les présents critères. Ces exemples de classes sont basés sur les classes définies dans les critères nationaux allemands [ZSIEC], parmi lesquelles cinq classes sont en étroite correspondance avec les exigences fonctionnelles du document américain Trusted Computer System Evaluation Criteria [TCSEC].

Dans tous les cas, le commanditaire d'une évaluation doit définir la cible de sécurité pour l'évaluation. Cette cible doit définir les fonctions dédiées à la sécurité qui doivent être fournies par la TOE et contiendra également d'autres informations pertinentes, telles que les objectifs de sécurité de la TOE et les menaces envisagées à l'encontre de ces objectifs. Les détails des mécanismes de sécurité particuliers qui seront utilisés pour implémenter les fonctions dédiées à la sécurité peuvent également être donnés.

Les fonctions dédiées à la sécurité choisies pour atteindre les objectifs de sécurité d'une TOE ne constituent qu'un des aspects de la cible de sécurité d'un produit ou d'un système. L'assurance que les objectifs de sécurité sont atteints par les fonctions et les mécanismes dédiés à la sécurité choisis est tout aussi importante.

L'assurance doit être abordée de différents points de vue et, pour les présents critères harmonisés, il a été décidé de distinguer la confiance dans la conformité de la réalisation des fonctions et mécanismes dédiés à la sécurité, de la confiance dans leur efficacité.

L'évaluation de l'efficacité consiste à estimer si les fonctions et les mécanismes dédiés à la sécurité fournis dans la TOE satisfont effectivement aux objectifs de sécurité déclarés. L'estimation porte sur la pertinence de la fonctionnalité, la cohésion de la fonctionnalité (si les fonctions choisies opèrent ensemble en synergie), les conséquences de vulnérabilités connues et découvertes (tant au point de vue de la construction de la TOE que de la manière dont elle sera utilisée en exploitation réelle) et la facilité d'emploi.

En outre, l'évaluation de l'efficacité consiste à estimer la capacité des mécanismes de sécurité de la TOE à résister à une attaque directe (résistance des mécanismes). Trois niveaux de résistance sont définis - élémentaire, moyen et élevé - représentant des degrés de confiance croissants dans la capacité des mécanismes de sécurité de la TOE à résister à une attaque directe.

L'évaluation de la conformité consiste à estimer si les fonctions et les mécanismes dédiés à la sécurité sont implémentés correctement. Il a été défini sept niveaux d'évaluation numérotés de E0 à E6, représentant des degrés croissants de confiance dans la conformité. E0 correspond à une confiance insuffisante. E1 correspond au point d'entrée au-dessous duquel il ne peut être accordé aucune confiance utile, et E6 correspond au degré de confiance le plus élevé : les autres niveaux correspondent à des degrés de confiance intermédiaires. La conformité est considérée du point de vue de la construction de la TOE, ce qui recouvre à la fois le processus de développement et l'environnement de développement, et aussi du point de vue de l'exploitation de la TOE.

Les niveaux d'évaluation sont définis dans le contexte des critères de conformité. Les exigences concernant l'efficacité (incluant la résistance des mécanismes) ne changent pas selon les niveaux mais s'appuient plutôt sur l'estimation de la conformité et sont examinées sur la base des documents fournis par le commanditaire pour cette estimation ; naturellement, dans la pratique, les tâches d'estimation de la conformité et de l'efficacité seront imbriquées.

Si une TOE ne parvient pas à satisfaire à l'un quelconque des aspects de l'évaluation à un niveau donné, par manque d'information ou pour toute autre raison, l'imperfection doit être corrigée, ou la TOE doit être retirée de l'évaluation pour ce niveau. Sinon il lui sera attribué le niveau E0.

La réussite de l'évaluation à l'un des six niveaux E1 à E6 couvre un large éventail de confiance possible. L'ensemble de ces six niveaux ne sera pas forcément nécessaire ni approprié pour tous les secteurs du marché qui ont besoin d'une évaluation indépendante des mesures techniques de sécurité. Toutes les combinaisons de fonctionnalité et de confiance ne seront pas nécessairement judicieuses ou utiles. Par exemple, un bas degré de confiance dans la fonctionnalité requise pour satisfaire à une exigence de sécurité multi-niveau militaire ne sera normalement pas approprié. De plus, il est peu probable qu'un haut degré de confiance dans la conformité d'une TOE soit associé à l'exigence d'un bas niveau de résistance des mécanismes.

Les présents critères harmonisés ne constituent pas un guide de conception pour réaliser des produits ou des systèmes sûrs. Il appartient au commanditaire d'une évaluation de fixer les objectifs de sécurité de sa TOE et de choisir les fonctions de sécurité propres à atteindre ces objectifs. Toutefois, pour chaque niveau d'évaluation, la partie "assurance" des critères peut être vue comme une "liste de contrôles de sécurité" obligatoire auxquels il faut satisfaire.

Profils d'Assurance

Pour certaines TOE, il peut être exigé d'atteindre un degré de confiance supérieur pour certaines fonctions de sécurité et inférieur pour d'autres ; par exemple, certaines fonctions de sécurité peuvent être plus importantes que d'autres. Dans ces circonstances, le commanditaire peut envisager de produire plus d'une cible de sécurité pour la TOE. Les détails sur la façon dont ceci est effectué, et dans quelles conditions, sont hors du champ d'application des présents critères.

Le processus d'évaluation

Le processus d'évaluation est représenté dans son contexte en figure 3. Il exige que le commanditaire de l'évaluation y soit fortement impliqué. Plus le niveau d'évaluation est élevé, plus l'implication du commanditaire devra être importante. Les utilisateurs aussi bien que les fournisseurs peuvent agir en tant que commanditaires d'une évaluation. Il est vraisemblable que l'évaluation d'un système sera commanditée par les utilisateurs finals ou leurs représentants techniques, et que l'évaluation d'un produit sera commanditée par le fabricant ou le fournisseur, mais cela n'est pas obligatoire. Tous les intéressés qui peuvent fournir l'information technique nécessaire peuvent être commanditaires d'une évaluation.

En premier lieu, le commanditaire doit déterminer les exigences opérationnelles et les menaces auxquelles la TOE doit faire face. Dans le cas d'un système, il est nécessaire d'examiner son environnement opérationnel réel afin de déterminer les menaces qui doivent effectivement être prises en compte. Pour un produit, il faut décider quelles menaces contre la sécurité celui-ci devrait prendre en compte. On s'attend à ce que des groupements d'industriels et des organismes internationaux de normalisation définissent dans l'avenir des classes standards de fonctionnalité pour servir de cibles de sécurité de produits. Les développeurs de produits, qui n'ont pas d'idée précise sur des créneaux particuliers du marché ni sur des types d'utilisateurs, peuvent trouver que de telles classes de fonctionnalité pré-définies constituent de bonnes cibles de sécurité pour concevoir des produits qui y correspondent.

Les objectifs de sécurité de la TOE peuvent alors être déterminés en tenant compte des lois et des autres réglementations. Ils constituent la contribution à la sécurité (en termes de confidentialité, d'intégrité et de disponibilité) que cette TOE est destinée à fournir. Une fois ces objectifs fixés, les fonctions dédiées à la sécurité qui sont nécessaires peuvent être établies, éventuellement par itération, en même temps que le niveau d'évaluation auquel la TOE devra satisfaire pour fournir le degré de confiance nécessaire.

L'ensemble des résultats de ce travail - définition des fonctions dédiées à la sécurité, menaces identifiées, objectifs de sécurité identifiés, mécanismes spécifiques de sécurité à utiliser - devient la cible de sécurité à prendre en compte pour le développement.

Pour chaque niveau d'évaluation, les critères énumèrent les éléments que le commanditaire doit fournir à l'évaluateur. Le commanditaire doit s'assurer que ces éléments sont fournis, en veillant à ce que toutes les exigences sur le contenu et la présentation soient satisfaites, et aussi que ces éléments apportent directement ou aident à établir les éléments de preuve demandés.

Pour que l'évaluation puisse être conduite efficacement, et à un coût minimum, l'évaluateur doit travailler en liaison étroite avec le développeur et le commanditaire de la TOE, l'idéal étant qu'il le fasse dès le début de ce développement, de façon à établir une bonne compréhension de la cible de sécurité et à pouvoir repérer ce que les décisions impliquent pour l'évaluation au fur et à mesure qu'elles sont prises. Toutefois, l'évaluateur doit rester indépendant et ne doit pas faire de suggestion quant à la conception et la réalisation de la TOE. Son rôle est analogue à celui d'un auditeur financier extérieur, qui doit de la même façon construire une bonne relation de travail avec un service financier, et qui, dans bien des cas, utilisera, après examen, les rapports et les résultats des contrôles internes. Et pourtant il doit lui aussi rester indépendant et poser des questions.

Les exigences concernant les tests et les analyses de sécurité dans les critères méritent une mention particulière ; dans tous les cas, la responsabilité des tests et des analyses échoit au commanditaire. Pour tous les niveaux d'évaluation sauf E1, l'évaluateur vérifiera principalement les résultats des tests et des analyses fournis par le commanditaire. L'évaluateur n'effectuera lui-même des tests et des analyses que pour vérifier les résultats fournis, pour compléter les éléments de preuve fournis et pour se livrer à des investigations sur les vulnérabilités. Au niveau E1, la fourniture des résultats des tests est facultative. Si ces résultats ne sont pas fournis, l'évaluateur doit en plus effectuer des tests fonctionnels par rapport à la cible de sécurité.

Le processus de certification

Les présents critères ont été conçus pour minimiser la subjectivité inhérente aux résultats d'une évaluation. Les organismes nationaux de certification auront la responsabilité de maintenir l'uniformité des résultats d'évaluation certifiés. La manière d'y parvenir est hors du champ d'application des présents critères.

Pour que les résultats d'une évaluation par rapport aux présents critères puissent être certifiés par un organisme national de certification, l'évaluateur devra produire un rapport contenant les résultats de l'évaluation sous une forme qui convienne à son examen par l'organisme de certification. Le format et le contenu précis de tels rapports sont hors du champ d'application des présents critères.

La plupart des cibles de sécurité et des TOE vont évoluer avec le temps. Le maintien d'une cotation certifiée à la suite de changements apportés à la TOE (qu'ils concernent ou non la sécurité) ou à la suite de changements apportés à la cible de sécurité (tels que l'apparition de nouvelles menaces ou de nouveaux objectifs de sécurité) sera réglementé par l'organisme national de certification approprié. Une réévaluation sera nécessaire dans certains cas et pas dans d'autres. Les détails de telles réglementations et procédures sont également hors du champ d'application des présents critères.

Correspondance avec le document TCSEC

Le TCSEC définit sept ensembles de critères d'évaluation appelés classes (D, C1, C2, B1, B2, B3 et A1) regroupés en quatre divisions (D, C, B et A). Chaque classe de critères couvre quatre aspects de l'évaluation : la politique de sécurité, l'imputabilité, l'assurance et la documentation. Les critères relatifs à ces quatre domaines deviennent de plus en plus détaillés d'une classe à l'autre et forment une hiérarchie dans laquelle D est le niveau le plus bas et A1 le plus haut. Chaque classe couvre à la fois les exigences de fonctionnalité et les exigences de confiance.

Les critères exposés dans l'ITSEC permettent de sélectionner des fonctions de sécurité arbitraires et définissent sept niveaux d'évaluation représentant une confiance croissante dans la capacité d'une TOE à atteindre sa cible de sécurité. Ainsi ces critères peuvent-ils être appliqués sur une gamme de systèmes et de produits possibles plus large que celle couverte par le TCSEC. D'une manière générale, pour une fonctionnalité identique et à un degré de confiance équivalent, une TOE a plus de liberté sur le plan de l'architecture pour satisfaire aux critères de l'ITSEC qu'à ceux du TCSEC, mais supporte plus de contraintes sur les modes de développement autorisés.

Plusieurs exemples de classes de fonctionnalité ont été définis pour correspondre étroitement aux exigences de fonctionnalité des classes C1 à A1 du TCSEC. Ce sont les classes F-C1 à F-B3, parmi les exemples de classes de fonctionnalité donnés en annexe A. Il n'est toutefois pas possible de relier directement les niveaux d'évaluation aux exigences de confidentialité des classes du TCSEC, car les niveaux de l'ITSEC sont issus de l'harmonisation des divers ensembles européens de critères de sécurité des TI, qui contiennent un certain nombre d'exigences qui n'apparaissent pas explicitement dans le TCSEC.

La correspondance recherchée entre les présents critères et les classes du TCSEC est la suivante :

	Classe ITSEC		Classe TCSEC
	E0	<--->	D
	F-C1, E1	<--->	C1
	F-C2, E2	<--->	C2
	F-B1, E3	<--->	B1
	F-B2, E4	<--->	B2
	F-B3, E5	<--->	B3
	F-B3, E6	<--->	A1

Il est à noter qu'il n'y a pas de classe de fonctionnalité F-A1, puisque les exigences de fonctionnalité de la classe A1 du TCSEC sont les mêmes que celles de la classe B3. Un produit conçu pour être évalué avec succès aussi bien par rapport à l'ITSEC qu'au TCSEC, et dont il a été montré qu'il satisfaisait à l'une des classes ou des combinaisons du tableau ci-dessus, devrait réussir l'évaluation par rapport aux autres critères pour la classe ou pour la combinaison correspondante. Toutefois, au niveau C1, le TCSEC exige la production d'éléments de preuve concernant les tests effectués par le développeur. Ainsi une évaluation [F-C1, E1] ne serait équivalente à une évaluation C1 que si le commanditaire avait choisi l'exigence optionnelle du niveau E1 de fourniture de la documentation relative aux tests, comme preuve que des tests adéquats par rapport à la cible de sécurité ont été effectués avant l'évaluation.

Tout au long du TCSEC la combinaison du sous-ensemble dédié à la sécurité et du sous-ensemble touchant à la sécurité est appelée base informatique de confiance ou TCB (Trusted Computing Base). Pour le TCSEC, les TOE des classes les plus hautes de la division B et de la division A tirent une confiance supplémentaire d'exigences croissantes de rigueur dans l'architecture et la conception de la TCB imposées par les critères du TCSEC. Les classes de niveau B2 et au dessus exigent que le contrôle d'accès soit réalisé par un mécanisme de validation de référence, mécanisme qui implémente le concept de moniteur de référence [AND]. Un tel mécanisme de validation de référence doit être résistant à l'intrusion, il doit être systématiquement mis en oeuvre, et il doit être assez petit pour pouvoir être soumis à des analyses et à des tests dont la complétude puisse être assurée.

Pour être compatibles avec le TCSEC, les exemples de classes de fonctionnalité F-B2 et F-B3 de l'ITSEC imposent que le contrôle d'accès soit implémenté avec un tel mécanisme. De plus, pour les niveaux supérieurs d'évaluation, l'ITSEC impose des contraintes d'architecture et de conception sur la réalisation de toutes les fonctions dédiées à la sécurité. Tout ceci, combiné avec les exigences d'efficacité de l'ITSEC relatives au fait que la fonctionnalité de sécurité est pertinente et que ses éléments se soutiennent mutuellement, signifie qu'une TOE capable de satisfaire aux niveaux supérieurs d'évaluation de l'ITSEC, et fournissant une fonctionnalité égale aux fonctionnalités des classes équivalentes du TCSEC, doit nécessairement satisfaire aux exigences du TCSEC quant à l'existence d'une TCB et utiliser le concept de moniteur de référence.

-

Système TI

Produit TI

-

Processus de développement et d'évaluation

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