Tester la conformité d'un réseau à une politique de sécurité

30/08/2017
Publication REE REE 2006-6
OAI : oai:www.see.asso.fr:1301:2006-6:19706
DOI : You do not have permission to access embedded form.

Résumé

Tester la conformité d'un réseau à une politique de sécurité

Métriques

12
4
3.07 Mo
 application/pdf
bitcache://edc7989a597b3873de7e8ad36c9596eeab601eb8

Licence

Creative Commons Aucune (Tous droits réservés)
<resource  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                xmlns="http://datacite.org/schema/kernel-4"
                xsi:schemaLocation="http://datacite.org/schema/kernel-4 http://schema.datacite.org/meta/kernel-4/metadata.xsd">
        <identifier identifierType="DOI">10.23723/1301:2006-6/19706</identifier><creators><creator><creatorName>Vianney Darmaillacg</creatorName></creator><creator><creatorName>Jean-Claude Fernandez</creatorName></creator><creator><creatorName>Roland Groz</creatorName></creator><creator><creatorName>Laurent Mounier</creatorName></creator><creator><creatorName>Jean-Luc Richie</creatorName></creator></creators><titles>
            <title>Tester la conformité d'un réseau à une politique de sécurité</title></titles>
        <publisher>SEE</publisher>
        <publicationYear>2017</publicationYear>
        <resourceType resourceTypeGeneral="Text">Text</resourceType><dates>
	    <date dateType="Created">Wed 30 Aug 2017</date>
	    <date dateType="Updated">Wed 30 Aug 2017</date>
            <date dateType="Submitted">Sat 24 Feb 2018</date>
	</dates>
        <alternateIdentifiers>
	    <alternateIdentifier alternateIdentifierType="bitstream">edc7989a597b3873de7e8ad36c9596eeab601eb8</alternateIdentifier>
	</alternateIdentifiers>
        <formats>
	    <format>application/pdf</format>
	</formats>
	<version>33478</version>
        <descriptions>
            <description descriptionType="Abstract"></description>
        </descriptions>
    </resource>
.

Dossier RISQUES ET SÉCURITÉDES RÉSEAUX ET DES SYSTÈMES A COMPOSANTES LOGICIELLES(iele partie) Tester la conformité 1% iutu d'un réseau à une politique ILpr m 10, de sécurité r Validation, Test, Politiquesdesécurité, Réseaux Vianney DARMAILLACG', Jean-Claude FERNANDEZ1,Ro ! and GROZ \Laurent MOUNIER 1,Jean-Luc RICHIER Laboratoire LSR-IMAG', Laboratoire Véri'mag 1 Cet article présente les problèmes liés à l'automatisation du test de la sécurité dans un réseau, en prenant comme exemple le système de courrier électronique d'un réseau de typeTCP/IP 1. Objectifs et contexte Les administrateursderéseauxet de systèmesinforma- tiques sont chargésde mettre en oeuvreet de faire respecter despolitiques de sécurité.Cettemise en oeuvrepassepar le déploiement de solutions standardet par la configuration de systèmesdestinésà assurerla sécuritépar descontrôles à différents niveaux. Du fait de l'évolution quotidienne des systèmes, il n'est pas aisé de garantir la cohérence des mises àjour effectuées.Le testconstitue la principale façon de vérifier qu'une mise en oeuvrereste cohérente avec la politique de sécurité. Les administrateurs disposent de nombreux outils pour testerindividuellement les différents dispositifs matériels et logiciels qui constituent le réseau. Cependant l'utilisation effective des outils de test réseau requiert un haut degré d'expertise, qui ne peut être acquis qu'avec le temps. L'exploitation croisée des résultats de plusieurs outils estencoreplus complexe. Elle estpourtant indispensable pour assurer qu'aucune incohérence entre deux dispositifs, sûrs individuellement, ne conduise à un dysfonctionnement du réseau. Dans le domaine réseau, le test de conformité d'une implémentation vis-à-vis d'un protocole de communica- tion a fait l'objet de nombreusesétudesdepuis la mise en place desinterconnexions de machines au sein d'architec- tures ouvertes, en particulier dans le cadredesarchitectu- res de type OSI et Internet. Il a donné lieu à l'élaboration denormes [Il, 14] dédiéesau test de conformité despro- tocoles. Les méthodes de génération automatique basées sur les méthodesformelles ont été largement étudiéesque ce soit dans le cadre de la théorie des automates [12] ou dans celui des systèmesde transition [5]. Le test du respect d'une politique de sécurité est un test de conformité d'une mise en oeuvre (déployée sur l'ensemble des machines en réseau) à une spécification de la sécurité. Il s'agit d'un test fonctionnel a posteriori aprèsdéploiement d'un ensemble d'éléments logiciels et matériels. Il est donc possible, et souhaitable, d'utiliser le cadredéfini par le test de protocole pour étudier le test de sécurité. Le test de conformité s'appuie sur des notions essen- tielles pour une démarche formelle qui permette de déve- lopper des outils d'analyse automatique des logiciels déployés pour la sécurité, qui pourraient être utilisés pour tester la conformité à une politique de sécurité : . Une modélisation formelle de la politique desécurité. i SYNOPSIS Cet articlediscutedifférentsproblèmesà résoudreà proposdu test de conformitéd'un réseauà une politiquede sécurité. Desélémentsde réponsesontapportésà traversuneétudede caset laprésentationdesoutilsutilisésà lafois parlesadminis- trateurset lespirates,ainsiquedesmodèlesutilisésclassique- mentpourmodéliserdespropriétésdesécurité. Thispaperdiscussesproblemsthatarisewhena networkhasto betestedforconformanceto a statedsecuritypolicy.Weinvesti- gateafewissuesthroughasimplecasestudyandpresenttypical solutionsusedinsecurityengineering. REE No 6/7 Juin/juillet 2006 ossierN BJtt B t f* jf)M t« t' t Z RISQUES ET SÉCURITÉDES RÉSEAUX ET DES SYSTÈMES A COMPOSANTE LOGICIELLE(iele partie) . Une définition de l'architecture du test, en référence à l'architecture du système,qui exprime les capacités d'interaction (observation et contrôle) entre le sys- tème de test et le systèmeà tester. . Une formalisation de la relation de conformité (par- fois appelée relation d'implantation) entre le sys- tème à tester et la spécification qu'il doit respecter. Dans cet article, nous proposons quelques clés d'ana- lyse de cesnotions. Notre objectif principal est de forma- liser la notion de conformité vis-à-vis d'une politique de sécurité. Nous partons d'un exemple et montrons com- ment les exigences de sécurité et les mécanismes mis en oeuvrepour les satisfaire amènent à revisiter le problème du test de conformité. Notons d'abord quel'interdépendanceentreles réseaux et les systèmesd'exploitation desmachinesconduit à asso- cier les deux à la fois dansla gestion de la sécurité et dans la définition despolitiques. C'est pourquoi nous nous inté- resserons à des modélisations qui intègrent à la fois les mécanismesde protection (au niveau applicatif) des systè- mes d'exploitation et ceux associés aux protocoles des réseaux,égalementau niveau descoucheshautes.Un cer- tain nombre de formalismes ont été proposéspour décrire les politiques à ceniveau ; nousavonsenparticulier consi- déréponder [7],PDL [3] etOrBAC [1]. Destravaux plus spécifiques sur la modélisation et le déploiement ou le test de pare-feux ont aussiétéproposés. Le travail présentéici s'inscrit dans le cadre de plu- sieurs projets auxquelsnousparticipons : le projet Potestat et PACI Sécuritéet le projet IMAG Modeste. Dans cet article, nous présentons d'abord les appro- ches utilisées pour la sécurité des réseaux informatiques. Nous présentons ensuite une étude de cas qui guidera notre discussion ; nous en avons extrait quelques règles de sécurité significatives. En partie 3, nous analysons comment ces règles pourraient être testées,et les problè- mes que soulève la définition des tests.Nous en tirerons enfin quelques conclusions. 2. Outils et modèles pour la sécurité des réseaux Pour assurer la sécurité des systèmeset des réseaux, il faut d'abord définir ce qui doit êtreprotégé(le "QUOI "), quelles informations et quels services sont concernés, et quels sont les utilisateurs ou entités utilisatrices concernés ainsi que leurs droits et devoirs. Ces éléments sont décrits par des politiques de sécurité. Il faut aussi disposer de moyens (le "COMMENT ") pour assurercetteprotection et contrôler leséchangesdansle système:pour cela,les admi- nistrateurs disposent d'une multitude d'outils de contrôle, mis en oeuvredansleur activité quotidienne. Nous passonsici rapidement en revue différents outils de contrôle, ainsi que desformalismes existants proposés pour décrire les politiques de sécurité. Les outils utilisés permettent de traiter des situations recensées,les modèles permettent quant à eux de modéliser les règles de sécurité et d'en vérifier la cohérence. Nous indiquons ensuite comment on peut espérerpar- tir de la description d'une politique pour construire la sécurité en dérivant des contrôleurs ou la configuration d'outils de contrôle. Nous introduisons ensuite notre approche qui consiste à confronter l'état de protection d'un réseauà la politique qu'il est censéappliquer. 2.1. Outils de contrôle de sécurité réseau Les administrateurs disposent de nombreux outils pour contrôler les différents aspects de la sécurité des réseaux dont ils ont la charge. La plupart de ces outils contrôlent un point particulier, soit sur une machine par- ticulière, soit sur l'ensemble des machines d'un site. Nous allons évoquer ici les grandes classesd'outils ordi- nairement utilisés par les administrateurs réseau. Un pare-feu est un dispositif matériel ou logiciel, ins- tallé sur un équipement dédié, un routeur ou une machine, qui permet de filtrer les communications selon desrègles de bas niveau (routeurs, Netfilter). Les antivirus sont utilisés pour contrôler qu'un fichier n'est pas infecté par un virus ou que le comportement d'un processus n'est pas celui d'un processus infecté (KasperskyAnti- Virus, Norton AntiVirus). Lesfiltres antispam sont des dispositifs logiciels utili- séspour analyserles courriers électroniques et déterminer si ce sont desspams(Spamassassin). Les contrôleurs d'intégrité sont utilisés pour détecter les modifications non autorisées des fichiers importants d'un systèmed'exploitation (Tripwire). Les casseursde mots depasse sont utilisés pour véri- fier que les utilisateurs n'ont pas choisi de mots de passe trop faciles à découvrir par un attaquant (John the Ripper, LC4, Pwdump3, airsnort). Les injecteurs de paquets sont des logiciels permet- tant d'injecter sur le réseaudes fragments de communica- tion et de tester le comportement de certaines machines (Hping2, Nemesis). Les sniffers permettent d'écouter le trafic sur un lien physique (Ethereal, Ettercap, Eismet, Network Stumbler, Snort, tcpdump, WinDump). REE No 6/7 Juii)/juillet 2006 Tester a conformité d'un réseau à une politique de sécurité Les scanneurs de portssont utilisés pour savoir si des ports TCP et UDP sontouvertssur unemachine alors qu'ils ne devraient pasl'être. Desversionsplus évoluéespermet- tent égalementde déterminer les logiciels utilisés et le sys- tème d'exploitation (Ninap, SuperScan,XProbe 2). Les scanneurs de vulnérabilités sont utilisés locale- ment ou sur une machine distante pour déterminer les vulnérabilités qui peuvent exister sur cette machine (ISS Internet Scanner, GFILanGuard, Nessus, Nikto, N- Stealth, Retina, Saint, Sara, Whisker). Un IDS (Intrusion Detection System) est un logiciel qui écoutele trafic d'une machine ou d'un réseauet l'ana- lyse pour essayerde découvrir des indices d'une possible intrusion (Snort). Enfin, de nombreux outils d'administration peuvent être utilisés pour observer (traceroute, ping, whois, fport, netstat) ou contrôler desmachines (Netcat). 2.2. Définitionet expressiondes politiques de sécurité La plupart du temps, les politiques de sécurité sont exprimées de manière informelle, sous la forme d'un ensemble de documents rédigés en langue naturelle. On peut considérer les politiques de sécurité comme une spé- cification des besoins d'un système, assez semblable au cahier des chargesd'un logiciel. Plusieurs formalismes ont été proposés pour la modé- lisation de la sécurité de systèmesd'information, comme par exemple PDL, Ponder ou Or-Bac. PDL [3] est un langagecréé pour modéliser des poli- tiques de gestion de réseau,dont des politiques de sécu- rité. Il est basésur l'idée qu'une politique est une spécifi- cation du comportement que le réseaudoit avoir en réac- tion à certains événements. Ponder [7] est un langage créé pour spécifier des politiques de sécurité réseau.Une politique est un ensem- ble de règles organiséespar modalités (obligation condi- tionnelle, autorisation, interdiction, délégation et rete- nue). [10] présente un modèle d'administration d'une politique Ponder qui est utilisé dans une suite d'outils. Or-BAC [1] est un modèle de contrôle d'accès qui étend les concepts de RBAC. La politique de sécurité des hôpitaux de Toulouse a été modélisée en Or-Bac. Plus récemment, Or-BAC a étéutilisé pour modéliser despoli- tiques de sécurité réseaux, et pour générer des règles de pare-feux [6]. 2.3. Approchesconstructives Les approches constructives fournissent une aide au déploiement d'une politique de sécurité dans un réseau, et établissent un lien entre les outils pratiques de contrôle de la sécurité et les modèles formels d'expres- sion de la politique de sécurité. La plupart des travaux existants visent à générer automatiquement les tables de filtrage des pare-feux d'un réseau à partir d'une politi- que de sécurité formelle. Par exemple, [13] utilise un cliquodrome, [2] utilise un modèle entités-relations et [6] utilise Or-BAC. Ces travaux utilisent le fait que différents niveaux de description des politiques de sécurité existent dans les réseaux. Chacun de ces articles propose de passer d'un niveau d'abstraction élevé au niveau de détail des confi- gurations des tables de filtrage. Dans la communauté sécurité, on note un intérêt sur la question des relations qui lient les modèles de niveaux d'abstraction différents, en termes de relation d'équivalence ou de préordre. Par exemple [9] propose une méthode pour dériver par raffi- nementssuccessifsun moniteur à partir d'une description formelle d'une politique de sécurité. Le rôle de ce moni- teur est de surveiller la conformité du comportement du réseauà la politique de sécurité. 2.4. Discussion Des outils et des modèles existent pour traiter de la sécurité dans les réseaux. Ces approchesconstructives ne sont guère utilisées actuellement, en particulier pour le déploiement àpartir d'une description formelle de la poli- tique. S'il est déjà difficile de définir une configuration pour chacun des éléments disparates d'un réseau lors de son déploiement, la tâche devient ingérable quand il faut conserver la cohérence entre ces éléments après qu'une partie d'entre eux ont été mis àjour. Or certains éléments nécessitent d'être mis à jour à une fréquence élevée en terme d'administration (quasi-quotidienne pour les anti- virus ou les systèmesd'exploitation). Les administrateurs préfèrent utiliser, dans la phase constructive, dessolutions classiquescomme desfichiers de configuration types et des guides de bonnes pratiques. Pour la détection desanomalies, ils s'en remettent ensuite aux utilisateurs pour leur signaler les dysfonctionnements du réseau,et aux outils de surveillance ; les outils présen- tés dans la section précédente permettent en outre de rechercher l'origine des dysfonctionnements. Il n'existe actuellement pas de méthodologie permet- tant de reproduire ces procédés de manière automatique et de chercher des incohérences. Nous nous intéressons ici à dériver des tests qui, exécutéssur un réseau,contrô- leront si globalement le réseauest conforme à un ensem- ble de politiques de sécurité. Dans le paragraphesuivant, nous allons fournir quelques éléments de réponse à ce problème. REE W6/7 Jtiin/juiliet 2006 Dossier RISQUES ET SÉCURITÉ DES RÉSEAUX ET DES SYSTÈMES A COMPOSANTE LOGICIELLE (iefe partie) 3. Problèmes soulevés par le test de règles de sécurité Nous énumérons ici certains des problèmes spécifi- ques posés par la génération et la mise en oeuvre de poli- tiques de sécurité décrites par des règles telles que celles définies dans la section 3.1. Pour cela nous décrirons tout d'abord un formalisme permettant d'exprimer ces règles de manière plus précise, nous donnerons ensuite un exemple de test pour une règle précise, et nous discute- rons un certain nombre de problèmes relatifs à la généra- tion ou à l'exécution de ce type de tests. 3.1. L'étude de cas Nous illustrerons la discussion des problèmes posés par l'application du test de conformité aux politiques de sécurité par des exemples tirés d'une étude de cas, réali- sée à l'été 2004 pour recenser les politiques de sécurité appliquées dans le réseau IMAG, qui connecte nos labo- ratoires [4]. Cette étude comprenait l'analyse de docu- ments fournis aux administrateurs et aux utilisateurs du réseau, et des entretiens. Nous avons collecté des infor- mations à différents niveaux d'administration, du labora- toire au fournisseur d'accès national. L'analyse a permis d'obtenir une description assez large et détaillée d'une politique de sécurité réseau assez typique d'un environne- ment universitaire. Pour étudier les problèmes posés par le test de ces poli- tiques, nous avons extrait de cette étude un sous ensemble de règles sur la messagerie. Le jeu de règles a été choisi assez riche pour montrer la plupart des notions à étudier : plusieurs niveaux de politiques et d'organisations intercon- nectées, variété des services et des méthodes d'accès. Description informelle de l'exemple étudié Dans un réseau, on distingue en général l'intérieur et l'extérieur. L'intérieur du réseau est un ensemble de machines sous la responsabilité d'une organisation. L'extérieur est un ensemble de machines non contrôlées, et considérées, pour la sécurité, comme non fiables. On raffine souvent en considérant d'autres zones, qui diffè- rent par le degré d'administration, de fiabilité et de confiance. Les sous-zones de la zone interne correspon- dent en général à des critères architecturaux, par exemple des séparations entre sous-réseaux physiques, alors que les sous-zones de la zone externe correspondent à des niveaux différents de confiance. Les politiques de sécu- rité sont exprimées sur ces zones. On distingue de plus parmi les machines internes cel- les qui fournissent des services et qui sont accessibles de l'extérieur. Ces machines sont plus visibles et sont sou- vent objet d'attaques. C'est pourquoi l'état de l'art en administration de réseau conseille de définir une zone tampon fortement contrôlée pour ces machines. Seules les machines dans cette zone (souvent appelée DMZ ou zone démilitarisée) peuvent communiquer avec l'extérieur, et tout le trafic entre la DMZ et le reste du réseau interne est contrôlé. La figure 1estune simplification du réseauIMAG qui indi- que les flux de trafic autorisés liés au courrier électronique. HTTI'/S '\.,ITP" s,nI'entrant'\ll'i',. ",, -% IT P/S t [t 11) I\L\P/S -0 ,A SMTP ,'FNIP liiiicitS('i1' : u-amleri=a:l STMP: bil 11 1'l l'\ \i! i"!Pacccs\\\\V .S : \it,ii,é, llt*],, '1'ITP rats rdaïs\7xJt cl,»noine7 serveur cblnb SMTP s\-n'p StfH.'ur listes (UtTus !MAP/S y (ic ,IILIX SL'n'cur d\'n ! ! ! c \1,-\Il Nli 1 p t Tt, l ( Figure 1. Flux de courrier valides dans le réseau. REE No 6/7 Juin/juillet 2006 ? Règle 1 Les relais de messagerie ouverts sur l'extérieur doivent être placés dans la DMZ ; on les appellera par la suite " relais principaux ". 2 Il n'y aura pas de compte utilisateur sur les relais principaux. 3 Les serveurs de boîtes aux lettres qui contiennent les comptes des utilisateurs sont dans la zone protégée. 4 Les relais principaux sont les seules machines habilitées au dialogue SMTP avecle monde extérieur : le relais du courrier entrant vers les serveurs de boîtes aux lettres et du courrier sortant vers l'extérieur s'effectue par les relais principaux. 5 Les serveurs de boîte aux lettres peuvent être utilisés comme relais internes de messagerie. 6 En entrée de site la politique de filtrage par défaut est que tout ce qui n'est pas explicitement autorisé est interdit. 7 Tous les messages de l'extérieur arrivant sur une machine qui n'est pas un relais principal doivent être redirigés sur un relais principal. 8 Il est interdit de relayer des courriers de l'extérieur vers l'extérieur. 9 [blacklisting] Refus de communiquer avec les relais appartenant à une liste donnée (quoti- diennement mise à jour). 10 Des logiciels antivirus et antispams sont installés au niveau des relais de messagerie ou au niveau des boîtes aux lettres. Il est possible de mettre en place une protection au niveau des postes clients. 11 Toute pièce jointe à un courrier électronique doit être contrôlée par un logiciel antivirus au moins une fois avant d'être ouverte. 12 Tout courrier électronique doit être modifié s'il contient un virus. Le virus est supprimé du courrier et le destinataire en est prévenu. Figure 2. Politique pour la messagerie électronique. Règles de sécurité pour l'exemple étudié Nous donnons dans la figure 2 un ensemble de règles pour le courrier électronique tiré de notre étude de cas. Cet ensemble ne cherche pas à être exhaustif, il a été choisi pour illustrer les différents aspects d'une politique de sécurité dans un réseau : flux d'informations, sépara- tion en zones, possibilité, obligation ou interdiction de certaines actions, différents niveaux de détails. Pour sim- plifier le problème, nous supposons que certaines contraintes " globales " sont vraies et n'ont pas à être explicitées : routage correct, systèmes à jour... 3.2. Formaliser la politique de sécurité Nous avons vu dans la section 2.2 différents forma- lismes pour la modélisation de politiques de sécurité. Ces formalismes n'ont pas été conçus pour générer auto- matiquement des tests à partir de l'expression des règles. PDL n'est pas parfait pour le test de conformité car, par exemple, on ne peut spécifier qu'une action ne peut/doit pas être faite (règle 8), et la plupart des contraintes stati- ques sont impossibles à spécifier, par exemple la règle 1 de l'étude de cas. Les problèmes rencontrés avec Ponder sont la totale impossibilité d'exprimer clairement des contraintes statiques, le fait qu'on ne puisse spécifier que des comportements comprenant un sujet et une cible identifiés, et la difficulté de représenter des comporte- ments complexes. Or-BAC permet d'exprimer aisément des contraintes statiques en logique du premier ordre. Son orientation vers le contrôle d'accès ne permet que diffici- REE. W 6/7 Juin/juillet2006 M 37 Dossier RISQUES ET SÉCURITÉ DES RÉSEAUX ET DES SYSTÈMES À COMPOSANTE LOGICIELLE (ieepartie) lement d'exprimer des comportements complexes. Nous adoptons une démarche permettant de générer dans certains cas automatiquement des tests. La généra- tion automatique de tests à partir d'une politique de sécu- rité nécessite tout d'abord de disposer d'une description de ces règles, exprimées dans un formalisme dont la sémantique est définie de manière rigoureuse et non ambiguë. Nous donnons ici brièvement un exemple de formalisme très simple mais suffisant pour décrire les règles utilisées dans cet exemple. Ce formalisme est basé sur une logique temporelle permettant d'exprimer des formules combinant des pro- positions évaluées soit sur l'état courant du réseau, soit sur ses états futurs. Plus précisément, la syntaxe de ces formules est constituée des éléments suivants : . des prédicats élémentaires, qui portent sur l'état courant du réseau (les configurations des machines, le contenu des messages reçus par chaque machine, etc.) ; . des événements, qui correspondent aux actions exécu- tées sur le réseau (arrivée d'un message, changement de configuration d'une machine, etc.), et qui peuvent être conditionnés par des prédicats (arrivée d'un mes- sage infecté sur une machine interne du réseau) ; dans le cas où un événement e est conditionné par un prédicat C, on utilisera la notation e[C] ; . les connecteurs logiques usuels ; . un opérateur 0 0, permettant d'exprimer que la sous- formule if doit être vraie dans un futur borné (avant expiration d'un certain délai, fixé au moment de l'exécution du test). 3.3. Exemple d'un test pour une règle Considérons la règle 13 qui dit que " Tout courrier élec- tronique doit être modifié s'il contient un virus. Le virus est supprimé du courrier et le destinataire en est prévenu ". En termes logiques, cette règle exprime une obliga- tion. Elle s'exprime dans notre formalisme de la manière suivante : Vin, h,, h, entréeréseati (iii, h,) [infecté (m)]) => 0 transfert (hl, h', m) [intérieur (h,) A m'- désinfecté (m)] Dans cette formule : . entréeRéseau (m,h,) est un événement qui indique l'arrivée du message m sur l'un des relais principaux h, du réseau ; a infecté (m) est un prédicat qui indique que le mes- sage m est infecté par un virus ; transfert (h,,h,,m) est un événement qui indique que le message m est transféré de la machine h, à une machine h, ; . intérieur (h,) est un prédicat qui indique que la machine ho est une machine située dans la zone interne du réseau ; . désinfecté (m) est une fonction qui retourne le mes- sage m', obtenu à partir de m dans lequel les éven- tuels virus ont été supprimés. Informellement, pour tester cette règle on peut utiliser la séquence d'interactions suivantes : 1. On transfère un message m infecté par un virus sur une machine h, qui est un relais principal du réseau. Le destinataire de ce message est une machine interne au réseau. Si cet envoi ne se déroule pas correctement le test n'est pas concluant, sinon le test se poursuit. 2. Si, avant l'expiration d'un certain délai, on observe un transfert correct du message m de h, à h,, alors . si m n'est plus infecté, le test réussit (verdict pass) ; . si m est encore infecté, alors le test échoue (ver- dictfail, la règle 13 n'est pas respectée). Si le délai expire avant qu'un transfert correct ait eu lieu alors le test échoue (verdict ?, la règle 13 n'est pas respectée). Notons que nous avons ici choisi un test actif, dans lequel on envoie explicitement un message infecté, plutôt qu'un test plus passif qui aurait consisté à " attendre " qu'un message infecté entre sur le réseau. La séquence de test proposée est montrée figure 3. lzabekI,ehwiour ''.Y ;f;Rf; !.. (.. ,) Ok r " r, s'T:vrtT rrJra,n i.) p'r-rrrr ;.xJri,l . lr=. rrrl rfrrtfrrrt oh Gt)'TC) ior i ; i, S'TriT I.Op ?'.- "r (/! i./.'j.f) ?/' ; !" f, S'TAnT tirncoul 101' : 1/'11" s/, li,I, :'1'2, III) '(fuiltulfl .' " l, GOTO top . j, tol) (:OI'1ST1'i'AlYlt;i '.l-t',1'(ÎI(:con.sn'am verdc r (///t ijx'orH' ,/-> l'ail pas Figure 3. Cas de test en pseudo TTCNpour la règle 13. REE No 6/7 Juiii/jtiillet 2006 3.4. Problèmes soulevés Bien qu'assez intuitives en apparence la définition et l'exécution de ce test soulèvent un certain nombre de questions. Nous en citons ici quelques unes : . La règle testée est une règle qui exprime une obliga- tion. Nous avons exprimé ici cette obligation par le fait que le message devait nécessairement être transféré sans virus à son destinataire avant l'expiration d'un certain délai, c'est-à-dire que nous avons transformé une modalité déontique en une modalité temporelle. . Les événements qui apparaissent dans ce test sont exprimés à un certain niveau d'abstraction. Ces évé- nements ne se situent pas forcément à une interface avec le testeur ou ne correspondent pas à des actions de communication. Exprimé à ce niveau d'abstrac- tion un tel test n'est donc pas exécutable. Il faut donc encore préciser comment implémenter au niveau du testeur un événement comme une demande de transfert de message (envoi d'une séquence de PDU particuliers), ou une réponse négative à une telle demande (temporisation, code d'erreurs, etc.). . De plus, les interactions mises en oeuvre lors du test se situent à différents niveaux de l'architecture, comme effectuer une demande de connexion sur une machine ?, ou tester si une demande de transfert entre une machine h'et h " a correctement eu lieu, ou encore si un message est infecté. . Enfin, une dernière question concerne la génération du test. Les techniques de génération automatiques proposées dans le cas du test de conformité reposent généralement sur une spécification précise du com- portement attendu du système ou protocole sous test. Ici, l'objet du test est l'ensemble du réseau, pour lequel il est difficilement envisageable de dis- poser d'une telle spécification. Tous ces problèmes font que les techniques utilisées en test de conformité doivent être étendues pour traiter des politiques de sécurité. Nous détaillons certains de ces problèmes dans la suite, en donnant quelques pistes envi- sageables pour les résoudre. 3.5. Architecture de test, contrôle, interfaces Dans le test de conformité de type boîte noire, on dis- tingue généralement les actions contrôlables, émises par le testeur, des actions observables, observées par le tes- teur. Dans le cadre du test de conformité, l'implantation est accessible via une interface homogène, c'est-à-dire que la communication entre le testeur et le protocole testé se situe à des niveaux bien définis de la couche réseau (la couche supérieure ou inférieure du protocole). A l'in- verse, dans le cadre du test de politique de sécurité, les actions de contrôle et d'observation effectuées par le tes- teur peuvent se placer à des niveaux d'abstraction très dif- férents. En effet, une politique de sécurité est définie glo- balement sur l'ensemble du réseau et concerne donc plu- sieurs niveaux de l'architecture du réseau. Ainsi, les pré- dicats " un message est infecté ", " une machine est interne " ou l'événement " transférer un message " sont exprimés au niveau de l'implantation par des séquences ou des arbres d'actions et d'événements de plus bas niveau. Par exemple, " transférer un message m de la machine h vers la machine h " peut requérir les actions suivantes : une demande de connexion de h vers h', sui- vie d'une demande de transfert de m de h à h'. Chacune de ces actions entraîne une réponse de h'indiquant si l'ac- tion correspondante a été ou non correctement effectuée (acquittement, code d'erreur, etc.). Cette hétérogénéité se retrouve dans le test. Par exem- ple, tester l'installation de logiciels antivirus (règle 10) ne se situe par au même niveau que vérifier qu'une machine se comporte comme un relais (règle 5). De même, le tes- teur, qui est inséré comme une machine dans le réseau, a un rôle particulier ; il contrôle les émissions vers d'autres machines, et observe non seulement les messages qui lui sont destinés mais aussi le trafic existant entre deux autres machines. Ces observations externes peuvent être effectuées soit par des " sondes " placées sur le réseau, soit par exemple par la lecture de "journaux de bord " ou de fichiers de configuration. 3.6. Modèle d'exécution Dans le cadre du test de conformité, on distingue généra- lement deux modes d'exécution des tests : . Le test actif, dans lequel le testeur stimule (contrôle) l'implantation et observe ses réactions. En fonction de celles-ci, il décide du prochain stimulus à émettre. Le test passif, dans lequel les stimuli ne sont pas contrôlés par le testeur. Cette séquence est alors appli- quée à l'implantation, et une séquence d'observations est obtenue en retour. L'analyse de cette séquence per- met au testeur d'émettre un verdict soit à l'issue du test, soit pendant le test si une faute se produit. Dans le cadre du test de la politique de sécurité ces deux modes restent envisageables. 3.7. Structure des tests Dans un test actif, l'exécution d'un test consiste en une suite d'interactions entre le testeur et l'implantation, REE No 6/7 Juin/juillet2006 Dossier RISQUES ET SÉCURITÉ DES RÉSEAUX ET DES SYSTÈMES À COMPOSANTE LOGICIELLE (lê" partie) des actions de contrôle et des observations. Dans le cas du test de conformité, après chaque obser- vation le testeur peut choisir la prochaine action à exécu- ter, ou le verdict à émettre. Le cas de test peut donc être représenté par une structure arborescente. Dans le cas du test de politique de sécurité, certains événements observables (interaction entre deux machines distantes, variables d'environnement mises à jour par le système d'exploitation, etc.) ne peuvent pas toujours être connus du testeur pendant l'exécution du test. Ces événe- ments, stockés au fur et à mesure dans un journal de bord, ne sont alors disponibles qu'a posteriori. Le contrôle effectué par le testeur n'est donc que par- tiel et un certain nombre de décisions doivent être prises arbitrairement, sans connaître complètement l'état du système sous test. De même, le verdict de test ne pourra être émis qu'après analyse de la séquence d'exécution, en fonction de l'état atteint dans l'arbre de test. 3.8. Modalités Les formalismes classiquement utilisés pour décrire des politiques de sécurité (Ponder, OrBAC, PDL, etc.) reposent sur un certain nombre de modalités. Celles-ci doivent être prises en compte pour appliquer différents schémas de test. Par exemple : La possibilité : " un serveur de boîtes aux lettres peut être utilisé comme relais interne... " (règle 5). En fonction du contexte cette modalité peut être inter- prétée de deux manières différentes : . soit, il s'agit d'un degré de liberté laissé par la spécifi- cation (la possibilité d'implémenter ou non une certaine fonctionnalité, de réagir ou non à certains événements) ; w soit, il s'agit au contraire d'une propriété qui doit être bien offerte par l'implémentation, le verbe " peut " étant alors interprété comme " doit pouvoir être ". Dans le deuxième cas tester cette modalité consiste alors à exhiber une séquence d'exécution qui réalise le comportement attendu (sur l'exemple il s'agit de sol- liciter un serveur de boîtes aux lettres pour le mettre en situation de relayer un message interne). Ce type de test peut nécessiter de modifier la configuration du réseau, par exemple en introduisant de nouvelles machines (testeur). L'obligation : " toute pièce jointe à un courrier électronique doit être contrôlée par un logiciel antivirus... " (règle 12). Tester cette modalité consiste à exhiber une séquence d'exécution qui met en défaut la propriété attendue. Pour la règle 12 il pourrait s'agir par exemple d'iden- tifier un ensemble de scénarios " critiques " sur une spécification du service de messagerie. Notons que cette modalité peut être conditionnée par l'arrivée d'un événement, ou la validité d'un prédicat qu'il fau- dra alors prendre en compte dans le test. L'interdiction : " il est interdit de relayer des courriers de l'extérieur vers l'extérieur " (règle 8). Tester cette modalité consiste à essayer d'exécuter une séquence " interdite " et vérifier qu'elle est bien rejetée par l'implantation. En pratique il est souvent nécessaire de raffiner le scénario abstrait décrit par la propriété en y intégrant des actions fonctionnelles. 3.9. La génération des tests Un enjeu important en pratique réside dans la possibi- lité d'automatiser au moins partiellement la production des tests. L'une des approches effectives dans le cadre du test de conformité consiste à générer les tests à partir d'une spécification qui fournit un modèle opérationnel du comportement attendu du système sous test. Les tests sont alors obtenus par sélection de séquences d'exécution par- ticulières. Le critère de sélection peut être défini en fonc- tion d'un ensemble de scénarios d'exécutions que l'on sou- haite voir apparaître dans l'exécution du test, ou encore à travers une notion de couverture définie sur ce modèle. Dans le cas du test de politiques de sécurité nous avons vu que la plupart des règles portent sur le compor- tement global du réseau (et non sur un composant ou une couche protocolaire particulière). Par conséquent il est difficilement envisageable de disposer d'un modèle de ce comportement global à un niveau de détail suffisant pour permettre la génération de tests. Nous avons donc proposé récemment une approche dif- férente [8], dans laquelle les tests sont obtenus directement à partir des formules caractérisant les règles de sécurité, et d'un ensemble de " tests élémentaires " (ou tessons élémen- taires) permettant de tester les différents prédicats ou évé- nements qui apparaissent dans ces formules. Ainsi le test complet est obtenu par assemblage de ces différents tessons en utilisant des opérateurs de composition qui expriment la sémantique de la formule considérée (à chaque opérateur logique est ainsi associé un opérateur de composition de tes- sons). En pratique les tessons élémentaires pourront être REE No 6/7 Juiii/juillet 2006 Tester la conformité d'un réseau à une politique de sécurité v Figure 4. Généi-atioli de test poitr la i-ègle 13. fournis par l'administrateurdu réseau, en fonction des moyens dont il dispose pour tester la validité d'un prédicat, ou l'occurrence d'un événement. Nous illustrons cette approche ci-dessous sur la règle 13. La figure 4 décrit la composition de différents tessons asso- ciés respectivement aux événements entréeRéseau (m,h,), transfert (h,,h,,m), et non infecté (in). Enfin, dans le cas d'un test actif, un dernier point concerne le choix des paramètres utilisés pour instancier les cas de test générés (le contenu des messages à transmet- tre, les machines émettrices et destinataires, etc.). En fonc- tion de la règle concernée par le test plusieurs solutions peuvent être envisageables : . L'exécution du cas de test peut parfois être complè- tement indépendante de certains paramètres, ou sen- sible uniquement à certaines classes de valeurs parti- culières (par exemple une adresse valide ou non valide). On parle alors d'hypothèse d'uniformité sur les données du test, et le choix des paramètres consiste à " couvrir " l'ensemble des classes possibles. Les valeurs des paramètres intéressantes pour le test peuvent également être fournies sous la forme d'un profil d'ittilisation, c'est-à-dire des hypothèses sur la manière dont est utilisé le réseau sous test. Dans le cas de test de politiques de sécurité ce profil peut parfois être déduit de scénarios d'attaque connus (pour lesquels il est important de tester l'efficacité de la politique de sécurité). . Enfin, le choix des paramètres peut également se faire en fonction des mises à jour qui ont été effec- tuées sur le réseau depuis la dernière campagne de test (on peut alors parler de test de non régression). Par exemple il peut être intéressant de cibler le test sur les dernières machines installées. 4. Conclusion L'étude présentée ici s'inscrit dans le cadre de trois projets de recherche auxquels nous participons. REE N 6/7 Jiiin/juillet 2006 Dossier RISQUES ET SÉCURITÉ DES RÉSEAUX ET DES SYSTÈMES A COMPOSANTE LOGICIELLE (lece partie) MODESTE (MODElisation pour la SécuriTE : test et raffinement en vue d'un processus de certification) est un projet de l'IMAG (Institut d'Informatique et de Mathématiques Appliquées de Grenoble). Il s'intéresse en particulier à la modélisation de la sécurité dans les phases de conception de logiciels embarqués. On associe des propriétés de sécurité aux méthodes ou procédures d'un code logiciel, qu'on relie aux exigences de sécurité exprimées dans le SPM (Security Policy Model) selon les critères communs de certification. On s'intéresse donc à garantir la cohérence entre les propriétés exprimées dans la politique de sécurité du système et les mécanismes mis en oeuvre. POTESTAT (POlitiques de sécurité : TEST et Analyse par le Test de systèmes en réseau ouvert) est un projet de l'ACI Sécurité du ministère de la recherche, qui rassemble des équipes de l'IMAG et de l'IRISA. Il s'intéresse à divers aspects de l'utilisation de techniques issus du test pour vali- der la sécurité de système. On étudie en particulier : < l'analyse de la non-interférence entre des flots de calcul, < l'application de techniques de diagnostic à la sur- veillance de propriétés de sûreté extraites des politiques, w lagénération de test à partir d'une formalisation des politiques sous forme de règles. POLITESS (projet exploratoire du réseau national de recherche en télécommunications RNRT) étudie com- ment garantir que les politiques de sécurité sont bien appliquées dans des réseaux, des systèmes d'information et leurs interconnexions. Il part d'une modélisation for- melle des politiques de sécurité pour dériver soit des déploiements automatiques des règles sur les équipe- ments, soit des tests ou des procédures de surveillance pour vérifier la conformité d'un déploiement. Des expéri- mentations seront menées sur des applications à base de services Web. Cette première expérience nous permet de penser que le modèle du test de conformité des protocoles peut s'étendre aux politiques de sécurité : nous avons toujours des événements échangés entre composants, des arbres de décision. Nous pouvons donc espérer que les méthodes de génération automatique de test pourront elles aussi être étendues. Toutefois cette expérience montre aussi que le modèle est plus complexe, à la fois en termes de niveau d'abstrac- tion (les événements ne sont plus de simples échanges de " Protocol Data units "), mais aussi en termes de visibilité d'action et d'accessibilité : on ne peut pas toujours espé- rer qu'un élément sous test acceptera certaines comman- des si on n'a pas un contrôle suffisant (par exemple pour envoyer un message acceptable, il faut connaître un nom de boîte aux lettres valide, ce qui peut être interdit). Le test de politiques de sécurité est donc plus difficile à mettre en oeuvre, et il sera sans doute nécessaire de pren- dre en compte de multiples architectures de test. Ce trava ! a été soutenu par le projet Potestat de IACI Sécurité et le projet IMAG Modeste. Références [1 [2] f3l [4] [5] 171 191 A. ABOU EL KALAM R, EL BAIDA. P BALBIANL SBENFERHAT, F CUPPENS, Y DESWARTE, A. MIÈGE, C. SAUREL et G. TROUESSIN. "Organization Based Access Contro ln IEEE4th International Workshop on Policies for Oistributed Systems and Networks, 2003. Y. BARTAL, A. MAYER, K. NISSIM et A. WOOL. "A FIRMATO A Novel Firewall Management Toolkit' ; ln IEEE C { {uter Society Symposium on Security and Privacy, 1999, F BHATIA, J. LOBO et M. KOHLI. " Policy Evaluation for Network Management' 'In INFOCOM 2000, 19th Conference IEEE Computer and Communications Societies, 2000. S. BOUTONNET. " Sécurité des réseaux informatiques de l'IMAG' ; Rapport interne, LSR- ! MAG. septembre 2004. ED BRINKSMA et JAN TRETMANS. "An Annotated Bibliography' : ln Modellmg and Verification of Parallel Processes, volume 2067 of Lecture Notes in Computer Science, pages 187-195. Springer-Veriag, 2001. F CUPPENS, N. CUPPENS-BOULAHIA, T SANS, et A. MIÈGE. 'A Formal Approach to Specify and Deploy a Network Security Policy','n Second Workshop on Formal Aspects in Security and Trust {FAST !. Toulouse, France, August 2004. N. DAMIANOU, N. DULAY, E. LUPU et "The Ponder Policy Specification Language' ; Workshop on Policies for Distributed Networks, 2001. M. SLOMAN. ln International Systems and [81 V DARMA ! LLACQ, J-C. FERNANDEZ, H. GROZ, L. MOUNIER et J-L. RICHIER. " Test Generation for Network Security Rules','In 18th IFIP International Conference, TestCom 2006, New York, May 2006. LNCS 3964, Springer. [91 V. DARMAILLACO et N. STOULS. " Développement for- mel d'un moniteur détectant les violations de politiques de sécurité de réseaux','In AFADL2006 -Approches Formelles dans/ssance au Développement de Logiciels, Paris, mars 2006. [101 N. DULAY, E. LUPU, M, SLOMAN et N. DAMIANOU. "A Policy Deployment Model for the Ponder Language' ; ln IEEE/IFIP International Symposium on Integrated Network Management (IM'2001), pages 529-544, Piscataway, NJ, 2001. IEEE [11] ISO, Information Technology, Open Systems Intercon- nection, Conformance Testing Methodology and Framework. International Standard IS-9646, CCITT X290- X.294, ISO, 1991. [12] D. LEE et M. YANNAKAKIS. " Principles and Methods of Testing Finite State Machines','A Survey, ln Proceedings of the IEEE, 84 (8), pages 1090-1123, 1996. REE No 6/7 Juiii/juillet 2006 Tester la conformité d'un réseau à une politique de sécurité [131 M. CASASSA MONT, A. BALDWIN et C. GOH. POWER. Prototype, "Towards Integrated Policy-Based Mana- gement','Technical report HP Laboratories, 1999. [14] UIT, Cadre général des méthodes formelles appliquées aux testsde conformité. Recommandation UIT-T Z.500, IUT, 1997 Les auteurs Vianney Darmaillacq, après une maîtrise d'Informatiqueà l'UniversitédAngers, a obtenu un DEA Systèmes d'Informationà l'UniversitéJoseph Fourierde Grenoble.Ilest aujourd'huidocto- rantdans l'équipeVasco du laboratoireLSR, sous la supervisionde RolandGroz etJean-LucRichier. Ses recherchesconcernentlasécuritédes réseaux. Jean-Claude Fernandez est professeur des Universitésà l'UniversitéJoseph Fourierde Grenoble,membre du laboratoire Vérimag.Ils'intéresseà lacompilationetà lagénérationautomati- que de testsde logiciel, Roland Groz estingénieurdes Télécommunications, actuellement professeurassociéà l'INPGIENSIMAG etTelecom) etmembre du laboratoireLSR-IMAG. Ses recherchesportentsurletest,appliqué à l'ingénieriedes composants logicielset à la sécuritépour les réseauxet lesservicesde télécommunications. Laurent Mounier estMaîtrede Conférencesà l'UniversitéJoseph Fourieret membre du Iaboratoire Vérimag.Ses activitésde recher- che concernentlaspécificationetlavalidationdes systèmes distri- bués ou embarqués :sémantique des langagesde spécification, techniques et outils de validation (analysestatique,model- checking,générationde séquences de test). Jean-Luc Richierest chargéde rechercheau CNRS, membre du LSR-IMAG à Grenoble.Ses domaines d'intérêtssont lesréseaux Internetet lavalidationparletest. REE W 6/7 Juin/juillet 2006