24

Vers une Formalisation des Politiques de Sécurité

Wadie Krombi, Mohammed Erradi Networking & Distributed Systems Research Group, TIES, Lab SIME

ENSIAS, Université Mohammed V Souissi Rabat, Maroc

krombi@yahoo.com, erradi@ensias.ma

Résumé— En général, les politiques de sécurité sont des règles exprimant des contraintes pour sécuriser un système donné. Souvent ces règles sont exprimées sous forme de texte informel, ce qui mène alors à des ambigüités et à des contradictions lors de leur implémentation. L’objectif de ce travail est : étant donné un système S et une politique de sécurité P comment peut-on générer un système Sp qui est une version sécurisée de S ? Ceci ne peut être réalisé que si le système et la politique de sécurité sont exprimés dans un même langage. En vue d’une formalisation de politiques de sécurité et partant du fait qu’une politique de sécurité est un ensemble de règles, nous proposons une démarche de construction d’une Machine à Etats Finis (MEF) à partir d’une politique de sécurité. Un cas de politique de sécurité d’un firewall est utilisé pour illustrer notre démarche.

Mots clés- politique de sécurité, règle de sécurité, machine à états finis, firewall

I. INTRODUCTION Les systèmes d'information constituent actuellement le

centre névralgique de toute organisation, de part le fait du caractère stratégique de l’information qui devient incontestablement un facteur clé de succès. Cependant, dans la plupart des cas, ces systèmes sont conçus sans prendre en considération les aspects liés à la sécurité. Cela les rend vulnérables aux menaces qui peuvent compromettre leur fonctionnement normal. Il est alors plus aisé d’en admettre l’importance, d’en organiser la protection en établissant des politiques de sécurité [1].

Afin d’assurer un certain niveau de sécurité, le comportement d’un système doit être contrôlé par une «politique de sécurité». La politique de sécurité d’un système spécifie l'ensemble des lois, règlements et pratiques qui régissent la façon de gérer, protéger et diffuser les informations et autres ressources sensibles au sein d'un système spécifique. Elle doit identifier les objectifs de sécurité du système et les menaces auxquelles celui-ci devra faire face [2]. Dans [3], une politique de sécurité est définie comme un ensemble de règles de sécurité, de procédures ou de lignes directives pour une organisation. Une politique peut se rapporter à un environnement opérationnel spécifique.

L’objectif de notre travail est de générer un système sécurisé Sp à partir de la spécification d’un système S et d’une politique de sécurité P. Cela revient à développer une approche formelle permettant la composition d’un système avec une politique de sécurité. Par conséquent, cette composition doit

assurer une conformité du système obtenu à partir de cette composition avec le système original et la politique de sécurité. Pour ce faire, il est nécessaire d’avoir un même modèle formel dans lequel peut être exprimé aussi bien S que P. Cette formalisation permet d’abstraire la politique de sécurité, de gérer sa complexité, de détecter et de résoudre les situations conflictuelles et de vérifier que tous les objectifs de sécurité sont couverts par les mesures préalablement identifiées. [4]

Afin de résoudre cette problématique, nous proposons une approche basée sur les étapes principales suivantes :

� Modéliser une politique de sécurité P par une MEF.

� Le système S doit être modélisé par une MEF ou un ensemble de MEF communicantes.

� Composer S et P pour obtenir Sp un système sécurisé comme résultat de l’application de la politique de sécurité sur le système original.

Dans ce travail, nous focalisons notre contribution sur la première étape relative à la modélisation de la politique de sécurité. Notre démarche consiste à construire une MEF à partir d’une politique de sécurité.

La suite de cet article est organisée comme suit. La section II présente un état de l’art sur la modélisation des politiques de sécurité. La section III présente des notions de base sur les firewalls et les MEF. La section IV est dédiée à l’expression d’une politique de sécurité sous forme de MEF. La section V est dédiée au processus de construction d’une MEF à partir d’une politique de sécurité. La section VI présente une étude de cas illustrant l’expression d’une politique de sécurité sous forme de MEF. Enfin, nous terminons par une conclusion et des perspectives.

II. ETAT DE L’ART Plusieurs travaux de recherche qui traitent les politiques de

sécurité des réseaux se focalisent sur les firewalls. Dans [5], les auteurs proposent une méthode de découverte des divergences fonctionnelles entre plusieurs implémentations d’une politique de sécurité d’un firewall. La structure de donnée utilisée pour la modélisation de la politique de sécurité d’un firewall est appelée « Firewall Decision Diagram » (FDD) [6]. Un FDD est un arbre qui fait correspondre chaque paquet à une décision en testant le paquet tout au long de l’arbre à partir de la racine jusqu’à un nœud terminal. Ceci indique la décision à prendre par le firewall pour le paquet en cours. Chaque nœud non

978-1-4673-1053-6/12/$31.00 ©2012 IEEE

25

terminal dans un FDD spécifie un test réalisé sur un champ du paquet, et chaque branche descendant de ce nœud correspond à des valeurs possibles de ce champ.

Dans [7], les auteurs présentent un ensemble de techniques et d’algorithmes qui permettent une découverte des anomalies dans la politique de sécurité du firewall. Cette dernière est représentée par un arbre à racine unique appelée «Policy Tree», où chaque nœud représente un champ de la règle de filtrage, chaque branche étant une valeur possible du champ. Chaque chemin dans la « Policy Tree » commence par la racine et se termine par une feuille, il représente une règle de filtrage dans la politique de sécurité et vice versa. Les feuilles sont les actions pouvant être prises (Accept, Deny).

Dans [8], les auteurs introduisent Fireman, un « toolkit » d’analyse statique pour la modélisation et l’analyse des firewalls. Fireman applique un ensemble de techniques d’analyse statiques afin d’examiner les erreurs de configuration telles que les violations de politiques et incohérences au sein d’un firewall. Fireman est implémenté par la modélisation des règles du firewall en utilisant des diagrammes de décision binaires (Binary Decision Diagrams).

Dans ces travaux, aucune distinction n’a été faite entre le système (à sécuriser) et la politique de sécurité à appliquer. Aussi les approches proposées ne traitent pas la spécification formelle du système du point de vue fonctionnel.

Dans [9], les auteurs proposent un framework qui rend possible la génération de manière automatique des séquences de test afin de valider la conformité d’une politique de sécurité. Dans ce framework, le comportement du système est spécifié sous forme d’une « MEF étendue » [10] alors que la politique de sécurité est spécifiée en se basant sur le modèle Orbac [11].

III. NOTIONS DE BASE SUR LES FIREWALLS ET LES MACHINES A ETATS FINIS

Afin de modéliser une politique de sécurité par une MEF, nous allons rappeler quelques notions de base sur les firewalls et les MEF.

A. Notions de base sur les firewalls

Les firewalls sont des dispositifs ou des programmes qui contrôlent le flux du trafic réseau entre des réseaux ou des hôtes qui ont des exigences de sécurité différentes [12]. Ceci se fait sur base de règles qui régissent les communications autorisées entre les réseaux. Le comportement d’un firewall est contrôlé par sa politique de sécurité qui est représentée par une liste ordonnée de règles définissant les actions et décisions à prendre à chaque fois qu’un paquet traverse le firewall. Un paquet est défini comme un Tuple composé d’un nombre fini de champs réseau tels que: l’adresse IP source, l’adresse IP destination, le numéro de port, le protocole, etc.

Une règle de sécurité d’un firewall (appelée aussi règle de filtrage) s’exprime sous la forme : si certaines conditions sont satisfaites, une certaine action doit être entreprise soit pour autoriser l’accès soit pour le refuser. Une règle peut être représentée sous la forme : « Condition => Action ». Le champ « Condition » est une expression booléenne appliquée sur les

différents champs du paquet. Elle est composée d’un ensemble de champs de filtrage. Ces derniers représentent les valeurs possibles des champs correspondants dans les paquets qui constituent le trafic réseau actuel et qui correspond à cette règle. Le champ « Action » peut être «Accepter» (Accept) qui permet au paquet de traverser le firewall ou «Refuser» (Deny) qui bloque la traversée du paquet. La traversée d’un paquet est permise ou bloquée par une règle spécifique si les informations de l’entête du paquet correspondent à tous les champs réseau de cette règle. Autrement, la règle suivante est examinée et le processus est répété jusqu’à ce qu’une règle qui correspond est trouvée. Si aucune règle ne correspond au paquet qui traverse le firewall, une politique par défaut est appliquée.

B. Notions de base sur les machines à états finis

Dans [13], l’auteur présente des définitions et des notions de base sur les MEF. Soit un ensemble � appelé alphabet, dont les éléments sont appelés caractères (ou lettres). Un mot (sur �) est une séquence finie de caractères (de �). On note uv la concaténation des mots u et v. On note �* l'ensemble des mots sur �. Un langage sur � est un sous-ensemble L de �*. Si U et V sont des langages sur �, on note U V l'ensemble des mots obtenus par la concaténation d'un mot de U et d'un mot de V.

Une MEF est un graphe dont les sommets sont des états et les arcs orientés des transitions. La MEF est à un instant donné dans un état donné et la consommation d'une lettre du mot la fait changer d'état en suivant une transition, autrement dit une transition représente le passage instantané d’un état vers un autre. Une transition est déclenchée par un événement. Autrement dit: c'est l'arrivée d'un événement qui conditionne la transition. Les transitions peuvent aussi être automatiques, lorsqu'on ne spécifie pas l'événement qui la déclenche (comme dans le cas le plus simple de la consommation d’une lettre du mot). Lorsqu’un mot est entièrement consommé par la MEF, il est reconnu si l'état courant est un état particulier dit final.

Une MEF est un quintuplet (Q, q0, A, �, ) où :

� Q est un ensemble fini d’états,

� q0 est l’état initial,

� A � Q est un ensemble d’états dits terminaux,

� � est un alphabet fini,

� est une fonction de transition de Q � dans Q.

La MEF démarre dans l’état q0 et à chaque fois qu’elle lit un caractère c � �, elle bascule de l’état courant q vers l’état �(q,c). L’état initial est marqué par une flèche et les états finaux sont doublement cerclés. Si l’état courant est un élément de A on dit alors que la chaîne lue a été reconnue par la MEF.

IV. EXPRESSION D’UNE POLITIQUE DE SECURITE SOUS FORME DE MACHINE A ETATS FINIS

Comme défini précédemment, la politique de sécurité dans le cas d’un firewall est une liste ordonnée de règles. Lorsque le firewall reçoit un paquet, il compare les informations de l’entête du paquet et celles des champs de filtrage de la règle en cours. S’il y a correspondance, l’action relative à cette règle est

26

appliquée sur ce paquet. Sinon le firewall examine le paquet par la règle suivante et le processus sera répété jusqu’à ce qu’une règle de sécurité qui correspond au paquet sera trouvée.

Nous allons montrer maintenant comment modéliser une règle de sécurité par une MEF. Soit � l’alphabet composée des chiffres, des lettres et du symbole « . ». L(IP) le langage des adresses IP dont les mots sont de la forme « a.b.c.d » avec a,b,c,d � [0,255]. L(Port) le langage des ports dont les mots sont les numéros compris entre 0 et 62535. L(Protocole) le langage des protocoles qui comporte les mots représentant un protocole (TCP, UDP, etc).

Soit L(Paquet) le langage définit comme étant la concaténation L(IP) L(IP) L(Port) L(Protocole). L’entête d’un paquet composé d’une adresse IP source, d’une adresse IP destination, d’un numéro de port et d’un protocole peut être vu comme un mot du langage L(Paquet).

Soit L(Paquet-Ri) le langage obtenu par la concaténation L(IPsrc-Ri) L(IPdst-Ri) L(Port-Ri) L(Protocole-Ri). Avec :

� L(IPsrc-Ri) est le sous-ensemble des mots du langage L(IP) constitué des adresses IP qui correspondent à la condition du champ de filtrage relatif à l’adresse IP source dans la règle Ri.

� L(IPdst-Ri) est le sous-ensemble des mots du langage L(IP) constitué des adresses IP qui correspondent à la condition du champ de filtrage relatif à l’adresse IP destination dans la règle Ri.

� L(Port-Ri) est le sous-ensemble des mots du langage L(Port) constitué des numéros de port qui correspondent à la condition du champ de filtrage relatif au port dans la règle Ri.

� L(Protocole-Ri) est le sous-ensemble des mots du langage L(Protocole) constitué des protocoles qui correspondent à la condition du champ de filtrage relatif au protocole dans la règle Ri.

L’entête d’un paquet composé d’une adresse IP source, d’une adresse IP destination, d’un numéro de port et d’un protocole qui correspondent aux champs de filtrage d’une règle Ri peut être vu comme un mot du langage L(Paquet-Ri).

La condition sur un champ de filtrage peut être soit une valeur exacte, un intervalle de valeurs ou « Any » qui signifie n’importe quelle valeur.

L’idée de base derrière la modélisation d’une règle de sécurité par une MEF est la suivante. Dans un état donné qui porte le label d’un champ de filtrage réseau (IPsrc, IPdst, Port ou Protocole), la MEF consomme une valeur d’un champ réseau. Cette transition porte un label qui indique la condition de passage d’un état vers un autre.

Une règle de sécurité Ri d’un firewall peut être modélisée sous forme de la MEF représentée dans Fig.1. Cette MEF reconnait les mots (paquets) de L(Paquet-Ri) et en les consommant se retrouve dans un état final qui indique l’action à entreprendre pour ce type de paquets. Les autres mots (paquets) de L(Paquet) n’appartenant pas à L(Paquet-Ri) doivent être examinés par Ri+1.

On appelle « transition positive » une transition qui porte le label de la condition de filtrage relative à un champ de filtrage d’une règle. On appelle « transition négative » une transition qui porte le label de la condition de filtrage inverse relative à un champ de filtrage d’une règle. Le label d’une transition négative sera noté «! Condition». On appelle «chemin positif» de la règle Ri le chemin qui mène de l’état initial de Ri vers l’état final qui indique l’action à entreprendre si un paquet correspond à Ri. Ce chemin est une suite de transitions positives. On appelle «chemin négatif» de la règle Ri un chemin qui mène de l’état initial de Ri vers l’état initial de Ri+1. Ce chemin comporte une transition négative dont le label est une condition non vérifiée par l’un des champs de filtrage de Ri. Un chemin négatif peut comporter des états et des transitions spéciaux que l’on appellera «états et transitions de consommation» dont l’utilité sera décrite ultérieurement. La condition d’une transition de consommation est toujours vérifiée et porte le label « Any ».

Figure 1. Machine à états finis modélisant la règle Ri

Supposons que le firewall est au stade d’examiner, par la règle Ri, un paquet appartenant au langage L(Paquet) dont l’entête est composé des valeurs [IPsrc-Paquet IPdst-Paquet Port-Paquet Protocole-Paquet] . Si par exemple IPsrc-Paquet n’appartient pas à L(IPsrc-Ri) alors : quelque soient IPdst-Paquet, Port-Paquet et Protocole-Paquet, le paquet en cours ne correspond pas à Ri. Donc, ce paquet doit être examiné par Ri+1. Le passage de Ri vers Ri+1 peut être modélisé par un chemin négatif constitué des transitions et états suivants :

� Une transition négative partant de l’état IPsrc de la règle Ri vers un nouvel état de consommation IPdst. cette transition porte le label « ! IPsrc-Ri ». Ce label décrit la condition de non appartenance de IPsrc-Paquet à L(IPsrc-Ri).

� Une transition de consommation partant du dernier état de consommation créé IPdst vers un nouvel état de consommation Port.

� Une transition de consommation partant du dernier état de consommation créé Port vers un nouvel état de consommation Protocole.

Un chemin négatif de la

règle Ri

Chemin positif de la règle Ri

IPsrc IPdst Port ProtocoleIPsrc_Ri IPdst_Ri Port_Ri Protocole_Ri

Etat initial Ri+1

IPdst

Port

Protocole

! IPsrc_Ri

any

any

any

Port

Protocole

! IPdst_Ri

any

any

Protocole

! Port_Ri

any

Etats et transitions de consommation de la règle Ri

Action_Ri

! Protocole_Ri

27

� Une transition de consommation partant du dernier état de consommation créé Protocole vers la règle Ri+1.

Les états et transitions de consommations sont créés lorsqu’un paquet ne correspond pas à une règle Ri et doit être examiné par Ri+1. Leur rôle est d’assurer qu’un chemin négatif qui relie Ri et Ri+1 transite par les mêmes états que ceux du chemin positif de Ri et ce dans le même ordre. Ainsi, après consommation de l’état relatif au dernier champ de filtrage du paquet, la MEF se retrouve : Soit à l’état final « Action-Ri » si le paquet correspond à Ri. Soit à l’état initial de Ri+1 si l’un des champs du paquet ne correspond pas à une condition de filtrage de Ri.

On appelle Sequence-Ri d’une règle Ri une suite de champs de filtrage qui indique dans quel ordre les champs d’un paquet doivent être passés en entrée de la MEF partielle de Ri pour se retrouver dans l’état final de Ri ou dans l’état initial de Ri+1. On appelle Sequence-Policy d’une MEF une suite de champs de filtrage qui indique dans quel ordre les champs d’un paquet doivent être passés en entrée de la MEF de la politique de sécurité du firewall pour se retrouver dans un état final de la MEF. Cette séquence est la concaténation de toutes les séquences de toutes les règles de sécurité du firewall.

V. CONSTRUCTION D’UNE MEF A PARTIR D’UNE POLITIQUE DE SECURITE

Dans cette section, nous allons décrire la démarche suivie pour la construction d’une MEF à partir d’une politique de sécurité. Nous supposons que la politique est correcte et qu’elle ne comporte aucune anomalie [7] et qu’elle a nécessairement une seule règle « par défaut » (la dernière).

A. Cas d’une politique de sécurité avec une seule règle Dans ce cas, la seule règle de cette politique est

nécessairement la règle par défaut. (Tableau I)

TABLEAU I. POLITIQUE DE SECURITE AVEC UNE SEULE REGLE

IPsrc IPdst Port Protocole Action Any Any Any Any Action-R1

Fig.2 représente la MEF correspondant à la politique du Tableau I. Cette politique peut être interprétée de la sorte : pour un paquet reçu par le firewall, quelque soient IPsrc, IPdst, Port et Protocole l’action à entreprendre est « Action-R1 ». Ainsi, dès la réception d’un paquet, le firewall n’a besoin de vérifier aucune des valeurs des champs de filtrage de la règle et la MEF se retrouve directement dans l’état final « Action-R1 ». Par conséquent, la règle par défaut peut être modélisée par la MEF réduite représentée dans Fig.4 qui est équivalente à celle représentée dans Fig.3. Et on a dans ce cas : Séquence-Policy = Sequence-R1= {} (null)

Figure 2. MEF modélisant la politique de sécurité du Tableau I

Figure 3. MEF réduite modélisant la politique de sécurité du Tableau I

B. Cas d’une politique de sécurité avec deux règles

Selon la démarche suivie dans la section précédente pour modéliser une règle de sécurité et celle concernant la modélisation de la règle par défaut, la MEF correspondant à la politique de sécurité du Tableau II est représentée dans Fig.4.

TABLEAU II. POLITIQUE DE SECURITE AVEC 2 REGLES

IPsrc IPdst Port Protocole Action IPsrc-R1 IPdst-R1 Port-R1 Protocole-R1 Action-R1

Any Any Any Any Action-R2

Figure 4. MEF modélisant la politique de sécurité du Tableau II

Rappelons que les états et transitions de consommations sont créés lorsqu’un paquet ne correspond pas à une règle Ri et doit être examiné par la règle suivante Ri+1. Or dans ce cas la règle suivante (R2) est celle par défaut. Donc, dès qu’un champ du paquet ne correspond pas à une condition de filtrage de la règle en cours (R1) la MEF change d’état via une transition négative vers l’état final Action-R2. La politique de sécurité du Tableau II peut ainsi être modélisée par la MEF réduite représentée dans Fig.5 qui est équivalente à celle représentée dans Fig.4. Et on a dans ce cas :

Sequence-R1 = {IPsrc,IPdst,Port,Protocole} Sequence-R2 = {} Sequence-Policy = {IPsrc,IPdst,Port,Protocole}

Figure 5. MEF réduite modélisant la politique de sécurité du Tableau II

Chemin positif de la règle R1

IPsrc IPdst Port ProtocoleIPsrc_R1 IPdst_R1 Port_R1 Protocole_R1

Action_R1

Action_R2L’action de la règle par défaut R2 est atteinte directement par les transitions négatives de la règle R1

! Protocole_R1! Port_R1! IPdst_R1! IPsrc_R1

Chemin positif de la règle R1

IPsrc IPdst Port ProtocoleIPsrc_R1 IPdst_R1 Port_R1 Protocole_R1

IPdst

Port

Protocole

! IPsrc_R1

any

any

Port

Protocole

! IPdst_R1

any

any

Protocole

! Port_R1

any

Etats et transitions de consommation de la règle R1

Action_R1

Action_R2

! Protocole_R1

any

L’action de la règle par défaut R2 est atteinte par les chemins négatifs de la règle R1

Etat initial

IPsrc IPdst Port Protocoleany any any any

Action_R1

Etat initial

A c tio n _ R 1

E ta t in it ia l

28

C. Cas d’une politique de sécurité avec plus de trois règle

La MEF est obtenue suivant le processus suivant :

� Création et concaténation des MEF partielles de chaque règle avec la suivante jusqu’à l’avant dernière règle (en utilisant la démarche décrite dans la section IV et illustrée dans Fig.1)

� Création du chemin positif de l’avant dernière règle

� Création des transitions négatives de l’avant dernière règle qui mènent à l’action par défaut de la dernière règle (en utilisant la démarche décrite dans le paragraphe V.A et illustrée dans Fig.3).

Tableau III est l’exemple d’une politique avec 3 règles et

Fig 6 représente la MEF équivalente.

TABLEAU III. POLITIQUE DE SECURITE AVEC 3 REGLES

IPsrc IPdst Port Protocole Action IPsrc-R1 IPdst-R1 Port-R1 Protocole-R1 Action-R1 IPsrc-R2 IPdst-R2 Port-R2 Protocole-R2 Action-R2

Any Any Any Any Action-R3

Figure 6. MEF modélisant la politique de sécurité du Tableau III

VI. ETUDE DE CAS Considérons un réseau d’entreprise connecté à internet et

que nous souhaitons protéger par un firewall (Fig. 7). Le réseau interne est composé de deux segments: Le LAN des utilisateurs (192.168.10.0/24) et la DMZ qui héberge les serveurs Web (212.217.65.201) et FTP (212.217.65.202). L’entreprise possède une succursale (194.204.201.0/28) qui est connecté au réseau interne de l’entreprise à travers internet.

Figure 7. Exemple d’un réseau d’entreprise sécurisé par un firewall

La politique de sécurité de l’entreprise est la suivante :

� L’accès au serveur Web est autorisé par tous.

� L’accès au serveur FTP est permis uniquement à partir des réseaux LAN internes de l’entreprise (LANs du siège et celui de la succursale).

� Les utilisateurs du LAN interne du siège de l’entreprise sont autorisés à accéder à tout le réseau internet à l’exception du réseau malicieux 81.10.10.0/24.

Tableau IV représente la politique de sécurité correspondant aux exigences de sécurité de l’entreprise sous forme de règles de firewall.

TABLEAU IV. POLITIQUE DE SECURITE DE L’ENTREPRISE

IPsrc IPdst Port Protocole Action Any 212.217.65.201 80 TCP Accept

192.168.10.0/24 81.10.10.0/24 Any Any Deny 194.204.201.0/28 212.217.65.202 21 Any Accept 192.168.10.0/24 Any Any Any Accept

Any Any Any Any Deny

Cette politique de sécurité est composée de 5 règles. Chaque règle contient 4 champs de filtrage (IPsrc, IPdst, Port et Protocole). Dans cette politique de sécurité on remarque l’existence de champs de filtrage ayant la valeur « Any ». Prenons l’exemple du champ de filtrage « IPsrc » de la règle R1. « IPsrc-R1= Any » signifie que : lorsque le firewall est au stade d’analyser un paquet par la règle R1, il n’a pas besoin d’examiner l’adresse IP source de ce paquet. Ainsi, le firewall passe directement à l’examen des champs de filtrage suivants de la même règle. Cela se traduit dans la MEF partielle de la règle R1 par l’élimination de l’état portant le label IPsrc. En généralisant ce principe sur l’ensemble des règles du firewall et en suivant la démarche de construction d’une MEF à partir d’une politique de sécurité décrite précédemment on obtient la MEF équivalente suivante : (Fig.8)

Chemin positif de la règle R1

IPsrc IPdst Port ProtocoleIPsrc_R1 IPdst_R1 Port_R1 Protocole_R1

IPdst

Port

Protocole

! IPsrc_R1

any

any

Port

Protocole

! IPdst_R1

any

Protocole

! Port_R1

Etats et transitions de consommation de la règle R1

Action_R1

Chemin positif de la règle R2

IPsrc IPdst Port ProtocoleIPsrc_R2 IPdst_R2 Port_R2 Protocole_R2

Action_R2

Action_R3L’action de la règle par défaut R3 est atteinte directement par les transitions négatives de l’avanrt dernière règle R2

! Protocole_R2! Port_R2! IPdst_R2! IPsrc_R2

anyanyany

! Protocole_R1

BRANCH OFFICE

HEADQUARTERS

LAN 192.168.10.0/24

DMZ Web server

212.217.65.201

FTP server212.217.65.202

194.204.201.0/28

Firewall

MALICIOUS NETWORK

81.10.10.0/24

INTERNET

29

Figure 8. MEF équivalente construite à partir de la politique de sécurité de l’entreprise

La séquence de cette MEF est {IPdst, Port, Protocole, IPsrc, IPdst, IPsrc, IPdst, Port, IPsrc}. La MEF consomme les champs d’un paquet donné dans l’ordre de cette séquence. Ainsi, la MEF est capable de reconnaître quelle action à entreprendre pour un paquet en effectuant : au moins 3 transitions si le paquet correspond à la règle R1 et au plus 9 transitions si le paquet correspond à la dernière règle par défaut R5. Chaque transition correspond en fait à un test effectué sur une condition de filtrage d’une règle de sécurité. Pour le même exemple étudié, le filtrage d’un paquet par le processus classique d’un firewall nécessite d’effectuer au moins 4 tests si le paquet correspond à la règle R1 et au plus 16 tests si le paquet correspond à la dernière règle par défaut R5.

VII. CONCLUSION

L’objectif global de notre travail est de modéliser un système S et sa politique de sécurité P par le même formalisme de machines à états finis. Ceci dans le but de pouvoir les composer pour générer un nouveau système Sp. Ce système est une version sécurisée de S conforme à P. Une telle séparation dans la spécification du système et de la politique de sécurité permet d’une part d’améliorer l’évolutivité des systèmes et de l’autre part la réutilisation des politiques de sécurité. Dans ce travail nous avons montré comment exprimer

une politique de sécurité sous forme de MEF. Notre travail en cours vise la composition d’un système (modélisé sous forme de MEF) avec une politique de sécurité (règles transformées en MEF). Comme autre perspective de ce travail, nous prévoyons proposer et implémenter un algorithme de transformation qui génère automatiquement la MEF correspondante à une politique de sécurité. Aussi nous prévoyons étudier l’impact sur les performances d’un firewall si ce dernier filtre les paquets en utilisant la MEF correspondante à une politique de sécurité. Ceci en prenant comme repère le processus classique de filtrage du firewall basé sur le parcours séquentiel de tous les champs de filtrage de chaque règle de sécurité.

REFERENCES

[1] N. Dausque, “PSSI & CAPSEC : Politique de Sécurité des Systèmes d’Information & Comment Adapter une Politique de Sécurité pour les Entités du CNRS,” CNRS/UREC pour le groupe CAPSEC, Mars 2005.

[2] “Critères d’évaluation de la sécurité des systèmes informatiques,” v1.2, 28 juin 1991, Luxembourg: Office des publications officielles des Communautés européennes, 1992.

[3] “Commun Crireria for Information Technology Security Evaluation, Part 1: Introduction and general model”, Version 3.1, Revision 3, Final, CCMB-2009-07-001, July 2009.

[4] A. Baina, “Contrôle d'Accès pour les Grandes Infrastructures Critiques: Application au réseau d'énergie électrique,” Thèse de doctorat, Université de Toulouse, 29 septembre 2009.

[5] A. Liu et M. Gouda, “Diverse Firewall Design,” IEEE Transactions on parallel and distributed systems, vol. 19, no. 8, Août 2008.

[6] A. Liu et M. Gouda, “Structured Firewall Design,” Computer Networks: The International Journal of Computer and Telecommunications Networking, Volume 51, Issue 4, pp.1106-1120, Mars 2007.

[7] E. Al-Shaer et H. Hamed, “Modeling and Management of Firewall Policies,” IEEE Transactions on Network and Service Management, Volume 1-1, Avril 2004.

[8] L. Yuan, J. Mai, Z. Su, H. Chen, C. Chuah, P. Mohapatra, “FIREMAN: A Toolkit for FIREwall Modeling and Analysis,” pp.199-213, IEEE Symposium on Security and Privacy, 21-24 Mai 2006.

[9] W. Mallouli, J. Orset, A. Cavalli, N. Cuppens, F. Cuppens, “A Formal Approach for Testing Security Rules,” SACMAT'07 Proceedings of the 12th ACM symposium on Access control models and technologies, Sophia Antipolis, France, June 20-22, 2007.

[10] D. Lee et M. Yannakakis, “Principles and methods of testing finite state machines - A survey,” In Proceedings of the IEEE, volume 84, pp.1090–1126, 1996.

[11] A. Abou El Kalam, R. El Baida, P. Balbiani, S. Benferhat, F. Cuppens, Y. Deswarte, A. Miège, C. Saurel, G. Trouessin. “OrBAC : un modèle de contrôle d'accès basé sur les organisations,” Cahiers francophones de la recherche en sécurité de l'information, CRIC (Centre de Recherche en Information et Communication), Université de Montpellier I, n° II, pp.30-43, 1er trimestre 2003.

[12] K. Scarfone, P. Hoffman, “Guidelines on Firewalls and Firewall Policy, Recommendations of the National Institute of Standards and Technology” NIST Special Publication 800-41 Revision , September 2009.

[13] L. Maranget, “Cours de compilation,” Ecole polytechnique, pp. 49–66, 2004-2006.