Soutenance mémoire
Intégrité
L’intégrité de l’information est la propriété qu’elle soit « correcte », c’est-à-dire qu’elle reflète la réalité, tout le temps. Cela signifie que le système informatique doit permettre les actions autorisées, forcer les actions obligatoires et empêcher les actions malveillantes afin de garantir l’intégrité des informations stockées dans ce système. En particulier, il doit:
– forcer la création d’une information devant être créée,
– permettre la création autorisée de l’information,
– permettre une modification autorisée de l’information,
– empêcher une modification indue de l’information, c’est-à-dire une modification par des utilisateurs non autorisés ou une modification incorrecte par des utilisateurs autorisés,
– faire en sorte qu’aucun utilisateur ne puisse empêcher la modification légitime de l’information ; par exemple, empêcher la mise à jour périodique d’un compteur de temps serait une atteinte contre l’intégrité.
Pour assurer cette propriété, le système doit mettre en œuvre des mécanismes garantissant la création légitime de l’information, des mécanismes vérifiant que les mises à jour effectuées sont autorisées et valides, des mécanismes garantissant la réalisation des mises à jour devant être effectuées ainsi qu’éventuellement des mécanismes vérifiant la correspondance entre l’information et ce qu’elle représente. Cette définition peut être interprétée dans un sens très général. En particulier, des opérations non autorisées peuvent affecter aussi bien des parties physiques du système que des parties logiques. Le premier type d’altération consiste à modifier un composant physique, par exemple la modification d’une carte à puce par faisceau ionique. Nous nous intéressons tout particulièrement aux altérations qui portent sur les parties logiques du système, c’est-à-dire les programmes et les informations. Ainsi définie, l’intégrité des informations peut être mise en défaut par des fautes intentionnelles mais aussi par des fautes accidentelles. Dans le cadre des fautes intentionnelles, il est nécessaire d’empêcher toute altération non autorisée de l’information. De plus, même si un utilisateur est autorisé à modifier une donnée, il faut empêcher les abus de pouvoir, c’est-à-dire empêcher que cet utilisateur, par exemple un administrateur système, ne profite de ses droits pour altérer une information de manière inappropriée. Dans le cadre des fautes accidentelles, on doit s’assurer que chaque programme se comporte de manière correcte, c’est-à-dire conformément aux fonctions qu’il est censé remplir, y compris dans ses interactions avec les autres processus. Cela revient à dire qu’il doit être suffisamment fiable pour qu’on puisse assurer qu’il n’effectuera pas une action non conforme au bon fonctionnement du système. Une atteinte contre l’intégrité vise, soit à introduire de fausses informations soit, à provoquer des erreurs en modifiant ou en détruisant l’information, pour que le service délivré par le système produise un bénéfice pour l’attaquant, au détriment des utilisateurs autorisés. C’est typiquement le cas des fraudes informatiques, où l’attaquant La sécurité informatique : de la prévention à la tolérance aux attaques essayera de faire en sorte que les erreurs qu’il introduit ne soient pas détectables et que les défaillances qui en résultent ne soient pas identifiables.
Politiques et modèles de sécurité
Une politique de sécurité est définie comme “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écifique” [ITSEC 91]. Elle définit d’une part l’ensemble des propriétés de sécurité qui doivent être satisfaites par le système, c’est-à-dire des propriétés de confidentialité, d’intégrité, et de disponibilité, et d’autre part les règles de sécurité qui sont imposées au comportement du système dans le but d’obtenir et de maintenir ces propriétés. Par exemple, une propriété de sécurité pourra être “une information classifiée confidentielle ne doit pas être transmise à un utilisateur non habilité à la connaître”, alors qu’une règle du schéma d’autorisation pourra être “le propriétaire d’une information peut accorder un droit d’accès pour cette information à n’importe quel utilisateur”. Si la politique d’autorisation est cohérente, il ne doit pas être possible, partant d’un état initial sûr (c’est-à-dire satisfaisant les propriétés de sécurité), d’atteindre un état d’insécurité (c’est-à-dire un état où les propriétés de sécurité ne sont pas satisfaites) en appliquant les règles du schéma d’autorisation [Deswarte et al. 03]. Les règles de sécurité expriment des contraintes sur le comportement du système en exprimant les opérations autorisées et celles qui sont interdites. Dans une politique de sécurité, les règles doivent satisfaire les objectifs de sécurité (confidentialité, intégrité, et disponibilité), en fait, l’application de ces règles doit avoir comme conséquence la garantie des propriétés de sécurité du système. La violation d’une règle de sécurité ne constitue pas nécessairement une défaillance vis-à-vis de la sécurité, c’est-à-dire le non respect d’une propriété de sécurité, mais peut rendre le système plus vulnérable. Ainsi, par exemple, une règle peut spécifier que les mots de passe doivent être choisis de manière aléatoire dans un espace de données suffisamment grand. La violation d’une telle règle ne constitue pas immédiatement une défaillance vis-à-vis de la sécurité, mais expose le système à des attaques par dictionnaire sur les mots de passes.
!Détection d’intrusion
La détection d’intrusion a été introduite par Anderson [Anderson 80] qui a été le premier à montrer l’importance de l’audit de sécurité dans le but de détecter les éventuelles violations de la politique de sécurité d’un système. Il y a deux approches principales dans la détection d’intrusion : 1) la détection d’anomalies (anomaly detection), et 2) la détection d’attaques (misuse detection). La première approche consiste à d’abord modéliser le comportement normal du système, afin de reconnaître par la suite un comportement corrompu. Le modèle est généralement construit par une période d’apprentissage. L’apprentissage peut se faire dans l’environnement normal du système cible pour permettre au système de détection d’intrusion d’apprendre progressivement les comportements normaux de celui-ci [Forrest et al. 96]. Pour d’autres systèmes plus figés (le comportement du système n’évolue pas dans le temps), la phase d’apprentissage peut se faire à partir des séquences de tests exhaustives décrivant toutes les configurations possibles des actions normales prévues pour le système cible [Debar et al. 98]. Après la période d’apprentissage, le modèle reste stable. Dans ce cas, il est difficile qu’un attaquant parvienne à détourner l’IDS en modifiant le comportement du système. Dans d’autres systèmes, l’apprentissage est continu, pendant toute la vie opérationnelle du système, le modèle évoluant alors en fonction de l’évolution de l’usage qu’on est fait. Néanmoins, il est alors possible qu’un attaquant (par exemple, un utilisateur interne malveillant) parvienne à détourner ce type d’IDS en modifiant lentement son comportement afin de parvenir à un comportement intrusif qui, ayant été progressivement appris, ne sera pas détecté : c’est un faux négatif. La deuxième approche consiste à modéliser non plus des comportements normaux, mais modéliser des comportements interdits. Dans ces cas, on analyse les événements observés à la recherche de scénarios d’attaques prédéfinis représentés dans une base de signatures d’attaques (par exemple, SNORT). Cette approche génère des alertes plus crédibles mais ne permet pas de détecter que les attaques connues. La construction du modèle de comportement normal peut se faire de différentes manières [Mé et al. 01] :
1) Méthodes statistiques : le profil est calculé à partir de variables, comme le temps processeur utilisé ou la durée et l’heure des connexions, échantillonnées à intervalles réguliers. Un modèle statistique est utilisé pour construire la distribution de chaque variable et pour mesurer, au travers d’une grandeur La sécurité informatique : de la prévention à la tolérance aux attaques 36 synthétique, le taux de déviation entre un comportement courant et le comportement passé [Denning 86].
2) Immunologie : cette approche permet de construire un modèle de comportement normal des services (et non des utilisateurs) au travers de courtes séquences d’appels système caractérisant l’exécution normale des services considérés. En phase de détection, toute séquence étrangère à cet ensemble est considérée comme attaque potentielle [Forrest et al. 96].
3) Graphes : certaines approches de détection d’anomalies utilisent des modèles à base de graphes pour mettre en évidence des propriétés et des relations entre ces propriétés. L’intérêt de cette approche est qu’elle permet de traiter plus facilement des événements rares [Cheung et al. 99].
4) Approche bayésienne : les réseaux bayésiens permettent de modéliser des situations dans lesquelles la causalité joue un rôle, mais où la connaissance de l’ensemble des relations entre les phénomènes est incomplète, de telle sorte qu’il est nécessaire de les décrire de manière probabiliste. Les indications obtenues progressivement sur l’état du système modélisé influent sur la confiance que l’on accorde à une hypothèse donnée [Bronstein et al. 01]. Les IDS peuvent également se classer selon deux catégories majeures selon qu’ils s’attachent à surveiller le trafic réseau ou l’activité des machines. On parle d’IDS sur réseau (network based IDS) ou d’IDS sur calculateur (host based IDS).
– IDS sur réseau : ces outils analysent le trafic réseau ; ils comportent généralement une sonde qui surveille ce qui se passe sur le segment de réseau ainsi qu’un moteur qui réalise l’analyse du trafic afin de détecter les signatures d’attaques ou les divergences face au comportement de référence. Les IDS Réseau à base de signatures sont confrontés actuellement à deux problèmes majeurs qui sont le développement de l’utilisation du chiffrement et le développement des réseaux commutés. En effet, il est d’une part plus difficile de contrôler le trafic sur les réseaux commutés et le chiffrement rend l’analyse du contenu des paquets presque impossible. La plupart des IDS sur réseau sont aussi dits IDS inline car ils analysent le flux en temps réel.
– IDS sur calculateur : ils analysent quant à eux le fonctionnement ou l’état des machines sur lesquelles ils sont installés afin de détecter les attaques. Ils sont très dépendants du système sur lequel ils sont installés. Il faut donc des outils spécifiques en fonction des systèmes déployés. Ces IDS peuvent s’appuyer sur des fonctionnalités d’audit du système d’exploitation ou sur d’autres capteurs pour contrôler l’état du système et générer des alertes. Il faut cependant noter qu’ils sont mal adaptés pour détecter les attaques affectant les couches réseaux de la machine, typiquement les dénis de service comme ″SYN flood″ ou autre.
Les malveillances
Deux principales classes de fautes sont à considérer dès lors que nous nous intéressons aux fautes malveillantes: les logiques malignes et les intrusions. Les logiques malignes sont des parties du système conçues pour provoquer des dégâts (bombes logiques) ou pour faciliter des intrusions futures (vulnérabilités créées volontairement, par exemple les portes dérobées). Les logiques malignes peuvent être introduites dès la création du système (par un concepteur malveillant), ou en phase opérationnelle, par l’installation d’un logiciel contenant un cheval de Troie ou par une intrusion. La définition d’une intrusion est étroitement liée aux notions d’attaques et de vulnérabilité :
– Attaque : faute d’interaction malveillante visant à violer une ou plusieurs propriétés de sécurité. C’est une faute externe créée avec l’intention de nuire, y compris les attaques lancées par des outils automatiques : vers, virus, zombies, etc.
– Vulnérabilité : faute accidentelle ou intentionnelle (avec ou sans volonté de nuire), dans la spécification des besoins, la spécification fonctionnelle, la conception ou la configuration du système, ou dans la façon selon laquelle il est utilisé. La vulnérabilité peut être exploitée pour créer une intrusion.
– Intrusion : faute malveillante interne, mais d’origine externe, résultant d’une attaque qui a réussi à exploiter une vulnérabilité… Il existe toujours deux causes sous-jacentes à une intrusion (figure 2.3) :
– une action malveillante ou attaque qui tente d’exploiter une faiblesse dans le système,
– au moins une faiblesse, faille ou vulnérabilité, qui est une faute accidentelle ou intentionnelle (avec ou sans volonté de nuire), introduite dans la spécification, la conception, la configuration du système, ou dans l’opération du système.
Des exemples typiques d’intrusions interprétées en termes de vulnérabilités et attaques sont:
– Un intrus externe ou «outsider» qui pénètre dans le système en devinant un mot de passe d’un utilisateur: la vulnérabilité se trouve dans la configuration du système, qui n’impose de contraintes assez fortes sur les mots de passe (trop courts, vulnérables aux attaques par dictionnaire).
– Un intrus interne ou «insider» qui abuse de son pouvoir : la vulnérabilité réside dans la spécification et la conception ou l’opération du système socio-technique (violation du principe du moindre privilège, procédure d’habilitation trop laxiste des personnels).
– Une attaque en déni de service par surcharge de requêtes (comme les attaques DDoS de sites Webs en février 2000) : la vulnérabilité réside en partie dans les spécifications-mêmes du système puisqu’il est contradictoire d’exiger qu’un système soit totalement ouvert à des utilisateurs bien intentionnés et fermé aux utilisateurs malveillants. Ce type particulier d’attaque exploite aussi des fautes de conception ou de configuration dans les nombreux hôtes connectés à Internet qui ont été piratés pour insérer des processus zombies nécessaires au montage d’une attaque distribuée et coordonnée. Une troisième vulnérabilité, qui empêche de lancer des contre-mesures efficaces, repose sur une faute de conception de ceux des fournisseurs de services Internet qui n’implémentent pas de filtrage en entrée et en sortie (ingress/egress filtering) qui permettrait de tracer l’adresse IP source de l’attaque, et donc dissuader des attaquants potentiels.
|
Table des matières
Introduction générale
Chapitre 1 La sécurité informatique!: de la prévention à la tolérance aux attaques
1.1 Définitions
1.1.1 Confidentialité
1.1.2 Intégrité
1.1.3 Disponibilité
1.1.4 Autres propriétés de sécurité
1.2 Vulnérabilités et attaques
1.3 Politiques et modèles de sécurité
1.3.1 Politiques d’autorisation
1.3.1.1 Politiques discrétionnaires (Discretionary Access Control)
1.3.1.2 Politiques obligatoires (Mandatory Access Control)
1.3.1.3 Politiques de contrôle de flux
1.3.1.4 Politique de sécurité basée sur les rôles (RBAC)
1.3.1.5 Or-BAC (Organization-based Access Control)
1.3.2 Politiques et modèles pour la disponibilité
1.4 Mise en oeuvre de la sécurité
1.4.1 Protection centralisée
1.4.2 L’approche du livre rouge
1.4.3 Le schéma d’autorisation de MAFTIA
1.4.4 Autres mécanismes de sécurité
1.4.4.1 Audit
1.4.4.2 Pare-feu
1.4.4.3 Détection d’intrusion
1.5 Conclusion
Chapitre 2 La tolérance aux intrusions
2.1 La sûreté de fonctionnement
2.1.1 Les concepts de la sûreté de fonctionnement
2.1.2 Notions de fautes, erreurs, défaillances
2.1.2.1 Défaillances
2.1.2.2 Erreurs
2.1.2.3 Fautes
2.1.2.4 Pathologie des fautes
2.1.3 Les malveillances
2.2 La tolérance aux fautes
2.3 Tolérance aux intrusions et survivabilité
2.3.1 Techniques de tolérance aux fautes intentionnelles
2.3.1.1 Quelques techniques classiques
2.3.1.2 La Fragmentation-Redondance-Dissémination
2.3.1.3 Techniques basées sur les schémas à seuil
2.3.1.4 La redondance avec diversification
2.3.2 Mise en œuvre de la tolérance aux intrusions!: exemples d’architectures tolérant les intrusion
2.3.2.1 L’architecture Delta4
2.3.2.2 Malicious and Accidental Fault Tolerance for Internet Applications (MAFTIA)
2.3.2.3 PASIS (Perpetually Available and Secure Information Storage)
2.3.2.4 SITAR (A Scalable Intrusion-Tolerant ARchitecture for Distributed services)
2.3.2.5 Intrusion Tolerant Database System (ITDB)
2.4 Conclusion
Chapitre 3 Une architecture tolérante aux intrusions pour serveurs Internet
3.1 Systèmes cibles
3.2 Modèle de fautes et hypothèses des attaques
3.3 Une architecture tolérant les intrusions pour des systèmes à contenu statique
3.3.1 Originalité
3.3.2 Composants
3.3.2.1 Les mandataires
3.3.2.2 Serveurs d’application
3.3.2.3 Mécanismes de détection
3.3.3 La politique de tolérance aux intrusions!: gestion des répliques et réponse aux alertes
3.3.3.1 Politique de tolérance aux intrusions!: cas de l’architecture mono-mandataire
3.3.3.2 Politique de tolérance aux intrusions!: cas d’une architecture multi-mandataires
3.4 Une architecture tolérant les intrusions pour des systèmes à contenu dynamique
3.4.1 Composants
3.4.1.1 Le serveur de base de données
3.4.1.2 Les mandataires
3.4.1.3 Serveurs d’application
3.4.1.4 Prise en compte de l’adjudicateur dans la politique de tolérance aux intrusions
3.4.2 Exemples
3.4.2.1 Déroulement «!normal!» d’une requête
3.4.2.2 Détection de la corruption d’un serveur
3.5 Discussion
3.6 Conclusion
Chapitre 4 Mise en œuvre d’un prototype et mesures de performances
4.1 Implémentation
4.1.1 Plateforme expérimentale
4.1.2 Les mandataires
4.1.2.1 Le gestionnaire des alertes
4.1.2.2 Les modules spécifiques
4.1.3 Les serveurs d’application
4.1.3.1 La bibliothèque de base de données (DITSQL)
4.1.3.2 Le médiateur
4.2 Mesures de performances
4.2.1 Première mesure
4.2.2 Deuxième mesure
4.2.3 Troisième mesure
4.3 Conclusion
Conclusion générale
Bibliographie
Télécharger le rapport complet
