Les critères communs (CC) sont un ensemble de normes (ISO 15408) internationalement reconnues dont l'objectif est d'évaluer de façon impartiale la sécurité des systèmes et des logiciels informatiques. Également dénommés Common Criteria, ce référentiel est né d'un partenariat entre le Canada, les États-Unis et l'Europe. Grâce au cadre offert, les utilisateurs de technologies de l’information vont pouvoir utiliser des profils de protection pour spécifier les exigences fonctionnelles de sécurité attendues et les évaluateurs pourront vérifier que les produits sont bien conformes au niveau d’assurance requis.
La mise en œuvre des critères communs décidée par les signataires d’un accord de reconnaissance mutuelle, facilite grandement l’acceptation des certificats de sécurité des technologies de l’information émis par l’un des pays signataires. Le produit certifié en toute impartialité par une autorité compétente, peut être utilisé sans nécessiter une évaluation plus poussée.
Bien que présentant de nombreux avantages, l’application de cette norme s’avère coûteuse, difficilement compréhensible pour un non initié et souvent compliquée à mettre en œuvre. C’est la raison pour laquelle plusieurs méthodes d’utilisation ont vu le jour.
Historique thumb|upright=1.7|Liste des pays signataires ou reconnaissants l'accord CC-MRA..
En 1983, puis 1985, le NISTNIST pour National Institute of Standards and Technology qui pourrait être traduit par Institut National des normes et de la Technologie et la NSANSA pour Agence Nationale de la Sécurité publient l'Orange Book. Le but de ce document était d'évaluer la capacité d'un système à se défendre contre des attaques.
Dans le même temps l'Europe s'inspire des TCSECTCSEC pour Trusted Cumputer System Evaluation Criteria qui pourrait être traduit par Critères d'évaluation pour Systèmes informatiques éprouvés pour définir en 1991 ses propres critères d'évaluation les ITSECITSEC pour Information Technologie System Evaluation Criteria. Ils vont combler des lacunes dans l'analyse des risques.
En 1993, le Canada définit sa propre norme CTCPECCTCPEC pour Canadian Trusted Computer Product Evaluation Criteria que l'on pourrait traduire par Critères d'évaluation Canadien des produits informatiques éprouvés</ref>.
Le certificat obtenu dans un pays est reconnu uniquement par les pays signataires de l'accord de reconnaissance mutuelle. En Europe c'est l'accord SOG-ISSOG-IS pour Senior Officers Group for Information qui fait foi.
En 1999, l'ISOISO pour International Organisation for Standardisation que l'on pourrait traduire par Organisation internationale de normalisation. est à l'origine des Critères Communs. Cette organisation va regrouper les différents états pour définir une norme (ISO 15408) reconnue par tous les états signataires de l'accord CC-MRACCMRA pour Common Criteria Mutual Recognition Arrangement que l'on pourrait traduire par Accord de reconnaissance mutuelle selon les Critères Communs en mai 2000. En plus des 17 pays signataires, 9 pays non signataires reconnaissent ces certificats.
Concepts Généraux
Les Critères Communs (CC) sont un guide servant de référence pour le développement et le contrôle de produits et systèmes de l’information manipulant des informations. Le but est la protection contre la divulgation non autorisée, la modification, la perte d'usage. Les catégories de ces trois types de défaillances sont communément désignées par confidentialité, intégrité et disponibilité. Les CC prennent en compte les risques émanant d'activités humaines (malicieuses ou non) ou non-humaines.
Les produits contrôlés sont ceux collectant, transportant et manipulant ces informations, à savoir des réseaux informatiques, des systèmes d’exploitation, des systèmes distribués et des applications. Un système sera évalué en fonction de l’usage pour lequel il est dédié. Il devra répondre à deux catégories d’exigences de sécurité : exigences fonctionnelles et d’assurance.
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é: .
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.
thumb|upright=1.4|Certification Détection faux doigt : paquet d'exigences fonctionnelles
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 SPODSPOD pour Biometric Spoof Detection qui pourrait être traduit par Détection biométrique d'une usurpation à 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 ; + Exigences d'assurance de sécuritéClasse Domaine couvert ADV Développement ACO Composition AGD Documentation ALC Cycle de Vie APE Évaluation Profile de protection ASE Évaluation de la cible de sécurité ATE Tests AVA Estimation des Vulnérabilités
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