• Aucun résultat trouvé

1.5. T ECHNIQUES ET MÉCANISMES POUR SÉCURISER UN SYSTÈME

1.5.2. Autres contre-mesures

1.5.2.6 Évaluation de la sécurité

Il est important d’évaluer la sécurité des systèmes d’information et de communication, pour savoir si on a obtenu un niveau de sécurité satisfaisant, pour identifier les points les plus critiques à surveiller ou à corriger, et enfin pour estimer s’il est rentable de mettre en œuvre telle ou telle défense supplémentaire. Trois grandes méthodes d’évaluation de la sécurité peuvent être distinguées : l’utilisation des critères d’évaluation, l’analyse des risques ainsi que les méthodes d’évaluation quantitative de la sécurité.

1.5.2.6.1 Critères d’évaluation

Les premiers critères d’évaluation de la sécurité ont été définis aux Etats-Unis dans ce qui est couramment appelé le Livre Orange ou TCSEC (Trusted Computer System Evaluation Criteria) [TCSEC 1985], ou dans les différentes interprétations associées à des livres de diverses couleurs qui l’accompagnent, comme le Livre Rouge ou T N I (Trusted Network Interpretation of the TCSEC) [TNI 1987]. Ces critères, fondés à la fois sur des listes de fonctions de sécurité à remplir et sur les techniques employées pour la vérification, conduisent à classer les systèmes en sept catégories (D, C1, C2, B1, B2, B3, A1). Pour chaque niveau, quatre familles de critères sont définies, traitant de la politique d’autorisation, de l’audit, de l’assurance et de la documentation :

- La politique d’autorisation stipule une politique précise à suivre (discrétionnaire ou obligatoire) en fonction des différents niveaux de certifications visés. La politique obligatoire imposée est celle définie par Bell-LaPadula [Bell-LaPadula 1976] (voir 2.2).

- Les critères d’audit précisent les fonctions requises en matière d’identification, d’authentification et d’audit des actions.

- Les critères d’assurance fixent des recommandations concernant des méthodes de conception et de vérification utilisées afin d’augmenter la confiance de l’évaluateur, il s’agit de garantir que le système implémente bien la fonctionnalité qu’il prétend avoir.

- Les critères de documentation spécifient les documents qui doivent être fournis avec le produit lors de l’évaluation.

Les caractéristiques principales des différents niveaux définis par le livre orange sont ainsi : - un système classé au niveau D est un système qui n’a pas été évalué ;

- jusqu’au niveau C1 et C2, le système peut utiliser une politique discrétionnaire ; - pour les niveaux B1, B2, et B3 le système utilise une politique obligatoire ;

- un système classé A1 est fonctionnellement équivalant à un système classé B3, sauf qu’il est caractérisé par l’utilisation de méthodes formelles de vérification pour prouver que les contrôles utilisés permettent bien d’assurer la protection des informations sensibles.

Les TCSEC visent d’abord à satisfaire les besoins du DoD (Department of Defense) des États-Unis, privilégiant ainsi la confidentialité des données militaires. Par ailleurs, le manque de souplesse et la difficulté de leur mise en œuvre, ont conduit au développement de nouvelles générations de critères. À titre d’exemple abordons les critères adoptés par la Communauté Européenne [ITSEC 1991], mais d’autres pays tels que le Canada [CTCPEC 1993] et le Japon [JCSEC 1992] ont également élaboré leurs propres critères d’évaluation.

Les ITSEC sont le résultat d’harmonisation de travaux réalisés au sein de quatre pays européens : l’Allemagne, la France, les Pays-Bas et le Royaume-Uni [ITSEC 1991]. La différence essentielle entre les TCSEC et les ITSEC réside dans la distinction entre fonctionnalité et assurance. Une classe de fonctionnalité décrit les fonctions que doit mettre en œuvre un système tandis qu’une classe d’assurance décrit l’ensemble des preuves qu’un système doit apporter pour montrer qu’il implémente les fonctions qu’il prétend fournir.

Les ITSEC introduisent également la notion de “cible d’évaluation” (TOE pour Target Of Evaluation). Une TOE rassemble les différents éléments du contexte d’évaluation, dont une politique de sécurité, une spécification des fonctions requises dédiées à la sécurité, une définition des mécanismes de sécurité (optionnelle), la cotation annoncée de la résistance minimum des mécanismes, ainsi que le niveau d’évaluation visé.

Les ITSEC proposent dix classes de fonctionnalités de base :

- les classes de fonctionnalité F-C1, F-C2, F-B1, F-B2, F-B3 sont des classes de confidentialité qui correspondent aux exigences de fonctionnalité des classes C1 à A1 dans les TCSEC ;

- la classe de fonctionnalité F-IN concerne les TOE pour lesquelles il y a des exigences d’intégrité (par exemple, pour les bases de données) ;

- la classe de fonctionnalité F-AV impose des exigences de disponibilité ;

- la classe de fonctionnalité F-DI impose des exigences élevées pour l’intégrité des données au cours de leur transmission ;

- l’exemple de classe de fonctionnalité F-DC est destinée aux TOE exigeantes en confidentialité des données au cours de leur transmission ;

- la classe de fonctionnalité F-DX est destinée aux réseaux exigeants en matière de confidentialité et d’intégrité de l’information.

Les différents critères d’assurance exigés se découpent en deux aspects : les critères d’assurance d’efficacité et les critères d’assurance de conformité. Ces critères d’assurance se découpent à nouveau en deux catégories vis-à-vis de la construction et de l’exploitation du système. Les critères d’assurance de conformité sont définis vis-à-vis de six niveaux d’exigences, numérotés de E1 à E6, qui correspondent à des contraintes de plus en plus fortes et définissent le niveau de certification atteint par une TOE. De plus amples détails sur les ITSEC et les TCSEC peuvent être trouvés dans [Branstad et al. 1990 ; Dacier 1994].

La tentative d’harmonisation des critères canadiens, européens et américains, a donné naissance aux critères communs (en anglais « Common Critéria for Information Security Evaluation ») [CC 1999a] qui sont maintenant une norme internationale [ISO 15408]. Ces critères contiennent deux parties bien distinctes comme dans les ITSEC : fonctionnalité et assurance. Les critères communs définissent également une cible d’évaluation (TOE) ainsi que les profils de protection [CC 1999b], déjà existants dans les critères fédéraux américains [Federal Criteria 1992]. Pour une catégorie de TOE, un profil de protection définit un ensemble d’exigences de sécurité et d’objectifs, indépendant d’une quelconque implémentation. L’intérêt de ces profils est double : un développeur peut inclure dans la définition de la TOE un ou plusieurs profils de protection ; un client désirant utiliser un système ou un produit peut

également demander à ce qu’il corresponde à un profil de protection particulier, évitant ainsi de donner une liste exhaustive des fonctionnalités et des assurances qu’il exige.

1.5.2.6.2 Analyse des risques

Un risque peut être vu comme un événement redouté, auquel on peut attribuer une fréquence d’occurrence et un coût. La littérature définit différentes notions relatives aux risques comme l’évaluation, la gestion et l’analyse des risques [Dacier 1994]. Dans notre travail, nous nous intéressons à ce dernier concept, car plus large, et englobant les deux autres.

L’analyse des risques est une discipline destinée à mettre en œuvre une politique de sécurité en tenant compte des vulnérabilités résiduelles, en évaluant leurs impacts sur la sécurité, et en calculant les rapports coûts/bénéfices apparaissant dans une organisation [ISO 17799].

D’une manière générale, une analyse des risques peut être faite selon les étapes suivantes : - l’identification des actifs, c’est-à-dire les éléments à protéger dans le système ;

- pour chaque actif, l’identification des menaces correspondantes (contre qui ou quoi on veut protéger les actifs ?) ;

- l’analyse des conséquences de la réalisation d’une menace sur l’actif du système ;

- le calcul des risques : pour chaque menace, calculer le risque qu’elle représente ; ce risque étant évalué comme égal à la fréquence d’occurrences de la menace multipliée par la conséquence financière de sa réalisation ;

- l’évaluation des parades possibles qui identifient les contre-mesures utilisables pour parer à une menace ainsi que leur efficacité et leur coût ;

- la proposition d’un choix de parades optimales du point de vue du rapport coût/efficacité pour l’amélioration du niveau existant de sécurité ;

- la formulation d’un plan de sécurité qui constitue le résultat final de l’étude incluant le compte-rendu des résultats précédents et un plan de mise en œuvre des nouvelles mesures de protection choisies.`

La réalisation de ces différentes étapes peut s’effectuer sous divers modes opératoires. À titre d’exemple, on peut citer les approches basées sur :

- les listes de contrôle qui partent des parades disponibles et étudient la nécessité de leur mise en place ;

- l’identification de scénarios d’attaques, qui prennent en compte non seulement la possibilité de réussir à exploiter une vulnérabilité, mais également la probabilité de réussir à exploiter une succession d’attaques ;

- l’évaluation quantitative qui partant de l’identification exhaustive des actifs, des vulnérabilités et des menaces, propose une quantification des risques ; cette approche sera étudiée en détail dans la section suivante.

Le principal problème de l’analyse des risques reste celui de la collecte des données. Soit la méthode se veut exhaustive et devient alors extrêmement coûteuse en temps et en effort, soit elle utilise une méthode de sélection et s’en remet alors en pratique à la qualité de l’expertise de l’évaluateur. De plus la majorité des organisations ne dispose pas d’une modélisation réelle de leurs fonctionnements. Par conséquent, les évaluations des effets des menaces et des vulnérabilités sur la sécurité demeurent peu efficaces ou tout au moins difficiles.

1.5.2.6.3 Évaluation quantitative

Dans cette section, nous détaillons une méthode d’évaluation de la sécurité qui utilise les indicateurs quantitatifs de la sécurité, de façon à permettre aux administrateurs de surveiller au

jour le jour le niveau de sécurité et de prendre des mesures correctives en cas de baisse de ces indicateurs. Ceci permet d’évaluer la sécurité opérationnelle, c’est-à-dire correspondant à la façon d’utiliser les systèmes et ses mécanismes de protection, plutôt qu’une vision statique comme celle donnée par les critères d’évaluation ou par les méthodes classiques d’analyse de risques. C’est aujourd’hui un domaine de recherche actif, mais qui a jusqu’à présent donné peu de résultats. C’est le cas de la méthode d’évaluation de la sécurité en calculant le temps et l’effort nécessaire à un intrus pour violer les objectifs de protection [Dacier 1994]. Cette méthode utilise un formalisme basé sur les graphes de privilèges (voir 2.2.2.5) et les réseaux de Petri stochastiques, et se base sur les étapes suivantes :

- détermination des vulnérabilités à prendre en compte, en s’appuyant notamment sur la politique de sécurité ou sur une liste de vulnérabilités déjà identifiées ;

- quantification de ces vulnérabilités ;

- évaluation quantitative en utilisant la politique de sécurité et une représentation des vulnérabilités existantes dans le système.

Cette méthode utilise le graphe de privilège comme modèle de représentation des vulnérabilités d’un système [Dacier 1994 ; Dacier & Deswarte 1994]. Dans le graphe de privilège, une vulnérabilité correspond à une méthode de transfert de privilèges. Les nœuds du graphe représentent les différents privilèges qui existent dans le système. Un arc est créé entre deux nœuds si une méthode, possédant les privilèges du nœud origine, permet d’obtenir ceux du nœud destination. L’existence d’un arc entre deux nœuds dépend donc de l’état du système à un instant donné, qui peut ou non permettre l’exploitation d’une certaine vulnérabilité.

Les vulnérabilités, qui doivent tout au début de ce processus être recherchées dans le système, peuvent avoir des origines variées, comme la mauvaise utilisation des mécanismes de protection ou les délégations de pouvoirs. Des valeurs quantitatives sont ensuite associées aux vulnérabilités élémentaires afin de définir des mesures quantitatives de la sécurité globales. Par exemple, on affecte à chaque arc du graphe des privilèges un poids correspondant à l’effort nécessaire à un attaquant potentiel pour exploiter la méthode de transfert de privilèges correspondant à cet arc. Cette notion d’effort regroupe les différentes caractéristiques du processus d’attaque comme la puissance de calcul disponible pour l’attaquant.

Par ailleurs, les objectifs de sécurité définis par la politique de sécurité permettent d’identifier les différents nœuds du graphe correspondant aux attaquants et aux cibles potentiels qui sont pertinents à étudier dans un système donné.

Les travaux effectués par Ortalo ont utilisé cette méthode et ont abouti à l’élaboration du prototype ÉSOPE (pour Évaluation de la Sécurité Opérationnelle) [Ortalo et al.1999].

Enfin, il est important de noter que les mesures de sécurité que nous avons décrites (cloisonnement, détection et tolérance aux intrusions, chiffrement, etc.) ne devront pas être mises en place tant que l’on n’aura pas défini et documenté au préalable une politique de sécurité. En effet, une démarche sécuritaire repose sur une politique de sécurité pour recenser les objectifs de sécurité à atteindre, les éléments à protéger ainsi que les risques encourus (et leurs combinaisons). Ensuite il convient de définir comment le système évolue (face aux risques identifiés) et quelles sont les mesures préventives et les mécanismes à mettre en place.

L’évaluation de la sécurité permet, par la suite, d’identifier le niveau de sécurité visé et de savoir (ou prouver) si la politique et les mécanismes de sécurité mis en œuvre permettent bien d’atteindre le niveau visé.

Chapitre 2. Politiques et modèles de sécurité

Préambule

Le précédent chapitre a présenté les définitions relatives à la notion de sûreté de fonctionnement. La sécurité a été présentée comme la combinaison de trois propriétés : la confidentialité, l’intégrité et la disponibilité de l’information. Ensuite, les principales techniques et mesures de sécurité ont été définies, et l’analyse a montré l’intérêt des politiques d’autorisation dans la construction de la sécurité d’un système ou d’une organisation.

Examinons maintenant les grandes familles de politiques de sécurité ainsi que les principaux modèles de sécurité représentés dans la littérature ; en l’occurrence les politiques discrétionnaires, obligatoires, à base de rôles, ainsi que les modèles HRU, Take-Grant, TAM, graphe des privilèges, etc. Nous évalurons les avantages et les limites de ces modèles et politiques de sécurité, puis les confrontons aux spécificités des SICSS, déjà identifiées. Les résultats de projets récents, s’intéressant aux problèmes de la sécurité dans le domaine médical, et plus précisément aux politiques de sécurité, seront également abordés.

Enfin, la discussion des politiques actuellement en vigueur permettra de conclure qu’elles ne couvrent pas toute la richesse des SICSS. Sur le plan réglementaire, les bases et textes légaux existent, même s’ils ne sont pas assez formalisés ou formalisables, de même qu’ils ne sont pas encore appliqués ou applicables dans les pays européens. Sur le plan technique, les notions de rôles et d’équipes sont prometteurs. Néanmoins, elles nécessitent une adaptation considérable et doivent être complétées par de nouveaux concepts.