Complexité des algorithmes d’énumération

Afin d’étudier la complexité des différents algorithmes, nous notons m = |IV | le nombre d’arcs du graphe de dépendance causale, n = |SC| le nombre de contextes de sécurité, k le nombre maximum de chemins recherchés et op = |IS| le nombre d’opérations constituant la politique de contrôle d’accès. L’implantation de l’algorithme d’énumération des chemins (kshortestpath) a une complexité de : O(m + nlog(n) + k) (cf. [Eppstein 1997]). L’algorithme d’énumération des interac-tionsenum_interactionest ainsi en O(op), l’algorithme d’énumération des séquencesenum_sequence

Propriété de sécurité Complexité de l’algorithme d’analyse Intégrité - integrity O(op + op2 ∗ n ∗ m + op2 ∗ n2log(n) + n∗ op2 ∗ k) - int_biba O(n2 ∗ op) - int_subject O(n2 ∗ op2 ) - int_domain O(n2 ∗ op) Confidentialité

- confidentiality O(op + m + nlog(n) + k + n∗ (m + nlog(n) + k)2

) - conf_blp O(n2 ∗ op + m ∗ n2 + n3 log(n) + n2 ∗ k)) - conf_blpr O(n2 ∗ op + m ∗ n2+ n3 ∗ log(n) + n2 ∗ op) - conf_data O(n∗ op2 ∗ m + n2 ∗ op2log(n) + k∗ n ∗ op2) Abus de privilèges - duties_sep O(n2 ∗ op2+ n3 ∗ (m + nlog(n) + k)2) - bad_transition O(op + m + nlog(n) + k)

- tpe O(n2

∗ op)

TAB. 4.3 – Complexité des algorithmes d’énumération

est en O(m + nlog(n) + k) (i.e. la même complexité que l’algorithme kshortestpath). Les al-gorithmes d’énumération d’accès à un privilège et d’accès à l’information sont respectivement en O(n∗ op ∗ m + op ∗ n²log(n) + n∗ op ∗ k) et O(n ∗ (m + nlog(n) + k)²).

La table 4.3 donne la complexité des algorithmes d’énumération associés à chaque propriété. Nous pouvons remarquer que les deux algorithmes ayant la complexité la plus importante sont ceux associés aux propriétés d’intégrité et de confidentialité générale ainsi que l’algorithme de cohérence d’accès aux données. Notons que la complexité de ces algorithmes prend en compte l’énumération de l’ensemble des contextes, alors que ces règles sont en fait appliquées sur un sous-ensemble de contexte du système. De plus, la plupart des boucles imbriquées ne sont pas réalisées grâce à la présence de test logique avant chaque boucle, comme dans l’algorithme conf_data, ce qui permet de réduire énormément le nombre d’appel aux algorithmes d’énumération des séquences et des corrélations. Finalement, nous verrons dans le chapitre 6, que les politiques de contrôle d’accès étudiées ont pour caractéristiques op < 200,n < 3.500 et m < 400.000. Ces caractéristiques nous ont permis d’utiliser tous ces algorithmes sur des politiques réelles, malgré la complexité de certains algorithmes.

4.5 Conclusion

Dans ce chapitre nous avons proposé une formalisation d’une politique de contrôle d’accès en tant qu’ensemble d’interactions et la notion de graphe d’interactions. Ce graphe contient l’ensemble des interactions autorisées par la politique de contrôle d’accès.

De plus, nous définissons la notion de graphe de dépendance causale qui représente l’ensemble des dépendances entre interactions de la politique. Ce graphe conduit à deux cas particuliers : le graphe de flux d’informations et le graphe de transitions. Nous avons montré qu’il y avait équivalence entre l’existence d’un chemin dans un de ces graphes et une séquence observable.

Nous proposons différents algorithmes permettant l’énumération des interactions, des séquences et des corrélations. Pour chaque propriété de sécurité formalisée dans notre langage d’activités, nous proposons un algorithme qui permet d’énumérer toutes les activités illicites (signatures) violant cette propriété. Ces algorithmes correspondent à une implantation des terminaux de notre langage et nous traitons ainsi les trois classes d’activités définies précédemment : les interactions, les séquences et les corrélations.

4.5. CONCLUSION 125 “réalisation” des activités violant une propriété de sécurité. Cette approche exploite la définition d’une politique de détectionet d’une politique de contrôle d’accès afin de calculer une base de signatures d’activités illicites. Une politique de détection définit alors l’ensemble des propriétés de sécurité qui doivent être respectées sur un système. Ainsi, par analyse des traces du système, cette approche permet de détecter l’apparition des activités qui correspondent à des violations effectives des propriétés de sécurité.

Chapitre 5

Application à la détection d’intrusions

La détection d’intrusions proposée dans ce chapitre prend en entrée une politique de contrôle d’accès et une politique de détection. La politique de détection contient un ensemble de propriétés de sécurité tel que définies dans le chapitre précédent. L’intérêt de cette politique de détection est donc de permettre à un administrateur de définir les propriétés de sécurité souhaitées qu’il ne peut pas exprimer dans la politique de contrôle d’accès. La politique de contrôle d’accès permet de générer les trois graphes vus précédemment. Les graphes permettent alors d’énumérer les activités qui violent les propriétés définies dans la politique de détection. Ces activités sont ensuite utilisées pour détecter les violations apparaissant sur le système. La détection analyse les traces des interactions (log d’appels système) afin de signaler l’apparition de ces activités illicites. Notre langage de description d’activités sert non seulement à exprimer des propriétés de sécurité mais permet aussi d’exprimer les activités illicites (attaques). La méthode proprosée est tout à fait générale puisqu’elle repose sur un langage qui permet d’exprimer toute propriété d’intégrité ou de confidentialité mettant en jeu des interactions, des séquences ou des combinaisons observables sur un système.

Notre approche de détection d’intrusions comprend deux grandes étapes. En premier lieu, l’admi-nistrateur du système doit utiliser les propriétés de sécurité définies précédemment, c’est-à-dire toutes celles exprimables dans notre langage, pour définir des règles de sécurité qui vont constituer la poli-tique de détection. Dans un second temps, cette polipoli-tique est utilisée par notre solution de détection d’intrusions afin de construire une base d’activités illicites.

Ce chapitre détaillera dans un premier temps la politique de détection et dans un second temps la solution générique de détection. La figure 5.1 fait apparaître les deux grandes étapes d’administration et de détection. Pour l’étape de détection, il montre les trois phases permettant de lever une alerte lorsqu’une propriété définie dans la politique de détection est violée :

1. Construction des graphes : la politique de contrôle d’accès permet de construire le graphe d’interactionset les différents graphes de dépendance causale ;

2. Génération de la base de signatures : chaque règle de la politique de détection permet d’énumé-rer les activités qui violent cette règle. Chaque activité correspond à une signature et l’ensemble de ces signatures constitue la base de signatures violant la politique de détection ;

3. Détection des activités : nous utilisons les traces d’interactions pour détecter les activités qui correspondent à des signatures de la base. Lorsqu’une telle activité est reconstituée, une alerte est alors levée.

Dans ce chapitre, nous détaillons l’étape d’administration qui correspond à la définition d’une politique de détection dans la section 5.1. Ensuite, nous présentons les trois phases de l’étape de détection.

FIG. 5.1 – Fonctionnement général.

L’application de l’analyse d’une politique de contrôle d’accès à la détection d’intrusion, dévelop-pée dans ce chapitre, a également été exposée dans les articles [Briffaut et al. 2005a, Briffaut 2005, Blanc et al. 2006, Briffaut et al. 2006c].

5.1 Politique de détection

Nous définissons par politique de détection, un ensemble de propriétés de sécurité qui doivent être respectées sur un système. Ces propriétés sont toutes celles exprimées dans notre langage de descrip-tion d’activités. Notre politique de détecdescrip-tion définit ainsi un ensemble de propriétés à satisfaire. La table A.1 (page 188) synthétise l’ensemble des propriétés de sécurité qui peuvent être exprimées. La définition de ces propriétés repose sur le nom des règles correspondant aux algorithmes d’énumération des violations définis dans la section 4.4.

Une règle est une de ces propriétés pour laquelle on définit la valeur des paramètres. Pour chaque propriété, nous indiquons le nom à utiliser dans la politique de détection, les paramètres nécessaires et l’objectif de cette règle. Par exemple, la propriété integrity(ligne 1) correspond à la propriété d’intégrité des objets et prend en arguments un couple de contextes ou un couple d’ensemble de contextes. Cette propriété permet par exemple de définir la règle integrity(SCuser, SC_admin, Gc)

pour garantir l’intégrité des contextes administrateurs.