Méthode de définition d’une politique de sécurité

Télécharger le fichier pdf d’un mémoire de fin d’études

Les fautes dues à l’homme

Les fautes et leurs sources sont extrêmement diverses. Les cinq points de vue prin-cipaux selon lesquels on peut les classer sont leur cause phénoménologique (fautes physiques, fautes dues à l’homme), leur nature (fautes accidentelles, fautes inten-tionnelles), leur phase de création ou d’occurrence (fautes de développement, fautes opérationnelles), leur situation par rapport aux frontières du système (fautes inter-nes, fautes externes), et leur persistance (fautes permanentes, fautes temporaires). Les définitions complètes associées à ce classement peuvent être trouvées dans [Laprie 1995].
Les fautes dues à l’homme donnent lieu à quatre classes de fautes combinées :
• les fautes de conception, qui sont des fautes de développement accidentelles ou intentionnelles sans volonté de nuire;
• les fautes d’interaction, qui sont des fautes externes, accidentelles ou inten-tionnelles sans volonté de nuire;
• les logiques malignes, qui sont des fautes internes intentionnellement nuisibles
• les intrusions, qui sont des fautes opérationnelles externes intentionnellement nuisibles.
Quelques commentaires sur ces classes de fautes dues à l’homme sont particulière-ment pertinents vis-à-vis de la sécurité-confidentialité:
1) Les fautes de conception intentionnelles sans volonté de nuire résultent généra-lement de compromis effectués durant la conception, dans un souci de conser-ver au système un niveau de performances acceptable ou de faciliter son utilisation, ou encore pour des raisons économiques; cependant ces fautes peuvent être des sources d’atteinte à la sécurité-confidentialité, sous la forme de canaux cachés. Un canal caché désigne un mécanisme non prévu pour la com-munication qui peut être utilisé pour transférer de l’information d’une manière qui viole la politique de sécurité du système d’information [ITSEC 1991].
2) Les fautes d’interaction intentionnelles sans volonté de nuire peuvent résulter de l’action d’un opérateur soit destinée à faire face à une situation imprévue, soit violant délibérément des procédures sans avoir réalisé les conséquences mal-heureuses de cette action. Généralement, ces fautes intentionnelles sans volonté de nuire ne sont identifiées comme des fautes qu’après qu’elles aient causé un comportement inacceptable du système, donc une défaillance.
3) Les logiques malignes recouvrent aussi bien des fautes de développement comme les chevaux de Troie, les portes dérobées, les bombes logiques ou tem-porelles, ou des fautes opérationnelles (pour le système considéré) comme les virus et les vers. Ces fautes peuvent être définies comme suit :
– une bombe logique est une partie de programme qui reste dormante dans le système hôte jusqu’à ce qu’une date ou un événement d’activation sur-vienne, ou que certaines conditions soient remplies, entraînant des effets dévastateurs pour le système hôte;
– un cheval de Troie est un programme effectuant une fonction illicite tout en donnant l’apparence d’effectuer une fonction légitime; la fonction illicite peut être de divulguer ou de modifier des informations (attaque contre la confidentialité ou l’intégrité), ou peut être une bombe logique
– une porte dérobée est un moyen de contourner les mécanismes de contrôle d’accès il s’agit d’une faille du système de sécurité due à une faute de con-ception accidentelle ou intentionnelle (cheval de Troie en particulier)
– un virus est un segment de programme qui, lorsqu’il s’exécute, se reproduit en s’adjoignant à un autre programme (du système ou d’application), qui devient ainsi un cheval de Troie ; un virus peut être porteur d’une bombe logique;
– un ver est un programme autonome qui se reproduit et se propage à l’insu des utilisateurs; un ver peut également être porteur d’une bombe logique.
4) Les intrusions ne peuvent être couronnées de succès sans l’existence de fautes de conception; on peut identifier des similarités évidentes et néanmoins intéres-santes entre une intrusion et une faute accidentelle externe “exploitant” un défaut de blindage; il faut de plus noter que le caractère externe des intrusions n’exclut pas qu’elles soient tentées par des opérateurs ou administrateurs du système qui abusent de leur pouvoir.
Les définitions complètes des différentes notions relatives à la sûreté de fonctionne-ment, incluant certains aspects que nous n’avons pas évoqués ici (notamment en ce qui concerne les moyens de la sûreté de fonctionnement) pourront être trouvées dans [Laprie 1995].

La sécurité-confidentialité

Lorsque le contexte permet de lever aisément le doute, l’adjonction d’un qualificatif permettant de distinguer entre la sécurité-confidentialité et la sécurité-innocuité n’est pas nécessaire. Dans la suite de ce mémoire, nous utiliserons donc directe-ment le terme “sécurité” pour désigner la sécurité-confidentialité, qui fait l’objet de nos travaux.
Assurer la sécurité d’un système consiste à garantir le maintien d’un certain nombre de propriétés de sécurité définissant les caractéristiques de confidentialité, d’inté-grité et de disponibilité qui doivent être maintenues dans le système. Ceci implique d’empêcher la réalisation d’opérations illégitimes contribuant à mettre en défaut ces propriétés, mais aussi de garantir la possibilité de réaliser des opérations légitimes dans le système. La description de ces différentes propriétés fait partie de la politique de sécurité du système. Assurer la sécurité du système, c’est donc assurer que les propriétés retenues sont vérifiées (et donc garantir la non-occurrence de défaillances vis-à-vis de ces propriétés).
Il faut noter qu’a priori, l’occurrence d’opérations illégitimes n’est pas forcément le signe d’une action intentionnellement nuisible d’un utilisateur. Des opérations met-tant en danger la sécurité du système peuvent survenir du fait d’un utilisateur auto-risé et bien intentionné, mais qui ignore certaines des propriétés attendues du système ou qui ne maîtrise pas complètement toutes les implications des opérations qu’il effectue.

Confidentialité

La confidentialité peut être définie comme la prévention de la divulgation non-autorisée de l’information [ITSEC 1991, §6.18]. Ceci correspond à empêcher un utilisateur de consulter directement une information qu’il n’est pas autorisé à connaître, mais aussi à empêcher un utilisateur autorisé à lire une information de la divulguer à un utilisateur non autorisé à y accéder. Le terme information doit être pris au sens le plus large: il recouvre non seulement les données elle-mêmes, mais aussi les flux d’information et la connaissance de l’existence des données ou des communications. Assurer la confidentialité d’un système est donc une tâche bien plus compliquée qu’il n’y paraît de prime abord. Il faut analyser tous les chemins qu’une information particulière peut prendre dans le système pour s’assurer qu’ils sont sécurisés. Il importe également de prendre en compte les connaissances qu’un ou plusieurs utilisateurs peuvent déduire à partir des informations qu’ils acquièrent (soit parce que le système les autorise à les consulter, soit parce qu’elles font partie des informations librement diffusées dans l’environnement du système). Il faut donc contrôler non seulement les informations présentes dans le système, mais aussi les liens logiques qui peuvent les relier entre elles ou à des informations publi-ques, afin de garantir que les informations diffusées par le système ne transforment pas une information protégée en secret de polichinelle [Morgenstern 1988 ; Garvey & Lunt 1992; Cuppens & Trouessin 1994].
Les attaques contre la confidentialité consistent à essayer d’obtenir des informa-tions qui doivent être protégées selon la politique de sécurité en dépit des moyens de protection et des règles de sécurité. Par exemple, les écoutes passives consistent à accéder aux données transmises sur un canal de communication (câble réseau) ou stockées sur un support vulnérable (disques externes, bandes magnétiques). Une telle écoute peut, dans certaines circonstances, permettre d’accéder à des informa-tions sensibles, comme par exemple le mot de passe d’un utilisateur, tapé sur un ter-minal connecté par une liaison série à un ordinateur central, et qui transite en clair entre ce terminal et la machine. On voit également que cette attaque peut être parti-culièrement difficile à identifier a posteriori étant donné l’absence totale de traces laissées dans le système.

Intégrité

L’intégrité peut être définie comme la capacité du système à empêcher la corruption des informations par les fautes accidentelles ou intentionnelles, et à garantir leur mise à jour correcte. Dans le cas des fautes intentionnelles, les attaques contre l’intégrité visent soit à introduire des fausses informations, soit à modifier ou à détruire des informations pour que le service inapproprié délivré par le système pro-duise un bénéfice pour l’attaquant. C’est par exemple le cas pour une fraude. Il faut noter qu’en général, les erreurs introduites par l’attaquant ne sont pas facilement détectables, c’est-à-dire que l’information paraît intègre alors qu’elle ne l’est pas, ce qui rend les défaillances résultantes difficilement détectables. Dans le cas où une information est visiblement erronée, les méthodes permettant de parer à la corrup-tion des informations due à des fautes accidentelles s’appliquent plus naturellement et la défaillance résultante est généralement mieux maîtrisée.
Afin de se prémunir contre les fautes affectant l’intégrité des données, il importe d’intégrer dans le système des mécanismes permettant de rendre détectables des erreurs affectant ces données. Dans le cas de fautes accidentelles, comme par exem-ple celles pouvant affecter le support physique d’une voie de communication d’informations, l’adjonction de codes correcteurs aux données transmises peut être suffisante pour détecter une donnée erronée. Néanmoins, quand il s’agit de se pré-munir contre les altérations malveillantes de l’information, ceci est généralement insuffisant puisque l’attaquant est en mesure d’altérer également le code accompa-gnant l’information pour lui donner une apparence d’intégrité. Dans ce cas, il faut donc séparer les voies de transmission de la signature de l’information et de l’infor-mation elle-même, ou utiliser des mécanismes plus sophistiqués comme les algo-rithmes cryptographiques permettant la génération d’un sceau ou d’une signature.

Disponibilité

Une attaque contre un système peut avoir simplement pour but d’empêcher le sys-tème de remplir le service pour lequel il a été conçu. Il s’agit alors d’une attaque contre la disponibilité du système ou déni de service. Ces attaques consistent à faire en sorte que les actions du système ne correspondent plus à ce que l’on attend de lui, soit parce que le résultat des actions effectuées par le système est erroné, soit parce que ce résultat n’est pas disponible en temps voulu. La première catégorie d’attaque est étroitement liée à l’intégrité étant donné qu’elle consiste à modifier l’information présente dans le système cible, ou dans son système de communica-tion, voire au cours de son traitement, afin que le système fournisse un résultat incorrect. La deuxième catégorie peut également trouver sa source dans une attaque contre l’intégrité des données ou du système dont l’objectif est d’interrompre le traitement de l’information (ou tout au moins de le retarder), comme dans le cas de la destruction d’un lien de communication. Cependant ce type d’attaque peut égale-ment être mis en œuvre en perturbant le fonctionnement temporel du système, par exemple en surchargeant certaines des ressources dont il est dépendant, ou en sur-chargeant le système lui-même, afin que le temps de traitement d’une opération par-ticulière devienne inacceptable.
Il faut noter que, en ce qui concerne les systèmes informatiques, les attaques contre la disponibilité d’un système semblent constituer à l’heure actuelle un des problè-mes de sécurité majeurs. En effet, les systèmes ne sont pas conçus pour résister à de telles attaques. De plus, celles-ci sont facilitées par de nombreuses vulnérabilités introduites dans le système pour en améliorer les performances dans des circonstan-ces nominales. La facilité de mise en œuvre de ce type d’attaque, notamment vis-à-vis des systèmes informatiques, est un problème préoccupant.

Politiques et modèles de sécurité

La politique de sécurité d’un système constitue une partie de la spécification des propriétés non-fonctionnelles de ce système. Plus précisément, elle précise les dif-férentes propriétés qui sont relatives aux différents attributs de sécurité-confidentialité: l’intégrité, la disponibilité et la confidentialité.

Contenu d’une politique de sécurité

Dans les [ITSEC 1991, §2.9], la politique de sécurité “est l’ensemble des lois, règles et pratiques qui régissent la façon dont l’information sensible et les autres ressources sont gérées, protégées et distribuées à l’intérieur d’un système spécifi-que”.
Plus précisément, on peut considérer qu’une politique de sécurité définit:
• des objectifs de sécurité, c’est-à-dire des propriétés de confidentialité, d’inté-grité et de disponibilité désirées pour le système;
• et des règles de sécurité permettant de modifier l’état de sécurité du système, qui sont imposées au comportement du système dans le but d’obtenir ces pro-priétés.
La politique de sécurité est cohérente si, partant d’un état sûr où les propriétés sont satisfaites, il n’est pas possible, sans violer les règles, d’atteindre un état non-sûr où ces propriétés ne sont pas satisfaites. La définition des propriétés de sécurité peut nécessiter la description d’éléments appartenant en propre au système (des sujets ou des objets spécifiques, les opérations mises en œuvre, ou une représentation de l’organigramme d’une organisation, par exemple). Ces éléments de description, présents dans la politique de sécurité, constituent une description partielle du sys-tème. Contrairement à eux, les objectifs et les règles de sécurité sont relatifs aux besoins de sécurité du système. Les objectifs de sécurité décrivent les propriétés attendues et définissent ainsi la notion d’état sûr pour le système. La formulation de ces objectifs peut utiliser des notions comme la permission, l’interdiction, ou l’obli-gation [Minsky & Lockman 1985], et décrit la manière dont elles s’appliquent au système. Les règles de sécurité s’attachent plus particulièrement à décrire (à un haut niveau) les mécanismes fondamentaux de sécurité utilisés dans le système. Si des attributs spécifiques à la sécurité sont introduits explicitement, ces règles spécifient la manière dont ils sont manipulés. L’ensemble des règles de sécurité constitue donc une description des moyens permettant de modifier l’état de sécurité du système. Certaines règles peuvent également être introduites dans le but de contribuer à assu-rer la validité des propriétés de sécurité attendues du système.
La notion de politique de sécurité peut se développer dans trois directions distinctes: les politiques de sécurité physique, administrative et logique.
La première précise tout ce qui touche à la situation physique du système à proté-ger. En particulier, y sont définis les éléments critiques et les mesures prises vis-à-vis du vol par effraction, des agressions sur les personnes, des catastrophes naturelles, du feu, etc. De par la nature des éléments auxquels elle s’applique, une politique de sécurité physique s’attache avant tout à la description de certains objets physiques présents dans le système et au choix des objectifs. Dans le cas où les objectifs de sécurité ne sont pas satisfaits, une intervention directe sur le système (par exemple le renforcement d’un blindage, ou l’installation d’une temporisation sur un coffre-fort) est préalablement nécessaire. Sinon, la propriété recherchée n’est tout simplement pas assurée.
La politique de sécurité administrative est un ensemble de procédures qui traitent de tout ce qui ressort de la sécurité d’un point de vue organisationnel au sein de l’entreprise. La structure de l’organigramme choisi, la répartition des tâches et des responsabilités en différentes fonctions, et finalement l’affectation de ces fonctions aux individus en font également partie. Les propriétés de sécurité recherchées visent par exemple à limiter les cumuls ou les délégations abusives de pouvoirs, ou à garantir une séparation des pouvoirs.
La politique de sécurité logique s’intéresse quant à elle au contenu du système informatique ou, plus généralement, du système d’information présent dans l’orga-nisation. Elle décrit les contrôles d’accès logiques, en spécifiant à qui il est permis d’accéder à quoi et dans quelles circonstances. Une politique de sécurité logique peut être raffinée en plusieurs branches correspondant aux différentes étapes de l’accès au système d’information. Un individu qui utilise le système soumis à la politique de sécurité doit d’abord s’identifier, et ensuite doit apporter la preuve qu’il est bien la personne qu’il prétend être. À ces deux phases correspondent la politique d’identification et la politique d’authentification. Une fois ces étapes fran-chies, la politique d’autorisation définit les opérations que l’utilisateur est autorisé à réaliser dans le système. Dans le cadre d’une politique d’autorisation, les règles de sécurité constituent le schéma d’autorisation du système.

Politiques d’autorisation

Politiques de sécurité

Les politiques de sécurité s’attachent donc à définir des propriétés de sécurité dési-rées pour le système. Dans le cas des organisations, ces politiques de sécurité s’expriment généralement en langage naturel et constituent un règlement de sécu-rité, spécifiant simultanément les propriétés désirées et les règles devant être appli-quées par les individus afin de garantir ces propriétés. On trouve ce type de règlement dans la plupart des organisations qui doivent respecter des contraintes de sécurité, que ce soit par obligation légale ou pour des raisons déontologiques (par exemple dans le domaine bancaire, dans le domaine des assurances, dans le domaine de l’informatique vis -à- vis des bases de données nominatives [CNIL 1978], ou dans le domaine médical [CO 1979; Saury 1991; CNIL 1994; DGS 1995]). De par leur nature informelle, ces règlements sont souvent sujets à interprétation. Ils peuvent contenir des ambiguïtés et conduire à des contradictions (vis-à-vis du secret médical par exemple, ces contradictions sont actuellement pré-occupantes [Saury 1991; Abecassis 1995]; en ce qui concerne le respect de l’assen-timent du patient d’autres difficultés ont également été identifiées [Pigeaud 1993]). Néanmoins, ils constituent vraisemblablement la grande majorité des politiques de sécurité en application, et ont fait l’objet de représentations formelles [Kanger 1972 ; Jones & Sergot 1992 ; Jones & Sergot 1993 ; Royakkers 1994 ; Cuppens & Saurel 1996; Cholvy & Cuppens 1997].
Les politiques d’autorisation utilisées dans les systèmes informatiques constituent la majorité des travaux possédant une base rigoureuse. Afin d’exprimer les objectifs de sécurité, ces politiques d’autorisation introduisent des éléments de modélisation particuliers. En effet, elles impliquent généralement une division de très haut niveau du système entre ses entités actives (appelées les sujets) et passives (appelées les objets), l’introduction d’attributs de sécurité associés aux éléments du système (comme dans le cas des politiques multi-niveaux), ou éventuellement l’utilisation d’une méthode spécifique de modélisation du système (comme dans le cas des poli-tiques de contrôle de flux).

Modèles de sécurité

Cependant, les différentes classes de modèles de sécurité présentées dans la littéra-ture correspondent souvent étroitement à la définition d’une politique de sécurité particulière: par exemple, les modèles basés sur la notion de treillis sont en liaison étroite avec la définition d’une politique multi-niveaux.
L’utilisation d’un modèle de sécurité pour la représentation de la sécurité a pour objectif de définir clairement en langage mathématique ce que décrit la politique de sécurité. Ainsi, les différentes politiques de sécurité étudiées dans la littérature ont également donné lieu à la définition de différentes classes de modèles de sécurité. Par exemple, une politique multi-niveaux est en liaison étroite avec les modèles basés sur la notion de treillis. Toutefois, la définition d’un modèle de sécurité n’est pas seulement guidée par le besoin d’une représentation formelle des objectifs de sécurité et des règles du schéma d’autorisation. Le choix des différents éléments du système pris en compte, des attributs spécifiques de la sécurité qui sont introduits, ainsi que des principes de construction qui apparaissent dans le modèle de sécurité, est également motivé par la nécessité de concevoir un modèle commode. Les critè-res qui conduisent à adopter un modèle particulier viennent principalement de deux sources. D’une part, les problèmes d’application d’un modèle de sécurité à un sys-tème particulier, par exemple un système informatique, motivent l’utilisation de représentations qui tiennent compte des contraintes de mise en œuvre. D’autre part, les propriétés de sécurité recherchées (les objectifs de sécurité) doivent être vérifia-bles ou tout au moins exprimables grâce au modèle utilisé. En définitive, le modèle de sécurité fournit un formalisme permettant de représenter de façon claire et non- ambiguë ce que signifie la sécurité pour le système considéré. Ce formalisme peut également servir de support à la vérification de la cohérence de la politique de sécurité pour ce système. Toutefois, il est possible que la politique de sécurité défi-nie ne puisse pas être vérifiée pour un système particulier à l’aide du modèle consi-déré. La définition du comportement du système quand les propriétés attendues ne sont pas obtenues est aussi une préoccupation qui peut être prise en compte dans le modèle de sécurité. Toutefois, cette situation est ignorée par la plupart des modèles classiques présentés ci-après.

Politiques d’autorisation obligatoire et discrétionnaire

Les politiques d’autorisation peuvent se classer en deux grandes catégories: les politiques discrétionnaires et les politiques obligatoires. Dans les deux cas, on effectue en général une partition des éléments présents dans le système en deux grandes catégories: les entités actives ou sujets (individus, processus, etc.) qui manipulent l’information, et les entités passives ou objets (documents, fichiers, etc.) qui contiennent l’information.
Dans le cas d’une politique discrétionnaire, chaque objet est associé à un sujet pré-cis responsable de l’information contenue dans cet objet (généralement, le proprié-taire) qui peut manipuler librement les droits d’accès de cet objet, à sa discrétion. Le propriétaire de l’information peut donc librement définir et transmettre ces droits à lui-même ou un autre utilisateur. La gestion des accès aux fichiers du système d’exploitation UNIX constitue un exemple classique de mécanismes de contrôles d’accès basés sur une politique discrétionnaire. Sur ce système, trois types d’accès sont définis: read (consultation/lecture), write (modification/écriture) et execute (exécution), et ces droits peuvent s’appliquer soit au propriétaire du fichier, soit à un groupe d’utilisateurs, soit aux autres utilisateurs. Mais supposons qu’un utilisa-teur u1 , propriétaire d’un fichier f 1 , fasse confiance à un utilisateur u2 mais pas à un utilisateur u 3 . u1 donne alors un droit d’accès en lecture à u2 sur le fichier f 1 , mais pas à u3 . Toutefois, u 2 est alors en mesure de faire une copie des informa-tions contenues dans f 1 dans un autre fichier f 2 dont il est lui -même propriétaire. Dans ce cas, u2 est alors aussi en mesure de donner à u 3 un droit en lecture sur cette copie. Ceci constitue une fuite d’informations qu’il est impossible, avec une politique d’autorisation discrétionnaire, de contrôler. De même, une politique dis-crétionnaire ne permet pas de résoudre le problème des chevaux de Troie. Un che-val de Troie est un programme qui, sous couvert de réaliser une action légitime, réalise à l’insu de la personne qui l’utilise une autre action qui peut consister en une attaque contre les règles de sécurité du système. Par exemple, sous UNIX, si l’on réussit à remplacer le programme standard d’authentification d’un nouvel utilisateur login par un programme spécifique, un utilisateur qui se connecte, pensant exécuter la véritable procédure d’authentification, confie son mot de passe à un programme qui peut par exemple le communiquer à un autre utilisateur.
Pour résoudre ce type de problème, les politiques obligatoires imposent, en plus des règles discrétionnaires, des règles incontournables destinées à assurer le respect de propriétés globales. Par exemple, il peut être précisé que des attributs de sécurité doivent être associés à chaque unité d’information dans le système, que ces attributs doivent être propagés à chaque manipulation ou création d’information, et que seuls les utilisateurs explicitement associés à un niveau de sécurité sont en mesure de manipuler ou d’accéder à une information de ce niveau. Ces règles obligatoires per-mettent de garantir que le système maintient une propriété globale de sécurité (con-fidentialité ou intégrité par exemple). Elles viennent s’ajouter aux règles du contrôle discrétionnaire (qui fournissent un principe commode pour régir les droits d’accès) et un utilisateur sera alors autorisé à manipuler une information si les droits corres-pondants lui ont été attribués (contrôle discrétionnaire) et s’il est habilité à le faire (contrôle obligatoire).
Des exemples classiques de politiques obligatoires sont la politique du DoD (Department of Defense) formalisée par Bell et LaPadula [Bell & LaPadula 1975], qui vise à offrir des propriétés de confidentialité, la politique de Biba [Biba 1977] basée sur les mêmes principes mais visant à offrir des propriétés d’intégrité, ou celle de Clark et Wilson [Clark & Wilson 1987] qui formalise des principes plus spécifiques à des systèmes commerciaux. Ces différents exemples sont détaillés dans les sections suivantes.

Modélisation des politiques discrétionnaires

Un certain nombre de modèles ont été définis afin de représenter dans un forma-lisme mathématique les mécanismes associés aux politiques de sécurité discrétion-naires. Nous présentons dans cette section les principaux modèles rencontrés dans la littérature. On notera que ces modèles sont des modèles généraux, qui peuvent également représenter les propriétés rencontrées dans une politique de sécurité obli-gatoire. Toutefois, les politiques obligatoires sont généralement décrites par des modèles spécifiques.

Modèles basés sur les matrices de contrôle d’accès

La notion de matrice de contrôle d’accès, dédiée à la représentation des droits d’accès (autorisations), a d’abord été introduite par [Lampson 1971]. La structure de ce modèle est celle d’une machine à états où chaque état est un triplet (S,O,M), où S est un ensemble de sujets, O un ensemble d’objets (S étant un sous-ensemble de O ), et M est une matrice de contrôle d’accès. La matrice M possède une ligne pour chaque sujet, une colonne pour chaque objet, et est telle que M( s,o) est l’ensemble des droits d’accès que le sujet s possède sur l’objet o. Ces droits d’accès sont pris dans un ensemble fini A , défini par la politique de sécurité, et correspon-dent aux différentes opérations qu’un sujet peut réaliser sur un objet. La matrice des droits d’accès n’est pas figée. Elle évolue dans le temps, en fonction de la création de nouveaux sujets, de nouveaux objets et en fonction des opérations effectuées par les utilisateurs. L’état de sécurité est ainsi changé par toutes les actions qui modi-fient la matrice M.
En règle générale, la plupart des approches basées sur cette notion ajoutent des lignes et des colonnes à la matrice de contrôle d’accès à chaque fois qu’un nouveau processus agissant pour le compte d’un utilisateur est introduit dans le système ou qu’un nouveau fichier est créé. Ces lignes ou ces colonnes sont initialisées avec un certain nombre de valeurs par défaut fixées par les fichiers de configuration de l’uti-lisateur. Un utilisateur peut ultérieurement modifier les droits d’accès des fichiers qu’il a créé (dans une politique de sécurité discrétionnaire), mais n’effectue pas directement des modifications dans la matrice M. En effet, les opérations de modifi-cation des droits d’accès doivent être légitimes, et peuvent aussi être soumises à des contrôles imposés par le schéma d’autorisation (dans une politique de sécurité obli-gatoire), et l’utilisateur réalise ces opérations par le biais d’utilitaires du système qui n’effectuent les modifications demandées que si elles sont conformes à ce schéma d’autorisation.
Ce modèle basé sur les matrices de contrôle d’accès a connu une longue évolution et a été progressivement amélioré, notamment en raison des travaux initiaux de Bell et LaPadula [Bell & LaPadula 1975], et de Harrison, Ruzzo et Ullman [Harrison et al. 1976].

Le modèle HRU

Harrison, Ruzzo et Ullman ont utilisé le modèle de la matrice de contrôle d’accès de Lampson dans le but d’étudier la complexité de la tâche de vérification des pro-priétés assurées par une politique d’autorisation. Pour préciser le contexte de leurs travaux, ils ont considéré un modèle de sécurité particulier, le modèle HRU , analo-gue au modèle de Lampson, mais contenant seulement des commandes de modifi-cation de la matrice M de la forme suivante: command α(x1, x2, …, xk) if aʹ′ ∈ M( sʹ′, oʹ′) and aʺ″ ∈ M( sʺ″, oʺ″) and … and a m ∈ M( s m, o m) then op1;op2;…;opn

La politique de la muraille de Chine

La politique de sécurité dite de “la muraille de Chine”, présentée dans [Brewer & Nash 1989], est une politique de sécurité spécifique issue des règlements de sécurité ayant cours dans les institutions financières britanniques. Dans ce type d’organisation, un souci très particulier est accordé au cloisonnement des différen-tes informations pouvant être relatives à des clients concurrents. Dans le cas où un organisme financier est amené à traiter des opérations pour le compte de deux sociétés concurrentes, les personnels de cet organisme ne sont autorisés à accéder qu’aux informations concernant l’une des deux sociétés. Une fois des informations connues concernant l’une d’elles, tout accès aux informations concernant l’autre doit être interdit. Chaque classe d’information est donc obligatoirement séparée de l’autre par une barrière infranchissable une fois le choix initial effectué (un “mur”, d’où le nom donné à cette politique).
La formalisation de la politique de la muraille de Chine implique de regrouper les informations contenues dans le système en différents ensembles Ec relatifs à cha-cune des organisations extérieures avec lesquelles l’organisation cible de la politi-que de sécurité est en contact. Ces différents ensembles de données sont répartis dans des classes de conflit d’intérêt disjointes: COI1, COI2,…, COIn, comptant chacune mj ensembles de données. On pose: COI j = COI COI COI E1 j E2 j Em j j en notant ECOIk j l’ensemble des données relatives à la kième organisation, apparte-nant à la classe de conflit d’intérêt COIj.
L’objectif de cette politique de sécurité est donc de garantir qu’aucun utilisateur n’accède simultanément à des données appartenant à des ensembles en conflit d’intérêt. Ceci est obtenu en imposant deux règles de fonctionnement triviales : l’accès à une donnée n’est autorisée que si cette donnée appartient à un ensemble auquel l’utilisateur a déjà accédé, ou si cette donnée appartient à un ensemble qui n’est en conflit avec aucun autre ensemble de données auquel l’utilisateur a préala-blement accédé.
Un utilisateur désirant accéder à une donnée d’un ensemble Ec ∈ COI j n’est donc autorisé à y accéder que s’il n’existe pas d’ensemble COIi≠ j contenant des don-nées auxquelles il aurait déjà accédé.
Différents contrôles supplémentaires peuvent éventuellement être associés à une politique de sécurité du type de la muraille de Chine, de manière à contrôler l’accès aux différentes données appartenant à un même ensemble Ec (par exemple des con-trôles multi-niveaux).
L’intérêt de cette politique de sécurité est de mettre en évidence un besoin de sécu-rité réel, qui apparaît même dans la législation britannique, mais qui ne correspond pas aux objectifs des politiques de sécurité classiques et notamment des politiques multi-niveaux.

Limites de ces approches

Les différentes politiques de sécurité ainsi que les modèles éventuellement associés que nous venons de détailler peuvent s’appliquer avec plus ou moins de succès. Dans ce paragraphe, nous nous intéressons aux qualités et aux faiblesses de ces dif-férentes approches selon deux points de vue. D’abord, nous examinons l’impact de l’utilisation de ces méthodologies dans le contexte d’un système d’information quelconque (et pas seulement informatique). Enfin, du point de vue d’un système informatique, pour lequel elles ont souvent été initialement développées, nous iden-tifions les problèmes que ces approches peuvent poser.

Dans le cadre d’un système d’information

Ainsi que nous avons pu le voir, la plupart des modèles de sécurité présentés dans les sections précédentes introduisent des règles de contrôle obligatoires basées sur la définition de niveaux. Ceci montre le rôle majeur joué par les politiques multi-niveaux dans les représentations de la sécurité étudiées jusqu’à présent. On retrouve donc souvent la définition de différents niveaux de confidentialité ou d’intégrité dans l’utilisation qui a pu être faite des modèles de sécurité dans les organisations.
Pourtant, dans une organisation, l’introduction de classifications ou de niveaux d’intégrité pour les données, d’habilitations ou de niveaux d’intégrité pour les indi-vidus, et des règles obligatoires associées, pose un problème majeur. En effet, elle induit une grande rigidité. Une politique de sécurité telle que la politique de confi-dentialité de Bell- LaPadula restreint considérablement les flux d’information auto-risés et, dans tous les cas, impose des contraintes sur la propagation de l’information. Or, dans beaucoup d’organisations, la souplesse des flux d’informa-tion entre individus et l’adaptabilité de l’ensemble de la structure sont généralement considérées comme des atouts. Il en ressort que peu d’organisations peuvent accep-ter de sacrifier leur flexibilité pour mettre en place une telle politique de sécurité, même si elles présentent des besoins de confidentialité. C’est la principale raison qui fait que les politiques multi-niveaux sont essentiellement utilisées dans des organisations militaires ou gouvernementales, une entreprise ne pouvant générale-ment pas tolérer leur mise en place généralisée sans compromettre sa propre effica-cité.
Par ailleurs, certains des besoins de sécurité présents dans ces organisations, comme la séparation des pouvoirs, ou les conflits d’intérêt, ne sont pas directement pris en compte par une politique multi-niveaux. Ce sont ces besoins qui ont conduit à la définition de politiques de sécurité spécifiques comme la politique de Clark et Wilson (cf 1.2.8.1) et la politique de la “muraille de Chine” (cf 1.2.8.2). Ces tra-vaux ont permis d’identifier un certain nombre de préoccupations associées à cer-tains systèmes d’information, et qui donnent parfois l’impression qu’une politique de sécurité, dans ce contexte, doit avant tout être spécifique de l’organisation ou du système auquel elle est censée s’appliquer ([McLean et al. 1984; McLean 1987]). Il importe d’ailleurs, en règle générale, de pouvoir adapter la politique de sécurité à l’organisation considérée, plutôt que de devoir adapter l’organisation à la politique de sécurité choisie comme c’est généralement nécessaire avec les politiques de sécurité que nous avons présentées.
La possibilité d’utiliser les informations disponibles sur la structure du système ou de l’organisation comme support à la définition de sa politique de sécurité consti-tuent des atouts majeurs qui soutiennent les modèles de sécurité basés sur la notion de rôle (cf 1.2.4.2). En effet, si la notion de rôle présente également un intérêt théorique en proposant l’utilisation d’une forme de paramétrage pour la définition des objectifs de sécurité du système, elle présente avant tout un intérêt pratique: elle reflète le fonctionnement du système d’information considéré, et elle permet d’éclaircir la définition et l’évolution éventuelle de la politique de sécurité. Toute-fois, cette approche reste, à l’heure actuelle, indépendante du choix d’une politique de sécurité particulière. Malgré les améliorations apportées par les modèles de sécurité basés sur les rôles, la proposition d’une méthodologie de définition d’une politique de sécurité suffisamment souple pour être adaptable à différents types d’organisations reste un problème ouvert.

Dans le cadre d’un système informatique

Quand on considère leur application à un système informatique, les faiblesses des différentes approches étudiées jusqu’à présent sont de nature assez différentes et dépendent de la politique choisie.
Le problème le plus délicat associé à l’utilisation de la politique de Bell-LaPadula dans un système informatique réside dans la nécessité de vérifier l’absence (ou la très faible capacité) de tous les canaux cachés présents dans le système. Le partage de ressources et la complexité des systèmes informatiques font que les moyens de transmission de l’information par des voies non-conventionnelles sont très nom-breux. Leur identification exhaustive et leur quantification, pourtant indispensable pour la certification du système [TCSEC 1985], sont des problèmes extrêmement complexes, qui retardent considérablement l’introduction de systèmes sûrs basés sur cette approche. À cette validation difficile s’ajoute bien évidemment le problème de surclassification progressive de l’information, inhérent au schéma d’auto-risation de Bell-LaPadula (ou de dégradation dans le cas de celui de Biba), et qui impose l’introduction de mécanismes de déclassification (ou de vérification d’inté-grité) permettant de le résoudre.
Les modèles basés sur le contrôle des interfaces (cf 1.2.7) permettent de choisir des objectifs de sécurité dont les propriétés sont suffisantes pour garantir le contrôle des canaux cachés. Néanmoins, la définition de méthodes de conception de systèmes informatiques correspondant à de tels modèles, et la vérification de l’assurance de propriétés telles que la non-interférence ou la restriction constituent encore le plus souvent des problèmes ouverts [McLean 1994]. Outre l’approche présentée dans [Haigh & Young 1986] s’agissant de la non-interférence, une des rares implémenta-tions basées sur un modèle formel suffisamment puissant pour éviter la recherche et l’élimination spécifique des canaux cachés est basée sur le modèle de causalité (cf 1.2.6) [Calas 1994; Calas 1995]. Toutefois, il semble que cette implémentation ne puisse être utilisée qu’avec un nombre limité de niveaux.
Les modèles généraux basés sur une matrice de contrôle d’accès, présentés au 1.2.4.1, sont indépendants du choix d’une politique de sécurité particulière. Afin de permettre la vérification de propriétés sur le modèle (c’est-à -dire la détermina-tion des états maximaux de la matrice de contrôle d’accès), ils imposent des con-traintes particulières sur le schéma d’autorisation, mais celles-ci restent acceptables (tout au moins dans le cas de TAM). Néanmoins, pour un système réel, de telles vérifications sont généralement coûteuses et incomplètes: on ne peut vérifier, sans faire une énumération totale, qu’il n’est pas possible d’atteindre un état d’insécu-rité. Par ailleurs, l’extension de ces modèles et surtout de leur implémentation vers les systèmes distribués pose de nombreux problèmes. Par exemple, la gestion cen-tralisée d’une matrice de contrôle d’accès couvrant l’ensemble des sites du système a un impact extrêmement négatif sur les performances. Dans la plupart des implé-mentations, la défaillance d’un des sites met en péril la sécurité de l’ensemble du système. L’adaptation des solutions utilisées pour assurer la sécurité d’un système centralisé à des environnements distribués demande ainsi des travaux spécifiques [TNI 1987; Deswarte et al. 1991; Kohl & Neuman 1993]. Ces difficultés peuvent nécessiter l’introduction de concepts nouveaux, encore non -pris en compte formel-lement dans les modèles de sécurité, comme la délégation de droit mise en œuvre grâce à des coupons dans [Nicomette 1996; Nicomette & Deswarte 1997].
Enfin, dans toutes ces approches, il n’est pas possible d’adapter ces politiques de sécurité pour représenter des propriétés de sécurité spécifiques, recherchées pour un système donné à un instant donné. De ce fait, les différents contrôles obligatoires mis en place sur le système sont généralement mal supportés par les utilisateurs qui les jugent inadaptés et trop stricts. Consciemment ou non, ceux-ci introduisent alors des vulnérabilités dans le système en détournant les mécanismes de sécurité. Ce problème correspond tout d’abord à une lacune des modèles de sécurité. Ils sont rarement configurables (à l’exception de ceux introduisant une notion de rôle), et ne permettent pas de faire évoluer les objectifs de la politique de sécurité ni de les adapter à l’organisation. On peut également considérer que la présence de vulnéra-bilités dans un système est une situation inévitable, qui ne constitue pas en tant que telle une menace rédhibitoire pour la sécurité globale, mais qui peut dans certains cas la compromettre plus ou moins. La politique de sécurité du système et le modèle qui la reflète devraient donc intégrer la présence de ces vulnérabilités, en fournissant un moyen de les identifier et de déterminer celles qui sont effectivement dangereuses pour la sécurité.

Table des matières

Chapitre 1 Approches classiques de la sécurité
1.1 Concepts de base
1.1.1 Concepts de sûreté de fonctionnement
1.1.1.1 Définitions
1.1.1.2 Les fautes dues à l’homme
1.1.2 La sécurité-confidentialité
1.1.2.1 Confidentialité
1.1.2.2 Intégrité
1.1.2.3 Disponibilité
1.2 Politiques et modèles de sécurité
1.2.1 Contenu d’une politique de sécurité
1.2.2 Politiques d’autorisation
1.2.2.1 Politiques de sécurité
1.2.2.2 Modèles de sécurité
1.2.3 Politiques d’autorisation obligatoire et discrétionnaire
1.2.4 Modélisation des politiques discrétionnaires
1.2.4.1 Modèles basés sur les matrices de contrôle d’accès
1.2.4.1.1 Le modèle HRU
1.2.4.1.2 Le modèle
1.2.4.1.3 TAM
1.2.4.2 Modèles basés sur la notion de rôle
1.2.5 Les politiques multi-niveaux
1.2.5.1 La politique du DoD
1.2.5.2 La politique d’intégrité de Biba
1.2.6 Les politiques de contrôle de flux
1.2.7 Les politiques de contrôle d’interface
1.2.7.1 Systèmes déterministes: Non-interférence
1.2.7.2 Systèmes non déterministes: Non-déductibilité, Non-interférence Généralisée, Restriction
1.2.8 Les politiques et modèles spécifiques
1.2.8.1 La politique de Clark et Wilson
1.2.8.2 La politique de la muraille de Chine
1.2.9 Limites de ces approches
1.2.9.1 Dans le cadre d’un système d’information
1.2.9.2 Dans le cadre d’un système informatique
1.3 Évaluation de la sécurité
1.3.1 Critères d’évaluation
1.3.1.1 Le livre orange (TCSEC)
1.3.1.2 Les ITSEC
1.3.1.3 Les critères communs
1.3.1.4 Des critères d’évaluation de la sûreté de fonctionnement
1.3.1.5 Conclusion
1.3.2 Analyse des risques
1.3.3 Évaluation quantitative
1.3.3.1 Mesure de l’information
1.3.3.2 Mesures probabilistes
1.3.3.3 Évaluation par utilisation du graphe des privilèges.
1.4 Conclusion
Chapitre 2 Méthode de définition d’une politique de sécurité
2.1 Structure de la méthode
2.1.1 Description d’un système d’information
2.1.1.1 Éléments de base
2.1.1.2 Règles de fonctionnement
2.1.2 Description des objectifs de sécurité
2.1.3 Description des règles de sécurité
2.1.4 Vérification de la cohérence
2.2 Spécification
2.2.1 Intérêt d’une approche formelle
2.2.2 Utilisation d’une logique modale
2.2.3 Définition du langage
2.2.3.1 Langage de la logique déontique
2.2.3.2 Extension du langage
2.2.3.3 Utilisation d’une représentation graphique
2.2.4 Formalisation d’une politique de sécurité
2.2.4.1 Éléments de description
2.2.4.1.1 Éléments de base
2.2.4.1.2 Règles de fonctionnement
2.2.4.2 Objectifs de sécurité
2.2.4.2.1 Description
2.2.4.2.2 Propriétés nécessaires
2.2.4.3 Règles de sécurité
2.2.4.4 Définitions complémentaires
2.2.4.4.1 Notion de privilège
2.2.4.4.2 Notion de vulnérabilité
2.2.4.5 Le problème de la vérification
2.2.4.5.1 Propriétés attendues
2.2.4.5.2 Méthodes de vérification
2.3 Application
2.3.1 Application à une organisation
2.3.1.1 Utilisation de représentations existantes
2.3.1.1.1 Description SRD
2.3.1.2 Obtention des règles de fonctionnement et des éléments de base
2.3.1.2.1 Éléments de base
2.3.1.2.2 Mécanismes et fonctionnement de l’organisation
2.3.1.3 Introduction d’objectifs de sécurité
2.3.1.4 Raffinement
2.3.1.5 Apports
2.3.1.5.1 Clarification des responsabilités
2.3.1.5.2 Recherche des vulnérabilités
2.3.1.6 Exemple d’application: une agence bancaire
2.3.1.6.1 Eléments de base
2.3.1.6.2 Règles de fonctionnement et règles de sécurité
2.3.1.6.3 Objectifs de sécurité
2.3.2 Modélisation de la sécurité informatique
2.3.2.1 Représentation d’un schéma d’autorisation
2.3.2.1.1 Matrice de contrôle d’accès
2.3.2.1.2 Règles de cession de droits
2.3.2.2 Représentation d’une politique de sécurité
2.3.2.2.1 Propriétés d’une politique multi-niveaux
2.3.2.2.2 Notion de capacité
2.3.2.3 Un exemple de système informatique: UNIX
2.3.2.3.1 Formalisation de certaines règles de fonctionnement d’UNIX
2.3.2.3.2 Objectifs de sécurité
2.3.2.3.3 Vulnérabilités considérées
2.4 Perspectives
Chapitre 3 Évaluation de la sécurité
3.1 Une méthode d’évaluation quantitative
3.1.1 Présentation de la méthode
3.1.1.1 Intégration de vulnérabilités dans la description de la sécurité
3.1.1.2 Détermination des vulnérabilités à prendre en compte
3.1.1.3 Quantification des vulnérabilités
3.1.1.4 Évaluation quantitative
3.1.2 Représentation des vulnérabilités: Graphe des privilèges
3.1.2.1 Définition d’une vulnérabilité
3.1.2.2 Construction directe du graphe
3.1.2.3 Exploitation de la spécification logique
3.1.2.3.1 Présentation de la méthode des tableaux
3.1.2.3.2 Exemple d’application
3.1.3 Évaluation quantitative
3.1.3.1 Hypothèses de comportement
3.1.3.2 Mesures
3.1.3.3 Comportements attendus
3.1.3.4 Discussion
3.1.3.5 Validité des mesures
3.2 Mise en oeuvre
3.2.1 Application à un système informatique: UNIX
3.2.1.1 Vulnérabilités étudiées
3.2.1.2 Présentation du système cible
3.2.1.3 Description du prototype
3.2.1.4 Résultats
3.2.1.5 Comparaison des différentes mesures
3.2.1.6 Comparaison avec d’autres outils
3.2.1.7 Conclusion
3.2.2 Application à une organisation
3.2.2.1 Vulnérabilités prises en compte
3.2.2.2 Construction du graphe des privilèges
3.2.2.2.1 Premier cas
3.2.2.2.2 Deuxième cas
3.2.2.3 Évaluation quantitative
3.2.2.3.1 Premier cas
3.2.2.3.2 Deuxième cas
3.2.2.4 Conclusion
Conclusion générale
Annexe A Introduction à la logique modale
A.1 Syntaxe
A.2 Modèles standards
A.3 Schémas d’axiomes
A.4 Les logiques multimodales
A.4.1 Syntaxe
A.4.2 Schémas généraux d’axiomes
A.4.3 Détermination
A.4.4 Décidabilité
Annexe B Analyse détaillée des événements de sécurité
Références bibliographiques

Télécharger le rapport complet