Approches classiques de la sécurité

Dans ce chapitre, nous passons en revue les différentes approches de la sécurité représentées dans la littérature. Dans une première étape, nous présentons les concepts de base correspondant à l’étude de la sécurité en tant qu’attribut composite du domaine plus général de la sûreté de fonctionnement. Ensuite, nous examinons les principaux modèles de sécurité et les principales politiques de sécurité utilisés dans l’étude de la sécurité des systèmes informatiques. Enfin, nous présentons les différentes approches associées à l’évaluation, ou plus précisément à la validation, de la sécurité.

Concepts de base

Nous présentons dans cette section les concepts de base et la terminologie relatifs à la sûreté de fonctionnement, propriété générale des systèmes englobant les notions habituelles de fiabilité, disponibilité, sécurité, etc. La sécurité représente un attribut particulier de la sûreté de fonctionnement. Cette partie est adaptée de[Laprie 1995].

Concepts de sûreté de fonctionnement

Définitions

La sûreté de fonctionnement d’un système informatique est la propriété qui permet à ses utilisateurs de placer une confiance justifiée dans le service qu’il leur délivre. Le service délivré par un système est son comportement tel que perçu par son, ou ses utilisateurs; un utilisateur est un autre système (humain ou physique) qui interagit avec le système considéré.
Selon la, ou les applications auxquelles le système est destiné, l’accent peut être mis sur différentes facettes de la sûreté de fonctionnement, ce qui revient à dire que la sûreté de fonctionnement regroupe des propriétés différentes mais complémentaires, qui permettent de définirses attributs:
• le fait d’être prêt à l’utilisation conduit à la disponibilité;
• la continuité de service conduit à la fiabilité;
•la non-occurrence de conséquences catastrophiques pour l’environnement conduit à la sécurité innocuité;
•la non-occurrence de divulgations non-autorisées de l’information conduit à la confidentialité;
•la non-occurrence d’altérations inappropriées de l’information conduit à l’intégrité;
• l’aptitude aux réparations et aux évolutions conduit à la maintenabilité.
L’ as s ociation de la confidentialité, de l’ intégr ité et de la dis ponibilité vis – à- vis des actions autorisées conduit à la sécurité-confidentialité.
Une défaillancedu système survient lorsque le service délivré dévie de l’accomplissement de la fonction du système, c’est-à-dire ce à quoi le système est destiné.
Une erreurest la partie de l’état du système qui est susceptible d’entraîner une défaillance: une erreur affectant le service est une indication qu’une défaillance survient ou est survenue. Une fauteest la cause adjugée ou supposée d’une erreur.

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 produise 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îtintè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 corruption 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 exemple 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 accompagnant 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’information elle même, ou utiliser des mécanismes plus sophistiqués comme les algorithmes 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 systè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 communication, 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 également ê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 surchargeant le système lui-même, afin que le temps de traitement d’une opération particuliè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 circonstances 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 d’autorisation

Politiques de sécurité

Les politiques de sécurité s’attachent donc à définir des propriétés de sécurité désiré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écurité, spécifiant simultanément les propriétés désirées et les règles devant être appliqué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’assentiment 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 politiques decontrô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érature 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.

Politiques d’autorisation obligatoire et discrétionnaire

L’ utilisation d ’ u n 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 systè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érifiables 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éfinie ne puisse pas être vérifiée pour un système particulier à l’aide du modèle considé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 UNIXconstitue 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 utilisateur , propriétaire d’un fichier , fasse confiance à un utilisateur mais pas à un utilisateur . donne alors un droit d’accès en lecture à sur le fichier , mais pas à . Toutefois, est alors en mesure de faire une copie des informations contenues dans dans un autre fichier dont il est lui-même propriétaire.
Dans ce cas, est alors aussi en mesure de donner à 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 discrétionnaire ne permet pas de résoudre le problème des chevaux de Troie. Un cheval 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 loginpar 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.

Table des matières
Introduction générale
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 Take-Grant
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 œuvre
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