• Aucun résultat trouvé

Outils et critères méthodologiques

Évaluation d’un produit anti-virus

8.2.1 Outils et critères méthodologiques

La première chose à faire lorsque l’on cherche à comparer des produits consiste à définir clairement notre cible, au niveau de la catégorie de produit et des caractéristiques de son environnement. Nous avons adopté le même périmètre que celui défini par le profil de protection : US Government Protection Profile Anti-Virus Applications for Workstations in Basic Robustness Environments [CCE05]2.

UnProfil de Protectionest une spécification des exigences d’assurance sur l’information indépendante des spécifi- cation. Les Profils de Protection sont une combinaison complète d’objectifs de sécurité, d’exigences fonctionnelles relatives à la sécurité, d’exigences d’assurance sur l’information, d’hypothèses et d’éléments de preuve. Les Profils de Protection sont rédigés en conformité avec le standard des Critères Communs. Dans le schéma d’évaluation des Cri- tères Communs [Her03], un Profil de Protection est prévu pour permettre à un constructeur de logiciel de concevoir un produit qui pourra être évalué par un laboratoire d’évaluation indépendant. Les analystes de sécurité effectuent des tests et évaluent la couverture des exigences de sécurité. Plusieurs acteurs peuvent prendre part au processus d’évaluation : analystes de sécurité, développeurs du produit antivirus cible, une tierce partie, chargée d’arbitrer et de contrôler le processus. Par exemple, en France, cette tierce partie est une organisation gouvernementale qui dépend des services du premier ministre. Le laboratoire d’évaluation doit en outre être agréé par cette tierce partie. Ce Profil de Protection [CCE05] spécifie les exigences de sécurité minimum pour un produit antivirus utilisé sur des stations de travail du gouvernement US pour un environnement de niveau de robustesse basique. Le niveau de robustesse de la cible d’évaluation (i.e. dans quelle mesure la cible d’évaluation peut se protéger elle-même ainsi que ses ressources) de robustesse basique est considéré comme suffisant lorsque l’environnement correspond à un faible niveau de menace ou lorsque la compromission de l’information protégée n’aura pas un impact significatif sur les objectifs de mission. Ce point est discuté en détail dans [CCE05]. Ce profil de protection est basé sur les Critères Communs, version 2.2. La figure8.1représente la cible d’évaluation et son environnement.

Nous avons utilisé ce profil de protection et les critères communs comme base (méthode et terminologie) pour nos analyses. Par exemple, dans cette terminologie, le terme virus est utilisé de manière générique pour désigner une suite d’exploits de vulnérabilités de sécurité, comme c’est le cas d’un ver ou d’un cheval de Troie. Le même terme

2Ce profil de protection a été mis à jour en 2006 [CCE06], puis en 2007 [CCE07], principalement pour des raisons de compatibilité

Fig. 8.1 – Cible d’évaluation et son environnement

est utilisé plus spécifiquement pour désigner les exploits qui se répliquent eux mêmes. Le terme antivirus désigne typiquement les mesures utilisées pour contrer la suite entière d’exploits, pas seulement la définition plus spécifique de la notion de virus.

L’idée consiste à s’appuyer sur cette cible de sécurité générique pour définir une stratégie de test permettant à l’évaluateur de mener à bien ses tâches :

– analyse des fournitures et des éléments de preuve fournis par le développeur (les fournitures comprennent notamment les différents guides et les documents de spécification et de conception de l’application, parfois le code source) ;

– validation de la démarche de test du développeur (repasser les tests et statuer sur la couverture des tests du développeur) ;

– analyse de conformité des fonctions de sécurité (c’est-à-dire vérifier que les fonctions de sécurité se comportent suivant leurs spécifications, en spécifiant des tests complémentaires de conformité) ;

– analyse indépendante de vulnérabilité (spécification de tests de pénétration, visant à mettre en oeuvre des menaces ou à enfreindre des règles de la politique de sécurité en exploitant des vulnérabilités).

Cette dernière étape est cruciale, puisqu’elle doit permettre de confirmer ou d’infirmer, par une estimation in- dépendante, le potentiel minimum d’attaque nécessaire pour mettre en oeuvre les attaques, tel que l’a estimé le développeur.

En résumé, l’utilisation d’un profil de protection, c’est à dire d’une spécification de besoin de sécurité générique à la catégorie des produits anti-virus (la cible de sécurité constituant le point d’entrée de toute évaluation selon les critères communs) va nous servir de base à l’élaboration d’une stratégie de test. Sur la base du résultat de ces tests, il est possible de mener les différentes tâches d’une évaluation selon les critères communs. Je pense que ce jeu de test peut permettre également à un particulier mener une analyse indépendante de vulnérabilité, la plupart des tests étant menés en boite noire.

Les autres tâches d’évaluation nécessitent des informations sur les spécifications ou la conception du produit qui ne sont généralement pas fournies à l’utilisateur final.

Remarquons que depuis la publication de ce chapitre dans les actes de la conférence EICAR [Jos06a], une seule évaluation de produit anti-virus (il s’agit du produit McAfee VirusScan [McA07,CAF07]) a été menée en conformité avec ce profil de protection (version 1.1, [CCE06]).

Le rapport de Certification Sécurité de Premier Niveau (CSPN) émis par la DCSSI fournit aux commanditaires un document leur permettant d’attester du niveau de sécurité offert par le produit dans les conditions d’utilisation ou d’exploitation définies dans ce rapport pour la version qui a été évaluée. Il est destiné également à fournir à

l’acquéreur potentiel du produit les conditions dans lesquelles il pourra exploiter ou utiliser le produit de manière à se trouver dans les conditions d’utilisation pour lesquelles le produit a été évalué et certifié.

Ce rapport de certification est destiné à être lu conjointement aux guides d’utilisation et d’administration évalués ainsi qu’à la cible de sécurité du produit qui décrit les menaces, les hypothèses sur l’environnement et les conditions d’emploi présupposées afin que l’utilisateur puisse juger de l’adéquation du produit à son besoin en termes d’objec- tifs de sécurité.

Il valide les travaux d’évaluation menés par un centre d’évaluation agréé, dans un temps et une charge contraints (une vingtaine d’homme/jour), comprenant notamment :

– une analyse de conformité du produit à la cible de sécurité ;

– une description de l’installation, des options d’installation retenues pour le produit et des non-conformités éventuelles vis-à-vis de la documentation ;

– une analyse de la conformité des fournitures (analyse de la documentation, éventuellement revue du code source) et des fonctionnalités du produit ;

– une analyse de la résistance des mécanismes et des fonctions ; – une analyse des vulnérabilités (conception, construction, etc.) ;

– une analyse de la facilité d’emploi (cas où la sécurité est ambiguë) et préconisations, recommandations pour une utilisation sûre du produit ;

– une analyse de la résistance des mécanismes cryptographiques et du générateur d’aléas.

Je pense que la stratégie de test présentée dans la suite de ce chapitre permet d’accélerer sensiblement la réalisation des tâches d’une évaluation CSPN d’un produit anti-virus.

La CSPN a été mise en oeuvre à titre expérimentale sur l’année 2008. La documentation décrivant ce proces- sus est donc suceptible d’évoluer au fur et à mesure de la prise en compte des retours d’expérience. Le premier produit certifié au titre de la CSPN n’est pas un produit anti-virus (il s’agit de l’hyperviseur de machines virtuelles Trango Hypervisor).