Critères communs

Audience visée

Les besoins des utilisateurs sur le plan de la sécurité sont des besoins de disponibilité, de confidentialité et d'authenticité des informations personnelles. Les critères communs s'adressent à trois catégories d'utilisateurs :

Les utilisateurs finaux

Les utilisateurs finaux vont pouvoir déterminer si un produit répond à leurs besoins en consultant le résultat de l'évaluation.

Les développeurs

Les développeurs se servent des CC pour identifier les exigences de sécurité que doit satisfaire leur produit.

Les évaluateurs

Les évaluateurs trouveront les critères à utiliser pour évaluer qu'un produit est conforme à sa cible d'évaluation. La norme décrit les actions à mener, mais aucunement les procédures à suivre.

Documentation de la norme

Les critères communs font l'objet de trois documents liés entre eux:

Introduction et modèle général

Ce document définit les concepts généraux et présente un modèle général d'évaluation. Il propose également un glossaire des termes et mots clés utilisés. À ce titre les trois acronymes suivants sont régulièrement utilisés :

TI

TI est l'acronyme de « Technologie de l'Information ». Il est également connu sous l'acronyme IT, « Information Technology » dans la littérature anglo-saxonne.

TOE

TOE est l'acronyme anglophone de « Target Of Evaluation ». La TOE est la cible de l'évaluation. C'est un produit ou une TI évaluée avec la documentation associée destinée à l'administrateur d'une part et à l’utilisateur d'autre part.

TSF

TSF est l'acronyme anglais de « TOE Security Functions ». Il désigne l'ensemble des fonctions de sécurité de la TOE.

Exigences fonctionnelles de sécurité

Il s'agit d'un catalogue des composants fonctionnels de sécurité classifiés en familles et classes.

Exigences d'assurance de sécurité

Ce document recense les exigences pour le développeur et les tâches à realiser pour l'évaluateur.

Exigences fonctionnelles

Les exigences fonctionnelles de sécurité concernent uniquement les spécifications de fonctions de sécurité. Elles sont regroupées en onze classes couvrant chacune un domaine. Chaque classe est découpée en familles. Chaque famille contient un ensemble de composants qui constitue une exigence de sécurité. Chaque classe est désignée par un nom unique dont l'abréviation est constituée de trois caractères Fxx: F pour classe d'exigence Fonctionnelle et xx pour identifier le nom de la fonctionnalité couverte.

Classe Audit de Sécurité FAU

Décomposée en 6 familles regroupant chacune de 1 à 4 composants de sécurité:

« Auditer la sécurité implique la reconnaissance, l'enregistrement, le stockage et l'analyse d'informations associées à des activités touchant à la sécurité ».

Classe Communication FCO

Cette classe traite de la non répudiation des émissions et réception. Elle est par conséquent décomposée en 2 familles; la première concerne l'émission alors que la seconde porte sur la réception.

Classe Support Cryptographique FCS

Elle concerne la sécurité de haut niveau nécessitant l'utilisation de fonctions de cryptographie. Elle est également composée de 2 familles; l'une concernant la gestion des clés, l'autre relative à la génération de ces clés.

Classe Protection des Données de l'utilisateur FDP

Découpée en 8 familles réparties dans quatre groupes, elle concerne la manipulation des données de l'utilisateur.

Classe Identification et Authentification FIA

Cette classe est composée de 6 familles pour identifier l'utilisateur, l'authentifier et gérer ces droits d'accès.

Classe administration de la sécurité FMT

Elle permet entre autres de définir des rôles de sécurité. Elle est également découpée en 6 familles ayant de 1 à 3 composants.

Classe protection de la vie privée FPR

Les exigences de cette classe couvrent la protection de l'individu contre la découverte ou l'utilisation frauduleuse de son identité par autrui.

Classe protection de la TOE FPT

Son but est de décrire les exigences de protection des fonctions de sécurité de la TOE et non plus de l'utilisateur. Les familles qui la composent peuvent apparaître comme une duplication de la classe FDP.

Classe utilisation des ressources FRU

Trois familles d'exigences concernant la disponibilité des ressources composent cette classe: la tolérance aux pannes, l'allocation de ressources et la priorité des services.

Classe d'accès à la Cible d'évaluation FTA

Elle spécifie les exigences fonctionnelles nécessaires pour contrôler l'établissement d'une connexion de l'utilisateur. Par exemple contrôler le nombre de sessions, modifier des paramètres d'accès, afficher un historique des connexions.

Classe chemin et canaux de confiance FTP

concerne les chemins utilisés pour établir une communication sécurisée entre l'utilisateur et la technologie de l'information mais également entre TI.

Le développeur va pouvoir définir un paquet de composants à partir de cette liste suivant les fonctionnalités de son produit. Cette liste n'étant pas exhaustive, elle peut être complétée en fonction des besoins. Ainsi pour la certification de son dispositif biométrique de détection de faux doigts SAFRAN a ajouté la famille SPOD à la classe FPT. Pour la certification de ce produit, SAFRAN a également retenu des composants des familles suivantes :

• Génération de l'audit de sécurité FAU_GEN
• Protection des Informations Résiduelles FDP_RIP
• Administration des données de la TSF FMT_MTD

Exigences d'assurance de sécurité

La liste des exigences d'assurance est la seconde liste des Critères Communs. Elle recense les points à vérifier pour qu'un produit atteigne un certain niveau de confiance sur le plan de la vulnérabilité. Elle couvre la validité de la documentation et du produit ou système. Pour le développeur il s'agit d'une liste d'éléments de preuve qu'il devra fournir dans le cadre de l'évaluation. Quant à l'évaluateur, il va pouvoir identifier les tâches à réaliser pour conduire à une certification selon les Critères Communs.

Cette liste est également constituée de classes recouvrant un thème. Ces classes sont découpées en familles regroupant des composants. Chaque composant représente un niveau plus ou moins poussé de l'évaluation d'un point précis. Ils sont découpés en éléments d'assurance. Le nommage des classes est effectué avec trois caractères Axx : A désignant assurance suivi de deux lettres pour identifier le domaine couvert.

Liste des classes ;

Classe ADV

définit les exigences d'assurance à prendre en compte depuis les spécifications de la TOE jusqu'à son implémentation.

Classe ACO

est composée de cinq familles dont le but est de s'assurer que la cible de l'évaluation respectera la sécurité lorsqu'elle interagira avec les fonctionnalités de sécurité fournies par les logiciels ou les composants matériels déjà évalués.

Classe AGD

concerne les exigences relatives à la documentation fournie par le développeur à l'utilisateur. Cette documentation doit être compréhensible, complète et permettre d'utiliser efficacement la TOE.

Classe ALC

traite des exigences associées au cycle de vie de la TOE. Elle est décomposée en sept familles relatives à l'environnement de développement, les outils d'analyse et développement, la configuration et la prise en charge de la correction d'éventuelles anomalies détectées.

Classe APE

doit s'assurer que le profil de protection est complet.

Classe ASE

son but est de démontrer que l'évaluation de la cible de sécurité est saine techniquement.

Classe ATE

permet de s'assurer que les tests sont suffisamment détaillés et complets.

Classe AVA

traite des exigences associées à l'identification de vulnérabilité pendant les phases de développement, configuration et exploitation.

Niveaux d'assurance EAL

Tout certificat émis à la suite de l'évaluation selon les critères communs garantit que le Système d'Information évalué respecte un certain niveau d'assurance. Celui-ci équivaut à une note allant de EAL1 à EAL7 (evaluation assurance level). Ces niveaux sont associés à un paquet minimum d'exigences d'assurance. Il existe sept niveaux hiérarchiques qui vont déterminer le degré de confiance accordé au produit évalué.

Chaque niveau contient les exigences du niveau précédent. Ils reflètent un équilibre entre le niveau d'assurance obtenu et le coût pour parvenir à ce niveau.

Niveau 1

le moins coûteux et ne nécessite pas la participation du développeur. Il permet d'affirmer que la cible de l'évaluation fonctionne conformément à ce qui est décrit dans la documentation. Seules les menaces identifiées dans le domaine public sont couvertes.

Niveau 2

nécessite la participation du développeur pour communiquer des informations sur la spécification et les résultats des tests réalisés.

Niveau 3

atteste d'une recherche de vulnérabilités évidentes.

Niveau 4

représente un bon compromis entre sécurité et coûts. Il ne nécessite pas de connaissances ou d'expertise spécialisée. Il répond à une vulnérabilité relative à des attaques élémentaires.

Niveau 5

atteste d'une analyse des fonctions de sécurité. Cette analyse s'appuie sur les spécifications fonctionnelles, les spécifications complètes des interfaces, les guides et la conception de la TOE.

Niveau 6

destiné à des développements de TOE dans le cadre d'environnements à risques élevés.

Niveau 7

niveau maximum à ce jour. Il nécessite une présentation formelle des spécifications fonctionnelles et un niveau élevé des spécifications.

Organisation

Seuls les pays signataires de l'accord de reconnaissance mutuelle selon les critères communs sont autorisés à émettre des certificats. Ce sont également eux qui vont accepter qu'un nouveau membre les rejoigne. Ainsi l'Inde est devenu le 17^e pays signataire en 2013.

Afin d'être impartiale, l'évaluation d'un produit informatique doit être réalisée par une entité indépendante. Les laboratoires chargés des évaluations sont accrédités par les organismes gouvernementaux représentant les pays signataires de l'accord CCMRA.

Aux États-Unis

La NSA pilote le programme gouvernemental NIAP responsable des besoins de sécurité des clients et concepteurs de technologies de l'information. Elle accrédite les laboratoires d'expertises dénommés CCTLs^, et valide les résultats de l'évaluation en délivrant ou non le certificat final.

En France

Par décret, l'Agence nationale de la sécurité des systèmes d'information (ANSSI) est nommée autorité de certification. Cette agence a deux rôles :

• responsable de l'agrément des Centre d'évaluation de la sécurité des technologies de l'information (CESTI) qui sont chargés de l'évaluation.
• responsable de la délivrance ou non du certificat de validation.

Étapes de la certification

La certification se déroule en 3 étapes :

Demande d'évaluation

Le commanditaire fait une demande d'évaluation auprès de son organisme gouvernemental chargé des certifications. Il incombe à l'entreprise :

• d'établir la liste des exigences de sécurité de son produit. Cette liste est établie dès l'étude de conception. Son contenu est fonction du périmètre fonctionnel du produit.
• d'établir la liste des exigences d'assurance liée à la qualité du produit.
• de fournir une description détaillée des composants du produit qui seront soumis à l'évaluation.
• de fournir un document décrivant la cible d'évaluation, son environnement de fonctionnement et les menaces auxquelles elle devra répondre.

Évaluation

L'évaluateur peut intervenir tout au long de la conception du produit. Il va devoir vérifier la pertinence du cahier de tests et le résultat de ces tests qui sont déroulés par le commanditaire. Il émet ensuite un rapport d'évaluation technique RTE validant le niveau d'assurance atteint.

Certification

L'autorité chargée de la certification va s'appuyer sur le rapport d'évaluation technique pour émettre ou non le certificat d'évaluation selon les critères communs.

Les bénéfices, avantages, intérêts

Les contraintes, inconvénients, freins

Méthodes basées sur les diagrammes de cas

La méthode proposée par Taguchi, est basée sur un diagramme de cas d'utilisation selon plusieurs principes. Le premier de ces principes est l'utilisation d'un diagramme qui détaille les concepts de sécurité, pour faire apparaître les besoins de sécurité. Ensuite, tous les concepts du diagramme sont des éléments issus d'un méta modèle de la CC. Enfin, les modèles de sécurité sont ajoutés selon les contraintes de sécurité de chaque étape de la construction du produit.

Cette méthode utilise un méta modèle dérivé de la CC, qui fait partie de la fonctionnalité de sécurité de la TOE. Les concepts des CC suivants sont maintenus :

• Les menaces ;
• Les agents de menace ;
• Les actifs ;
• Les fonctions de sécurité ;
• Les exigences fonctionnelles de sécurité ;
• Les objectifs de sécurité ;
• L'environnement opérationnel ;
• Les hypothèses.

L'auteur fait le choix d'enlever de son méta modèle les concepts des CC suivants :

• La TOE. Celle-ci est implicitement comprise dans le modèle de sécurité ;
• La politique de sécurité organisationnelle. De nombreux organismes établissent aujourd'hui leurs propres politiques de sécurité organisationnelles pour prévenir les violations de sécurité des données hautement confidentielles sur leurs activités.

Un diagramme prototype est proposé en 3 phases. La première phase (Exigences de sécurité de base), analyse les fonctions de sécurité et les menaces de sécurité de façon abstraite. La seconde ( Exigences et objectif de sécurité), analyse en détail les exigences de sécurité pour en définir des objectifs de sécurité. Ce travail est réalisé à partir du résultat de la phase 1. Et enfin la phase 3 (Sélection des exigences fonctionnelles de sécurité), sert à la sélection des exigences fonctionnelles de sécurité, qui répondent aux objectifs de sécurité identifiés dans la phase précédente. Cette tâche est réalisée à partir de la norme des CC partie 2 et des profils de protection. Puis on aligne les exigences de sécurité aux exigences d'assurance en vertu de la méthodologie de CC.

La méthode proposée par Ware consiste à utiliser les profils d'acteurs pour tirer les menaces de sécurité. Puis faire la cartographie des menaces et des objectifs de sécurité. Et enfin, réaliser la cartographie des objectifs de sécurité et des exigences de sécurité. La cartographie est réalisée à l'aide d'une boite à outils qui contient une liste des menaces, les objectifs et les exigences fonctionnelles des CC. Pour mettre en œuvre cette approche, un outil de modélisation graphique open source UML, est proposé.

L'outil montre clairement, dans sa « table des menaces », les objectifs nécessaires pour contrer une menace spécifique et les exigences nécessaires pour satisfaire un objectif spécifique.

Puis l'outil propose à l'utilisateur de générer un fichier de sortie dans un format HTML. L'outil propose deux styles de rapports possibles :

• Une option générale, qui génère un modèle de cas d'utilisation avec le champ de menaces contenant une liste des menaces associées à chaque acteur. Chaque menace a une liste imbriquée des exigences de sécurité qui sont nécessaires pour satisfaire les objectifs ;
• Une option « principe CC », qui génère une double cartographie, menaces / objectifs et composants fonctionnels de sécurité / objectifs.

Le rapport « principe CC » vise à produire la partie de la justification d'une cible de sécurité de la TOE. En outre, les correspondances montrent clairement les objectifs nécessaires pour contrer une menace spécifique et les exigences nécessaires pour satisfaire un objectif spécifique.

Utilisation des CC lors de la conception d’un logiciel

La méthode proposée par Vetterling, est un processus qui combine le développement de logiciels 'orienté phase' avec les activités requises par les CC. Le principe est d'intégrer les activités des CC dans les phases de développement du projet. Cette méthode est basée sur un processus itératif dans chaque phase du projet. À la fin de chaque itération, le résultat peut être évalué. L'itération suivante recommence avec le résultat de la phase précédente, avec l'ajout de nouvelles exigences.

Dans la phase de planification, le plan de gestion de configuration (class ACM) est rédigé. Le manuel du cycle de vie (class ALC), est aussi rédigé en fonction du niveau d'EAL retenu. C'est dans cette phase, que doit être décidé le niveau d'EAL, et quelle partie du système ou produit doit être développée conformément aux CC.

Dans la phase d'analyse, la cible de sécurité (class ASE) est rédigée. C'est aussi dans cette phase que l'on commence la rédaction des premières versions du document de test (class ATE) et des guides utilisateurs (class AGD).

Dans la phase de conception, on commence la rédaction de la conception et représentation (class ADV). Son niveau de détail dépend du niveau d'EAL retenu. L'Évaluation de la vulnérabilité (class AVA) est aussi initialisée dans cette phase. Cette phase apporte des informations aux manuels utilisateurs (class AGD).

Il y a, dans la phase de développement, des éléments d'analyse de résultat de test qui vont être importants pour la documentation de test (class ATE). Pour les niveaux d'EAL les plus élevés, le document de conception et représentation (classe ADV) doit être complété avec une représentation de l'implémentation. L'évaluation de la vulnérabilité (class AVA) et les guides utilisateurs sont finalisés dans cette phase de développement. Les documentations pour les livraisons et l'exploitation (class ADO) sont aussi rédigés dans la phase de développement.

Les documents pour les livraisons (class ADO) sont finalisés dans la phase de déploiement et mise en exploitation.

Une étude de cas a été menée sur le développement d'une application de porte-monnaie électronique. Le projet a duré 3 mois avec une équipe de 18 personnes avec une charge de 630 jours hommes.

Le premier retour d'expérience, est que les CC laissent trop de place à des ambiguïtés, il est souvent difficile de trouver la juste signification des exigences de sécurité. Des interprétations différentes des exigences des CC sont souvent possibles, et font perdre un temps précieux au cours du projet.

Les CC rendent les documents interdépendants, ce qui augmente la charge documentaire. Cette charge documentaire est aussi accrue du fait que l'exigence des CC positionne des spécifications sur différents niveaux d'abstraction. Le champ d'application des exigences fonctionnelles de la CC est principalement dans le domaine des réseaux de communication et du commerce électronique. Il ne couvre pas de façon adéquate les exigences de sécurité de la protection de la vie privée de l'utilisateur ou les exigences de juste-échange.

Autres approches

José Romero-Mariona, propose une approche qui fait correspondre les exigences de sécurité des CC aux éléments d'architecture et leurs connexions. La méthode propose un guide, qui est principalement basé sur les observations du processus des CC : élaboration des exigences de sécurité. Avec l'aide de ce guide les utilisateurs devraient être en mesure de cartographier ces exigences en éléments architecturaux et leurs connexions.

Puis, à partir de cette cartographie, un outil va automatiser la construction d'un fichier XML après avoir effectué une vérification de la cartographie. Les modules principaux de l'outil sont :

• Syntaxe XML: Définition du format d'entrée des autres modules de l'outil ;
• CCARCH v1.1.: Effectue une vérification de la cartographie ;
• Générateur de composants. Automatise la construction de fichier XML.

Les composants des CC et leurs connexions sont définis en XML par 4 paramètres :

• Le nom du système dans son ensemble ;
• Un numéro d'identification unique du composant ;
• Le nom du composant ;
• La liste de tous les autres composants, avec lequel est lié ce composant.

Le second module effectue une vérification de la définition réalisée par l'utilisateur et produit un digramme dans un format XDR non standard. En cas d'erreur, l'outil l'indique et fournit à l'utilisateur des informations sur ce qui est nécessaire de faire pour résoudre le problème. Le troisième module génère automatiquement un fichier de sortie au format XML. L'utilisateur peut alors ajouter de nouveaux composants. L'outil créé un nouveau fichier XML qui peut être remis en entrée du second module pour vérification.

Shanai Ardi propose une méthode qui consiste à compléter la cible de sécurité, en y ajoutant les vulnérabilités logicielles. La cible de sécurité traite les points suivants :

• Prise en compte des menaces issue des vulnérabilités de l'exploitation ;
• Ajout, dans les menaces de sécurités, les risques de menaces possible et leurs conséquences sur les actifs ;
• Identification des méthodes pour prévenir les vulnérabilités ;
• Ajout des Exigences fonctionnelles de sécurité des vulnérabilités ;
• Ajout des Relations entre les objets de sécurité et les vulnérabilités.

Notes

Références