Utilisateur:Thierry Petrilli/Brouillon

Les Critères Communs 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. Egalement dénommés Common Criteria, ce référentiel est né d'un partenariat entre le Canada, les Etats Unis et l'Europe. Grace au cadre offert, les utilisateurs de technologies de l’informations vont pouvoir utiliser des profiles 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èes Communs décidée par les signataires d’un accord de reconnaissance mutuelle, facilite grandement l’acceptance des certificats émis. Bien que présentant de nombreux avantages, l’application de cette norme s’avère couteuse , 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

Liste des pays signataires ou reconnaissants l'accord CC-MRA

En 1985 le NIST et la NSA publient l'Orange Book. Le but de ce document était d'évaluer la capacité d'un system à se défendre contre des attacks .

Dans le même temps l'Europe s'inspire des TCSEC pour définir en 1991 ces propres critères d'évaluation les ITSEC. Ils vont combler des lacunes en terme d'analyse des risques .

En 1993, le Canada définit sa propre norme CTCPEC.

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-IS qui fait foi.

En 1999, l'ISO 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-MRA en mai 2000. En plus des 17 pays signataires, 9 pays non signataires reconnaissent ces certificats.

Concepts Généraux

Audience visée

Les besoins des utilisateurs en terme de sécurité sont des besoins de disponibilité, de confidentialité et d'authenticité des informations personnelles. Les critères communs s'adressent à trois cathégories d'utilisateurs :

Les utilisateurs finaux

Les utilisateurs finaux vont pouvoir déterminer si un produit répond à leur besoins en consultant le résultat de l'évaluation.

Les dévelopeurs

Les développeurs se servent des CC pour identifier les éxigences de sécurité auxquelles doivent 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 3 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 uitilisés. A ce titre les 3 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 TSF ». 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 famille et classe.

Exigences d'assurance de sécurité

Ce document recense les éxigences pour le développeur et les taches à 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 11 classes couvrant chacune un domaine. Chaque classe est découpée en familles. Chaque famille contient un ensemble de composants qui constitut une exigence de sécurité. Chaque classe est désignée par un nom unique dont l'abréviation est constituée de 3 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é:

« Auditer la sécurité implique la reconnaissance, l'enregistrement, le stockage et l'analyde d'informations associées à des activités touchant à la 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.

Certification Detection faux doigt : paquet d'exigences fonctionnellles

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 idéntifier l'utilsateur, l'authentifier et gérer ces droits d'accès.

Classe administration de la sécurité FMT

Elle permet entre autre 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 prtotection 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 apparaitre comme une duplication de la classe FDP.

Classe utilisation des ressources FRU

Trois familles d'exigences concernant la disponibilté 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 controler l'établissement d'une connexion de l'utilisateur. Par exemple controler 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' utilsateur et la technologie de l'information mais également entre TI.

Le dévelopeur va pouvoir définir un paquet de composants à partir de cette liste suivant les fonctionnalités de son produit. Cette liste n'étant pas exaustive, 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ée la famille SPOD à la classe FPT. Pour la certification de ce produit, SAFRAN a également retenu des composants des familles suivantes :

• Generationde l'audit de sécurité FAU_GEN
• Protection des Informations Rediduelles 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 en terme de 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. Quand à l'évaluateur, il va pouvoir identifier les tâches à réaliser pour conduire à une certification.

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 classe est effectué avec trois caractères Axx : A désignant assurance suivi de deux lettres pour identifer le domaine couvert.

Liste des exigences d'assurance de sécurité

Classe	Domaine couvert	But
ADV	Développement	définit les exigences d'assurance à prendre en compte depuis les spécifications de la TOE jusqu'à son implémentation.
ACO	Composition	composée de 5 familles dont le but est de s'assurer que la cible de l'évaluation respectera la sécurité lorsqu'elle inter agira avec les fonctionnalités de sécurité fournies par les logiciels ou les composants matériels déjà évalués.
AGD	Documentation	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.
ALC	Cycle de Vie	traite des éxigences 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.
APE	Evaluation Profile de protection	doit s'assurer que le profile de protection est complet.
ASE	Evaluation de la cible de sécurité	démontrer que l'évaluation de la cible de sécurité est saine techniquement.
ATE	Tests	s'assurer que les tests sont suffisamment détaillés et complets.
AVA	Estimation des Vulnérabilités	traite des éxigences associées à l'identification de vulnérabilité pendant les phases de développement, configuration et exploitation.

Niveaux d'assurance EAL

Tout certificat émis suite à l'évaluation selon les critères communs garantit que le Système d'Information évalué respecte un certain niveau d'assurance. Celui ci équivaut à une note allant de EAL1 à EAL7. Ces niveaux sont associés à un paquet minimum d'éxigences d'assurance. Il existe 7 niveaux hiérarchiques qui vont déterminer le degré de confiance accordé au produit évalué. Chaque niveau contient les éxigences du niveau précédent. Ils reflètent un équilibre entre le niveau d'assurance obtenu et le coût pour parvenir à ce niveau.

Niveau 1

le moins couteux et ne necessite pas la participation du développeur. Il permet d'affirmer que la cible de l'évaluation fonctionne conformément à ce qui est décrit dans la documentation. Seule les menaces identifiées dans le domaine public sont couvertes.

Pourcentage Produits certifiés par niveau d'assurance

Niveau 2

nécessite la participation du développeur pour communiquer des informations sur la spécification et les résultats des tests réalisés.

Niveau 3

atteste d'une recherche de vulnérabilités évidentes.

Niveau 4

représente un bon compromis entre sécurité et coûts. Il ne nécessite pas de connaissances ou d'expertise spécialisée. Il répond à une vulnérailité relative à dse attaques élémentaires.

Niveau 5

atteste d'une analyse des fonctions de sécurité. Cette analyse s'appuie sur les spécifications fonstionnelles, les spcésifications complètes des interfaces, les guides et la conception de la TOE.

Niveau 6

destiné à des développement de TOE dans le cadre d' environnements à risques élevés.

Niveau 7

niveau maximum à ce jour. Il nécessite une présentation formelle des spécifications fonctionnelles et un niveau élevé des spécifications.

Profils de Protection

Un profil de protection définit un ensemble d'exigences de sécurité pour une catégorie de produits sans tenir compte de l'implémentation. Ainsi, un client doit être en mesure d'utiliser un profil de protection pour exprimer sa politique de sécurité. L'intérêt d'un tel document est d'être réutilisable. C'est la raison pour laquelle, il doit être générique et structuré avec les chapitres suivants :

• Une introduction dans laquelle figurent une description du profil de protection et une vue d'ensemble suffisamment détaillée.
• Une description du contexte de l'évaluation.
• L'environnement d'utilisation comprenant entre autre les aspects physiques et humains. La politique de sécurité organisationnelles doit être décrite ainsi que les menaces auxquelles la cible d'évaluation sera confrontée.
• Les objectifs de sécurité doivent être le reflet de l’état souhaité pour contrer les vulnérabilités identifiées.
• Les exigences fonctionnelles et d'assurance de sécurité. Des packages prédefinis peuvent être utilisés.

Mise en oeuvre

Organisation

Seuls les pays signataires de l'accord de reconnaissance mutuelle selon les critères communs sont authorisés à émettre des certificats. Ceux sont égalemnt eux qui vont accepter qu'un nouveau membre les rejoigne. Ainsi l'Inde est devenu le 17éme pays signataire en 2013.

Pour être impartiale, l'évaluation d'un produit informatique doit être réalisée par une entité indépendante. Les laboratoires chargés des évaluations sont accrédités par les organismes gouvernementaux représentant les pays signataires de l'accord CCMRA.

Ainsi :

Aux Etats Unis

La NSA pilote le programme gouvernemental NIAP en charge des besoins de sécurité des clients et concepteurs de technologies de l'information. Elle accrédite les laboratoires d'expertises dénommés CCTLs et valide les résultats de l'évaluation en délivrant ou non le certificat final.

En France

Par décret, l' agence nationale des systèmes d'information ANSSI est nommée autorité de certification. Cette agence a deux rôles:

• responsable de l'agrément des centres d'évaluatuin en sécurité et Technologies CESTI qui ont en charge l'évaluation.
• responsable de la délivrance ou non du certificat de validation.

Organisation gouvernementales par pays signataire

Pays	Organisation Gouvernementale
Australie	Australian Signals Directorate ASD
Canada	Canadian Common Criteria Evaluation and Certification Scheme CECS
France	Agence Nationale de la Sécurité des Systèmes d'Information ANSSI
Allemagne	Bundesamt für Sicherheit in der Informationstechnik BSDI
Inde	Indian Common Criteria Certification Scheme IC3S
Italie	Organismo di Certificazione della Sicurezza Informatica OCSI
Japon	Japan IT Security Evaluation and Certification Scheme JISEC
Malaisie	CyberSecurity Malaysia
Pays Bas	NSCIB operated by
Nouvelle Zélande	Defence Signals Directorate
Norvège	SERTIT
République de Corée	IT Security Certification Center(ITSCC)
Espagne	Organismo de Certificación de la Seguridad de las Tecnologías de la Información
Suède	Swedish Certification Body for IT Security FMV/CSEC
Turquie	Turkish Standards Institution Common Criteria Certification Scheme TSE
Angleterre	UK IT Security Evaluation and Certification Scheme
Etats Unis	National Information Assurance Partnership NIAP

Etapes de la certification

La certification se déroule en 3 etapes.:

Cerficats émis par domaine

Demande d'évaluation

Le commanditaire fait une demande d'évaluation auprès de son organisme gouvernemantal en charge des certifications. Il incombe à l'entreprise:

• d'établir la liste d'éxigence de sécurité de son produit. Cette liste est établie dès l'étude de conception . Son contenu est fonction du périmètre fonctionnel du produit.
• d'établir la liste des exigences d'assurance liée à la qualité du produit.
• de fournir une description détaillée des composants du produit qui seront soumis à l'évaluation
• de fournir un document décrivant la cible d'évaluation, son environnement de fonctionnement et les menaces auxquelles elle devra répondre.

Evaluation

L'évaluateur peut intervenir tout au long de la conception du produit. Il va devoir vérifier la pertinence du cahier de tests et le résultat de ces tests qui sont déroulés par le commanditaire. Il émet ensuite un rapport d'évaluation technique RTE validant le niveau d'assurance atteint.

Certification

L'autorité en charge de le certification va s'appuyer sur le rapport d'évaluation technique pour émettre ou non le certificat d'évaluation selon les critères communs.

Retour d'expérience et usage

Les bénéfices, avantages, intérêts

Diminution des risques avec maitrise des couts

Selon Mellado et Taguchi la mise en œuvre de la stratégie de sécurité dans les premières phases du processus de développement, est rentable. Celle-ci engendre un système plus robuste en réduisant les vulnérabilités de sécurité qui peuvent être trouvés dans les étapes ultérieures du développement. Lloyd mentionne, que pour la fabrication et la commercialisation des COTS , la hausse des couts et les contraintes de délai, obligent, de nombreuses organisations et le gouvernement US, à intégrer les problèmes de sécurité dans leur développement d'application. Kallberg affirme, que la reconnaissance mutuelle de la norme, permet théoriquement d'économiser du temps et de l'argent en supprimant des assurances redondantes.

Confiance des utilisateurs

Pour Mellado, de nombreux utilisateurs des SI n'ont pas les connaissances et les ressources pour qualifier le niveau de sécurité des systèmes. L'utilisation des CC, comme base d'évaluation de la sécurité, donne confiance aux utilisateurs. Selon Sauveron, la certification permet aux clients de comparer les différents produits sur le marché d'une manière objective.

Avantage concurrentiel des fabricants

Sauveron indique que la certification est obligatoire sur certains marchés (banques par ex). Le fabricant a donc accès à des marchés fermés ou spécialisés. Les fabricants peuvent utiliser la certification comme argument marketing et ainsi d'élargir leur marché.

Maitrise des risques d'attaques nationale

Pour Sauveron, la certification permet aux organismes de certification gouvernementaux, de s'assurer que les produits utilisés dans leurs pays sont maitrisés. Et que, par conséquent, il n'y a pas de risque majeur d'attaques contre leurs systèmes informatiques.

Les contraintes, inconvénient, les freins

Mauvaise mise en œuvre

Selon Mellado et Razzazi, dans la majorité des projets logiciels, la sécurité est traitée quand les systèmes sont déjà conçus et mise en service. Très souvent, la spécification des exigences de sécurité est trop succincte. Les consommateurs ne sont pas en mesure d'indiquer clairement et sans ambiguïté les exigences de sécurité du produit. Les exigences de sécurité sont souvent mal comprises. La gestion des exigences en matière de sécurité est une question complexe pour les développeurs. De nombreux développeurs ont tendance à décrire des solutions de conception en termes de mécanismes de protection, au lieu de faire des propositions déclaratives concernant le niveau de protection requis.

Difficile et couteux

Pour Razzazi, les CC laissent trop de place à des ambiguïtés et il est souvent difficile de comprendre précisément la signification des exigences de sécurité. Shoichi indique que les critères de la CC sont très abstraits, il est impossible d'avoir un aperçu global. Il est difficile de définir entièrement les exigences à partir de zéro. Selon Keblawi, l'expérience montre que les normes prescrites sont inflexibles et ne tiennent pas compte des considérations du monde réel. Pour Taguchi, les méthodes sont très complexes en termes de sémantique, et par conséquent, le coût de l'apprentissage est très élevé. Pour Preschern, la certification impose une rigueur dans les processus de développement et de maintenance. De nos jours, la certification prend une grande partie des coûts de développement de produits . Hearn indique, que pour les systèmes utilisant des COTS, l'intégration du système et de la composition de la sécurité sont des problèmes difficiles. Car ils dépendent de principes d'ingénierie de sécurité des COTS utilisés et de leur fonctionnement avec d'autres éléments. Ce travail augmentant ainsi les coûts et les délais de livraison.

Complexe, pour des experts

Selon Ware, les CC sont difficiles à comprendre pour des personnes non spécialistes de la sécurité. Keblawi affirme, que bien que le domaine de la sécurité a des méthodes d'analyse, telles que la planification de la sécurité et des analyses de risque, ils n'ont jamais été conceptualisés dans un processus de développement. Pour Taguchi, un autre point crucial qui manque dans les méthodologies existantes est qu'il n'y a pas de norme sur la façon de documenter, de manière concise et systématique, les propriétés de sécurité de systèmes d'information, dans le processus de développement du système. Selon Shoichi, sans mécanisme d'évaluation, le processus est long et coûteux, car difficilement accessible à des vérificateurs qui ne sont pas des mathématiciens ou familiarisés avec les méthodes formelles. Selon Lloyd, la spécification des exigences de sécurité est difficile parce que les exigences englobent à la fois les aspects fonctionnels et non-fonctionnels et de nombreux développeurs peuvent ne pas être familiers avec l'ensemble des questions de sécurité qui doivent être traitées.

Ne s'applique pas toujours simplement

Selon Razzazi, les systèmes actuels n'ont pas la base technologique nécessaire pour répondre aux nouveaux besoins en matière de sécurité informatique. Keblawi indique, que certains systèmes ne correspondent pas facilement aux concepts de sécurité des Critères communs. Pour Lloyd, toutes les exigences des CC ne peuvent pas être directement applicables à des composants individuels de COTS en raison de leur périmètre fonctionnel plus petit par rapport aux systèmes informatiques.

Vision de l'industrie et des consommateurs

Selon Ware, les niveaux de protection de CC sont rarement utilisés dans la pratique. Pour Taguchi, les CC ne sont pas facilement applicables dans l'industrie en raison de l'inadéquation entre un processus de développement de logiciel existant et les méthodologies des CC. Hearn indique que les vendeurs ne voient pas les CC comme un processus d'amélioration du produit. Le rapport coût-bénéfice, qu'une utilisation des CC peut avoir sur un système informatique, est impossible à évaluer. Pour Isa, de nombreux chercheurs et des représentants de l'industrie, indiquent, que la pratique des CC, dans un monde en évolution rapide, ne peut exister, que dans le contexte « utopique » des CC . Selon Kallberg, avec la croissance de la guerre industrielle, il est peu probable que les CC atteignent une masse critique en tant que plate-forme mondiale de certification. Selon Hearn, les acheteurs voient les certifications comme un critère mineur de l'approvisionnement. Ils lisent rarement la cible de sécurité ou de certification, et ce qui a fait l'objet de l'évaluation. Le consommateur n'est pas concerné par les processus de CC, dans lequel le concept de sécurité et le modèle de menace est trop vague pour être utile.

Confiance gouvernementale

Selon Hearn, certains obstacles concernent les préoccupations au sujet de l'harmonisation des évaluations entre les pays. Les conflits entre l'harmonisation internationale et des investissements nationaux pourraient être particulièrement important si les principaux pays européens et les États-Unis continuent à suivre des voies divergentes de plus en plus dans la poursuite des intérêts nationaux. Même si les pays membres fondateurs étaient capables de travailler à une harmonisation, l'expérience montre que la mise en application de points de détails divergent. Pour Isa, il y a un manque d'intérêt des acheteurs et des vendeurs, car les CC viennent des gouvernements et augmente les prix de mise en œuvre. Hearn indique que l'interêt commercial est faible, car les certifications résultent de la réglementation gouvernementale ou de l'achat du gouvernement.

Méthodes d'utilisation

méthodes basées sur les diagrammes de cas

La méthode proposée par Taguchi, est basée sur un diagramme de cas d'utilisation. Elle possède son propre processus de modélisation, qui se décompose en 3 éléments:

• Le diagramme est une extension de diagrammes de cas d'utilisation
• Les éléments du modèle qui sont extraites d'un méta-modèle de la CC
• Les modèles de sécurité qui sont ajoutés selon les contraintes de sécurité à chaque étape

Meta Modèle Taguchi en PNG

Meta Modèle Taguchi

Cette méthode utilise un méta modèle dérivé de la CC, qui fait partie de la fonctionnalité de sécurité de la TOE. Les concepts des CC suivants sont maintenus:

• Les agents de menace
• Les actifs
• Les fonctions de sécurité
• Les exigences fonctionnelles de sécurité
• Les objectifs de sécurité de l'environnement opérationnel
• Les hypothèses.

L'auteur, fait le choix d'enlever de son méta modèle, les concepts des CC suivants:

• La TOE. Celle-ci est implicitement comprise dans le modèle de sécurité
• La politiques de sécurité organisationnelle. De nombreux organismes établissent aujourd'hui leurs propres politiques de sécurité organisationnelles pour prévenir les violations de sécurité des données hautement confidentielles sur leurs activités

Un diagramme prototype est proposé en 3 phases:

• Phase1, Exigences de sécurité de base: Analyse des fonctions de sécurité et des menaces de sécurité de façon abstraite
• Phase 2, Exigences et objectif de sécurité: à partir du résultat de la phase1, on analyse en détail des exigences de sécurité pour en définir des objectifs de sécurité
• Phase 3, Sélection des exigences fonctionnelles de sécurité : Dans cette phase, on sélectionne les exigences fonctionnelles de sécurité, qui répondent aux objectifs de sécurité identifiés dans la phase précédente. Ce travail est réalisé à partir de la norme des CC partie 2 et PP. Puis on aligne, les exigences de sécurité aux exigences d'assurance en vertu de la méthodologie de CC.

La méthode proposée par Ware consiste à utiliser les profils d'acteurs pour tirer les menaces de sécurité. Puis faire la cartographie des menaces et des objectifs de sécurité. Et enfin, réaliser la cartographie des objectives sécurités et des exigences de sécurité. La cartographie est réalisée à l'aide d'une boite à outils qui contient une liste des menaces, les objectifs et les exigences fonctionnelles des CC. Pour mettre en œuvre cette approche, un outil de modélisation graphique open source UML, est proposé.

écran: table des menaces en PNG

ecran: table des menaces

L'outil montre clairement, dans sa "table des menaces", les objectifs nécessaires pour contrer une menace spécifique et les exigences nécessaires pour satisfaire un objectif spécifique.

Puis l'outil propose à l'utilisateur de générer un fichier de sortie dans un format HTML. L'outil propose 2 styles de rapport possibles:

• Une option générale, qui génère un modèle de cas d'utilisation avec le champ de menaces contenant une liste des menaces associées à chaque acteur. Chaque menace a une liste imbriquée des exigences de sécurité qui sont nécessaires pour satisfaire les objectifs.
• Une option 'principe CC', qui génère une double cartographie, menaces / objectifs et composants fonctionnelles de sécurité / objectifs.

Le rapport 'principe CC', vise à produire la partie de la justification d'une cible de sécurité de la TOE. En outre, les correspondances montrent clairement les objectifs nécessaires pour contrer une menace spécifique et les exigences nécessaires pour satisfaire un objectif spécifique.

Autres approches

La méthode proposée par Vetterling, est un processus qui combine le développement de logiciels 'orienté phase' avec les activités requises par les CC. Le principe est d'intégrer les activités des CC dans les phases de développement du projet. Cette méthode est basée sur un processus itératif dans chaque phase du projet. A la fin de chaque itération, le résultat peut être évalué. L'itération suivante recommence avec le résultat de la phase précédente, avec l'ajout de nouvelles exigences.

Intégration des exigences des CC dans le process SI en PNG

Intégrationn des exigences des CC dans le process SI

Dans la phase de planification, le plan de gestion de configuration (class ACM) est rédigé. Le manuel du cycle de vie (class ALC), est aussi rédigé en fonction du niveau d'EAL retenu. C'est dans cette phase, que doit être décidé le niveau d'EAL, et qu'elle partie du système ou produit doit être développé conformément aux CC.

Dans la phase d'analyse, la cible de sécurité (class ASE) est rédigée. C'est aussi dans cette phase que l'on commence la rédaction des premières versions du document de test (class ATE) et des guides utilisateurs (class AGD).

Dans la phase de conception, on commence la rédaction de la conception et représentation (class ADV). Son niveau de détail dépend du niveau d'EAL retenu. L'Évaluation de la vulnérabilité (class AVA) est aussi initialisée dans cette phase. Cette phase apporte des informations aux manuels utilisateurs (class AGD).

Il y a, dans la phase de développement, des éléments d'analyse de résultat de test qui vont être important pour la Documentation de test (class ATE). Pour les niveaux d'EAL les plus élevés, le document de conception et représentation (classe ADV) doit être complété avec une représentation de l'implémentation. L'Évaluation de la vulnérabilité (class AVA) et les guides utilisateurs sont finalisés dans cette phase de développement. Les documentations pour les livraisons et l'exploitation (class ADO) sont aussi rédigé dans la phase de développement.

Les documents pour les livraisons (class ADO) sont finalisés dans la phase de Déploiement et mise en exploitation.

Une étude de cas a été menée sur le développement d'une application de porte-monnaie électronique. Le projet a duré 3 mois avec une équipe de 18 membres avec une charge de 630 jours hommes.

Le premier retour d'expérience, est que les CC laissent trop de place à des ambiguïtés, il est souvent difficile de trouver la juste signification des exigences de sécurité. Des interprétations différentes des exigences des CC sont souvent possible, et font perdre un temps précieux au cours du projet.

Les CC rendent les documents interdépendants, ce qui augmente la charge documentaire. Cette charge documentaire est aussi accrue du fait que l'exigence des CC positionne des spécifications sur différents niveaux d'abstraction. Le champ d'application des exigences fonctionnelles de la CC est principalement dans le domaine des réseaux de communication et du commerce électronique. Il ne couvre pas de façon adéquaté les exigences de sécurité de la protection de la vie privée de l'utilisateur ou les exigences de juste-échange.

José Romero-Mariona, propose une approche qui fait correspondre les exigences de sécurité des CC aux éléments d'architecture et leurs connexions. La méthode propose un guide, qui est principalement basé sur les observations du processus des CC : élaboration des exigences de sécurité. Avec l'aide de ce guide les utilisateurs devraient être en mesure de cartographier ces exigences en éléments architecturaux et leurs connexions.

interface utilisateur du logiciel CCARCH en PNG

interface utilsateur ccarch

Puis, à partir de de cette cartographie, un outil va automatiser la construction d'un fichier XML après avoir Effectué une vérification de la cartographie. Les modules principaux de l'outil sont:

• Syntaxe XML: Définition du format d'entrée des autres modules de l'outil
• CCARCH v1.1.: Effectue une vérification de la cartographie
• Générateur de composants. Automatise la construction de fichier XML

Les composants des CC et leurs connexions sont définis en XML par 4 paramètres:

• Le nom du système dans son ensemble
• Un numéro d'identification unique du composant
• Le nom du composant
• La liste de tous les autres composants, avec lequel est lié ce composant

Le second module effectue une vérification de la définition réalisée par l'utilisateur et produit un digramme dans un format XDR non standard. En cas d'erreur, l'outil l'indique et fournit à l'utilisateur des informations sur ce qui est nécessaire de faire pour résoudre le problème. Le troisième module génère automatiquement un fichier de sortie au format XML. L'utilisateur peut alors ajouter de nouveaux composants. L'outil créé un nouveau fichier XML qui peut être remis en entrée du second module pour vérification.

Cible De Sécurité complétée en PNG

Cible De Sécurité complétée

Shanai Ardi propose une méthode qui consiste à compléter la cible de sécurité, en y ajoutant les vulnérabilités logicielles. La cible de sécurité traite les points suivant:

• Prise en compte des menaces issue des vulnérabilités de l'exploitation,
• Ajout, dans les menaces de sécurités, les risques de menaces possible et leurs conséquences sur les actifs.
• Identification des méthodes pour prévenir les vulnérabilités
• Ajout des Exigences fonctionnelles de sécurité des vulnérabilités
• Ajout des Relation entre les objets de sécurité et les vulnérabilités

Notes et références

Bibliographie

• (en) « Site officiel "Common Criteria" »

• (fr) « Critères Communs Part 1: Introduction et modèle general », 1999, p. 1-66

• (fr) « Critères Communs Part 2: Exigences Fonctionnelles de sécurité », 1999, p. 1-382

• (fr) « Critères Communs Part 3: Exigences d'assurance de sécurité », 1999, p. 1- 224

• (en) « Critères Communs Part 3: Exigences d'assurance de sécurité version 3 », 2012

• (en) « CCMRA Comité : Procédures », 2008, p. 1- 17

• (en) « CCMRA Certificats », 2000, p. 1- 39

• (en) « Common Methodology for Information Technology Security Evaluation », 2009, p. 1- 425

• (fr) « Décret n°2009- 834 », 2009

• (en) « CCMRA membres »

• (en) « site CCMRA stats » (consulté le 15 décembre 2013)

• (en) « Portail SOGIS » (consulté le 3 décembre 2013)

• (en) « Portail Critères communs »

• « Accord de reconnaissance mutuelle »

• (en) « MorphoSmart Optic 301 Public Security Target », 2013

• (en) « NIAP and COTS Products Evaluation »

• (fr) Marc Dacier, « Vers une évaluation quantitative de la sécurité informatique », 1994, p. 152
• (en) Mellado, D., Fernandez-Medina, E. et Piattini, M., « A comparison of the Common Criteria with proposals of information systems security requirements », Availability, Reliability and Security, 2006. ARES 2006. The First International Conference on,‎ avril 2006 (ISBN 0-7695-2567-9, DOI 10.1109/ARES.2006.2, lire en ligne)

• (en) Keblawi, F, Fed. Aviation Adm, Washington, DC et Sullivan, D., « Applying the common criteria in systems engineering », Security & Privacy, IEEE (Volume:4 , Issue: 2 ),‎ avril 2006 (ISSN 1540-7993, DOI 10.1109/MSP.2006.35)
• (en) Taguchi, K., Yoshioka, N, Tobita, T. et Kaneko, H., « Aligning Security Requirements and Security Assurance Using the Common Criteria », Secure Software Integration and Reliability Improvement (SSIRI), 2010 Fourth International Conference on, Singapore,‎ juin 2010, p. 69 - 77 (ISBN 978-1-4244-7435-6, DOI 10.1109/SSIRI.2010.30)
• (en) Romero-Mariona, J., Irvine, Ziv, H. et Richardson, D.J., « CCARCH: Architecting Common Criteria Security Requirements », Information Assurance and Security, 2007. IAS 2007. Third International Symposium on, Manchester,‎ aug. 2007, p. 349 - 356 (ISBN 978-0-7695-2876-2, DOI 10.1109/IAS.2007.30)
• (en) Razzazi, M., Jafari, M., Moradi, S. et Sharifipanah, H., « Common Criteria Security Evaluation: A Time and Cost Effective Approach », Information and Communication Technologies, 2006. ICTTA '06. 2nd (Volume:2 ), Damascus,‎ 2006, p. 3287 - 3292 (ISBN 0-7803-9521-2, DOI 10.1109/ICTTA.2006.1684943)
• (en) Isa, M.A.M., Ab Manan et R Mahmod, « Finest authorizing member of common criteria certification », Cyber Security, Cyber Warfare and Digital Forensic (CyberSec), 2012 International Conference on, Kuala Lumpur,‎ juin 2012, p. 155 - 160 (ISBN 978-1-4673-1425-1, DOI 10.1109/CyberSec.2012.6246109)
• (en) Nguyen, T.D., Levin, T.E et Irvine, C.E., « High robustness requirements in a Common Criteria protection profile », Information Assurance, 2006. IWIA 2006. Fourth IEEE International Workshop on, London,‎ avril 2006, p. 10 pp. - 78 (ISBN 0-7695-2564-4, DOI 10.1109/IWIA.2006.13)
• (en) Bialas, A., « Ontology-Based Security Problem Definition and Solution for the Common Criteria Compliant Development Process », Dependability of Computer Systems, 2009. DepCos-RELCOMEX '09. Fourth International Conference on, Brunow,‎ juillet 2009, p. 3 - 10 (ISBN 978-0-7695-3674-3, DOI 10.1109/DepCoS-RELCOMEX.2009.15)
• (en) Preschern, C et Dietrich, K., « Structuring Modular Safety Software Certification by Using Common Criteria Concepts », Software Engineering and Advanced Applications (SEAA), 2012 38th EUROMICRO Conference on, Cesme, Izmir,‎ septembre 2012, p. 47 - 50 (ISBN 978-1-4673-2451-9, DOI 10.1109/SEAA.2012.9)
• (en) Dadeau, F., Castillos, K.C., Ledru, Y. et Triki, T., « Test Generation and Evaluation from High-Level Properties for Common Criteria Evaluations -- The TASCCC Testing Tool », Software Testing, Verification and Validation (ICST), 2013 IEEE Sixth International Conference on, Luembourg,‎ mars 2013, p. 431 - 438 (ISBN 978-1-4673-5961-0, DOI 10.1109/ICST.2013.60)
• (en) Pretre, V., Bouquet, F. et Lang, C., « Using Common Criteria to Assess Quality of Web Services », Software Testing, Verification and Validation Workshops, 2009. ICSTW '09. International Conference on, Denver, CO,‎ avril 2009, p. 295 - 302 (ISBN 978-1-4244-4356-7, DOI 10.1109/ICSTW.2009.23)
• (en) Sauveron, D. et Dusart, P., « Which Trust Can Be Expected of the Common Criteria Certification at End-User Level? », Future Generation Communication and Networking (FGCN 2007) (Volume:2 ), Jeju,‎ décembre 2007, p. 423 - 428 (ISBN 0-7695-3048-6, DOI 10.1109/FGCN.2007.235, lire en ligne)

• (en) Ardi, S. et Shahmehri, N., « Introducing Vulnerability Awareness to Common Criteria's Security Targets », Software Engineering Advances, 2009. ICSEA '09. Fourth International Conference on, Porto,‎ septembre 2009, p. 419 - 424 (ISBN 978-0-7695-3777-1, DOI 10.1109/ICSEA.2009.67)
• (en) Rannenberg, K. et Iachello, G., « Protection profiles for remailer mixes. Do the new evaluation criteria help? », Computer Security Applications, 2000. ACSAC '00. 16th Annual Conference, New Orleans, LA,‎ décembre 2000, p. 107 - 118 (ISBN 0-7695-0859-6, DOI 10.1109/ACSAC.2000.898864)
• (en) Hearn, J., « Does the common criteria paradigm have a future? », Security & privacy IEEE,‎ février 2004, p. 64 - 65 (ISSN 1540-7993, DOI 10.1109/MSECP.2004.1264857, lire en ligne)
• (en) Monika Vetterling, Guido Wimmel et Alexander Wisspeintner, « Secure systems development based on the common criteria: the PalME project », ACM SIGSOFT Software Engineering, New York, NY, USA,‎ November 2002, p. 129 - 138 (DOI 10.1145/605466.605486, lire en ligne)

• (en) Siv Hilde Houmb, Shareeful Islam, Eric Knauss, "Eliciting security requirements and tracing them to design: an integration of Common Criteria, heuristics, and UMLsec", March 2010, [lire en ligne]
• (en) Ware, M.S., Bowles, J.B et Eastman, C.M., « Using the Common Criteria to Elicit Security Requirements with Use Cases », SoutheastCon, 2006. Proceedings of the IEEE, Memphis, TN,‎ avril 2005, p. 273 - 278 (ISBN 1-4244-0168-2, DOI 10.1109/second.2006.1629363, lire en ligne)
• (en) Shoichi Morimoto, Shinjiro Shigematsu et Yuichi Goto, « Formal verification of security specifications with common criteria », SAC '07 Proceedings of the 2007 ACM symposium on Applied computing, ACM New York, NY, USA ©2007,‎ 2007, Pages 1506-1512 (ISBN 1-59593-480-^{[à vérifier : ISBN invalide]}, DOI 10.1145/1244002.1244325, lire en ligne)

• (en) Shoichi Morimoto, Shinjiro Shigematsu et Yuichi Goto, « Formal verification of security specifications with common criteria », SAC '07 Proceedings of the 2007 ACM symposium on Applied computing, ACM New York, NY, USA ©2007,‎ 2007, Pages 1506-1512 (ISBN 1-59593-480-^{[à vérifier : ISBN invalide]}, DOI 10.1145/1244002.1244325, lire en ligne)

• Michael Chochois et Nicolas Magnin, « Qualité des produits de SSI, les labels français », Techniques de l'ingénieur. Sécurité des systèmes d'information,‎ 2009, Pages 1-17 (ISSN 1953-4663, lire en ligne)
• (en) WJ Lloyd, « A Common Criteria Based Approach for COTS Component Selection », Journal of Object Technology, 2004
• (en) R Richards, D Greve, M Wilding, WM Vanfleet,, « The common criteria, formal methods and ACL2 », Workshop, 2004 - cs.utexas.edu, 2004
• (en) Karpati, Opdahl et Sindre, « Experimental Comparison of Misuse Case Maps with Misuse Cases and System Architecture Diagrams for Eliciting Security Vulnerabilities and Mitigations », Availability, Reliability and Security (ARES), 2011 Sixth International Conference on, Vienna,‎ aug. 2011, p. 507 - 514 (ISBN 978-0-7695-4485-4, DOI 10.1109/ARES.2011.77, lire en ligne)

• (en) Kallberg, « Common Criteria meets Realpolitik - Trust, Alliances, and Potential Betrayal », Security & Privacy, IEEE (Volume:10 , Issue: 4 ),‎ juillet-août 2012, p. 50 - 53 (ISSN 1540-7993, DOI 10.1109/MSP.2012.29)
• (en) Beatty, « Common Criteria Mutual RecognitionBeatty », Science Applications International Corporation,‎ 2007, p. 1-9 (lire en ligne)