Algorithme général de détection

Jusqu’ici, nous avons défini les trois phases de notre approche de détection des violations d’un ensemble de propriétés de sécurité. L’algorithme 10 synthètise l’application de ces trois phase et il représente ainsi notre algorithme général de détection. Ainsi, il utilise les trois algorithmes asso-ciés aux trois phases de notre approche de détection. Notre approche nécessite la définition d’une politique de contrôle d’accès, une politique de détection, trois tables de changement d’état et un en-semble de traces obtenu lors de l’exécution du système. La politique de contrôle d’accès est alors exprimée sous forme d’un ensemble de vecteurs d’interactions POL. Les trois tables de changement d’état Tdep, Tf lux, Ttranspermettent alors de construire un ensemble de graphes (phase 1) associés à cette politique de contrôle d’accès. Ces graphes correspondent ainsi au graphe d’interactions Gint, au graphe de dépendance causale G_dep, au graphe de flux d’informations G_{f lux} et au graphe de transi-tions Gf lux.

La seconde phase utilise alors ces graphes et une politique de détection POLdetection qui définit l’ensemble des propriétés de sécurité nécessaires. La politique de détection définit alors l’ensemble des règles d’analyse de ces graphes. Cette phase génère donc une base de signatures BASE contenant l’ensemble des activités violant les propriétés de sécurité.

La troisième phase permet, par analyse des traces d’interactions du système T , de détecter l’ap-parition des éléments de la base de signatures BASE. Cette phase utilise les reconstructeurs afin de génèrer une alerte pour chaque signature observée. L’observation d’une activité correspondant à une signature de la base est alors une violation d’une des propriétés de sécurité définies dans la politique

de détection.

detection_globale(POL ⊂ IV, POLdetection, Tdep, Tf lux, Ttrans, T ) début

Gint, G_dep, G_{f lux}, Gtrans:=construire_graphes(POL ⊂ IV, Tdep, T_{f lux}, Ttrans); BASE:=construire_base(POL ⊂ IV, POLdetection, Gint, G_dep, G_{f lux}, Gtrans); detection(T, BASE);

fin

Algorithme 10 : Algorithme général de détection

5.5 Conclusion

L’algorithme 10 résume notre approche. Nous pouvons remarquer que les trois phases proposées dans ce chapitre peuvent être utilisées séparément. Les phases de construction des graphes et de construction de la base de signaturesdoivent être appelées avant la phase de détection. Cependant, une phase s’applique indépendemment tant que les données de la phase précédente n’ont pas été modifiées.

Ainsi sur un système, ou un ensemble de système, nous n’avons pas besoin de reconstruire les graphes et la base tant que la politique de contrôle d’accès et la politique de détection sont fixes. De plus, nous conservons l’état des observations en cours afin d’éviter tout faux négatif lié au redémarrage du système (un flux d’informations dont chaque moitié est réalisée avant et après le redémarrage).

Finalement, lorsque la politique de contrôle d’accès est fixe, les modifications de la politique de détection n’impliquent que la reconstruction de la base. Cette nouvelle base sert alors de nouvelle entrée à la phase de détection et l’ancienne base peut être conservée afin de terminer la reconstruction des observations en cours.

Nous proposons, dans le chapitre suivant, une implantation de cette méthode de détection pour deux systèmes de contrôle d’accès : SELinux etGRSECURITY. Nous conclurons alors ce chapitre par les résultats de l’expérimentation de cette implantation.

Chapitre 6

Implantation et Expérimentation

Dans le chapitre 5, nous avons proposé une approche de détection des activités illicites sur un système. Cette approche utilise la politique de contrôle d’accès d’un système et nécessite la défini-tion d’une politique de détecdéfini-tion. Cette politique de détecdéfini-tion définit un ensemble de propriétés de sécurité qui doivent être respectées par ce système. L’approche d’analyse d’une politique de contrôle d’accès, proposée dans le chapitre 4, permet alors d’énumérer l’ensemble des violations possibles de ces propriétés de sécurité. Ces violations correspondent à des activités décrites dans notre langage de description d’activités (cf. chapitre 3). Ainsi, nous proposons un outil, que nous appelonsPIGA(pour Policy Interaction Graph Analysis), qui implante cette approche de détection. Cet outil, écrit en Java, implante les trois phases de détection proposées dans le chapitre 4.

Dans ce chapitre, nous proposons de décrire l’implantation de cet outil et l’expérimentation qui en a été faite. Nous proposons ainsi d’appliquer notre approche à deux systèmes cibles qui sont SELinux

et GRSECURITY. Dans la section 6.1, nous détaillons le mécanisme de conversion d’une politique

SELinux ouGRSECURITY en un ensemble de vecteurs d’interactions. La section 6.2 décrit le fonc-tionnement des trois phases de détection. Finalement, dans la section 6.3, nous proposons d’étudier une application de cetIDSdans le cadre des pots-de-miel.

L’implantation de notre approche de détection d’intrusions, développée dans ce chapitre, a éga-lement été exposée dans les articles [Briffaut et al. 2005b, Blanc et al. 2006, Briffaut et al. 2006b, Briffaut et al. 2006c, Briffaut et al. 2006a].

6.1 Conversion d’une politique en langage neutre

Dans notre approche, la politique de contrôle d’accès d’un système cible doit tout d’abord être projetée en une politique neutre qui consiste en un ensemble de vecteurs d’interactions POL ⊂ IV . Comme l’indique la figure 6.1, cette projection est alors réalisée par un mécanisme de traduction de la politique cible. Ainsi, nous proposons deux outils afin de convertir les politiques SELinux et

GRSECURITYen une politique neutre.

Dans cette partie, nous donnons tout d’abord le langage neutre utilisé pour définir les vecteurs d’interactions. Puis, pour chaque système cible, nous revenons sur les langages propres à ces systèmes. Nous montrons ensuite comment projeter le langage cible dans le langage neutre. Finalement, nous présentons des exemples pour SELinux et GRSECURITY et nous étudierons les politiques neutres associées.

FIG. 6.1 – Projection d’une politique de contrôle d’accès cible en politique neutre.

FIG. 6.2 –DTDpour la politique neutre.