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
Common Criteria
CESTI
Centre d’Evaluation de la Sécurité des Technologies de l’Information
COFRAC
Comité Français d'Accréditation
DCSSI
Direction Centrale de la Sécurité des Systèmes d’Information
DoD
Department of Defense (US)
EAL
Evaluation Assurance Level (EAL1 à EAL7)
ITSEC
Information Technology Evaluation Criteria
PP
Protection Profile
SGDN
Secrétariat Général de la Défense Nationale
ST
Security Target
TOE
Target of Evaluation
RÉFÉRENCES
<Réf. 1>
www.ssi.gouv.fr
<Réf. 2>
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