Détection d anomalies dans les configurations de composants de sécurité réseau

Transcription

1 Détection d anomalies dans les configurations de composants de sécurité réseau Réalisé par : Stere PREDA Encadrants : Frédéric CUPPENS Nora CUPPENS Février, 2006

2 Sommaire 1. Introduction La décomposition de politique de sécurité réseau Les anomalies dans la configuration des composants de sécurité Les firewalls Règles de filtrage Règles intrinsèquement respectées par un firewall Analyse d une configuration existante Génération d une configuration Les IDS Différentes approches de la Détection d Intrusion SNORT Configuration de SNORT Les VPN Technologie de réseaux privés virtuels La conception des VPN Configuration d un VPN Conclusion Bibliographie Détection d anomalies dans les configurations de composants de sécurité réseau 2

3 Abréviations : AH Authentication Header ATM Asynchronous Transfer Mode CIM Common Information Model CTL Computational tree logic DNS Domain Name System ESP Encapsulating Security Payload ftp file transfer protocol http HyperText Transfert Protocol ICMP Internet Control Message Protocol IDS Intrusion Detection System IKE Internet Key Exchange IMAP Internet Message Access Protocol IP Internet Protocol IPSec IP Security MPLS MultiProtocol Label Switching OSI Open System Interconnection Or-BAC Organization Based Access Control PE Provider Edge POP3 Post Office Protocol Version 3 RBAC Role-Based Access Control SA Security Association SMTP Simple Mail Transfer Protocol ssh Secure Shell TCP Transport Control Protocol VPN Virtual Private Network XML Extensible Markup Language XSLT extended Stylesheet Language Transformations Détection d anomalies dans les configurations de composants de sécurité réseau 3

4 1. Introduction La spécification et la gestion des règles de contrôle d accès est une tâche admise dans la communauté de la sécurité informatique comme étant difficile. Ces règles de contrôle d accès font partie d un ensemble plus global de règles appelé politique de sécurité organisationnelle. Cette politique doit être, à notre sens, raffinée et décomposée pour obtenir des packages de règles. Chaque package est mis en œuvre par un composant de sécurité. Les VPN, IDS et firewalls sont des exemples de composants de sécurité réseau. Pour assurer une sécurité optimale, il est impératif que la configuration de ces composants soit exempte d erreurs et traduise la politique de sécurité spécifiée. Une politique de sécurité définit ce qui doit être «sécurisé» dans un système. Un mécanisme de sécurité sert à mettre en place une ou plusieurs parties de la politique de sécurité. Parmi les plus connus, le contrôle d accès occupe une place privilégiée. Les composants de sécurité réseau qui l assurent, principalement les firewalls et les VPN doivent être configurés «sans anomalies». L existence d une anomalie peut être exploitée par un attaquant qui agira dans le but de violer la politique de sécurité. Une technique d audit aurait un rôle majeur dans la détection d une telle violation ; si l audit est une technique a posteriori pour la détermination des violations de la politique de sécurité, un IDS (qui est une forme d audit pour la détection des attaques) peut prendre en compte le facteur «temps» (voire «temps réel»). En ce qui concerne le contenu de la politique de sécurité, il peut y avoir plus ou moins de détails. Son expression dépend de l environnement pris en compte (on trouve un exemple dans [4]). Généralement, elle contient une partie qui décrit le contexte, ses objectifs, une autre qui contient la politique proprement dite et éventuellement une dernière qui décrit son implémentation et les résultats possibles de certaines violations. La politique comprend des aspects classiques de la sécurité (le contrôle d accès, la confidentialité, l intégrité, etc.) ; la différence entre la politique de sécurité et sa description abstraite (le modèle) est essentielle. Si la première abonde en détails, spécifications informelles, le modèle doit abstraire les exigences importantes, idéalement en éliminant les redondances et les ambiguïtés. Le modèle sur lequel on se focalise, Or-BAC [16], est considéré comme le plus adéquat pour résoudre les nombreux problèmes existants dans les autres modèles de contrôle d accès (par exemple, la définition du contexte, la gestion des conflits, la délégation, l administration, etc.). Les sections suivantes présenteront les principales problématiques de configurations liées aux différents composants de sécurité réseau. La section 2.1 traitera les firewalls, leurs anomalies et de différents travaux menés pour leur configuration en vue de réduire ces anomalies. La section introduit les principaux modèles d IDS ; on a choisi de détailler la configuration du SNORT, en raison de ses caractéristiques intéressantes pour notre travail de stage à venir. La section présente la forme générale d une signature du SNORT ; ensuite, une configuration basée sur l approche descendante sera proposée dans La partie VPN est traitée dans les sections 2.3. Divers travaux concernant la conception des VPN Détection d anomalies dans les configurations de composants de sécurité réseau 4

5 basée sur une politique de sécurité sont présentés dans Dans la section nous décrivons une méthode d implémentation de la politique de sécurité à déployer sur les VPN. 1.1 La décomposition de politique de sécurité réseau Pour que les configurations des différents composants de sécurité soient «sans anomalies», l approche prise en compte est illustrée par la figure 1. Spécifications informelles de la politique de sécurité (1) Abstraction de la politique de sécurité I (2) Transformations II (4) (3) Firewalls VPN IDS Configuration des composants de sécurité III Fig.1 : Implémentation de la politique de sécurité. Une des causes d anomalies est l implémentation directe (4) : à partir des spécifications informelles de la politique de sécurité, on configure directement les composants de sécurité. On perd facilement dans ce cas les besoins d interopérabilité entre composants. L approche qui nous intéresse est la suite (1), (2) et (3). Au niveau I on trouve, basée sur le modèle Or- BAC, l abstraction des spécifications informelles, matérialisée en pratique sous la forme d un fichier XML [6]. Le niveau II est un niveau dit intermédiaire : il correspond aux règles de sécurité exprimées indépendamment du langage du composant de sécurité (dans la syntaxe XML). La transformation (3) a comme résultat des règles de configuration dans le langage spécifique du composant de sécurité. Pour détecter les anomalies dans la configuration des composants, on pourrait envisager leur définition dans la relation «spécifications informelles» «niveau III». Dans ce cas, on déterminerait le degré de conformité de l implémentation courante vis-à-vis des spécifications de la politique de sécurité. L utilisation de la technique d audit est une façon pour faire cette vérification. Il est sous entendu qu une des tâches délicates sera la transformation (1), qui devra couvrir le plus de détails des spécifications, traduits ensuite dans le modèle Or-BAC ( des travaux allant dans ce sens ont été menés dans [12]). Cette transformation n est pas automatisable, car elle dépend de choix spécifique au concepteur de la politique de sécurité : Détection d anomalies dans les configurations de composants de sécurité réseau 5

6 la définition des entités (organisation, sujets, objets, rôles, etc.), les relations entre les diverses entités (hiérarchies), etc. Dans un autre cas (celui que l on aborde), les anomalies seront considérées dans la suite (2) et (3). Si les transformations (2) et (3) sont «correctes» il n y aura pas d anomalies. Ces transformations sont complètement automatisables. Si le modèle au niveau I est matérialisé sous la forme d un fichier XML, les transformations (2) et (3) peuvent être implantées en XSLT et doivent être «correctes», reflétant au niveau concret les objectifs de sécurité imposées au niveau I. Les passages (2) et (3) peuvent être vues comme un processus de raffinement ; nous cherchons à construire une méthodologie, éventuellement un catalogue de transformations qui traduisent le modèle de niveau I vers une implémentation concrète de la politique de sécurité (niveau III). Dans ce cas, surtout pour la transformation (3), nous devons tenir compte du langage, de la grammaire, de la signature du composant de sécurité. La variété des composants, des constructeurs qui constituent le marché (Cisco, Linksys, ) nous obligent à prendre toujours en compte la syntaxe et la sémantique de ces composants. L automatisation de ces transformations permettrait donc de simplifier la configuration des composants de sécurité tout en s appuyant sur le modèle Or-BAC. A la fin de ce processus, une technique d audit pourrait être mise en place pour des éventuelles vérifications. Dans certains cas, un raffinement peut être réalisé par des algorithmes de réécriture, au niveau III. ([7]). 2. Les anomalies dans la configuration des composants de sécurité Nous allons nous intéresser à plusieurs types de composants réseau : firewall, IDS et VPN. Leur configuration qui se veut conforme à la politique de sécurité réseau peut entraîner des anomalies. L objectif de cette section est de rappeler les fonctions de ces composants ainsi que les différentes problèmes d anomalie qui peut apparaître pour chacun. 2.1 Les firewalls Règles de filtrage Un firewall est une machine qui sert comme intermédiaire pour l accès à un réseau (interne), permettant ou interdisant certain type d accès avec le respect d une politique de sécurité ([4]). Il réalise le filtrage des paquets en se basant sur un ensemble de règles définies par l administrateur de sécurité : prenant en compte l adresse/port source ou destination du paquet, le flag acknowledge ou même la date. Il met en place une protection contre : des connexions indésirables et/ou non authentifiées, des attaques sur les points faibles des systèmes d exploitation internes, des attaques par déni de service sur les machines internes. Il ne protège pas contre le trafic qui ne passe pas par lui, contre des virus (sauf s il intègre un anti-virus), contre des attaques exploitant ses propres vulnérabilités ou si les machines internes sont mal administrées. Une règle de filtrage prend la forme illustrée par le tableau 1 (généralement, tout paquet n étant pas explicitement autorisé est rejeté, on dit alors que la politique est fermée) : Détection d anomalies dans les configurations de composants de sécurité réseau 6

7 action destination port source Port commentaire accept adr. IP dest. N port dest adr. IP source N port source connexion Tableau 1 : règle de filtrage Les règles sont analysées les unes après les autres, jusqu à ce qu une règle applicable soit trouvée. L ordre des règles dans la configuration d un firewall compte et peut être une cause d anomalies. Etant donné que l objectif est de réduire ce risque d anomalies, de les détecter et de les éliminer, la démarche que l on propose est la suivante : politique (modèle OR-BAC) filtre en langage indépendant de la grammaire du firewall traduction dans le langage du firewall (la suite (2) et (3) dans la figure1) Règles intrinsèquement respectées par un firewall Les règles qui apparaissent dans la configuration des firewalls doivent être vérifiées périodiquement. Pour cela, soit on extrait les fichiers de configuration des firewalls et on fait leur analyse vis-à-vis de la politique de sécurité, soit on met en place des techniques d audit dans les architectures qui comprennent des firewalls. Le but est d assurer que la configuration est en totale conformité avec la politique de sécurité. Même si, pour l implantation des règles dans un firewall il est recommandé de suivre l approche décrite dans 2.1.1, il y a un jeu de règles qui devraient être toujours respectées, indifféremment de la politique de sécurité (elles apparaissent implicitement dans tous les cas), concernant : Le trafic entrant provenant d une source (voire usager) non authentifiée, ayant comme destination le firewall lui-même ; cette fonctionnalité d authentification d usager n est pas présente dans tous les firewalls. Le trafic entrant avec une source appartenant au réseau privé protégé par le firewall ; Le trafic ICMP (on sait qu il peut servir à la découverte de la topologie du réseau) ; Le trafic entrant SNMP (l intrus probe le réseau) ; Le trafic entrant contenant de l IP Source Routing Information (des cas très rares) ; Trafic entrant ou sortant contenant comme adresse source ou destination ou ; Une liste complète se trouve dans [17]. La section traite les principales anomalies et leur détection dans les firewalls. Ensuite, présente des travaux portant sur leur configuration Analyse d une configuration existante La première remarque que l on peut faire est que la configuration directe (4), fig.1, est fréquemment source d erreurs de configuration. N ayant pas une base solide reposant sur des règles bien établies au niveau abstrait, il est peu probable qu une telle démarche soit exempte d erreurs. L un des aspects qui n est pas pris en compte par une telle approche est l interopérabilité des différents composants réseau dans la mise en œuvre de la politique de sécurité. Une anomalie apparaît dès qu un paquet qui arrive au niveau du firewall trouve plusieurs règles qui peuvent lui être appliquées (deny, accept, drop) avec la même priorité (la Détection d anomalies dans les configurations de composants de sécurité réseau 7

8 règle R1 est prioritaire par rapport à la règle R2 si R1 et R2 s appliquent toutes deux au paquet traité et c est la décision associée à R1 qui est privilégiée). Une fois les règles définies, les interactions entre celles-ci doivent être gérées. Plus le nombre de règles est grand, plus aisément des contradictions, conflits, ou redondances surgissent. Dans ce cas, des outils de vérification, d analyse de la configuration s avèrent utiles. Les principales anomalies sont la redondance et le shadowing (le masquage) ; ces anomalies sont définies de la façon suivante : On dit qu une règle est redondante, si on peut la supprimer sans changer la décision de filtrage, quel que soit le paquet présenté en entrée. [7] donne une définition formelle de la redondance. La redondance est considérée comme une erreur, elle ne contribue pas à la décision du firewall, par contre elle augmente la taille du tableau de règles ainsi que le temps de calcul. On dit qu une règle est masquée (shadowed) si la règle ne s applique jamais parce que des règles ayant des priorités plus grandes sont toujours applicables. La règle R2 est masquée par la règle R1 si R1 est plus prioritaire que R2 et R2 représente un sous ensemble de la règle R1 mais leurs décisions sont contradictoires. Le shadowing est critique car la règle masquée ne sera jamais utilisée. La conséquence est qu un paquet peut être accepté alors qu il aurait peut-être du être rejeté ou inversement (un paquet va peut-être être rejeté alors qu il aurait du être accepté). Une définition complète se trouve dans [7]. La littérature introduit d autres anomalies : la corrélation et la généralisation ([1]) ; selon leurs définitions, on remarque qu elles correspondent aux cas des règles «partiellement» redondantes, respectivement masquées. On réduit donc dans la suite ces cas considérés à de la redondance et à du shadowing. [14] et [11] offre une vision intéressante de la politique de sécurité mise en place par un firewall, en montrant ses anomalies. Elle consiste en un graphe où chaque noeud représente un champ de la règle de filtrage (par exemple, adresse IP source), chaque branche étant une valeur possible du champ ; les feuilles sont les actions pouvant être prises (accept, deny, drop). Une règle de filtrage sera un chemin commençant par la racine et se terminant par une seule feuille. L intérêt d une telle représentation est la simplicité d ajouter d autres règles (d autres branches) ; bien entendu, l ajout d une règle ne se traduit pas toujours par un simple ajout d une branche, il implique parfois une modification plus complexe de l arbre si on ne veut pas avoir des anomalies. Détection d anomalies dans les configurations de composants de sécurité réseau 8

9 Fig. 2 l arbre de la politique de sécurité [14] propose des algorithmes pour la découverte des anomalies, ainsi que pour l insertion (la mise à jour) de nouvelles règles ; ils sont développés en ayant cette vision - le graphe de la politique de sécurité. L idée de base est de vérifier si deux règles s appliquent au même chemin ; ce cas est saisi par l administrateur et des choix pour une correction lui sont offerts. C est sur ce mécanisme que certains analyseurs de la politique de sécurité fonctionnent. Parfois on désire des algorithmes qui font la correction, la réécriture automatique des règles, tout en préservant la politique de sécurité. Ils font la découverte des anomalies et prennent directement la bonne décision de réécriture. Ces algorithmes doivent être plus puissants, car ce n est plus l administrateur qui prend la décision en ce qui concerne la réécriture. L approche que l on a dans ce cas est basée, intuitivement, sur la projection d une règle ayant n attributs sur un espace à n dimensions (par exemple, fig. 3). En considérant deux règles de filtrage qui impliquent des adresses IP de la même sous-classe, l abscisse constitue un intervalle d adresses source, l ordonnée est un intervalle d adresses destinations. Une règle apparaîtra dans cet espace comme un rectangle ; une anomalie existe si deux (ou plusieurs) rectangles sont superposés [3]. Si on se limite à la redondance, l algorithme de réécriture s articule autour de la redéfinition des règles rectangles, qui n auront aucune portion commune (totalement disjointes), conservant la même «figure» dans l espace 2D. La figure suivante explique la démarche : Détection d anomalies dans les configurations de composants de sécurité réseau 9

10 d R1 R2 d R1 R2 d1 d2 s1 s2 s s a) b) Fig.3 : réécriture en cas de redondance Au début, les règles R1 et R2 ont une «portion» commune (redondance partielle), sur l espace d adressage source [s1, s2], respectivement destination [d1, d2] (fig.3.a). Les algorithmes de réécriture détectent la redondance et réalisent les règles R1, R2 qui sont disjointes dans l espace 2D (fig.3.b). La démarche complète est expliquée dans [7], ainsi que les algorithmes (qui ont été implémentés). Il s agit donc d un raffinement au niveau III, fig.1. Jusqu ici, le type d anomalies décrites était intra-firewall. Bien entendu, on peut envisager des architectures de réseau comportant plusieurs firewalls qui doivent coopérer, en délimitant des zones (par exemple, DMZ) dans le réseau. Un nouveau type d anomalie apparaît dans le cas d une mauvaise configuration des machines : des anomalies inter-firewall. Même si localement, les firewalls sont bien configurés (sans redondance ni masquage), un conflit entre ces firewalls peut apparaître dans la mesure où un firewall laisse passer les paquets (car localement la politique de sécurité le leur permet) et un autre les bloque. Des travaux existent et proposent des algorithmes d analyse des règles dans ce cas d anomalie inter-firewall ([1]) Génération d une configuration La première référence, [12], introduit un nouveau concept, celui de tactique de sécurité. C est un niveau d abstraction intermédiaire entre la politique de sécurité (modèle RBAC [19]) et son implémentation. Pour l exprimer, un langage de spécification est introduit. Il devrait assurer la description des éléments constitutifs d un réseau, les différentes technologies, la topologie du réseau, etc. Cette tactique de sécurité implique l identification des diverses fonctionnalités qui doivent répondre aux besoins de sécurité. Les composants ne sont plus traités sous leur forme réelle, car une première architecture comprend des composants particuliers, classés en fonction de leur comportement dans le réseau : des composants qui consomment les flux de données (les terminaux), des composants qui propagent les flux (des canaux), d autres qui le transforment (par exemple NAT, VPN), respectivement qui filtrent les flux (des modules de contrôle d accès au niveau du système d exploitation, des firewalls, etc.). Ceci est décrit dans le langage de la tactique. L approche proposée est très intéressante Détection d anomalies dans les configurations de composants de sécurité réseau 10

11 car elle serait utile dans le cas où il faudrait implémenter une politique de sécurité qui ne serait spécifiée que par des règles informelles (fig. 1) et aucune architecture réseau. Bien qu elle raisonne sur différents plans, (au niveau applicatif, on retrouve le modèle RBAC qui s appuie sur une infrastructure réseau résultant de l interconnexion de différentes fonctionnalités consommation des flux, filtrage, transformation), la procédure par laquelle l auteur explique le passage : [ règle informelle modélisation RBAC règles écrites dans le langage de la tactique de sécurité ] est dépourvue de continuité. On observe le manque de précision des étapes. D autre part, la tactique de sécurité est évaluée par des simulation en logique CTL visant (1) son exactitude : les mécanismes (par exemple, contrôle d accès) doivent répondre aux objectifs de sécurité définis dans RBAC, (2) sa consistance vis-à-vis des incompatibilités entre les mécanismes et (3) sa faisabilité : la tactique doit pouvoir être dérivée vers des technologies existantes (implémentation concrète dans les composants de sécurité). Ce processus formel de transformation entre les trois niveaux (les objectifs de sécurité spécifiés dans le modèle Or-BAC, la tactique de sécurité et la configuration des équipements), est abordé en exploitant le modèle CIM (Common Information Model) qui assurerait une représentation uniforme des informations des ressources gérées : il y a divers schémas CIM pour décrire le modèle RBAC, la tactique de sécurité (les fonctionnalités de base et leur interconnexion ; par exemple, la classe CIM_LogicalElement), les technologies (firewalls, VPN, etc.), ainsi que pour les relations entre ces trois niveaux. Un outil pour l automatisation de l analyse de l exactitude et de la consistance de la tactique de sécurité a été développé ; quant à l analyse de faisabilité, elle dépend de la technologie employée dans l architecture réseau mise en place ([12] donne un exemple pour des VPN et des firewalls). Cette approche d unification de l information (sous CIM), est intéressante, vu la diversité des composants réseau (l hétérogénéité réseau) mais elle est contrecarrée par une complexité croissante en terme de gestion, de la modélisation du processus de raffinement présenté ci-dessus; d autre part, la démarche proposée dans [12] manque de consistance au niveau théorique (saut des étapes lors du passage entre les 3 niveaux rappelés). Cependant, on peut retenir cette approche, qui permet de donner une représentation formelle de la politique de sécurité à un niveau intermédiaire, indépendamment de la technologie des composants sécurité. Firmato «A Novel Firewall Management Toolkit» ([2]) se veut un outil de configuration des firewalls dans lequel on retrouve une séparation entre le modèle de la politique de sécurité et les spécifications technologiques des composants de sécurité. L un de ses objectifs, en phase préliminaire de conception, et de permettre l implémentation de la politique de sécurité indépendamment de la topologie du réseau. Ainsi, face à des changements dans la topologie, la politique de sécurité serait maintenue et la génération des règles concrètes pour les firewalls serait, évidemment, automatique et accompagnée par un debugger qui permettrait à l administrateur de réseau de raisonner sur les fichiers des configurations des firewalls. L outil réalisé est basé sur un Modèle Entité-Association (niveau «abstrait») qui prend en compte la topologie du réseau (donc pas d indépendance claire entre la politique de sécurité et la topologie du réseau) par un concept nouveau, rôle, qui définit «les capacités du réseau» («positive capabilities») et que les auteurs utilisent sans une sémantique claire et non ambiguë. L instanciation du Modèle Entité-Association est faite par un langage de définition du modèle et un Compilateur de Modèle qui réalise la traduction (du Modèle Entité-Association) vers les fichiers de configuration du firewall. Par ce concept de rôle, on constate un mélange entre la topologie du réseau (niveau concret) et la politique de sécurité, d où l ambiguïté. Une nouvelle notion, celle de groupe est introduite qui, elle aussi, n est pas claire. En effet, cette notion de groupe désigne parfois un ensemble de machines, parfois un rôle. Celle-ci conduit inévitablement à des difficultés d affecter des entités réseau Détection d anomalies dans les configurations de composants de sécurité réseau 11

12 aux entités du modèle. Les auteurs utilisent l héritage des privilèges parmi les hiérarchies des groupes pour dériver automatiquement des permissions. Pour l héritage des permissions, ils introduisent la notion de «groupe ouvert» et pour les interdictions de «groupe fermé». Cette notion de groupe induit des confusions, alors qu elle n est pas nécessaire à ce niveau d abstraction. Les firewalls actuels ont des langages de configuration avec des sémantiques diverses. Chaque firewall implémente son algorithme qui s appuie sur un certain langage. L existence d une telle diversité de langages rend la tâche de gestion des composants de sécurité difficile. L implémentation d une politique de sécurité, dans les cas de certains outils (Cisco PIX, IpFilter, etc.), commence en prenant en compte le langage de configuration du firewall. Avec cette approche ascendante, il est fort probable qu on obtienne des non-conformités avec les spécifications de la politique de sécurité. D où l intérêt de l approche descendante (fig. 1) mentionnée auparavant. [6] offre une démarche très détaillée et claire du processus d implémentation de la politique de sécurité, en se basant sur le modèle Or-BAC (Organization Based Acces Control). Par rapport à RBAC, Or-BAC évite de nombreux inconvénients (d ailleurs vus aussi dans d autres modèles classiques) parmi lesquels la complexité rapide des règles à exprimer, l absence de structuration des règles, l absence de gestion de contextes et de conflits. Or- BAC est basé sur le concept d organisation qui désigne toute entité qui prend en charge une partie de la politique de sécurité (par exemple, un firewall) ([8]). Il s appuie sur deux niveaux d abstraction : un niveau organisationnel (avec les entités rôle, activité et vue) et un niveau concret (sujet, action, objet). Il permet d écrire (dans un formalisme articulé autour de la logique du premier ordre) des permissions, des interdictions et des obligations, indépendamment de l implémentation de la politique de sécurité. La gestion des contextes assure la prise en compte d une large variété de contextes (temporel, spatial, défini par l utilisateur, etc.). Il est possible de spécifier des contraintes sur les entités et les prédicats définis. L administration du modèle Or-BAC se fait par l intermédiaire du modèle AdOr- BAC qui assure une «auto-administration» du modèle Or-BAC ([16]). Les rôles standard et ceux administratifs ne sont pas séparés, les règles administratives ont le même format que celles standard. Alors que d autres modèles basés sur les «rôles» ne contrôlent pas la délégation, un composant du modèle AdOr-BAC le permet. [6] présente en détail le processus de génération automatique de règles de filtrage pour des firewalls à partir d une spécification formelle de la politique de sécurité réseau, exprimée avec Or-BAC. Habituellement, celle-ci sera déployée sur plusieurs composants de sécurité. L approche prise en compte est illustrée par la figure 4. Détection d anomalies dans les configurations de composants de sécurité réseau 12

13 Politique de sécurité Or-BAC (xml) XSLT Langage de Politique de sécurité XSLT IDS, Snort NetFilter Cisco PIX Autres composants Fig. 4 : approche descendante Au niveau du modèle Or-BAC, la politique de sécurité est exprimée en XML. Toutes les entités organisationnelles du modèle (rôle, activité et vue) et concrètes (sujets, objets, actions) sont décrites en XML. Par exemple, les firewalls sont considérés comme des organisations/sous-organisations (ils implémentent chacun une partie de la politique de sécurité). Les terminaux sont des sujets, à qui l on peut affecter des rôles (des serveurs), les services sont vus comme des activités (ftp, https, ssh, etc). Avec une première transformation XSLT, on génère des règles génériques dans un langage «multi-target», indépendamment du langage du composant de sécurité visé, on spécifie les entités (rôles, activités, vues) significatives dans chaque sous-organisation (dans ce cas les sous-organisations sont des firewalls) et on attribue à chacune les permissions/interdictions appropriées. Ensuite, avec la deuxième transformation XSLT, on génère des règles concrètes dans le langage de configuration du composant de sécurité cible. Pour le cas particulier de NetFilter, grâce à ses chaînes de filtrage, l ordre des règles concrètes, générées après la deuxième transformation XSLT, n est pas important (ce qui, généralement, n est pas le cas pour d autres types de firewalls pour lesquels cette transformation doit respecter un certain ordre des règles de filtrage, [16]). Le niveau d abstraction offert, la flexibilité concernant les règles à ce niveau, le modèle d administration existant, le fait de pouvoir spécifier une politique de sécurité indépendamment de la technologie employée font de Or-BAC le modèle sur lequel notre configuration des composants de sécurité sera basée. Détection d anomalies dans les configurations de composants de sécurité réseau 13

14 2.2 Les IDS Différentes approches de la Détection d Intrusion L audit est une technique a posteriori pour la détection des violations de la politique de sécurité. Le but de l IDS (Intrusion Detection System) est de détecter une grande variété d intrusions (des attaques connues ou inconnues), de préférence en temps réel (même si l analyse des commandes a un impact sur le temps de réponse du système), de représenter les résultats de l analyse dans un format simple et compréhensible et surtout d éliminer les «anomalies» concernant de fausses alarmes, faux négatifs et faux positifs. L IDS doit être efficace et fiable étant donnée la politique de sécurité mise en place. Il existe une grande variété d IDS principalement basés sur l un de ces trois modèles : la détection par seuil, la détection de comportement anormaux («anomaly detection») et la détection par scénarios d attaques («misuse models»). La détection par seuil analyse le comportement du système. Lorsqu un certain événement se produit trop souvent, dépassant un certain seuil qui a été fixé par ailleurs, une alarme est déclanchée. Par exemple, un nombre trop élévé de logins ayant échoués peut révéler une attaque réseau par cracking de mot de passe. La détection de comportements anormaux analyse un ensemble de caractéristiques du système et compare ses valeurs avec d autres, attendues. L approche basée sur un profil définit le comportement comme un ensemble de métriques (fréquence de logins, utilisation des commandes et d applications système, CPU, etc.) associées aux activités. Le profil correspond à une combinaison de ces métriques. Le profil courant est comparé au profil normal, si la déviation dépasse un seuil, une alarme est déclanchée. L approche neuronale [20] introduit une fonction d apprentissage. Ainsi, on essaie de prédire le comportement futur. Si la différence entre le comportement prédit et celui courant dépasse un seuil, une alarme est générée. L un des avantages de la détection par comportement est que la base de données de comportements normaux est créée au fur et à mesure, pendant une phase d apprentissage. L inconvénient est qu il faut assurer tout au long de cette période un comportement stable du système. La mise à jour de celle-ci, périodiquement, est l occasion pour un attaquant d y insérer son attaque qui sera ensuite traitée comme un comportement normal. En plus, en cas de profonde modification de l environnement, un flot ininterrompu d alarmes peut être généré (risques de faux positifs). Par rapport à l approche par scénarios discutée ci-après, la détection d intrusions inconnues est possible. La détection par scénarios est la plus courante. Elle nécessite la construction d une base de données d attaques. La recherche des attaques dans les données se fait généralement par application des techniques d analyse de signatures («pattern matching»). Elles déterminent si une séquence d instructions exécutée viole la politique de sécurité. La prise en compte des comportements exacts des attaquants (la définition précise des signatures d attaques) induit peu de faux positifs. La difficulté est de maintenir à jour une base de signatures, provoquant sinon le risque de faux négatifs. La détection d attaques inconnues n est pas possible, d où le même risque de faux négatifs. Les IDS «hôte» (par exemple, AAFID [26], ASAX [22], GASSATA [23]) obtiennent leurs informations des fichiers «logs». Ils détectent des violations de la politique de sécurité correspondant à des tentatives d exécution de l application dans un mode privilégié, des tentatives d accès à un fichier non autorisé ou la fourniture d un mot de passe erroné pour cet accès, le changement des droits d accès à des fichiers sensibles, etc. Les IDS «network based» (par exemple, BlackICE, Centrax, CyberCop Monitor, Dragon, Intruder Alert, NetProwler, NetRranger, NFR, RealSecure, etrust, SNORT, BRO, EMERALD, GrIDS, Shadow [24]) détectent des attaques orientées réseau ; ils peuvent surveiller le trafic Détection d anomalies dans les configurations de composants de sécurité réseau 14

15 («network sniffing») du réseau, généralement s il n est pas chiffré, pour un grand nombre d hôtes. Parmi cette multitude de IDS, en raison de nombreuses fonctionnalités qu il offre, SNORT sera celui sur lequel on va se focaliser par la suite SNORT SNORT est un logiciel IDS «ouvert» qui peut être utilisé en mode «sniffer», en mode de «journalisation des paquets» («packet logger») ou en mode «Détection d intrusions». La détection des paquets malveillants est basée sur une base de signatures d attaques. Il est capable de détecter un grand nombre d attaques comme des DoS (déni de service), Portscans, des attaques orientées http, DNS, SMTP, IMAP, POP3, même des attaques de vers. La communauté Internet offre de nombreuses bases de signatures. Comme elles sont complètement ouvertes (en «open source»), il est possible d écrire de nouvelles signatures. De nombreux outils pour la gestion de règles existent (par exemple, «IDS Policy Manager» [25]). Ils comprennent une interface graphique simple pour saisir de nouvelles règles, pour activer/désactiver un jeu de règles de la même famille (par exemple, signatures DNS), etc. Bien entendu, la configuration de l IDS doit être fondée sur une politique de sécurité. L analyse des paquets est réalisée en examinant l en-tête IP et le contenu du paquet pour rechercher des commandes, ou des chaînes représentatives de l attaque. Un IDS «hôte» n est pas capable de détecter les attaques présentées dans le contenu du paquet IP. La réponse de SNORT est en temps-réel, ce qui n est pas toujours le cas pour un IDS «hôte». Pour ce dernier, la notification d un certain événement peut être détectée après le déroulement de l attaque. Dans le cas d une attaque DoS (déni de service), la connexion TCP est instantanément arrêtée par SNORT (TCP «reset»), avant que le système ne tombe. SNORT peut être employé en complément des autres composants de sécurité. S il est placé «devant» un firewall, il peut détecter des attaques orientées vers les ressources situées derrière ce firewall. A l intérieur du réseau local, l IDS vérifie si la configuration du firewall est en conformité avec les spécifications de la politique de sécurité (si le trafic et les adresses que le firewall devrait rejeter le sont vraiment). [13] décrit différentes implémentations architecturales des IDS (SNORT) sur le réseau, en relevant les avantages et les inconvénients surtout du point de vue IP, c est-à-dire comment et où implanter l IDS dans le réseau. Bien que cet aspect soit important, l aspect majeur (principal) reste la manière d implémenter concrètement la politique de sécurité, la partie dédiée à l IDS, sous la forme de signatures. [4] présente de manière informelle la politique de sécurité dédiée IDS pour un réseau local qui contient des postes UNIX et qui partagent des fichiers en utilisant le protocole NFS. Ces spécifications qui décrivent la journalisation («logging») des paquets, les actions qui déclenchent des alertes et d autres actions caractéristiques de l IDS (drop, reject, etc.) devront être saisies et exemptes de redondance. Ensuite, elles doivent être implémentées sous la forme d un jeu de règles d IDS. La fiabilité et l efficacité de l IDS ainsi configuré, étant donnée la politique de sécurité (peu de faux négatifs/positifs), dépendent des définitions des signatures, de leurs précisions. La forme générale d une règle du SNORT est la suivante : <Action> <Protocole> <Adresse_IP_Source><N _Port_Source> -> <Adresse_Ip_Cible><N _Port_Cible> Détection d anomalies dans les configurations de composants de sécurité réseau 15

16 [(<option 1> ; < option 2> ; <option k>)] Exemple (extrait du manuel Snort) : alert tcp! [ /24, /24] any -> [ /24, /24] 111 (content : " a5 " ; msg : "external mountd access";) Cette règle déclenche une alerte, en renvoyant le message «external mountd access» lorsqu un paquet qui contient la chaîne « a5» est trouvé (sniffé). L opérateur «!» indique que la règle concernant les paquets ayant comme adresse source une adresse différente de /24, ou /24. L option «content» est l une des plus importantes. Elle permet la définition d une règle qui cherche, en s appuyant sur l algorithme de Boyer-Moore (voir manuel Snort), une chaîne spécifique (texte et/ou codes hexadécimaux) dans le paquet IP, chaîne considérée comme représentative d une attaque. SNORT offre une multitude d options dont dépend la précision des règles. Cependant, leur définition et leur gestion restent des tâches difficiles Configuration de SNORT [6] applique le modèle Or-BAC pour la configuration des firewalls (NetFilter). Dans 2.1.4, on a vu l importance de l approche descendante pour implémenter la politique de sécurité. On a souligné les avantages d Or-BAC par rapport aux autres modèles (Firmato) et on pourrait envisager d appliquer une démarche similaire pour configurer les IDS (tels que SNORT). Les «objets» dans le modèle Or-BAC correspondent aux messages échangés par les hôtes. Un message est représenté par deux éléments : le contenu du message et la station qui le recoit. Pour l IDS, le contenu du message (du paquet) sera pris en compte pour définir des règles, signatures. Certaines «vues» en Or-BAC incluront des conditions sur ce contenu. Les «sujets» étaient des hôtes et on leur attribuait des «rôles». Dans ce cas, la station qui implémentera l IDS aura le rôle d IDS (SNORT) tout comme certains hôtes auront le rôle de dns_server, ou de firewall ([6]). Bien entendu, étant donnée qu une «organisation» implémente une partie de la politique de sécurité, l IDS lui-même sera une organisation. Les actions réalisées par le sujet ayant le rôle d IDS sur les objets (messages), en fonction de leur contenu, pourraient être les actions qui apparaissent dans la définition de signatures IDS (alert, log, pass, activate, drop, reject, sdrop, etc.). La seule difficulté sera la création des «vues» appropriées, au niveau abstrait, car les messages (les contenus) peuvent contenir différents détails qu on doit saisir. Une fois pris en compte, ils renforcent la fiabilité et l efficacité de l IDS. Comme spécifié en 2.1.4, le modèle Or-BAC de la politique de sécurité réseau (y compris la partie IDS), spécifié sous la forme d un fichier XML, aura subi une première transformation XSLT (on a vu l objectif d une telle transformation dans la section 2.1.4). La deuxième transformation XSLT sera conforme à la technologie envisagée. Pour l IDS, bien évidemment, celle-ci sera différente de celle correspondant aux firewalls. Cette approche offre la possibilité de manipuler des données dans un format XML à tous les niveaux (fig.1). Par exemple, extraire la politique de sécurité, niveau III (fig.1) pour certaines vérifications ultérieures ou pour des échanges d information vers d autres systèmes. [5] et Détection d anomalies dans les configurations de composants de sécurité réseau 16

17 [18] donnent des modèles pour représenter les données pouvant être exportées à partir de la configuration d un IDS (SNORT). 2.3 Les VPN Technologie de réseaux privés virtuels Les réseaux privés virtuels (VPN Virtual Private Networks) peuvent être vus comme des services réseaux délivrés à travers une infrastructure de réseaux publics. Dans une première approche, le VPN connecte deux points à travers un réseau public pour obtenir une liaison logique. Cette liaison se fait soit au niveau 2 du modèle OSI, soit au niveau 3. En principe, il n y a pas de différence conceptuelle entre les VPN de niveau 2 et ceux de niveau 3. Les deux impliquent l ajout d un nouvel en-tête au paquet de données pour atteindre la destination. Implémenter un VPN de niveau 2 dans un routeur est similaire à implémenter un VPN en utilisant une technologie comme ATM ou Frame Relay. Un tel réseau établit une connectivité de bout-en-bout entre deux sites sur un circuit virtuel qui est une liaison logique de type PVC (circuit virtuel permanent). Un VPN de niveau 2 peut généralement transporter du trafic indépendamment du protocole de niveau 3 OSI, tout en assurant une certaine qualité de service (QoS). Pour relier les deux sites à travers un tunnel, le fournisseur du service VPN peut utiliser la technologie MPLS [21] à travers son réseau. Il ne connaît pas la topologie des sites, il configure les routeurs du cœur du réseau et les deux routeurs de bordure (PE provider edges) connectés respectivement à chacun des sites pour qu ils réalisent un tunnel MPLS. La topologie du VPN est déterminée par les configurations des PE. Pour les VPN de niveau 3 OSI, la technologie la plus répandue est l IPSec (IP Security). Elle comprend un ensemble de mécanismes destinés à garantir au trafic IP une sécurité de basée sur la cryptographie. Les services proposés par IPSec offrent le contrôle d accès, l intégrité en mode non connecté, l authentification de l origine des données, la protection contre le rejeu et la confidentialité. IPSec utilise deux protocoles pour assurer la sécurité du trafic : AH (Authentication Header) et ESP (Encapsulating Security Payload). Ils supportent deux modes d utilisation : le mode transport (qui propose une protection seulement pour les protocoles supérieurs à l IP) et le mode tunnel, où l on trouve une sécurisation de la couche Transport et IP. L en-tête original du datagramme est remplacé par un autre pour servir au routage tout au long du tunnel VPN. L en-tête d authentification (AH), un champ supplémentaire ajouté au datagramme IP, répond aux besoins d intégrité des données en mode non connecté, l authentification de l origine de données et éventuellement pour l anti-rejeu. L ESP assure de plus la confidentialité des données. Le principe est de générer un nouveau datagramme, à partir de celui d origine qui aura contenu les données et/ou l en-tête d origine chiffrés. Ce que l on trouve souvent est l ESP en mode tunnel. Les fonctions de chiffrement ne sont pas mises en œuvre de bout-en-bout, mais uniquement sur le réseau dit «non confiance», entre les deux correspondants VPN. Sur cette portion, le paquet original IP est entièrement chiffré, signé et encapsulé dans un nouveau datagramme qui aura comme contenu pour les adresses IP source et destination, celles des correspondants VPN les extrémités du tunnel. Avant l échange de l information, un certain nombre de paramètres sont négociés entre les deux parties communicantes (algorithmes de chiffrements, les clefs, etc). Ce contexte est placé dans une SA (Security Association), qui est unidirectionnelle. Concernant la gestion des SA, le protocole de gestion de clefs pour IPSec est par défaut IKE (Internet Key Exchange). Il Détection d anomalies dans les configurations de composants de sécurité réseau 17

18 se déroule en deux phases ayant comme but la négociation de certains paramètres (durée de vie de la SA, algorithmes d authentification, algorithmes de chiffrement, etc.), l élaboration de clefs d authentification et de chiffrement, l authentification mutuelle des correspondants VPN (mode d authentification, par clefs pré-partagées, ou par certificats X509). Une politique de sécurité IPSec décrit un jeu de règles pour assurer la sécurité du trafic IP ([15]). IPSec peut être implémenté au niveau des routeurs, passerelles, hôtes ou n importe quel autre système demandant une connexion sécurisée. De tels systèmes fournissent un large ensemble de protections. Si un firewall réalise le contrôle d accès en analysant les paquets IP et en décidant lesquels laisser passer, par IPSec on contrôle l intégrité, l authenticité, l antirejeu et la confidentialité des données. La gestion des composants implémentant l IPSec est une tâche difficile La conception des VPN Supposons une politique IPSec, pour un VPN entre plusieurs domaines ou sites. La politique est bien spécifiée et fonctionne correctement si, globalement, on n enregistre pas de brèches de sécurité et si le traffic IP ne souffre pas des blocages. Même si la politique est bien spécifiée, localement, dans chaque domaine, l ensemble des politiques doit pouvoir interagir de façon non conflictuelle. Ainsi, ([9] et [15]) argumentent la nécessité d un système de management pour assurer un service de sécurité de bout-en-bout. Ils introduisent deux niveaux pour spécifier la politique du VPN IPSec : un niveau «haut» (high level policy) qui représente les objectifs du VPN (les requis vis-à-vis d un certain trafic) et un niveau «bas» (low level policy), l implémentation de la politique dans les composants de sécurité. Un processus de transformation entre les niveaux devrait être défini tout en gardant la conformité entre ceux-ci. Un même niveau «haut» peut se traduire en diverses configurations concrètes au niveau réseau, en se basant sur certaines hypothèses (par exemple, de confiance : une passerelle a le droit d analyser le trafic, en le déchiffrant, car on lui fait confiance). Les spécifications au niveau «haut» comprennent : (1) la désignation du trafic (par un attribut flow id (src-addr, dst-addr, src-port, dst-port, proto, [user id] )) qui sera permis (allow) ou rejeté (deny), (2) les fonctions appliquées sur le trafic (sec functions qui peuvent être de l authentification, du chiffrement, etc), (3) certains nœuds ayant le droit d analyser le trafic (des firewalls, des IDS, etc.), éventuellement de le modifier et des nœuds pouvant accepter ou refuser des SA. Une politique de sécurité P sera une règle de la forme : P = (if condition) (actions) où condition comprendra les champs flow id, sec functions access nodes et différents nœuds concernés pour une SA donnée, actions spécifie les actions à entreprendre (sec functions) sur le trafic désigné, des algorithmes utilisés pour la protection du trafic (2.3.1), sur que les réseaux ces fonctions sont maintenues (from sous-réseau1 to sousréseau2, le trafic doit être protégé), éventuellement les nœuds qui ont le droit d analyser le trafic (trusted nodes). Au niveau «bas», condition vérifie les champs src-addr, dst-addr, src-port, dst-port, proto, ah-hdr (en-tête AH), esp-hdr (en-tête ESP). Quant à actions, elles peuvent être de trois types : deny (rejeter les paquets qui ne vérifient pas condition), allow, ou ip-sec action (secprot, algorithm, mode, from/to) où sec-prot indique le type de protocole AH ou ESP, algorithm, voir la section 2.3.1, mode précise si c est transport ou tunnel, from/to sont les deux nœuds qui créent la SA. Détection d anomalies dans les configurations de composants de sécurité réseau 18

19 Une politique de sécurité est «correcte» si le niveau «bas» est en parfaite conformité avec le niveau «haut». Elle présente des anomalies (des conflits) si, globalement (pour tous les nœuds où l on déploie la politique VPN) le trafic n est pas traité comme spécifié au niveau «haut». [9] présente quelques exemples où les spécifications du niveau «haut» ne sont plus respectées à cause d un enchevêtrement de tunnels IPSec. On arrive dans certains cas à des situations où le trafic parcourt deux fois le même chemin, circulant finalement vers la destination (le deuxième correspondant VPN) sans aucune protection, alors qu au niveau «haut» la politique requérait un certain service tout au long du tunnel IPSec. D où l importance pour le système de gestion de la politique VPN de résoudre de tels conflits ([9], [15]). Dans [15], le système de gestion de la politique VPN inclut un serveur qui définit, garde et traduit les objectifs de la politique de sécurité dans une configuration des composants réseaux. Au lieu d expliciter la politique de sécurité pour chaque composant réseau, [15] utilise le concept de rôle dont l intérêt est de spécifier la politique conformément aux fonctionnalités de chaque composant (et une meilleure gestion d un grand nombre de composants). Le modèle de la politique de sécurité IPSec est une représentation objet. Le rôle est une simple chaîne de caractères associée à chaque interface du composant. La classe SACondition et PolicyAction apparaissent en association avec une classe, SARule. Lorsque les attributs de la SACondition, associée à la classe SARule sont évalués à TRUE, les actions associées dans SAActions sont appliquées. Si [15] et [10] discutent sur un tel système de gestion de la politique de sécurité VPN, déployé sur un seul domaine, [9] présente CELESTIAL, un système de gestion inter-domaine Configuration d un VPN Cependant, un aspect important est toujours négligé : généralement, on ne peut pas séparer la politique de sécurité en une partie axée sur le VPN, une autre sur le contrôle d accès réseau et enfin une troisième sur les signatures de détection d intrusions sans le risque de conflits. Il faut envisager la configuration de tous les composants de sécurité (firewalls, IDS, VPN) comme un ensemble. Ainsi, le modèle Or-BAC avec son modèle d administration peut être utilisé pour fédérer les différentes phases de la politique de sécurité (fig. 4). Toutes les spécifications d une politique de sécurité seront présentes au niveau abstrait (I, fig.1). Les sujets, une fois identifiés, se voient attribuer des rôles. Ils auront ainsi le droit (Is_Permitted) de réaliser certaines actions sur des objets (des messages, leurs contenus, etc.). Par exemple, un routeur avec le sous-rôle IPSec_ESP réaliserait l action encapsulation sur des paquets (objets) ayant certains attributs et dans un certain context (par exemple, un intervalle temporel). Ensuite, seulement après la première transformation XSLT (fig. 4) vers le niveau intermédiaire, il faudra définir le deuxième ensemble de transformations en tenant compte de chaque technologie employée (firewall, IDS et VPN). Avec une telle approche, le risque de conflits inter composants et inter technologies peut être éliminé. Détection d anomalies dans les configurations de composants de sécurité réseau 19

20 3. Conclusion Cet état de l art met en exergue la difficulté de mettre en œuvre une politique de sécurité sur les composants réseau de manière à ce qu aucune anomalie ne puisse apparaître. Parmi les travaux présentés durant cet état de l art figurent ceux basés sur le modèle Or-BAC, apparaissant comme les plus prometteurs de par les résultats obtenus ou bien les outils d administration. Par dessus tout, son niveau d abstraction lui permet de s appliquer à des composants hétérogènes, parmi lesquels les firewalls, les IDS et les VPN. Concernant les perspectives et les objectifs du stage, elles seront liées à cette approche descendante : l expression d une politique de sécurité réseau basée sur Or-BAC, intégrant les exigences de filtrage sur les entités, des paquets IP, d analyse du contenu et de protection des communications. La politique de sécurité sera décomposée pour produire les configurations de différents composants de sécurité, en particulier des firewalls, IDS et VPN. Lors de la phase de déploiement, la topologie du réseau sera prise en compte. Avec cette stratégie de mise en place de la politique de sécurité réseau, le risque potentiel d anomalie de composants de sécurité devrait être diminué, voire éliminé. Détection d anomalies dans les configurations de composants de sécurité réseau 20

21 Bibliographie [1] Ehab S. Al-Shaer, Hazem H. Hamed, "Discovery of Policy Anomalies in Distributed Firewalls", IEEE INFOCOM 04, [2] Y. Bartal, A. Mayer, K. Nissim, A. Wool, "FIRMATO : A Novel Firewall Management Toolkit", In 20th IEEE Symposium on Security and Privacy, pages 17 31, Oakland, California, May [3] Cataldo Basile, Antonio Lioy, "Towards an Algebraic Approach to Solve Policy Conflicts". [4] M. Bishop, "Compter Security, Art and Science". [5] V. Chatzigiannakis, G. Androulidakis, M. Grammatikou, B. Maglaris, "A Distributed Intrusion Detection Prototype using Security Agents", Network Management & Optimal Design Lab (NETMODE), ECE Department National Technical University of Athens (NTUA). [6] Frédéric Cuppens, Nora Cuppens-Boulahia, Thierry Sans, Alexandre Miège. "A formal approach to specify and deploy a network security policy", Second Workshop on Formal Aspects in Security and Trust (FAST). Toulouse, France. August, [7] Frédéric Cuppens, Nora Cuppens-Boulahia, Joaquin Garcia-Alfaro, "Detection and removal of firewall misconfiguration", 2005 IASTED International Conference on Communication, Network and Information Security (CNIS 2005). Phoenix, AZ, USA, Novembre, [8] Frédéric Cuppens, Nora Cuppens-Boulahia, Alexandre Miège, "Héritage de privilèges dans le modèle Or-BAC : application dans un environnement réseau", Symposium sur la Securite des Technologies de l Information, [9] Zhi Fu, S. Felix Wu, He Huang, Kung Loh, Fengmin Gong, Ilia Baldine, and Chong Xu, "IPSec/VPN Security Policy: Correctness, Conflict Detection, and Resolution", Springer-Verlag Berlin Heidelberg [10] Xin Guo, Kun Yang, Alex Galis, Xiaochun Cheng, Bo Yang, Dayou Liu, "A Policybased Network Management System for IP VPN", Communication Technology Proceedings, ICCT International Conference. [11] Sylvain Hallé, Rudy Deca, Omar Cherkaoui, Roger Villemaire "Automated Validation of Service Configuration on Network Devices", Department of Computer Science, Université du Québec à Montréal. Détection d anomalies dans les configurations de composants de sécurité réseau 21

22 [12] Romain Laborde, "Un cadre formel pour le raffinement de l information de gestion de sécurité réseau : Expression et Analyse", thèse pour obtenir le grade de DOCTEUR DE L UNIVERSITÉ TOULOUSE III, le 26 Septembre [13] B. Laing, J. Andreson, "How to guide-implementing a Network Based Intrusion Detection System", Internet Security Systems (ISS), [14] T.K. Lee, S. Yusuf, W. Luk, M. Sloman, E. Lupu, N. Dulay, "Development Framework for Firewall Processors", Field-Programmable Technology, (FPT). Proceedings IEEE International Conference. [15] Man Li, Nokia Research Center, "Policy-Based IPsec Management", IEEE Communications Society, nov [16] Alexandre Miège, "Définition d un environnement formel d expression de politiques de sécurité. Modèle Or-BAC et extensions", M emoire de Thèse en vue de l obtention du grade de Docteur de l ENST, le 27 juin [17] John Wack, Ken Cutler, Jamie Pole, "Guidelines on Firewalls and Firewall Policy", NIST Special Publication. [18] Intrusion Detection Working Group, draft-ietf-idwg-idmef-xml-10.txt. [19] D. F. Ferraiolo and R. Kuhn, "Role-Based Access Controls", In Z. Ruthberg and W. Polk, editors, Proceedings of the 15th NIST-NSA National Computer Security Conference, pages , Baltimore, MD, October [20] H. Debar, M. Becker, D.Siboni, "A neural network component for an intrusion detection System", Proc IEEE Computer Society Symp. On Research in Security and Privacy Oakland, CA, May 1992, pp [21] JUNOS "VPNs Configuration Guide", Release 7.4 [22] A. Mounji, B. L. Charlier, D. Zampunieris, "Preliminary Report on Distributed ASAX", 27 mai 1994, Institut d Informatique FUNDP [23] Theuns Verwoerd, Ray Hunt, "Intrusion Detection Techniques and Approaches", University of Canterbury, New Zealand, 2002 [24] L Mé, Z Marrakchi, C Michel, H Debar, F Cuppens, "La détection d'intrusions : les outils doivent coopérer" - REE Journal - rennes.supelec.fr [25] [26] Détection d anomalies dans les configurations de composants de sécurité réseau 22