Architecture classique d’IDS

Détection d’intrusions

La détection d’intrusions est née, au début des années 80, de la nécessité d’automatiser les tâches d’audit des systèmes informatiques [And80,Den87,Lun88]. En effet, il est parfois possible, pour un utilisateur malveillant, de contourner les mécanismes de prévention et donc de violer la politique de sécurité que mettent en œuvre ces mécanismes. Une telle violation de politique engendre généralement des effets de bord sur le système. Il est donc du ressort de l’administrateur du système d’analyser régulièrement l’état du système et de vérifier qu’il n’a pas été compromis. Cette tâche d’audit suppose un mécanisme d’enregistrement des événements du système au sein de «journaux» et une phase d’analyse des journaux afin d’identifier une éventuelle violation de la politique.

L’objectif de la détection d’intrusions est d’automatiser la tâche d’audit. Il s’agit bien, théoriquement, de détecter de manière automatique les violations de politique de sécurité, qu’on appelle intrusions. Dans la pratique, les outils actuels ne sont cependant pas configurés directement par la politique. Aussi, s’ils détectent certaines intrusions, détectent-ils aussi les tentatives d’intrusions infructueuses, ce qui n’est pas toujours souhaité. En outre, la relative naïveté des algorithmes de détection conduit à un nombre élevé d’alertes, dont une part significative est en fait constituée de fausses alertes ou faux positifs. Enfin, certaines intrusions peuvent ne pas être détectées. On parle alors de faux négatifs.

Afin de qualifier un détecteur d’intrusion, ou IDS pour Intrusion Detection System, on s’intéresse à sa fiabilité, qui est sa capacité à émettre une alerte pour toute violation de la politique de sécurité, et à sa pertinence, qui est sa capacité à n’émettre une alerte qu’en cas de violation de la politique de sécurité. Un IDS fiable présente un faible taux de faux négatif (il devrait idéalement être caractérisé par l’absence de faux négatif) ; un IDS pertinent présente un faible taux de faux positif (il devrait idéalement être caractérisé par l’absence de faux positif).

Les IDS actuels ne sont ni fiables ni pertinents. Notre conviction est qu’une des causes essentielles de cet état de fait est l’empirisme qui préside à la conception de ces outils. Notre objectif est donc de proposer une approche formelle, dans laquelle le modèle de détection implanté dans l’IDS présente des capacités que l’on peut prouver.

Architecture classique d’IDS

Le capteur

Le capteur observe l’activité du système par le biais d’une source de données et fournit à l’analyseur une séquence d’événements qui informe de l’évolution de l’état du système. Le capteur peut se contenter de transmettre directement ces données brutes, mais en général un prétraitement est effectué. Ce traitement permet, par exemple, de filtrer un certain nombre de données considérées comme non pertinentes afin de limiter la quantité d’information à analyser par la suite. De plus, le capteur réalise généralement une mise en forme des données brutes acquises afin de présenter à l’analyseur des données utilisant un certain format d’événements. Ces fonctions sont, par exemple, réalisées par les modules Preprocessors et Decoder de l’IDS open-source SNORT . On distingue classiquement trois types de capteurs en fonction des sources de données utilisées pour observer l’activité du système :

– Les capteurs système qui collectent des données produites par les systèmes d’exploitation des machines, notamment par le biais des journaux d’audit système ou par celui des appels système invoqués par les applications. On désigne les IDS utilisant des capteurs système par l’acronyme HIDS (Host-based IDS).
– Les capteurs réseau qui collectent les données en écoutant le trafic réseau entre les machines par le biais d’une interface spécifique. On parle alors de NIDS (Network-based IDS).
– Les capteurs applicatifs qui collectent les données produites par une application particulière, avec laquelle des utilisateurs sont susceptibles d’interagir, comme un serveur web ou un serveur de base de données. L’application doit alors être instrumentée à cet effet.

L’avantage principal des capteurs réseau réside dans leur capacité à surveiller un grand ensemble de machines. Cette caractéristique simplifie le déploiement et la maintenance d’une solution de détection visant à garantir une couverture optimale du réseau surveillé. L’approche système est plus complexe à déployer car elle nécessite une multiplication du nombre de capteurs dans le réseau. De plus, le coût engendré par la collecte des données par ces capteurs peut dégrader sensiblement les performances des systèmes sur lesquels ils sont installés.

Cependant, on peut s’interroger sur la pérennité des capteurs réseaux pour trois raisons principales. Premièrement, la montée en débit des réseaux contraint fortement les capacités de collecte de l’intégralité du trafic. Les constructeurs de NIDS ont recours à des capteurs matériels spécifiques pour accélérer la collecte, mais la détection d’intrusions dans le cœur de réseau peut poser problème car seules certaines données peuvent être prises en compte. L’inspection de la totalité des paquets n’étant pas envisageable, les IDS pour les réseaux à haut débit doivent échantillonner les données et l’analyse ne porte souvent que sur l’entête et la détection reste imprécise [GSB06]. Deuxièmement, les capteurs réseau ne peuvent analyser le trafic chiffré. Or, la prise en compte progressive des problèmes de sécurité tend à généraliser l’utilisation du chiffrement dans les protocoles réseau, rendant à terme les capteurs réseau inopérants [ACF+00,LaP99]. Enfin, l’analyse seule du trafic réseau s’avère souvent insuffisante pour assurer une détection fiable et pertinente des violations de politique de sécurité, l’IDS ne disposant que de trop peu d’information sur les systèmes attaqués [ACF+00].

L’analyseur

L’objectif de l’analyseur est de déterminer si le flux d’événements fourni par le capteur contient des éléments caractéristiques d’une activité malveillante. Deux grandes approches ont été proposées, l’approche comportementale (anomaly detection) et l’approche par scénarios (misuse detection) :
– Dans l’approche comportementale, une attaque est qualifiée par la mesure d’une déviation sensible du système surveillé par rapport à un comportement de référence, réputé sain et défini auparavant.
– Dans l’approche par signatures, le système de détection possède une base de signatures qui modélisent les différentes attaques connues. L’analyse consiste à rechercher l’occurrence d’un motif caractéristique d’une attaque dans le flux d’événements.

L’approche par signature est actuellement la plus commune. Elle s’appuie sur une base de signatures d’attaques. Le système de détection consiste alors à reconnaître la présence de signatures parmi les traces d’audit fournies par les observateurs. Plusieurs techniques ont été proposées qui reposent en général sur des mécanismes de reconnaissance de motif ou pattern matching. Le pattern matching est une méthode simple à mettre en œuvre. Cependant, la difficulté vient de la définition des motifs. En effet, ceux-ci doivent être suffisamment précis pour pouvoir discriminer les différents types d’attaques, mais également suffisamment génériques pour pouvoir détecter les différentes variantes d’un même type d’attaque. Une signature trop générique conduira à l’augmentation du nombre de faux positifs, diminuant ainsi la fiabilité. La technique de détection par scénarios nécessite en outre une maintenance active du système pour mettre à jour régulièrement la base de signatures. En effet, le système ne peut détecter que des attaques connues a priori : il faut donc pouvoir réactualiser cette connaissance. Ceci implique notamment un coût de maintenance important. De plus, se pose le problème du choix du langage de signature pour lequel il n’existe pas, pour l’instant, de réel standard, même si l’on peut considérer, dans la pratique, que les signatures « à la SNORT » constituent un standard de facto. En théorie, cette approche devrait produire peu de faux positifs car le système possède des connaissances a priori sur les attaques.

Le manager

Le manager est responsable de la présentation des alertes à l’opérateur (fonction de console de management). Il peut également réaliser les fonctions de corrélation d’alertes, dans la mesure de leur disponibilité. Enfin, il peut assurer le traitement de l’incident, par exemple au travers des fonctions suivantes :
– confinement de l’attaque, qui a pour but de limiter les effets de l’attaque ;
– éradication de l’attaque, qui tente d’arrêter l’attaque ;
– recouvrement, qui est l’étape de restauration du système dans un état sain ;
– diagnostic, qui est la phase d’identification du problème, de ses causes et qui peut éventuellement être suivi d’actions contre l’attaquant (fonction de réaction).

Du fait du manque de fiabilité des systèmes de détection d’intrusions actuels, les réactions sont rarement automatisées, car elles peuvent se traduire par un déni de service en cas de réaction à des faux positifs.

Approche comportementale

Cette approche repose sur la modélisation d’un «comportement normal» du système ou de l’entité surveillée, appelé profil, et la détection des écarts par rapport à ce profil. Il en découle deux problèmes majeurs :
– la définition du «comportement normal» et la construction du profil de référence ;
– la définition des critères de déviation et la fixation des seuils associés.

Profil généré par apprentissage

Classiquement, la détection d’une anomalie repose sur un modèle statistique du comportement des utilisateurs. Denning a ainsi identifié trois familles de modèles statistiques [Den87] :
– les modèles simples utilisant des seuils sur des variables. Ces variables peuvent correspondre à la fréquence d’apparition d’un événement. Ce modèle simple est parfois utilisé par d’autres composants logiciels comme les mécanismes d’authentification. Ceux-ci considèrent en effet comme «anormal» un nombre d’échecs successifs donné, lors de la phase d’authentification par identifiant et mot de passe ;
– les modèles utilisant les moments statistiques (moyenne, écart-type, etc.). Ces modèles offrent plus de souplesse et permettent de mieux discriminer les comportements anormaux. Cependant, ils reposent sur l’hypothèse que le comportement «normal» d’un utilisateur peut être modélisé par une loi statistique, ce qui n’est pas toujours le cas ;
– les modèles dérivés du modèle de Markov. Les événements ne sont alors plus considérés indépendamment les uns des autres mais en séquence. Le modèle considère en effet les différents états successifs du système. Lorsque le système change d’état, l’IDS vérifie la probabilité d’occurrence de cette transition. Si cette dernière est suffisamment faible, le comportement observé est considéré comme anormal.

Les deux premières catégories permettent d’établir facilement un modèle comportemental. Néanmoins, leur pouvoir de discrimination est relativement limité et les nouveaux modèles comportementaux d’IDS appartiennent généralement à la dernière catégorie. Forrest propose par exemple de s’intéresser aux séquences d’appels système [FHS97]. L’auteur utilise l’exemple du système immunitaire qui est capable chez les êtres vivants de distinguer les corps étrangers des cellules appartenant à l’individu. Bien que les différentes cellules possèdent des caractéristiques variables du fait de la diversité des fonctions assurées, le système immunitaire dispose d’une définition assez précise du «soi», c’est-à-dire de l’ensemble des caractéristiques définissant les cellules appartenant à un même individu. Un tel système peut efficacement détecter des corps étrangers, même s’il ne les a jamais vus auparavant. L’auteur a établi expérimentalement que des séquences courtes d’appels système (typiquement 6 appels successifs) constituent de bonnes signatures comportementales d’un processus donné. Cette signature varie d’un processus à un autre, mais reste spécifique à chaque type d’application. Une intrusion se traduit par un comportement anormal d’un programme donné qui voit sa signature évoluer sensiblement.

L’auteur a expérimenté cette approche en développant un prototype d’HIDS. La source d’information est constituée des traces d’appels système qui sont systématiquement analysées. L’IDS implémentant cette technique fonctionne alors en deux temps :
– dans un premier temps, l’IDS constitue une base de données d’apprentissage. Les signatures sont obtenues par une technique de fenêtres glissantes ;
– dans un deuxième temps, l’IDS compare les séquences d’appels systèmes observées avec les signatures de la base et comptabilise le nombre de disparités. En dessous d’un certain seuil de concordance, l’IDS considère le comportement du système comme anormal et lève une alerte.

Cette approche constitue un moyen simple pour établir un profil de référence et mettre en œuvre un mécanisme de détection comportemental. Toutefois, les performances de cette technique restent difficiles à prévoir car beaucoup de paramètres sont fixés de manière empirique. Ce problème est d’ailleurs caractéristique des modèles comportementaux qui établissent le profil de référence par apprentissage. En outre, ces modèles considèrent qu’un comportement anormal au sens statistique du terme caractérise une intrusion. Or ce n’est pas toujours le cas et cela conduit à un nombre important de faux positifs [LJ99, ACF+00].

Table des matières

INTRODUCTION
1 Etat de l’art
1.1 Détection d’intrusions
1.1.1 Architecture classique d’IDS
1.1.1.1 Le capteur
1.1.1.2 L’analyseur
1.1.1.3 Le manager
1.1.2 Approche comportementale
1.1.2.1 Profil généré par apprentissage
1.1.2.2 Modèle par spécification du comportement des programmes
1.1.2.3 Approche paramétrée par la politique de sécurité
1.2 Contrôle de flux d’informations
1.2.1 Approches statiques
1.2.1.1 Certification de programme et politique en treillis
1.2.1.2 Non-interférence
1.2.1.3 Contrôle de flux d’informations par système de types
1.2.1.4 Mise en pratique
1.2.1.5 Bilan sur le contrôle statique de flux d’informations
1.2.2 Approches dynamiques
1.2.2.1 Contrôle par moniteur externe
1.2.2.2 Contrôle par instrumentation
1.2.2.3 Bilan sur le contrôle dynamique des flux d’informations
1.2.3 Bilan général sur le contrôle des flux d’informations
1.3 Bilan de l’état de l’art
2 Proposition d’un modèle de détection d’intrusions
2.1 Contenus, conteneurs et flux d’informations
2.1.1 Conteneurs d’informations
2.1.2 Contenus
2.1.3 Commande, trace et flux d’informations
2.1.3.1 Flux d’informations
2.1.3.2 Commande et flux d’informations élémentaire
2.1.3.3 Traces d’exécution et flux d’informations composés
2.2 Politique de flux d’informations
2.2.1 Définitions
2.2.1.1 Politique de flux d’informations et CCAL
2.2.1.2 Violation de la politique de flux d’informations
2.2.2 Création et suppression de conteneurs
2.2.3 Initialisation de la politique de flux d’informations
2.2.4 Interprétation d’une matrice de contrôle d’accès
2.2.5 Tags de sécurité
2.3 Modèle de système de détection
2.3.1 Objets
2.3.2 Flux de transition
2.3.3 Système et transitions
2.3.4 Règle de propagation des tags de sécurité
2.4 Détection d’intrusions
2.4.1 Théorème de détection d’intrusions
2.4.2 Discussion
3 Implémentation et résultats expérimentaux
3.1 Architecture générique
3.1.1 Gestion des tags de sécurité
3.1.2 Observation des flux d’informations
3.1.3 Contrôle des flux d’informations
3.1.4 Principe de contrôle collaboratif des flux d’informations
3.2 Blare
3.2.1 Architecture
3.2.1.1 Sonde
3.2.1.2 Analyseur
3.2.1.3 Gestionnaire de tags de sécurité
3.2.2 Autres services
3.2.3 Initialisation de la politique
3.3 JBlare
3.3.1 Motivations
3.3.2 Choix d’implémentation
3.3.3 Architecture
3.3.3.1 Conteneurs d’informations pris en compte et gestion des tags de sécurité
3.3.3.2 Instrumentation des champs d’objet et de classe
3.3.3.3 Instrumentation des méthodes d’objet et de classe
3.3.3.4 Collaboration avec Blare
4 Résultats expérimentaux
4.1 Détection d’instrusions
4.1.1 Initialisation automatique de la politique et attaques sur le serveur «jouet»
4.1.2 Attaque sur phpwiki
4.1.3 Attaque sur Jetty
4.2 Déclassification
4.3 Détection collaborative
4.4 Evaluation du surcoût engendré
4.4.1 Impacts de Blare
4.4.2 Impacts de JBlare
4.5 Bilan
CONCLUSION

Lire le rapport complet