CERTIFICATION CRITÈRES COMMUNS

CERTIFICATION CRITÈRES COMMUNS Par Gérard Peliks Expert sécurité Security Center of Competence EADS Defence and Security Août 2007 LA CERTIFICATION CRITÈRES COMMUNS EXPLIQUÉE À CEUX QUI CROIENT ENCORE À LA SÉCURITÉ SUBJECTIVE. ASSURANCE DE SÉCURITÉ SUBJECTIVE, ASSURANCE DE SÉCURITÉ OBJECTIVE On peut penser qu un produit de sécurité est lui-même sécurisé et assume bien son rôle parce que son voisin dont la sécurité repose sur le même produit ne s en est jamais plaint. On peut penser que si un produit de sécurité est développé ou commercialisé par une organisation qui a bonne réputation sur le marché de la sécurité, ce produit est sûr. On peut également admettre que si un produit coûte cher, c est qu il est bon. Et plutôt que de comparer deux produits, mieux vaut comparer la réputation de leurs concepteurs, leurs professions de foi ou encore leurs réseaux de distribution et leurs parts de marché. Ou alors on se base sur des référentiels différents. On peut considérer qu un produit de sécurité assure sa fonction, n assure que sa fonction et toute sa fonction, s il est passé à travers une batterie de tests, les mêmes pour tous les produits équivalents, qui poussent à un niveau suffisant les contrôles sur toute la surface des fonctionnalités attendues de ce produit et avec une profondeur suffisante. On peut vouloir vérifier, par un certificat, que ces tests ont été réalisés par un organisme indépendant et que le résultat a reçu l aval d un organisme d état, reconnu sur le plan international. On veut être persuadé que deux produits assurant les mêmes fonctionnalités ont passé les mêmes tests, avec le même degré d exigence, sur la même surface des produits et la même profondeur d évaluation. Au premier paragraphe est décrite une assurance de sécurité qu on pourrait qualifier de «plutôt subjective». Vous y croyez à cette sécurité? Moi non plus! Au deuxième paragraphe, on décrit une assurance de sécurité objective qui, de plus, permet de comparer deux produits équivalents. Vous préférez? Alors bienvenue dans le monde des Critères Communs! L ÉVOLUTION DE LA CERTIFICATION DES TECHNOLOGIES À TRAVERS LES ÂGES Au début des années 1980, le Département de la Défense US (DoD) émet un appel d offre pour que soit proposé un moyen de s assurer qu une technologie logicielle ou matérielle possède bien la sécurité nécessaire à son utilisation. Ainsi fut écrit l Orange Book qui définissait des niveaux de sécurité (de D à A1) mais qui ne permettait pas d avoir des critères de comparaison entre plusieurs produits de même Un livre blanc 1 / 5

nature. De plus l Orange Book était surtout reconnu aux US et ne tenait pas compte des spécificités européennes. Quatre pays européens, la France, l Allemagne, le Royaume Unis et les Pays Bas écrivirent d autres spécifications avec les ITSEC, reconnus uniquement en Europe et qui ne permettaient toujours pas de comparer des produits. Le Canada écrivit dans le même temps ses propres critères d évaluation. Alors que s annonçait le 21eme siècle, tous ces pays unirent leurs travaux pour définir une nouvelle méthodologie pour s assurer qu un produit remplit ses fonctions, et pas plus, et pas moins, avec un niveau d assurance quantifié. Ainsi furent élaborés les Critères Communs, dont la version 2 devint une norme internationale (l ISO 15408). CONTENU DES CRITÈRES COMMUNS Les critères communs forment un ensemble de spécifications qui évolue grâce aux travaux d un groupe d experts. La version actuelle 3.1 se compose de trois volumes : «Introduction et modèle général» qui explique ce que sont les critères communs (87 pages), les «exigences fonctionnelles» qui sont essentiellement une bibliothèque d éléments qui décrivent les fonctionnalités de sécurité pouvant être mises en œuvre par le produit (204 pages) et les «exigences et les niveaux d assurance» qui sont essentiellement une bibliothèque d éléments pour s assurer que les mesures de sécurité sont conformes aux spécifications et sont efficaces, en accord avec le niveau de certification visé (241 pages). Ces volumes sont écrits en anglais et il existe aussi une version française pour la version 2 des Critères Communs. PP, ST ET TOE Un produit est évalué Critères Communs, non pas pour l ensemble de ses fonctionnalités et de son code, ce serait illusoire et ce ne serait d ailleurs jamais atteint, mais sur un espace restreint appelé une «cible de sécurité». Bien évidemment, plus la cible est petite, plus elle est facile à atteindre. Aussi l astuce, pour l éditeur du produit qui se lance dans un processus de certification, serait de définir dans la cible, seulement les fonctionnalités dont il sait qu elles passeront les tests sans problème. L important n est-il pas d obtenir le diplôme de certification pour prendre un avantage marketing sur ses concurrents? Et qui va savoir qu un produit de sécurité certifié ne l est que sur une infime partie de sa surface? Mais cela n irait certainement pas dans l intérêt de ceux qui achètent le produit et pas non plus dans l intérêt de l organisme qui engage sa réputation en signant le certificat Critères Communs. Alors, pour éviter qu un éditeur ne se lance dans un jeu subtil de découpage de la cible de sécurité qu il définit pour ne proposer de soumettre aux tests qu une fine dentelle du produit, il a été prévu la notion de «Profil de Protection» (PP : Protection Profile). Un profil de protection est une cible de sécurité générique propre à un type d'équipement et ou à une communauté d'utilisateurs, comme, par exemple les Firewalls ou les passerelles VPN, que tout éditeur qui veut faire certifier un produit, se doit de soumettre aux tests. Ainsi, deux concurrents, qui se lancent dans une démarche de certification, feront passer les tests sur une cible de sécurité qui ne peut avoir une surface inférieure au Profil de Protection de cette famille de produits. Mais qui écrit, pour une famille de produits donnée, un profil de protection? Ce peut être un organisme officiel comme, en France, la DCSSI ou l AFNOR. En fait, un profil de protection peut être proposé par n importe qui, y compris par un éditeur, mais il faut que ce profil soit certifié pour devenir une référence utilisable. Le commanditaire de la certification doit rédiger une cible de sécurité (ST : Security Target) qui définit la surface de son produit qui va subir les tests de certification. S il existe pour ce produit un ou plusieurs profils de protection, une partie du travail est faite puisque la cible de sécurité doit au moins inclure ce ou ces profils de protection. Pour la rédaction de la cible de sécurité, le profil de protection est un bon début. S il n y en a pas, la rédaction de la cible de sécurité se fait «from scratch». Le travail est alors plus long, les ressources à mettre en œuvre plus conséquentes et bien entendu, la cible de sécurité doit être acceptée par l organisme signataire de la certification (en France la DCSSI) avant que les tests de certification ne puissent commencer. Souvent les premières versions de la cible sont jugées insuffisantes. Alors commence un va et vient entre le commanditaire et la DCSSI, coûteux en temps et en ressources. Dans la cible de sécurité sont définies les menaces auxquelles le produit doit faire face et comment il se comporte pour les contrer et le ou les profils de protection auxquels on se réfère. On définit aussi la surface d évaluation en choisissant parmi les éléments fonctionnels du volume 2 des Critères Communs, ceux qui correspondent aux fonctionnalités à tester. On décide du niveau de certification qu on souhaite atteindre, ce qui décide des éléments d assurance qu il faut inclure dans les tests. On décrit très précisément aussi la cible d évaluation qui va être soumise aux tests : la TOE (Target Of Evaluation). Les tests vont donc porter sur la TOE (Target Of Evaluation) décrite dans la ST (Security Target) qui doit au moins être aussi large que le ou les PP (Protection Profile) auxquels elle se réfère. Un livre blanc 2 / 5

CLASSES, FAMILLES, COMPOSANTS ET PAQUETS Les «composants» sont les plus petites parcelles qui seront utilisées pour définir soit les éléments de la technologie à tester (composants fonctionnels) soit la manière de conduire les tests (composants d assurance). Pour rationaliser et simplifier les Critères Communs, ces composants sont regroupés en familles, et les familles sont regroupées en classes. Chaque famille est un ensemble de composants qui s imbriquent suivant une structure hiérarchique car un composant peut dépendre de la présence d autres composants dans une même famille. La version 3 des Critères Communs décrit 11 classes fonctionnelles qui définissent ce qu on peut tester et 9 classes d assurance qui définissent comment sont conduits les tests, plus de 120 familles réparties entre classes fonctionnelles et classes d assurance et plusieurs centaines de composants. Choisir un niveau d assurance, c est s imposer de mettre dans la Cible de Sécurité un certain nombre de classes (donc avec toutes leurs familles et tous leurs composants), un certain nombre de familles en dehors des classes déjà imposées et un certain nombre de composants en plus des composants imposés par les classes et les familles. Le tout forme un «paquet». C est ce paquet qui va être évalué, pour atteindre le niveau de certification souhaité. On peut également rajouter d autres éléments non imposés, ou des éléments imposés dans un niveau d évaluation supérieur. On appose alors le signe «+» à la suite du niveau d évaluation, qui signifie «augmenté de tels composants non imposés par le niveau d évaluation choisi». Ces composants supplémentaires figurent dans le certificat. LES NIVEAUX D ÉVALUATION Un produit peut être certifié Critère Commun sur l un des sept niveaux d évaluation (EAL1 à EAL7). Chaque niveau impose un certain paquet, composé de classes, familles et composants d assurance définis dans le volume 3 des Critères Communs. Un niveau impose l ensemble des éléments du paquet du niveau au-dessous auquel on ajoute, de manière imposée, d autres classes, familles et composants d assurance. EAL1 est le plus bas niveau des Critères Communs et définit des tests de fonctionnement en boîte noire : on s assure que le produit se comporte conformément à ce qui est écrit dans sa documentation. EAL2 définit des tests de fonctionnement en boîte blanche : on commence à regarder comment est conçu le produit avant de s assurer qu il fait bien ce qu il est censé faire. Les Firewalls et les passerelles VPN visent, en général, le niveau EAL2+. Avec EAL4 on commence à vérifier des parties du code source du produit. C est le niveau le plus élevé dans la hiérarchie de la certification pour des technologies construit à l aide de méthodes de développement standards. Au-delà commence le domaine de la certification des technologies mettant en œuvre des méthodes de développement plus spécifiques et rigoureuses. On commence alors à parler de spécifications semi-formelles et formelles. EAL7, le plus haut niveau, impose des spécifications formelles c est à dire que les spécifications sont exprimées dans un langage syntaxique basé sur des concepts mathématiques. Si un produit n a pas été pensé, dès le début de sa conception, avec la volonté d atteindre une certification Critères Communs, il ne pourra atteindre au plus que le niveau de certification EAL4+. COMMANDITAIRES, CESTI ET DCSSI Le commanditaire est celui qui veut faire certifier un produit. En théorie, ce devrait être celui qui achète le produit car il est le plus concerné par l utilisation qu il veut en faire. En pratique c est l éditeur du produit qui demande le processus de certification (et donc engage les dépenses et mobilise ses ressources) pour tirer un avantage marketing du certificat obtenu, ou simplement parce que son client, c est le cas de certaines administrations, exige cette certification à un certain niveau. Bien sûr, ce n est pas le commanditaire qui teste son produit mais un cabinet indépendant et incorruptible, le CESTI. Il existe deux CESTI en France pour mener les certifications des logiciels (AQL et Oppida) et trois CESTI pour les produits matériels avec logiciel embarqué (CESTI LETI, Serma Technologies et CEACI). Ces CESTI doivent constamment prouver et leur compétence et leur sérieux qui font l objet d un contrôle et d une surveillance par la DCSSI et sont de plus accrédités et surveillés selon une norme qualité par un organisme d état, le COFRAC. Les tests étant satisfaisants, le CESTI porte le dossier de certification à la DCSSI, qui dépend du SGDN, organisme interministériel qui signe le certificat et publie sur son site Web la cible de sécurité certifiée et le rapport de certification. Les services de la DCSSI sont gratuits mais bien entendu ceux du CESTI, qui est un organisme privé, sont payants. Un livre blanc 3 / 5

LA LONGUE MARCHE VERS LA CERTIFICATION S engager dans une démarche de certification Critères Communs, c est emprunter un chemin long, sinueux et coûteux car cela suppose un travail important qui peut s étaler sur plus d un an. Le coût d une certification de EAL2+ à EAL4+ peut s élever à plus de 100000 euros à verser au CESTI, sans compter les ressources que le commanditaire de la certification doit mettre en œuvre en interne et dont le coût de revient est équivalent à celui du CESTI. Bien entendu plus le niveau de certification à atteindre est élevé (EAL1 à EAL7), plus le budget à prévoir doit être conséquent. S il existe un Profil de Protection pour la technologie à évaluer pour le niveau de certification souhaité, c est déjà un bon point, sinon, la rédaction de la cible de sécurité et les allés venues entre le rédacteur de la cible et la DCSSI qui trouvera la cible insuffisante à ses débuts, constitueront un travail à ne pas négliger. Évidemment, le CESTI est là pour tester, pas pour debogger votre produit alors gare, si on en arrive là, vous n êtes pas près d obtenir la certification souhaitée dans un délai raisonnable. Il tombe sous le sens qu il ne faut chercher à ne faire certifier que des produits dans une version stable et mature. LE CERTIFICAT ET SES LIMITES Comme pour tout diplôme, il convient de lire attentivement son contenu, car il peut cacher bien des pièges. D abord, un produit n est pas certifié Critères Communs dans l absolu mais, par exemple pour la version 3.1 des Critères Communs, au niveau EAL2 augmenté de tels composants d assurance (EAL2+) et seulement dans le périmètre de telle cible de sécurité. Il faut connaître ce que signifie le niveau de certification obtenu qui donne le degré de confiance qu on peut accorder au produit. Ensuite le produit n est pas certifié jusqu à la fin des temps mais pour une certaine version, sur un certain système d exploitation, et parfois seulement pour tourner sur certains matériels (c est le cas des appliances de sécurité). Comme la certification du produit s est étalée sur plus d une année, la version du produit proposée sur le marché n est plus, en général, celle qui a été soumise aux tests. Ses évolutions ont pu introduire des vulnérabilités non couvertes et de plus les menaces ont aussi évolué. Des processus ont donc été mis au point par les organismes de certification internationaux, permettant d une part de surveiller la résistance d un produit certifié dans le temps, et d autre part d étendre la validité du certificat d un produit à ses éventuelles nouvelles versions, dans la mesure où les changements apportés n impactent pas son niveau de sécurité. Ceci étant précisé, il faut reconnaître qu un commanditaire qui s engage dans une démarche de certification Critères Communs réalise une action responsable et ses équipes de développement peuvent acquérir, ne serait-ce que par obligation, de très bonnes habitudes. On ne ressort jamais de ce processus comme on y était entré la première fois. GLOSSAIRE CC CESTI COFRAC DCSSI DoD EAL ITSEC PP SGDN ST TOE Common Criteria Centre d Evaluation de la Sécurité des Technologies de l Information Comité Français d'accréditation Direction Centrale de la Sécurité des Systèmes d Information Department of Defense (US) Evaluation Assurance Level (EAL1 à EAL7) Information Technology Evaluation Criteria Protection Profile Secrétariat Général de la Défense Nationale Security Target Target of Evaluation RÉFÉRENCES <Réf. 1> <Réf. 2> www.ssi.gouv.fr www.commoncriteria.org Un livre blanc 4 / 5

Cérémonie de signature des premiers accords de reconnaissance mutuelle des Critères Communs à Washington DC. On reconnaît, pour la France, le Général Jean-Louis Desvignes, alors patron de la SCSSI qui allait devenir la DCSSI. A PROPOS DE L AUTEUR Gérard PELIKS est expert sécurité dans le Cyber Security Customer Solutions Centre de EADS. Il préside l'atelier sécurité de l'association Forum ATENA, participe à la commission sécurité des systèmes d'information de l'afnor et anime un atelier sécurité dans le cadre du Cercle d'intelligence Économique du Medef de l'ouest Parisien. Il est membre de l'arcsi et du Club R2GS. Gérard Peliks est chargé de cours dans des écoles d'ingénieurs, sur différentes facettes de la sécurité. gerard.peliks (at) eads.com Les idées émises dans ce livre blanc n engagent que la responsabilité de leurs auteurs et pas celle de Forum ATENA. La reproduction et/ou la représentation sur tous supports de cet ouvrage, intégralement ou partiellement est autorisée à la condition d'en citer la source comme suit : Forum ATENA 2007 Certification Critères communs Licence Creative Commons - Paternité - Pas d utilisation commerciale - Pas de modifications L'utilisation à but lucratif ou commercial, la traduction et l'adaptation sous quelque support que ce soit sont interdites sans la permission écrite de Forum ATENA. Un livre blanc 5 / 5