Loading AI tools
De Wikipédia, l'encyclopédie libre
Les critères communs (CC) 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. Également dénommés Common Criteria, ce référentiel est né d'un partenariat entre le Canada, les États-Unis et l'Europe. Grâce au cadre offert, les utilisateurs de technologies de l’information vont pouvoir utiliser des profils 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ères Communs décidée par les signataires d’un accord de reconnaissance mutuelle, facilite grandement l’acceptation des certificats de sécurité des technologies de l’information émis par l’un des pays signataires. Le produit certifié en toute impartialité par une autorité compétente, peut être utilisé sans nécessiter une évaluation plus poussée.
Bien que présentant de nombreux avantages, l’application de cette norme s’avère coûteuse, 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.
En 1983, puis 1985, le NIST[note 1] et la NSA[note 2] publient l'Orange Book. Le but de ce document était d'évaluer la capacité d'un système à se défendre contre des attaques[2].
Dans le même temps l'Europe s'inspire des TCSEC[note 3] pour définir en 1991 ses propres critères d'évaluation les ITSEC[note 4]. Ils vont combler des lacunes dans l'analyse des risques[3].
En 1993, le Canada définit sa propre norme CTCPEC[note 5],[3].
Le certificat obtenu dans un pays est reconnu uniquement par les pays signataires de l'accord de reconnaissance mutuelle[4]. En Europe c'est l'accord SOG-IS[note 6] qui fait foi[5].
En 1999, l'ISO[note 7] 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[note 8] en mai 2000[6]. En plus des 17 pays signataires, 9 pays non signataires reconnaissent ces certificats[1].
Les Critères Communs (CC) sont un guide servant de référence pour le développement et le contrôle[7] de produits et systèmes de l’information manipulant des informations. Le but est la protection contre la divulgation non autorisée, la modification, la perte d'usage. Les catégories de ces trois types de défaillances sont communément désignées par confidentialité, intégrité et disponibilité. Les CC prennent en compte les risques émanant d'activités humaines (malicieuses ou non) ou non-humaines.
Les produits contrôlés sont ceux collectant, transportant et manipulant ces informations, à savoir des réseaux informatiques, des systèmes d’exploitation, des systèmes distribués et des applications[8]. Un système sera évalué en fonction de l’usage pour lequel il est dédié. Il devra répondre à deux catégories d’exigences de sécurité : exigences fonctionnelles et d’assurance[9].
Les besoins des utilisateurs sur le plan de la sécurité sont des besoins de disponibilité, de confidentialité et d'authenticité des informations personnelles[10]. Les critères communs s'adressent à trois catégories d'utilisateurs :
Les critères communs font l'objet de trois documents liés entre eux:
Les exigences fonctionnelles de sécurité concernent uniquement les spécifications de fonctions de sécurité. Elles sont regroupées en onze classes couvrant chacune un domaine. Chaque classe est découpée en familles. Chaque famille contient un ensemble de composants qui constitue une exigence de sécurité[17]. Chaque classe est désignée par un nom unique dont l'abréviation est constituée de trois caractères Fxx: F pour classe d'exigence Fonctionnelle et xx pour identifier le nom de la fonctionnalité couverte[18].
« Auditer la sécurité implique la reconnaissance, l'enregistrement, le stockage et l'analyse d'informations associées à des activités touchant à la sécurité »[19].
Le développeur va pouvoir définir un paquet de composants à partir de cette liste suivant les fonctionnalités de son produit. Cette liste n'étant pas exhaustive, 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é la famille SPOD[note 9] à la classe FPT[30]. Pour la certification de ce produit, SAFRAN a également retenu des composants des familles suivantes :
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 sur le plan de la vulnérabilité. Elle couvre la validité de la documentation et du produit ou système[31]. 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[32]. Quant à l'évaluateur, il va pouvoir identifier les tâches à réaliser pour conduire à une certification selon les Critères Communs[32].
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[33]. Le nommage des classes est effectuées avec trois caractères Axx : A désignant assurance suivi de deux lettres pour identifier le domaine couvert[33].
Liste des classes ;
Classe | Domaine couvert |
---|---|
ADV | Développement |
ACO | Composition |
AGD | Documentation |
ALC | Cycle de Vie |
APE | Évaluation Profile de protection |
ASE | Évaluation de la cible de sécurité |
ATE | Tests |
AVA | Estimation des Vulnérabilités |
Tout certificat émis à la suite de 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 (evaluation assurance level). Ces niveaux sont associés à un paquet minimum d'exigences d'assurance. Il existe sept niveaux hiérarchiques qui vont déterminer le degré de confiance accordé au produit évalué.
Chaque niveau contient les exigences du niveau précédent. Ils reflètent un équilibre entre le niveau d'assurance obtenu et le coût pour parvenir à ce niveau[42].
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é[51]. 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 :
Seuls les pays signataires de l'accord de reconnaissance mutuelle selon les critères communs sont autorisés à émettre des certificats[57]. Ce sont également eux qui vont accepter qu'un nouveau membre les rejoigne[58]. Ainsi l'Inde est devenu le 17e pays signataire en 2013[59].
Afin d'ê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[60].
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 TrustCB |
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 |
États-Unis | National Information Assurance Partnership NIAP |
La certification se déroule en 3 étapes :
Le commanditaire fait une demande d'évaluation auprès de son organisme gouvernemental chargé des certifications[64]. Il incombe à l'entreprise[65] :
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[66].
L'autorité chargée de la certification va s'appuyer sur le rapport d'évaluation technique pour émettre ou non le certificat d'évaluation selon les critères communs[63].
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[67],[68]. Celle-ci engendre un système plus robuste en réduisant les vulnérabilités de sécurité qui peuvent être trouvées dans les étapes ultérieures du développement[67],[68]. Lloyd mentionne que pour la fabrication et la commercialisation des COTS[note 11], la hausse des coûts 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[69]. 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[70].
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[67]. Selon Sauveron, la certification permet aux clients de comparer les différents produits sur le marché d'une manière objective[71].
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[71]. Les fabricants peuvent utiliser la certification comme argument marketing et ainsi élargir leur marché[71].
Pour Sauveron, la certification permet aux organismes de certification gouvernementaux, de s'assurer que les produits utilisés dans leurs pays sont maîtrisés. Et que, par conséquent, il n'y a pas de risque majeur d'attaques contre leurs systèmes informatiques[71].
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 mis en service[67]. Très souvent, la spécification des exigences de sécurité est trop succincte[67]. Les consommateurs ne sont pas en mesure d'indiquer clairement et sans ambiguïté les exigences de sécurité du produit[72]. Les exigences de sécurité sont souvent mal comprises[67]. La gestion des exigences en matière de sécurité est une question complexe pour les développeurs[73]. De nombreux développeurs ont tendance à décrire des solutions de conception en ce qui a trait aux mécanismes de protection, au lieu de faire des propositions déclaratives concernant le niveau de protection requis[67].
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é[72]. Shoichi indique que les critères des CC sont très abstraits, il est impossible d'avoir un aperçu global[74]. Il est difficile de définir entièrement les exigences à partir de zéro[75]. Selon Keblawi, l'expérience montre que les normes prescrites sont inflexibles et ne tiennent pas compte des considérations du monde réel[76]. Pour Taguchi, les méthodes sont très complexes sur le plan sémantique, et par conséquent, le coût de l'apprentissage est très élevé[68]. 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 des produits[77]. 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[78].
Selon Ware, les CC sont difficiles à comprendre pour des personnes non spécialistes de la sécurité[79]. 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[80]. 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[68]. 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[75]. 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[81].
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[72]. Keblawi indique, que certains systèmes ne correspondent pas facilement aux concepts de sécurité des Critères communs[76]. 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[82].
Selon Ware, les niveaux de protection de CC sont rarement utilisés dans la pratique[79]. 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[68]. Hearn indique que les vendeurs ne voient pas les CC comme un processus d'amélioration du produit[83]. Le rapport coût-bénéfice, qu'une utilisation des CC peut avoir sur un système informatique, est impossible à évaluer[83]. 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[84]. 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[85]. 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[83]. 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[78].
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[83]. 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[84]. Hearn indique que l'intérêt commercial est faible, car les certifications résultent de la réglementation gouvernementale ou de l'achat du gouvernement[83].
La méthode proposée par Taguchi, est basée sur un diagramme de cas d'utilisation selon plusieurs principes. Le premier de ces principes est l'utilisation d'un diagramme qui détaille les concepts de sécurité, pour faire apparaître les besoins de sécurité. Ensuite, tous les concepts du diagramme sont des éléments issus d'un méta modèle de la CC. Enfin, les modèles de sécurité sont ajoutés selon les contraintes de sécurité de chaque étape de la construction du produit[86].
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[87] :
L'auteur fait le choix d'enlever de son méta modèle les concepts des CC suivants[87] :
Un diagramme prototype est proposé en 3 phases. La première phase (Exigences de sécurité de base), analyse les fonctions de sécurité et les menaces de sécurité de façon abstraite. La seconde ( Exigences et objectif de sécurité), analyse en détail les exigences de sécurité pour en définir des objectifs de sécurité. Ce travail est réalisé à partir du résultat de la phase 1. Et enfin la phase 3 (Sélection des exigences fonctionnelles de sécurité), sert à la sélection des exigences fonctionnelles de sécurité, qui répondent aux objectifs de sécurité identifiés dans la phase précédente. Cette tâche est réalisée à partir de la norme des CC partie 2 et des profils de protection. Puis on aligne les exigences de sécurité aux exigences d'assurance en vertu de la méthodologie de CC[88].
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 objectifs de sécurité et des exigences de sécurité[79]. 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[89]. Pour mettre en œuvre cette approche, un outil de modélisation graphique open source UML, est proposé.
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[90].
Puis l'outil propose à l'utilisateur de générer un fichier de sortie dans un format HTML. L'outil propose deux styles de rapports possibles[91] :
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.
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[92]. Le principe est d'intégrer les activités des CC dans les phases de développement du projet[93]. Cette méthode est basée sur un processus itératif dans chaque phase du projet. À 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[93].
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[93]. C'est dans cette phase, que doit être décidé le niveau d'EAL, et quelle partie du système ou produit doit être développée conformément aux CC[93].
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)[93].
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)[94].
Il y a, dans la phase de développement, des éléments d'analyse de résultat de test qui vont être importants 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és dans la phase de développement[94].
Les documents pour les livraisons (class ADO) sont finalisés dans la phase de déploiement et mise en exploitation[94].
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 personnes avec une charge de 630 jours hommes[94].
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 possibles, et font perdre un temps précieux au cours du projet[95].
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équate les exigences de sécurité de la protection de la vie privée de l'utilisateur ou les exigences de juste-échange[95].
José Romero-Mariona, propose une approche qui fait correspondre les exigences de sécurité des CC aux éléments d'architecture et leurs connexions[96]. 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[97].
Puis, à partir de cette cartographie, un outil va automatiser la construction d'un fichier XML après avoir effectué une vérification de la cartographie[97]. Les modules principaux de l'outil sont[97] :
Les composants des CC et leurs connexions sont définis en XML par 4 paramètres[97] :
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[98]. 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[99].
Shanai Ardi propose une méthode qui consiste à compléter la cible de sécurité, en y ajoutant les vulnérabilités logicielles[100]. La cible de sécurité traite les points suivants[101] :