Depuis 2008, les éditeurs de logiciels de sécurité voulant certifier de l’efficacité de leurs produits peuvent se tourner vers la Certification de Sécurité Premier Niveau (CSPN), alternative plus abordable aux Critères Communs (CC) mise en place par l’ANSSI.

Là où les Critères Communs se veulent exhaustifs, la CSPN privilégie la maîtrise des coûts et des délais. Ainsi, plutôt qu’une évaluation globale qui peut durer le temps qu’il faudra, la CSPN se déroule en temps et ressource contraintes.

De base, 25 jour-homme, portés à 35 si des mécanismes cryptographiques sont inclus. Pour être exhaustif, l’ANSSI peut demander à réduire ou augmenter légèrement suivant les situations, mais au final, ça doit rester compris entre 15 et 50.

Dans une démarche CSPN (mais aussi CC), la première étape consiste à rédiger la cible de sécurité. Souvent négligé, c’est pourtant le document le plus important dans la certification puisqu’il fixe le périmètre de la certification : ce qu’elle comprend (fonctions de sécurités) et ce qu’elle écarte (hypothèses).

Si vous voulez rédiger une cible, l’ANSSI fourni un référentiel documentaire complet concernant la certification et la méthodologie, mais ces documents peuvent paraître obscurs pour un néophyte. Un exemple de cible avec netfilter est également fourni mais comme il n’est pas commenté, ça n’aide pas tellement.

En fait, toutes les cibles des produits certifiés sont disponibles et donc utilisables pour avoir une idée du contenu. Sauf i-Suite 5.5.5, ne me demandez pas pourquoi.

Même si les CESTIs (centres d’évaluation) peuvent vous rédiger une cible, vous pourriez vouloir leur fournir un premier document de travail ou mieux appréhender le sujet pour relire efficacement la cible qu’ils vous fourniront.

C’est dans cette optique de démystification que je vous présente aujourd’hui mon exemple de Cible de Sécurité, qui utilisera, pour la cause, le blog développé pour nos examens (i.e. 2019). À partir de cette ligne, le corps du texte constitue la cible, mes commentaires seront en citation.

Identification du produit

Une Certification de sécurité, CSPN ou CC, n’est accordée que pour un produit spécifique dans une version spécifique. Le but de cette section est donc de permettre une « identification non ambiguë du produit ».

• Organisation éditrice : Speed-e-Devs,
• Lien vers l’organisation : Sans objet,
• Nom commercial du produit : Speed-e-Blog,
• Numéro de la version évaluée : Speed-e-Blog version 2.0,
• Catégorie de produit : Divers.

L’ANSSI a défini une liste officielle des catégories de produits pouvant faire l’objet d’une CSPN (cf. section B.2 de la procédure d’accréditation. Elles ont toutes en commun d’être des produits dont le but est de fournir une fonction de sécurité (i.e. détection d’intrusion, anti-virus, pare-feu, communication sécurisée, …) et les blogs n’en font donc pas partie. Ainsi, j’ai choisi la catégorie « Divers ».

Argumentaire du produit

La cible a pour vocation à être communiquée aux clients, pour qu’ils mesurent la portée de la certification mais aussi l’intérêt du produit en termes de sécurité. L’argumentaire a justement pour but de décrire le produit, son utilité, sa manière de l’utiliser ainsi que les éventuelles contraintes liées à son utilisation.

Description du produit

Speed-e-Blog est un logiciel permettant de réaliser un site web basé sur le principe du blog. Chaque rédacteur peut ainsi y publier des articles qui sont listés et mis à disposition du public.

Dans une philosophie du « Rester Simple », Speed-e-Dev se veut facile à installer, utiliser et minimaliste dans ses fonctionnalités pour se concentrer sur sa mission : faciliter la communication entre internautes.

Utilisation du produit

Il ne s’agit pas, ici, d’expliquer comment on utilise le produit mais plutôt de lister les façons dont les clients peuvent utiliser le produit ou encore quel problèmes différents le produit résout (pour un pare-feu ou un détecteur d’intrusion, on pourrait lister les diverses manières de déployer la solution).

Speed-e-Blog, en tant que système de gestion de contenu permet à une communauté de communiquer :

• De manière privée, seul les membres de la communauté ont accès à l’application. Speed-e-Blog facilite ainsi le partage et la sauvegarder des articles liés à l’activité de la communauté.
• De manière publique, tout internaute peut accéder au contenu, Speed-e-Blog facilite alors la communication marketing par l’information du public ou la création de communauté de fans.

Environnement d’exécution

Cette section vient compléter les précédentes pour décrire comment le produit s’insère dans l’infrastructure existante et interagi avec les autres composants du client.

Speed-e-Blog est une application web clé en main pouvant s’installer sur un serveur Web connecté au reste de votre réseau. Les lecteurs et rédacteurs utilisant leur navigateur pour lire, ajouter et supprimer les articles.

L’utilisation privée ou publique du blog se fait par restrictions des accès réseau au serveur hébergeant l’application. Un blog public devant être accessible depuis n’importe quelle connexion à Internet. Un blog privé pouvant être hébergé à l’intérieur du système informatique de la communauté (ou accessible à travers des réseaux privés virtuels).

Utilisateurs typiques

Cette section est parfois absente des cibles mais je la trouve intéressante. Même si ça peut paraître redondant, elle permet d’identifier formellement les catégories d’acteurs pouvant interagir avec la cible ainsi que les actions typiques, ce qui facilitera ensuite l’énumération des biens et des menaces concernant le produit.

D’une certaine manière, on peut voir cette section comme le « Diagramme de cas d’utilisation » ou tout au moins une version simplifiée listant les acteurs.

Speed-e-Blog peut être utilisé par deux catégories d’utilisateurs, non exclusives :

1. Les lecteurs, simples visiteurs du site web qui vont consulter la liste des articles et en lire certains,
2. Les rédacteurs, utilisateurs privilégiés pouvant, en plus, ajouter et supprimer leurs propres articles.

Par extension, même s’ils n’utilisent pas le produit, on considère également les acteurs suivants :

1. Les administrateurs système et réseau, en charge de l’installation du produit et de la bonne marche de l’infrastructure informatique.

Hypothèses sur l’environnement

Cachée dans la description, c’est pourtant une section très importante car elle détermine le périmètre des responsabilités entre l’éditeur du produit et son client. Deux pièges sont ici à éviter :

1. Mettre trop d’hypothèses, la sécurité devant être assurée par le client sans que le produit n’apporte rien. Dans ce cas, l’ANSSI pourra refuser la cible (et donc une certification) car la cible serait considérée comme trompeuse.
2. Mettre pas assez d’hypothèses, la sécurité étant alors assurée par le produit (et l’éditeur) au travers des fonctions de sécurité. Le risque ici est lié à l’étendue de la surface d’attaque du produit ; plus elle est grande, plus les évaluateur pourront trouver de vulnérabilités.

Le juste milieu consiste à lister ici les mécanismes de sécurité réaliste, relevant de la responsabilité du client et nécessaires pour que le produit fonctionne dans un environnement « honnête ». Si certaines vous semblent évidentes, rappelez-vous que certains produits sont justement conçus pour fonctionner en environnement hostiles et les menaces qui vont avec.

Sécurité logique

• L’infrastructure informatique (réseaux, serveurs et logiciels tiers) est sécurisée conformément à la section 2.1 des « recommandations pour la sécurisation des sites web » de l’ANSSI, document officiel,
• L’application a été installée conformément aux instructions fournies dans la documentation du produit.

Sécurité physique

• Les équipements informatiques (serveur web et base de donnée) doivent se trouver dans des locaux sécurisés dont l’accès est contrôlé et restreints aux administrateurs.

Sécurité organisationnelle

• Les administrateurs sont considéré comme de confiance, et formées aux bonnes pratiques en matière de sécurité informatique.

Périmètre de l’évaluation

Cette section permet de déterminer l’ensemble des fonctionnalités de sécurité qui feront l’objet d’une évaluation et seront certifiées.

Pour de (trop) gros projets qui remplissent plusieurs fonctions fondamentalement différentes, certaines parties peuvent être volontairement écartées, d’où l’intérêt de cette section.

La cible étant globalement cohérente, si une partie de l’application est écartée ici, elle le sera également du reste de la cible et des sections qui suivent (biens, menaces & fonctions). En ce sens, je vois cette section comme une sorte de résumé des fonctions de sécurité qui seront listées plus loin.

La cible de sécurité et l’évaluation du produit concerneront les fonctionnalités suivantes :

• Authentification,
• Contrôle d’accès,
• Stockage,
• Filtrage des entrées.

Environnement Technique

Cette section a pour but de clairement établir les dépendances nécessaires au produit. Là où la section « Environnement d’exécution » donnait les grandes lignes concernant les contextes d’utilisation, ici le but est de lister formellement tous les pré-requis techniques pour que le produit fonctionne. Un peu comme la « configuration système » à l’arrière des boites de jeux vidéos.

On rencontre en général trois cas de figure :

1. Les produits clé en main et grand public qui peuvent s’installer dans presque toutes les conditions. Il existe quelque contraintes mais elles sont facilement respectées.
2. Les produits spécifiques et de niche qui ne s’installent que dans des environnements très particuliers. Les contraintes sont alors nombreuses et l’éditeur devra sûrement aider les évaluateurs pour l’installation d’une plateforme de test.
3. Les produits spécifiques tout compris qui embarquent avec eux leurs dépendances. Les contraintes sont alors très réduite puisque l’éditeur fourni tout le nécessaire (allant parfois jusqu’à fournir le matériel).

L’évaluation ne pouvant se faire sur que sur une seule plateforme de test, il est parfois impossible de tester toutes les combinaisons compatibles. L’évaluateur en choisira alors une qui lui semble la plus adaptée et y mènera ses travaux.

Vous pourriez bien sûr contraindre l’évaluateur à la plateforme de votre choix en étant très restrictif dans cette section-ci mais sachez que la certification ne concernera alors que cet environnement spécifique. Une question de marketing donc.

Matériel

Les matériels utilisables sont ceux compatibles avec les systèmes d’exploitations retenus et pour une utilisation en tant que serveur web (muni d’au moins une carte réseau).

Système

L’application a été conçue pour fonctionner sur n’importe quel système d’exploitation permettant l’installation des logiciels nécessaires au fonctionnement du produit.

Logiciel

L’application est compatible avec n’importe quel serveur d’application web tant que celui-ci répond aux deux contraintes suivantes :

1. Il dispose d’un interpréteur PHP en version 5 ou supérieure,
2. Il dispose d’une connexion vers un serveur de base de donnée mySQL.

Biens à protéger

La notion de « bien » correspond aux ressources de l’application (e.g. ce peuvent être des données mais aussi des fonctionnalités) et qu’il est judicieux de protéger. Le terme anglais « asset » est plus parlant car il intègre toutes ces notions mais il fallait bien traduire par quelque chose.

La « protection » des biens s’entends vis à vis d’une propriété de sécurité que l’on souhaite maintenir dont voici les trois principales (et toujours très classiques) :

1. Confidentialité : seuls les entités autorisées accèdent à la ressource,
2. Intégrité : seuls les entités autorisées modifient la ressource,
3. Disponibilité : la ressource est accessible aux entités autorisées.

Même si ça n’est pas obligatoire, je trouve plus lisible et plus pratique pour la construction d’une cible de séparer les biens en deux catégories : métier et support. Même si les terminologies varieront d’une cible à l’autre, l’idée restera la même.

Biens métier

Les biens métiers correspondent aux ressources que le produit fourni ou manipule pour le compte des utilisateurs. Ce sont en quelque sorte tout ce qui a rapport direct avec les fonctionnalités attendues du produit et qu’on peut identifier assez facilement.

Il est d’usage de numéroter les biens (mais aussi les menaces et les fonctions). Sans rentrer dans les considérations psychanalytiques des névroses obsessionnelles, c’est surtout utile dans les tableaux lorsqu’il n’y a pas beaucoup de place pour écrire les éléments en entier.

Dans le cadre de son utilisation, Speed-e-Dev protège les biens suivant :

• B1 - Les articles publiés par les rédacteurs, protégés en intégrité.
• B2 - Le nom des rédacteurs utilisé pour s’identifier, protégés en intégrité.
• B3 - Le navigateur web utilisé par les lecteurs et rédacteurs, protégés en confidentialité et intégrité.

Biens support

Les biens supports correspondent aux ressources que le produit manipule pour son propre compte afin de garantir son bon fonctionnement. Le fait d’insérer une section dédiée permet d’y réfléchir et d’identifier des ressources qu’on aurait pu oublier sinon (i.e. des journaux d’événements ou des clés cryptographiques à usage interne).

Afin de garantir son bon fonctionnement, Speed-e-Dev protège également les biens suivants :

• B4 - Mots de passes utilisés par les rédacteurs pour s’authentifier, protégés en confidentialité et intégrité.
• B5 - Les fichiers de configuration utilisés par l’application pour son paramétrage, protégés en confidentialité et intégrité.
• B6 - Le code source utilisés par l’application pour fonctionnement, protégé en intégrité.
• B7 - Les serveurs utilisé pour le fonctionnement de l’application, protégés en confidentialité et intégrité.

Propriétés de sécurité

Je trouve toujours plus lisible d’ajouter ce genre de tableau permettant de synthétiser la relation entre les biens et les propriétés de sécurité. C’est aussi l’occasion de faire le point entre ce qui est attendu de la part des clients et ce que le produit propose vraiment. On ne peut plus tricher avec des effets de langage.

L’ANSSI peut d’ailleurs refuser une cible si elle considère que la liste des biens et des propriétés est incomplète.

Le tableau suivant synthétise les biens sensibles à protéger vis à vis des propriétés de sécurité à garantir. Par simplicité, les propriétés sont abrégée avec leur première lettre.

Ou plutôt par commodité pour que ça s’affiche bien sur les petits écrans de nos visiteurs qui viennent lire le site des arsouyes avec un smartphone. En vrai, mettez les titres des colonnes en toute lettre et si c’est long, tournez les de 90°.

Vous pouvez noter qu’aucun bien n’est protégé en disponibilité. Je reviendrai sur ce point plus tard dans cet article.

Menaces

Les menaces sont en quelque sorte la charnière entre les fonctions de sécurités mises en place par le produit et les biens sensibles que ces fonctions protègent. En effet, sans menace sur un bien, pas besoin de protection. C’est un principe et une méthode qui sous-tend la démarche des Critères Commun et donc la CSPN mais aussi les autres méthodes proposées par l’ANSSI (i.e. la Méthode EBIOS RM).

Agents de menace

Cette section est en fait facultative tant que les menaces qui suivront sont correctement caractérisées. Je la trouve tout de même pertinente car elle permet de se faire une idée des sources de problèmes de sécurité et c’est pédagogique pour le lecteur.

Dans le cas de notre blog, ça ne sera pas utile, mais comme je voulais faire un exemple exhaustif des contenus rencontrés dans une cible, le voici.

Dans le cadre de cette évaluation, les agents suivants sont considérés :

• Les lecteurs malveillants souhaitant détourner l’usage de l’application,
• Les rédacteurs malveillants souhaitant également détourner l’usage de l’application.

Comme abordé dans les hypothèses, les administrateurs systèmes et réseaux sont considérés comme de confiance.

Certaines cibles peuvent introduire également des « mauvaises manipulations » ou autres accidents involontaires. Ça n’a de sens que si l’agent en question n’est pas considéré comme malveillant (e.g. nos gentils administrateurs). Si l’agent peut être malveillant, ajouter des erreurs involontaire n’apportera rien.

Scénarios d’attaque

Un scénario d’attaque n’a pas besoin d’être très élaboré. Pour être caractérisé, il doit simplement mentionner l’acteur, l’action et le bien impacté.

Pour les plus techniques d’entre vous, chers lecteurs, on ne parle pas ici de vulnérabilités (e.g. injections de commandes). La différence est simple : un scénario se concrétise par l’exploitation d’une vulnérabilité. Donc on va plutôt lister ce que l’attaquant voudrait faire sans s’attacher à dire comment il le ferait pour de vrai, et ce pour (entre autres) les deux raisons suivantes :

1. On envisage tous les moyens pour arriver au même but, on ne se restreint pas à certaines vulnérabilités particulières.
2. On laisse ainsi plus de liberté à l’évaluateur lorsqu’il testera la conformité et la robustesse des mécanismes de protection du produit.

Vous pouvez quand même lister les vulnérabilités pour vous (i.e. TOP 10 OWASP) et voir si elles rentrent dans les scénarios, sinon, vous pourrez rajouter des menaces.

Les scénarios d’attaques suivant ont été retenus :

• M1 - Modification frauduleuse Un attaquant parvient à modifier le contenu d’un article d’un autre rédacteur.
• M2 - Exécution sur le navigateur Un attaquant parvient à envoyer du code et le faire exécuter sur le poste du visiteur.
• M3 - Suppression frauduleuse Un attaquant parvient à supprimer les données (articles et comptes rédacteurs)
• M4 - Usurpation d’identité Un attaquant parvient à usurper l’identité d’un rédacteur et publie des articles en son nom.
• M5 - Vol de mot de passe Un attaquant parvient à lire le mot de passe d’un rédacteur.
• M6 - Vol d’un compte Un attaquant parvient à modifier le mot de passe d’un rédacteur.
• M7 - Accès Frauduleux aux fichiers Un attaquant obtient un accès en lecture aux système de fichier et aux fichiers de configuration.
• M8 - Modification des fichiers Un attaquant parvient à modifier le code source et les fichiers de l’application.
• M9 - Exécution sur le serveur Un attaquant détourne l’application pour lui faire exécuter du code arbitraire, il obtient ainsi un contrôle sur le serveur et les fichiers qui s’y trouvent.

Couverture des biens par les menaces

Il s’agit ici encore d’un tableau de synthèse, facultatif donc indispensable, mettant en relation les biens sensibles à protéger et les menaces qui pèsent sur eux.

Le tableau suivant synthétise la couverture des biens (dont on reprendra le numéro suivi de la lettre de la propriété de sécurité) par les menaces.

J’affectionne beaucoup ces types de tableaux car ils permettent un contrôle qualité facile, rapide et plutôt efficace quand à la cohérence de la cible en répondant aux deux questions essentielles :

1. Tout les biens sont couverts, chaque colonne a bien une coche. Si un bien n’en a pas, vous avez deux solutions : ajouter une menace (si ce bien est essentiel, vous pouvez dire pourquoi), supprimer la propriété sur ce bien (après tout, elle n’est peut être pas importante).
2. Toutes les menaces ont un sens, chaque ligne a bien une coche. Si une menace n’en a pas, vous avez deux solutions : ajouter un bien ou une propriété (si la menace vous paraît importante, vous pouvez l’expliquer) ou supprimer la menace (elle porte sur quelque chose qui n’est pas important).

Fonctions de sécurité

Les fonctions de sécurité regroupent tous les mécanismes mis en place par le produit pour protéger les biens contre les menaces identifiées. C’est en quelque sorte la conclusion de notre mini analyse de risque et l’implémentation de la sécurité.

Liste des fonctions

• F1 - Authentification : Les utilisateurs sont identifiés par leur pseudonyme et authentifié par un mot de passe, connu d’eux seuls.
• F2 - Contrôle d’accès : L’accès aux fonctionnalités de l’application, en particulier la suppression d’un article, est restreinte aux seuls utilisateurs authentifiés et autorisés (e.g. seul l’auteur d’un article peut le supprimer).
• F3 - Stockage : des mots de passes Le stockage des mots de passes en base de donnée fait appel à un procédé cryptographique sûr.
• F4 - Filtrage des entrées : les données reçues par l’application font l’objet d’un filtrage pour éviter toute injection et/ou détournement de l’application.

Couverture des menaces par les fonctions

L’ANSSI impose de faire le lien entre les fonctions de sécurité et les menaces qu’elles évitent. On peu le faire directement lorsqu’on liste les menaces mais c’est généralement plus ergonomique avec une matrice de couverture.

Comme précédemment, ce tableau nous permet d’effectuer notre contrôle qualité sur la cohérence de la cible en répondant aux deux nouvelles questions essentielles :

Toutes les menaces sont couvertes s’il y a un une coche dans chaque colonne, sinon, vous avez deux solutions : 1. La menace est importante et vous pouvez l’argumenter. Votre produit devrait donc avoir des mécanismes pour la contrer que vous pouvez lister. 2. La menace n’est pas jugée suffisante pour nécessiter une défense spécifique, il faut alors enlever la menace. Notez que la couverture des biens par les menaces va donc changer et il faudra peut-être adapter les biens aussi.

Toutes les fonctions ont un sens s’il y a une coche dans chaque ligne. Sinon, vous avez deux solutions : 1. La fonction vous paraît pourtant importante. Vous êtes donc capable d’expliquer pourquoi, entre autre en identifiant le problème qu’elle résout, voilà donc votre menace. Notez que l’ajout d’une menace va modifier la couverture des biens par les menaces. 2. La fonction vous paraît superflue, dans ce cas, vous pouvez l’enlever.

Pour revenir à la propriété de « disponibilité » qui n’a pas été retenue tout à l’heure, vous pouvez maintenant comprendre le raisonnement :

1. Si on retient la disponibilité, il faut une menace, c’est assez facile, un attaquant lance un déni de service sur l’application.
2. Si on retient cette menace, il faut une fonction de sécurité… on peut imaginer une redondance des serveurs d’applications, du CDN, et tout un tas d’autres choses du genre.
3. On se rend compte que ces fonctions ne sont pas implémentées dans le produit (c’est une application PHP clé en main) et sortent de toutes façons du cadre du produit.
4. La fonction étant absente, on supprime la menace, et donc la propriété de sécurité.

Mécanismes cryptographiques

Cette section est « obligatoire » pour tous les produits mettant en œuvre des procédés cryptographiques. En réalité, certaines cibles font plutôt référence à un autre document spécifique en annexe. Pour les autres, qui contiennent cette section, la forme est plutôt libre.

Je vous proposes ici une structure directement inspirée des critères officiels pour la certification CSPN, meilleure manière de ne rien oublier.

Algorithmes

Le but est ici de lister les fonctions cryptologiques offertes par le produit ainsi que les références vers les algorithmes utilisés. La justification est simple, l’ANSSI peut refuser une cible (et la certification du produit) si les algorithmes sont « fait maison » ou impropre à l’usage prévu par le produit (et on peut les comprendre).

Le stockage des mots de passes fait intervenir le procédé cryptographique suivant :

• Stockage des mots de passes : utilisation du chiffrement de Vernam.

Cette méthode n’est pas conforme aux bonnes pratiques car on lui préfère généralement des fonctions à sens unique. La certification de notre blog serait donc refusée dès lecture de sa cible (pour une bonne raison) mais j’ai gardé cet algorithme car il me permet de compléter les sections suivantes.

Gestion des clés

La cryptographie moderne repose en grande partie sur la sécurité des clés utilisées et il est donc nécessaire de porter une attention particulière à leur gestion : taille, distribution, génération, conservation et transmission.

Chiffrement de Vernam : Le stockage de chaque mot de passe fait intervenir une clé unique, de la même taille que le mot de passe et générée aléatoirement. Celles-ci sont stockées dans des fichiers de configuration protégés. Elle n’est ni distribuée ni transmise.

Ceux ayant lu le code source ont vu que tout ceci n’est pas implémenté. Mais si j’avais écrit la vérité, cette cible n’aurait pas passé les filtres de l’ANSSI car c’est bien trop grossier. J’ai donc documenté quelque chose de « plus propres » et ce sera le travail des évaluateurs de montrer que le produit n’est pas conforme.

Traitement des données

Cette section a pour but de renseigner l’ANSSI et les évaluateurs sur les traitements additionnels sur les données qui font l’objet d’un procédé cryptographique, avant et après le traitement (compression, encodage, en-têtes).

Stockage des mots de passe : Avant l’application du procédé cryptographique, les mots de passes sont salés par l’ajout d’un préfixe généré aléatoirement.

Idem, ça n’est pas vrai, mais c’est pour l’exemple… Ce serait moins intéressant si toutes les sections étaient « sans objet ».

Générateur de nombres aléatoires

Cette section a pour but de rassurer sur la génération des nombres aléatoire, en décrivant les méthodes utilisées et montrant que cette génération est efficace.

Générateur aléatoire système L’application utilise les générateurs de nombres aléatoires cryptographiques fourni par le système et considérés comme sûrs.

De cette manière, je n’ai pas besoin de m’étendre sur son fonctionnement. En fait, cette section est surtout utile lorsque vous utilisez votre propre générateur de nombres aléatoires (c’est parfois justifié pour certains produits).

Et après ?

Avec cette cible, vous avez maintenant formellement établi à quoi sert votre produit, quels sont les biens que vous considéré important (et de quelle manière), contre quoi vous les protégez et comment vous le faites. La cible fera sûrement un aller-retour avec l’ANSSI qui s’assurera de sa cohérence avant de la valider, mais vous avez l’idée.

Le produit pourra alors entrer dans sa phase d’évaluation. Dont le but sera de vérifier que le produit est conforme aux prétentions de la cible (les fonctions sont présentes et résistantes aux attaques). Ce n’est qu’à l’issue de cette évaluation que l’ANSSI vous certifiera le produit (ou pas).

En attendant le Rapport Technique d’évaluation qui viendra compléter cette exemple, vous pouvez toujours allez voir le code du blog…