Soutenance mémoire
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.
Architecture classique d’IDS
Nous décrivons dans cette sous-section les trois composants qui constituent classiquement un système de détection d’intrusions [DDW00].Un capteur est chargé de collecter des informations sur l’évolution de l’état du système et de fournir une séquence d’événements qui traduit l’évolution de l’état du système. Un analyseur détermine si un sous-ensemble des événements produits par le capteur est caractéristique d’une activité malveillante. Un manager collecte les alertes produites par le capteur, les met en forme et les présente à l’opérateur. Éventuellement, le manager est chargé de la réaction à adopter. Nous détaillons par la suite chacun de ces trois composants.
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.
|
Table des matières
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
Télécharger le rapport complet
