Approche logique pour l'analyse de traces d'exécutions

Approche logique pour l’analyse de traces

d’exécutions

Mémoire

Rimeh Zribi

Maîtrise en informatique

Maître ès sciences (M.Sc.)

Québec, Canada

© Rimeh Zribi, 2013

R´

esum´

e

Les techniques traditionnelles de d´etection d’intrusions s’appuient sur diff´erentes approches permettant d’identifier une utilisation non pr´evue et non autoris´ee de diff´erentes ressources d’un syst`eme informatique. Afin de d´etecter ces comportements, nous d´ecrivons dans ce m´ e-moire une approche logique de d´etection d’intrusions bas´ee sur l’identification, dans des traces d’ex´ecutions, de violations de politiques de s´ecurit´e donn´ees. Le mod`ele d´evelopp´e sp´ecifie l’´etat des ressources d’un syst`eme ainsi que les effets des diff´erents appels syst`eme sur cet ´

etat. Le syst`eme obtenu, qui s’apparente `a un syst`eme expert, s’appuie sur un ensemble de r`egles logiques d´ecrivant les connaissances d’un expert en s´ecurit´e informatique. Tout com-portement ill´egal, c’est-`a-dire non conforme aux politiques de s´ecurit´e consid´er´ees, est signal´e et est consid´er´e comme une tentative d’intrusion. Le syst`eme impl´ement´e est capable de d´ e-tecter une large classe d’attaques puisque l’approche d´evelopp´ee ne se base pas sur certaines s´equences particuli`eres d’actions d´ej`a recens´ees, mais plutˆot sur les effets des diff´erentes ac-tions effectu´ees. De plus, il est capable de d´etecter de nouveaux comportements malveillants non pr´ealablement identifi´es.

Abstract

Traditional techniques for intrusion detection based on different approaches for identifying unintended and unauthorized use of different resources of a computer system. To detect these behaviors, we describe in this paper a logical approach to intrusion detection based on the identification, in execution traces, of violations of given security policies. The developed model specifies the state of system resources as well as the effects of different system calls on this state. The resulting system, which is similar to an expert system, relies on a set of logical rules describing the knowledge of an expert in computer security. Any illegal behavior, that means not conform to the considered security policies, is reported and is considered as an intrusion attempt. The implemented system is able to detect a wide class of attacks since the approach is not based on some particular sequences of actions already identified, but rather on the effects of different actions performed. In addition, it is able to detect new malicious behavior not previously identified.

Table des mati`

eres

R´esum´e iii

Abstract v

Table des mati`eres vii

Liste des tableaux ix

Liste des figures xi

Avant-propos xvii

I Etat de l’art´ 3

1 Propri´et´es de s´ecurit´e 5

1.1 D´efinitions. . . 5 1.2 Propri´et´es de s´ecurit´e . . . 7

2 D´etection d’intrusions 11

2.1 Techniques de d´etection d’intrusions . . . 11

2.2 Optimisation de l’analyse des intrusions . . . 21

3 Analyse de traces du noyau 31

3.1 Traces Lttng. . . 31

3.2 Analyse de traces du noyau : AFI . . . 34

II Contribution 39

4 Approche logique pour l’analyse d’une trace 41

4.1 Description g´en´erale . . . 41

4.2 Mod´elisation . . . 44

4.3 Exemples . . . 54

5 Impl´ementation 75

5.1 Module d’´echange de donn´ees avec AFI . . . 76

5.3 Mod`ele de raisonnement en Prolog . . . 77

6 Conclusion 81

6.1 Approche propos´ee . . . 81

6.2 Travaux futurs . . . 82

Liste des tableaux

2.1 Modes d’incertitude. . . 25

4.1 Syntaxe du mod`ele. . . 47

4.2 (a) Sp´ecifications des actions et des ´etats. . . 49

4.3 (b) Sp´ecifications des actions et des ´etats. . . 50

4.4 Liste des faits ajout´es . . . 58

4.5 Application des r`egles . . . 59

4.6 Application des r`egles dans l’exemple «ajout d’un utilisateur» . . . 61

4.7 Faits ajout´es pour ´echapper `a une prison chroot . . . 63

Liste des figures

2.1 Utilisations de Snort.. . . 14

2.2 Architecture de MulVAL. . . 20

2.3 Correspondance d’observation. . . 25

2.4 Mod`ele interne. . . 26

2.5 Architecture du syst`eme de raisonnement. . . 27

3.1 Format des ´ev´enements Lttng. . . 32

3.2 Instrumentation Lttng. . . 33

3.3 Architecture de AFI. . . 34

3.4 Algorithme g´en´eral du moteur de d´etection. . . 36

3.5 Module d’affichage AFI. . . 37

4.1 Architecture d’un syst`eme expert. . . 43

4.2 Approche propos´ee. . . 44

4.3 Architecture du mod`ele propos´e. . . 45

4.4 Description de l’´etat des ressources du syst`eme. . . 48

4.5 Exemple de description de l’´etat du syst`eme. . . 48

4.6 Exemples de sp´ecification formelle de politique de s´ecurit´e. . . 53

4.7 Exemples de sp´ecification formelle de r`egles. . . 54

4.8 Code C de l’attaque race condition. . . 56

4.9 Trace Lttng de l’attaque race condition. . . 57

4.10 Code assembleur pour la cr´eation d’un utilisateur. . . 60

4.11 Trace Lttng de la cr´eation d’un utilisateur. . . 61

4.12 Effets des fonctions syst`eme de la cr´eation d’un nouvel utilisateur. . . 61

4.13 Code C pour ´echapper `a une prison chroot. . . 64

4.14 Trace Lttng pour ´echapper `a une prison chroot. . . 65

4.15 Code pour l’escalade des privil`eges.. . . 67

4.16 Trace Lttng pour l’escalade des privil`eges. . . 68

4.17 Escalade des privil`eges. . . 68

4.18 Code C de la variante de l’attaque «race condition sur les fichiers syst`eme». . . 70

4.19 Trace Lttng de la variante de l’attaque «race condition sur les fichiers syst`eme». . 71

4.20 Race condition sur les fichiers syst`eme.. . . 71

4.21 Code C de la variante de l’attaque «´echappe `a une prison chroot». . . 72

4.22 Trace Lttng de la variante de l’attaque «´echappe `a une prison chroot». . . 73

5.1 Module de traitement du r´esultat AFI re¸cu. . . 76

5.3 Interface graphique de l’application impl´ement´ee. . . 77

5.4 Sp´ecification des effets des fonctions syst`eme. . . 78

`

A mon tr´esor Acil, `a qui j’ai donn´ee naissance. `A ma ch`ere Nefissa, qui m’a donn´ee naissance.

Tant qu’il y a de la vie, il y a de l’espoir, et inversement : sans espoir, plus de vie !

Avant-propos

Je tiens `a remercier tous ceux qui, de pr`es ou de loin, ont contribu´e `a la r´eussite de ce travail. Je d´esire remercier tout particuli`erement mon directeur de recherche, le professeur B´echir Ktari sans qui cette aventure n’aurait vu son ´epilogue si tˆot et pour la confiance qu’il m’a montr´ee tout au long de ces deux ann´ees de travail. J’exprime ´egalement toutes mes reconnaissances et ma gratitude aux professeurs Laurence Capus et Luc Lamontagne pour avoir accepter d’´evaluer ce m´emoire. Je remercie le personnel administratif du d´epartement d’informatique pour les nombreux services qu’il m’a rendus.

Je tiens `a remercier tous les coll`egues du LSFM pour leur support technique et moral. Je remercie le centre de recherche et de d´eveloppement pour la d´efense Canada (DRDC) et Ericsson Canada qui ont couvert en int´egralit´e tous les frais reli´es `a mes ´etudes et mon s´ejour. Enfin, mon dernier et plus gros mot de remerciement va `a mon mari Mohamed Aymen pour le support qu’il m’a donn´e d`es mes premiers pas `a Qu´ebec. Les remerciements vont aussi `a ma famille pour leur support moral et surtout `a mon tr´esor Acil qui m’a donn´e le courage de travailler davantage.

Introduction

Les ´evolutions r´ecentes et rapides de l’informatique ont contribu´e `a l’acc´el´eration des ´echanges d’information. Les entreprises se trouvent ainsi confront´ees au contrˆole efficace de l’acc`es `a leur information, et plus pr´ecis´ement `a la n´ecessit´e d’assurer la confidentialit´e, l’int´egrit´e et la disponibilit´e de leur information. V´eritable point n´evralgique, le syst`eme d’information est souvent en proie `a de multiples attaques qui menacent l’activit´e des entreprises et qui requi`erent la mise en place de mesures ad´equates afin de prot´eger leur syst`eme d’information ; ces mesures n´ecessitent au pr´ealable la d´efinition d’une politique de s´ecurit´e que l’on va par la suite renforcer dans le syst`eme d’information1.

L’utilisation de m´ethodes, de techniques et d’outils charg´es de prot´eger les ressources d’un syst`eme informatique est devenue essentielle afin d’assurer la s´ecurit´e d’un syst`eme d’informa-tion, notamment `a travers des outils comme les syst`emes de d´etection d’intrusions permettant d’identifier des attaques ou des violations de politiques de s´ecurit´e. Toutefois, `a l’instar de tous les syst`emes de d´etection d’intrusions, ils peuvent pr´esenter des failles (engendrant de faux n´egatifs), ´emettre de fausses alertes (faux positifs) ou ˆetre contourn´es afin d’aboutir `a une action malveillante. Dans le cadre de notre travail de recherche, notre d´efi consiste `a proposer une solution efficace pour analyser les traces d’ex´ecutions d’un syst`eme en vue d’en d´etecter des comportements malveillants ; ces traces correspondent `a des s´equences d’appels syst`eme effectu´es par le noyau du syst`eme d’exploitation.

L’´enorme quantit´e d’information g´en´er´ee par les outils de tra¸cage rend difficile leur analyse. De plus, cette analyse requiert une bonne connaissance des aspects techniques du noyau du syst`eme d’exploitation (Linux). Ainsi, nous proposerons de mettre en place une approche logique qui reproduit le raisonnement d’un expert en s´ecurit´e informatique en analysant les appels syst`eme extraits d’une trace du noyau afin de d´etecter les comportements malveillants. Par cons´equent, la solution propos´ee consiste `a concevoir un syst`eme expert2d’analyse logique de traces d’ex´ecutions. Pour ce faire, il est n´ecessaire de repr´esenter les connaissances et les

1. Au chapitre1, une d´efinition des notions de propri´et´es (confidentialit´e, int´egrit´e et disponibilit´e) et de politiques de s´ecurit´e est propos´ee.

raisonnements utilis´es pour sp´ecifier le mod`ele propos´e en se basant sur une approche visant la d´etection de comportements qui violent une politique de s´ecurit´e donn´ee. Par exemple, le non respect de cette politique peut ˆetre d´ecrit `a travers les attaques acc´edant aux syst`emes de fichiers, ou autorisant les utilisateurs qui essayent de s’accorder des autorit´es suppl´ementaires pour lesquelles ils ne devraient pas avoir acc`es, ou permettant `a des utilisateurs d’abuser de leurs privil`eges : une alerte devrait ˆetre d´eclench´ee en cas de d´etection d’un tel comportement. Dans ce travail de recherche, l’outil de tra¸cage Lttng (Linux Trace Toolkit - next generation) a ´et´e utilis´e (8; 35) afin de tracer le syst`eme et de fournir des ´ev´enements de bas niveau correspondant `a des appels syst`eme (syscall ). Ces ´ev´enements peuvent concerner les syst`emes de fichiers, la communication inter-processus, les appels syst`eme ou la gestion de la m´emoire et du r´eseau. En plus de Lttng, notre travail se base sur un pr´ec´edent travail, AFI (chapitre 3), (53), qui comprend un engin de d´etection de patrons de comportements ; cet engin est utilis´e comme source de donn´ees pour la base de connaissances du syst`eme que nous avons con¸cue.

En r´esum´e, ce travail de recherche a pour objectif de mettre en œuvre une approche logique qui assure l’extraction des donn´ees `a partir de traces d’ex´ecutions. Cette approche permet la repr´esentation des connaissances et de l’´etat des ressources du syst`eme, la reproduction du raisonnement d’un expert en s´ecurit´e informatique `a travers la mise en place d’un moteur d’inf´erence et la sp´ecification d’une politique de s´ecurit´e `a respecter.

Dans ce m´emoire, il nous apparaˆıt pertinent de pr´esenter `a titre pr´ealable les propri´et´es de s´ecurit´e `a v´erifier dans un syst`eme informatique (chapitre1), puis, de pr´esenter les diff´erents types de techniques de d´etection d’intrusions, en particulier celles bas´ees sur la d´etection de violation de politiques de s´ecurit´e (chapitre 2). Par la suite, au chapitre 3, une pr´esentation des outils utilis´es dans ce projet (tels que Lttng et AFI) est propos´ee. Aux chapitres 4 et5, l’approche logique con¸cue pour l’analyse de traces d’ex´ecutions est pr´esent´ee, illustr´ee par quelques exemples pratiques d’utilisation. Finalement, une conclusion est pr´esent´ee en fin de m´emoire afin de r´esumer nos contributions et de pr´esenter quelques travaux futurs.

Premi`

ere partie

´

Chapitre 1

Propri´

et´

es de s´

ecurit´

e

L’av`enement des syst`emes informatiques, des r´eseaux et d’Internet a certes r´evolutionn´e la vie quotidienne des individus et des entreprises, mais leur popularit´e (due notamment `a leur facilit´e d’emploi) n’offre pas que des avantages. Ils contribuent souvent `a alt´erer la fiabilit´e des syst`emes. Cons´equemment, de nouvelles contraintes sont apparues comme la n´ecessit´e d’assu-rer la disponibilit´e des services offerts par le syst`eme, ainsi que l’int´egrit´e et la confidentialit´e des donn´ees qui y sont stock´ees.

Dans ce chapitre, nous pr´ecisons diff´erentes notions permettant de mieux cerner le contexte dans lequel se situe notre travail : d´etection d’intrusions ou de comportements malveillants.

1.1

D´

efinitions

Les d´efinitions suivantes permettent de mieux situer le domaine de la d´etection d’intrusions.

Syst`eme informatique Un syst`eme informatique est compos´e d’outils mat´eriels et lo-giciels qui cohabitent et collaborent pour le traitement et l’´echange de donn´ees. Il est compos´e d’une ou de plusieurs machines reli´ees entre elles `a l’aide d’un r´eseau. Il peut ˆetre situ´e sur un seul site ou sur plusieurs sites ´eloign´es.

Intrusion Tous les syst`emes de d´etection d’intrusions partagent une d´efinition g´en´erale de l’intrusion comme ´etant l’utilisation non autoris´ee ou l’abus d’utilisation d’un syst`eme informatique.

Vuln´erabilit´e Les vuln´erabilit´es pr´esentes dans un composant informatique repr´esentent toutes les anomalies de conception ainsi que toutes les lacunes caus´ees par sa configuration. Par ailleurs, les vuln´erabilit´es d’un syst`eme informatique correspondent `a la combinaison des vuln´erabilit´es de ses composants. La pr´esence de certains composants particuliers entraine

souvent l’apparition de nouvelles vuln´erabilit´es. Toutes ces vuln´erabilit´es repr´esentent des faiblesses pour le syst`eme et ainsi des opportunit´es d’attaques pour les intrus.

Politique de s´ecurit´e Une politique de s´ecurit´e correspond `a un ensemble de r`egles ´etablies par les administrateurs des syst`emes informatiques. Elle mod´elise et formalise les actions `a autoriser et celles `a interdire en consid´erant tous les composants figurant dans un syst`eme donn´e. Ces autorisations et interdictions sont bas´ees sur les vuln´erabilit´es de chaque outil.

Syst`eme de d´etection d’intrusion (ou IDS : Intrusion Detection System) Un tel sys-t`eme est caract´eris´e par la pr´esence d’un m´ecanisme destin´e `a rep´erer des activit´es anormales ou suspectes sur la cible analys´ee (un r´eseau ou un hˆote).

Attaque Pour lancer une attaque sur un syst`eme informatique, l’intrus collecte, dans un premier temps, de l’information par le biais d’outils communs comme les scanners de ports. Il exploite ensuite l’information recueillie pour s’introduire dans le syst`eme cibl´e. Une fois que le syst`eme de s´ecurit´e est d´ejou´e, l’intrus organise son propre environnement en cr´eant un compte avec tous les privil`eges ou en installant des applications de prise de contrˆole (cheval de Troie, par exemple). Il proc`ede, ensuite, `a l’exploration de la cible et enfin il accomplit son action malicieuse.

Alerte Une alerte repr´esente l’information transmise par un IDS `a l’intention de l’ad-ministrateur. Elle doit ˆetre claire, nette et pr´ecise.

Faux positif On parle d’un faux positif lorsqu’un IDS consid`ere un fonctionnement normal comme une attaque.

Faux n´egatif On parle d’un faux n´egatif lorsqu’un IDS ne d´etecte pas une vraie attaque.

Signature d’attaque Une signature d’attaque est un motif (patron de comportement) repr´esentant toute l’information concernant une attaque connue. C’est par ce moyen que l’administrateur r´eseau configure les syst`emes de d´etection d’intrusions.

Toutes ces d´efinitions vont nous aider `a mieux comprendre la signification des termes utilis´es dans ce m´emoire, plus pr´ecis´ement, dans la description des techniques de d´etection d’intrusion et leurs fonctionnements (chapitre2). Dans la section suivante, un aper¸cu des propri´et´es de s´ecurit´e `a v´erifier par un IDS est pr´esent´e afin d’assurer le respect d’une politique de s´ecurit´e donn´ee.

1.2

Propri´

et´

es de s´

ecurit´

e

Dans le cadre de notre projet de recherche, on con¸coit un syst`eme qui d´etecte la violation d’une politique de s´ecurit´e donn´ee. Cette politique d´efinit une ex´ecution qui est jug´ee inac-ceptable (46). En g´en´eral, une politique de s´ecurit´e est sp´ecifi´ee sous la forme de r`egles ou de propri´et´es d´ecrivant des comportements, jug´es malicieux ou b´enins. Nous pr´esentons dans cette section les propri´et´es de s´ecurit´e que nous avons recens´ees. La plupart de ces propri´et´es sont mentionn´ees couramment dans la litt´erature.

1.2.1 Confidentialit´e

«La confidentialit´e est le maintien du secret des informations» (Le Petit Robert).

La confidentialit´e assure donc que seules les personnes autoris´ees ont acc`es `a certains ´el´ements donn´es. Ainsi, cette propri´et´e est viol´ee si une information est lue par un utilisateur sans avoir les autorisations d’acc´eder `a cette ressource. Et c’est `a travers une telle propri´et´e de s´ecurit´e que l’on sp´ecifie que les utilisateurs des dites ressources poss`edent uniquement les droits qui leur ont ´et´e octroy´es.

Exemples : La propri´et´e de confidentialit´e n’est pas respect´ee si on acc`ede `a une ressource priv´ee sans autorisation ou si on acc`ede `a une ressource priv´ee avec autorisation et qu’on la rend publique sans avoir les droits n´ecessaires permettant son accomplissement (29). Comme exemple, on peut consid´erer les situations suivantes :

– acc`es en lecture `a un fichier secret (comptes utilisateurs, mots de passe, etc.) par un utilisateur non autoris´e ;

– envoi d’un fichier secret sur le r´eseau.

Les attributs des ressources sont pr´ecis´es au niveau de la politique de s´ecurit´e. Ils pr´ecisent ce qui est confidentiel de ce qui ne l’est pas. Dans le mod`ele que nous proposons au chapitre 4, une ´etiquette (de type secret) est ainsi associ´ee `a toute ressource que l’on veut prot´eger. Plus pr´ecis´ement, les ressources qui sont jug´ees sensibles (secr`etes) sont :

– les fichiers sp´eciaux contenant le noyau et les fichiers de configuration du syst`eme, les pilotes des p´eriph´eriques et les donn´ees sensibles des utilisateurs ;

– le r´eseau et ses ports de communication ; – la m´emoire allou´ee aux processus du syst`eme.

Il existe deux actions compl´ementaires permettant d’assurer la confidentialit´e des ressources : – limiter leur acc`es par un m´ecanisme de contrˆole d’acc`es ;

– transformer les donn´ees par des proc´edures de chiffrement.

Par ailleurs, ces actions peuvent ˆetre sp´ecifi´ees dans la politique de s´ecurit´e globale de l’en-treprise.

1.2.2 Int´egrit´e

Le crit`ere d’int´egrit´e est relatif au fait que des ressources ne sont pas modifi´ees, alt´er´ees ou d´etruites tant de fa¸con intentionnelle que de mani`ere accidentelle. Ce type de propri´et´e est viol´ee si une ressource sensible est modifi´ee sans en avoir les autorisations.

Exemples : Les comportements malicieux qu’on cherche `a d´etecter et qui sont li´es au crit`ere d’int´egrit´e consistent principalement `a la modification d’une ressource sensible, tel qu’un fichier de mots de passe, afin d’atteindre des objectifs malintentionn´es. Parmi les exemples repr´esentatifs, on peut citer ceux qui suivent :

– modification du fichier des comptes utilisateurs (ajout d’un nouvel utilisateur par exemple) par un agent non autoris´e ;

– modification des droits d’acc`es d’un fichier de mots de passe et son envoi sur le r´eseau.

1.2.3 Disponibilit´e

Pour un utilisateur, la disponibilit´e d’une ressource est l’assurance de pouvoir mener correc-tement, `a terme, une session de travail. La disponibilit´e d’une ressource est indissociable de son accessibilit´e : il ne suffit pas qu’elle soit disponible, elle doit ˆetre utilisable avec un temps de r´eponse acceptable.

On parle de violation de cette propri´et´e d`es que les services, les syst`emes ou les programmes donnant acc`es `a une ressource donn´ee sont interrompus ou utilis´es d’une mani`ere inacceptable. Exemple : L’exemple le plus r´epandu et qui est associ´e directement `a ce type de priorit´e est l’attaque par d´eni de service. Il s’agit en g´en´eral de l’inondation et de la saturation d’un r´eseau afin d’empˆecher son fonctionnement par l’envoi syst´ematique de paquets.

1.2.4 Autres propri´et´es de s´ecurit´e

Aux trois propri´et´es d´ej`a cit´ees s’ajoutent d’autres qui permettent, par exemple, de prouver l’identit´e des entit´es (notion d’authentification), et qui indiquent que des actions ou ´ev´ ene-ments ont bien eu lieu (notions de non-r´epudiation, d’imputabilit´e et de tra¸cabilit´e).

Authentification

L’authentification est une propri´et´e qui assure la reconnaissance de l’identit´e d’une entit´e (personne, ordinateur, etc.), afin d’autoriser l’acc`es `a des ressources (syst`emes de fichiers, r´eseaux, processus, etc.). L’authentification permet donc de valider l’authenticit´e d’une entit´e, et de prot´eger l’usurpation d’identit´e.

Plusieurs attaques visent `a violer l’authentification en utilisant des moyens de d´eguisement (mascarade). En effet, pour s’introduire dans un syst`eme, un intrus essaye de pi´eger des usagers et de se faire passer pour quelqu’un d’autre (usurpation d’identit´e).

Exemple : La technique de spoofing, qui consiste `a envoyer des paquets d’information avec une adresse d’exp´editeur fausse, peut engendrer un probl`eme d’authentification dans la mesure o`u le destinataire des paquets aura une id´ee erron´ee `a propos de l’exp´editeur.

Non-r´epudiation

La non-r´epudiation est une propri´et´e qui assure que l’auteur d’une action ne peut pas nier l’avoir effectu´e. Plus g´en´eralement, la non-r´epudiation consiste `a garantir que l’auteur d’un message ou d’un document ne peut nier l’avoir ´ecrit ou transmis. Elle est principalement utilis´ee dans les protocoles d’´echange ´equitable.

Exemple : L’utilisation de signatures avec des m´ecanismes de chiffrement asym´etrique permet de s’assurer que l’´emetteur d’un message ne puisse pas r´epudier son ´emission. Par exemple, si l’agent Alice signe un courriel pour l’agent Bob avec sa cl´e priv´ee et qu’elle l’envoie, alors d’une part, Bob est sˆur de l’int´egrit´e du message, et d’autre part, du fait qu’Alice en est bien l’´emettrice ; il obtient ´egalement une preuve de non-r´epudiation de l’´emetteur : il peut prouver qu’Alice est bien l’´emettrice, quoi qu’elle affirme. De mˆeme, si Bob envoie un acquittement (par exemple, par l’envoi d’un hash sign´e du message re¸cu), alors Alice obtient une preuve de non-r´epudiation de r´eception : elle peut alors prouver `a tous que Bob a bien re¸cu son message, et en cas de litige, Bob ne pourra pas affirmer le contraire (54).

Conclusion Il n’est pas suffisant de d´efinir une politique de s´ecurit´e (en termes de confi-dentialit´e, d’int´egrit´e et de disponibilit´e des donn´ees et ressources du syst`eme `a prot´eger) et de mettre en œuvre des m´ecanismes implantant cette politique. Il faut aussi ˆetre capable de d´etecter toute tentative de violation de la politique de s´ecurit´e, et donc toute intrusion. A cette fin, dans le cadre de notre travail, nous voulons mettre en place une approche de d´etection des intrusions, ce qui implique une surveillance permanente des actions entreprises sur le syst`eme afin d’en assurer la l´egitimit´e. Cette surveillance est r´ealis´ee par le biais d’un m´ecanisme de collecte d’´ev´enements (actions r´ealis´ees sur un syst`eme) `a partir de traces d’ex´ecutions. Le nombre d’attaques ciblant ce type de syst`eme est en constante augmentation. La mise en œuvre de politiques de confidentialit´e et d’int´egrit´e au sein de ces syst`emes est une tˆache complexe.

Afin de r´esoudre les probl`emes de s´ecurit´e, tout en prenant en compte les diff´erentes propri´et´es `

a d´efendre, nous pr´esenterons dans le chapitre2 les travaux ant´erieurs relatifs `a la d´etection des intrusions. Diverses approches sont g´en´eralement employ´ees pour la protection des donn´ees

d’un syst`eme, permettant de s’assurer a priori du respect de la politique de s´ecurit´e.

Deux grandes approches ont ´et´e propos´ees dans la litt´erature, l’approche comportementale et l’approche par scenarios :

– Dans l’approche comportementale, une attaque est qualifi´ee par la mesure d’une d´ evia-tion sensible du syst`eme surveill´e par rapport `a un comportement de r´ef´erence, r´eput´e sain et d´efini auparavant.

– Dans l’approche par signatures, le syst`eme de d´etection poss`ede une base de signatures qui mod´elisent les diff´erentes attaques connues. L’analyse consiste `a rechercher l’occur-rence d’un motif caract´eristique d’une attaque dans le flux d’´ev´enements.

Avant la description de notre mod`ele propos´e, nous d´ecrivons dans le prochain chapitre les diff´erents types de techniques de d´etection utilis´es dans ces approches, afin de tirer profit de leurs points forts, de bien situer leurs probl`emes, et d’essayer alors d’en tenir compte dans notre conception et notre impl´ementation.

Chapitre 2

D´

etection d’intrusions

En s´ecurit´e informatique, la d´etection d’intrusions est l’acte de d´etecter des actions qui es-saient de compromettre la s´ecurit´e d’un syst`eme, notamment la confidentialit´e, l’int´egrit´e ou la disponibilit´e d’une de ses ressources (6). Elle repr´esente la m´ethodologie adopt´ee pour d´ e-tecter toutes les vuln´erabilit´es du syst`eme et elle est essentiellement utilis´ee pour surveiller le fonctionnement des syst`emes informatiques.

Pour d´ecrire le fonctionnement des syst`emes de d´etection d’intrusion, nous nous sommes bas´es sur diff´erents travaux de la litt´erature. Dans ce chapitre nous pr´esentons, dans un premier temps, les principales techniques de d´etection d’intrusions et quelques exemples illustrant leur fonctionnement. Dans un deuxi`eme temps, nous pr´esentons diff´erentes techniques permettant d’optimiser l’analyse des alertes, et ainsi rendre plus fiable la d´etection d’intrusions.

2.1

Techniques de d´

etection d’intrusions

Plusieurs approches sont apparues pour prot´eger et s´ecuriser les syst`emes informatiques. Elles sont toutes compl´ementaires les unes par rapport aux autres, mais demeurent insuffisantes. Une classification suivant la technique utilis´ee pour la d´etection d’intrusions est propos´ee dans cette section afin de prendre connaissance des diff´erentes approches con¸cues et impl´ement´ees. Nous distinguons trois grandes approches de d´etection d’intrusions : la d´etection `a base de signatures, la d´etection d’anomalies et la d´etection `a base de politiques de s´ecurit´e. Dans ce qui suit, chaque technique est d´etaill´ee et quelques exemples sont propos´es pour les illustrer.

2.1.1 D´etection `a base de signatures

Cette technique s’apparente aux techniques utilis´ees par les antivirus : elle est bas´ee sur la notion de signatures d’attaques. Une telle signature caract´erise l’attaque consid´er´e. Plus pr´ecis´ement, elle correspond `a un ´el´ement distinctif de l’attaque comme, par exemple, un

fragment de code, un d´ebut de requˆete, etc. La technique consiste donc `a analyser des flux de donn´ees et de les comparer `a des signatures pr´ed´efinies pour identifier d’´eventuelles intrusions (41).

Il est ´evident qu’en utilisant une telle technique, une menace dont on ignore la signature ne pourra pas ˆetre d´etect´ee. Comme il est fr´equent que la variante d’une attaque ne poss`ede pas la mˆeme trace collect´ee (la mˆeme signature), il est difficile de la d´etecter. Ainsi, afin de d´ejouer la s´ecurit´e d’un syst`eme de d´etection d’intrusions, les attaquants utilisent des m´ethodes pour modifier l’aspect, ou la signature, de leurs attaques d´ej`a r´epertori´ees par le syst`eme, et atteindre ainsi leurs objectifs. Par exemple, en menant une attaque sur plusieurs ´etapes, en changeant l’ordre des actions, et en lan¸cant leurs attaques depuis plusieurs sources diff´erentes, l’attaquant arrive `a modifier les signatures de ses attaques. Le nombre de variantes d’une attaque pouvant ˆetre nombreux, trouver la signature de chaque nouvelle variante n’est pas une solution viable. Ceci est le principal reproche fait vis-`a-vis des techniques de d´etection `

a base de signatures (6).

Ce mod`ele est en revanche tr`es ais´e `a impl´ementer et `a optimiser. Il permet la s´eparation du moteur logiciel de la base de signatures qui peut ainsi ˆetre mise `a jour de mani`ere autonome. Il permet ´egalement une classification relativement facile des attaques signal´ees (41). Par ailleurs, il existe plusieurs m´ecanismes pour mettre en œuvre cette approche. Parmi eux, on peut citer ceux qui suivent.

D´etection par comparaison (pattern matching )

Cette technique de reconnaissance d’intrusions est la plus ancienne des m´ethodes d’analyse des NIDS1 et elle est encore couramment utilis´ee (30). Le principe de cette approche est de faire correspondre `a chaque signature d’attaque un motif (pattern) qui a la forme d’une chaine de caract`eres. Durant l’analyse du flux de donn´ees, qui correspond aussi `a une chaine de caract`eres, le syst`eme de d´etection d’intrusion tente de reconnaˆıtre les motifs d’attaques d´ej`a connus (31). Une alerte est d´eclench´ee si un motif est d´etect´e. Par exemple, la recherche de la chaˆıne de caract`eres «/cgi-bin/phf» indique une tentative d’intrusion sur le script CGI appel´e «phf». Cette m´ethode est aussi utilis´ee en compl´ement de filtres sur les adresses IP sources et destinations utilis´ees par les connexions, les ports sources ou destinations.

Les principaux avantages de cette technique se situent au niveau de sa facilit´e de mise `a jour. Dans la mesure o`u on recherche des motifs sp´ecifiques, la qualit´e de la d´etection est bonne ; et cette m´ethode peut facilement ˆetre adapt´ee `a tous les protocoles.

Il faut tout de mˆeme ˆetre conscient du fait que les outils de recherche de motifs pr´esentent certains inconv´enients. D’abord, les motifs doivent ˆetre de bonne qualit´e pour ´eviter de d´

clencher de fausses alertes (faux positifs) (50). Aussi, un pirate exp´eriment´e peut d´eguiser son attaque de mani`ere `a ce qu’elle ne soit pas d´etect´ee (faux n´egatif), ce qui peut conduire parfois `a la multiplication de nombres de signatures pour d´etecter une unique attaque. Enfin, cette technique peut s’av´erer consommatrice en terme de m´emoire et de temps processeur si le nombre de signatures est important.

D´etection par analyse de transition d’´etats

Dans ce cas, on cr´ee un mod`ele tel que, `a l’´etat initial, le syst`eme ne soit pas compromis. L’intrus acc`ede au syst`eme ; il ex´ecute une s´erie d’actions qui provoquent, `a chaque fois, des transitions sur les ´etats du mod`ele, pouvant ˆetre des ´etats consid´er´es comme compromis (47). Cette approche de haut niveau peut reconnaˆıtre des variations d’attaques qui passeraient inaper¸cues avec des approches de plus bas niveau. USTAT (21; 22) est une impl´ementation mature de l’analyse de transitions d’´etats pour la d´etection d’intrusions. Le syst`eme est ini-tialement dans un ´etat consid´er´e sˆur et, `a travers un certain nombre d’actions mod´elis´ees par des transitions d’´etats, peut se retrouver dans un ´etat compromis.

Un exemple de sc´enario d’intrusion pr´esent dans les syst`emes Unix BSD, version 4.2, est : cp /bin/sh /usr/spool/mail/root

chmod 4755 /usr/spool/mail/root echo | mail root /usr/spool/mail/root

L’attaque consiste `a afficher le courriel de l’utilisateur « root ». L’intrus exploite la faille que la commande mail ne change pas le bit « setuid » lorsqu’il change le propri´etaire du fichier (courriel). Pour r´eussir cette intrusion, il suppose certaines conditions qui peuvent ˆetre vues comme un ´etat de d´epart comme par exemple « root » n’a pas de courriel. Ainsi, son attaque n’est pas valide si « root » a du courriel dans l’´etat courant du syst`eme. Chaque ´etape fait changer le syst`eme d’´etat vers un ´etat plus proche d’un ´etat compromis. La premi`ere transition sera la cr´eation d’un fichier dans le r´epertoire de mail, la deuxi`eme sera le changement du mode d’acc`es `a ce fichier pour pouvoir y acc´eder en derni`ere ´etape.

Pour terminer, notons qu’il existe plusieurs syst`emes de d´etection d’intrusions commerciaux, ou des logiciels libres, qui se basent sur la m´ethode d’analyse `a base de signatures. Parmi ces syst`emes, on retrouve Snort.

Snort (48) est un syst`eme de d´etection d’intrusions r´eseau. Il observe et analyse le trafic suivant des indicateurs ou des signatures d’attaques, tout comme il peut agir en envoyant des alertes ou en enregistrant le trafic. Sous forme de r`egles, Snort d´ecrit les signatures des attaques et effectue une d´etection par comparaison lors de la phase de d´etection d’intrusions. Une fois la signature d’une attaque identifi´ee, l’´ecriture d’une r`egle Snort ne prend que quelques minutes.

L’exemple suivant repr´esente une signature Snort :

alert tcp $EXTERNAL NET any → $HOME NET any (msg :”SCAN nmap TCP”; state- less ; flags :A,12 ; ack :0 ; reference :arachnids,28 ; classtype :attempted-recon ; sid :628 ; rev :3 ;)

qui se lit comme suit : si un paquet TCP provenant d’une adresse externe ($EXTERNAL NET) p´en`etre dans notre r´eseau ($HOME NET), peu importe les ports (any), et que ce paquet a le drapeau ACK activ´e, de mˆeme que les deux bits r´eserv´es (flags :A,12), et que le num´ero d’acquiescement est 0 (ack :0), peu importe l’ ´etat de la session (stateless), il faut alors signaler un balayage TCP fait avec nmap (11).

Snort peut d´ecoder et analyser le contenu des paquets sur le r´eseau (2). Son acc`es `a la couche application du r´eseau lui permet de d´etecter les signatures pouvant se trouver dans le contenu d’un paquet. C’est le cas avec les attaques de d´ebordement de m´emoire, de balayage de port, de scan cgi, etc.

WWW SMTP DNS Postes clients Pare-feu Internet 2 1 3

Figure 2.1 – Utilisations de Snort.

Cet outil de d´etection poss`ede trois utilisations primaires suivant sa position comme l’illustre la figure2.1:

– Position (1) : sur cette position, Snort peut d´etecter l’ensemble des attaques frontales, provenant de l’ext´erieur, en amont du pare-feu. Ainsi, beaucoup d’alertes seront remon-t´ees ce qui rendra les logs difficilement consultables ;

– Position (2) : Snort d´etecte les attaques qui n’ont pas ´et´e filtr´ees par le pare-feu et qui rel`event d’un certain niveau de comp´etence. Les logs seront ici plus clairs `a consulter puisque les attaques b´enignes ne seront pas recens´ees ;

– Position (3) : Snort peut ici rendre compte des attaques internes, provenant du r´eseau local de l’entreprise. Il peut ˆetre judicieux d’en placer un `a cet endroit, ´etant donn´e le fait que la majorit´e des attaques proviennent de l’int´erieur.

Snort pr´esente les avantages d’ˆetre un logiciel libre qui concurrence habilement les outils de d´etection d’intrusion commerciaux et il offre un format ouvert et document´e qui permet d’´ecrire les r`egles de son choix. Il peut facilement diagnostiquer une attaque sp´ecifique et autorise l’administrateur `a traquer les probl`emes de s´ecurit´e. Snort ne peut cependant d´etecter que les attaques connues ; il lui est difficile de d´etecter les variantes d’une attaque et il requiert une mise `a jour quotidienne avec sa base de signatures des attaques.

En r´esum´e, la d´etection `a base de signatures admet certains inconv´enients essentiellement dˆus au fait qu’elle ne d´etecte que les attaques connues. Une signature doit alors ˆetre cr´e´ee pour chaque attaque, et de nouvelles attaques ne peuvent ˆetre d´etect´ees. Les syst`emes de d´etection d’intrusions `a base de signatures sont ´egalement sujets `a de faux positifs car ils sont g´en´eralement bas´es sur des expressions r´eguli`eres. Les signatures fonctionnent bien contre les attaques avec un motif de comportement fixe. La d´etection est encore compliqu´ee par les progr`es technologiques qui permettent aux utilisateurs malveillants de g´en´erer diff´erentes variantes d’attaques. L’approche comportementale (d´etection d’anomalies), pr´esent´ee dans la section qui suit, apporte une premi`ere r´eponse `a cette limite.

2.1.2 D´etection d’anomalies

Contrairement `a l’approche `a base de signatures, cette approche se base sur le comportement pass´e des entit´es comme les utilisateurs, les applications et les services. Le principe repose sur la mod´elisation de ces entit´es pour mieux les contrˆoler. En effet, dans un premier temps, on fait correspondre un profil `a chaque entit´e en se basant sur son comportement normal. Dans un deuxi`eme temps, pendant la phase de d´etection, on observe l’entit´e mod´elis´ee et tous les ´

ev´enements, qui ne sont pas repr´esent´es dans le profil, d´eclenchent des alertes d’attaques. Cette approche a ´et´e largement ´etudi´ee et mise en œuvre dans un grand nombre de syst`emes (38). Elle tente de quantifier le comportement acceptable et donc identifier un comportement anormal comme une intrusion. Durant la phase d’apprentissage, les profils sont am´elior´es en d´efinissant le comportement normal de chaque entit´e. Cette phase d’apprentissage peut ˆ

etre limit´ee dans le temps ou bien continue tout au long de l’exploitation. La mise en œuvre effective de la d´etection d’anomalies d´epend de l’approche utilis´ee pour construire les profils. Nous pr´esentons ici trois des approches les plus utilis´ees.

Approche statistique

La d´etection par approche statistique (36) observe le comportement du syst`eme informatique surveill´e et apprend de mani`ere adaptative ce qui est consid´er´e normal pour les sujets. Les sujets correspondent `a des utilisateurs individuels, des groupes, des hˆotes distants et l’ensemble du syst`eme. Le comportement observ´e est marqu´e comme une intrusion potentielle s’il s’´ecarte de mani`ere significative par rapport au comportement attendu par ce sujet.

Dans ce type de d´etection, la construction des profils se base sur des mesures quantitatives de l’utilisation des ressources syst`emes. L’approche tient `a jour une base de connaissances statis-tiques compos´ee de profils. Un profil correspondant `a une description du comportement normal d’un sujet en respectant un ensemble de mesures de d´etection d’intrusions. Les profils sont con¸cus pour n’exiger qu’un minimum de stockage de donn´ees historiques et d’enregistrer que les informations suffisantes. Ces profils peuvent ˆetre facilement d´ecod´es et interpr´et´es lors de la d´etection d’anomalies. Plutˆot que de stocker toutes les donn´ees, les profils maintiennent seule-ment des statistiques comme des tableaux de fr´equence, des moyens ou des covariances (50). Le syst`eme prend en entr´ee des enregistrements trait´es, il g´en`ere p´eriodiquement une valeur indicative de son anomalie. Cette valeur est une fonction des valeurs anormales des mesures individuelles comprenant le profil de l’utilisateur. Par exemple, si S1, S2, ..., Sn repr´esentent les valeurs anormales des mesures d’un profil M1, M2, ..., Mn, une fonction de combinaison des valeurs individuelles Si peut ˆetre : a1S12+ a2S22+ ... + anSn2, ai > 0.

En g´en´eral, les mesures M1, M2, ..., Mn peuvent ne pas ˆetre mutuellement ind´ependantes ce qui m`ene `a une fonction complexe qui les combine.

Approche probabiliste

Dans cette approche, la construction des profils se base sur la probabilit´e qu’un ´ev´enement ait lieu par rapport `a une s´equence d’autres ´ev´enements. Un profil constitue par d´efinition la r´ef´erence `a laquelle tout comportement observ´e doit ˆetre conforme pour ne pas ˆetre consid´er´e suspect. La d´efinition pr´ecise d’une anomalie est ´evidemment variable en fonction des impl´ e-mentations et des buts poursuivis (55). Les exemples des ´ev´enements suivants peuvent ˆetre consid´er´es comme une anomalie :

– apparition d’un ´ev´enement non pr´evu par le profil ;

– apparition trop fr´equente d’un ´ev´enement de tr`es basse probabilit´e ; – non-apparition d’un ´ev´enement attendu.

Dans l’article (55), un exemple d’ex´ecution d’un serveur HTTP est mentionn´e. La s´equence d’´ev´enements ex´ecut´ee est la suivante :

– connexion d’un client sur le port 80 ; – r´eception d’une requˆete HTTP GET.

Le profil de ce serveur peut indiquer que dans ce cas, le prochain ´ev´enement pourrait ˆetre : – lecture du fichier dont le nom apparaˆıt dans l’URL (probabilit´e 60%) ;

– renvoi d’un message d’erreur HTTP 404 (probabilit´e 10%).

Si, apr`es la s´equence d’´ev´enements cit´ee, le profil accorde `a l’´ev´enement suivant une probabilit´e de 8% tandis qu’il se produit en pratique dans 10% des cas, le syst`eme pourrait lever une alerte pour signaler une violation du profil, donc une attaque potentielle. Cependant, vu le faible ´

ecart entre la probabilit´e attendue et la fr´equence observ´ee, il ne s’agit quasi-certainement pas d’une intrusion, notamment si ce chiffre est stable au cours d’une longue p´eriode. Deux r´eactions sont possibles dans ce cas : soit laisser le syst`eme lever les alertes ; soit modifier le profil et porter la probabilit´e «normale» `a 10% afin de mieux la faire correspondre au fonctionnement r´eel.

R´eseaux de neurones artificiels

Ce type de d´etection se base sur le comportement de chaque utilisateur (7). Le profil normal d’un utilisateur est construit en prenant en compte les activit´es de l’utilisateur comme ses outils pr´ef´er´es, ses habitudes de travail, sa vitesse de frappe au clavier, etc. Le profil est ensuite repr´esent´e par un r´eseau de neurones2 _{qui enregistre les op´erations de l’utilisateur durant une}

fenˆetre temporelle et tente de pr´edire la prochaine op´eration.

Leur rapidit´e permet l’analyse, en temps r´eel, d’importants flux de donn´ees. On peut utiliser les r´eseaux neuronaux pour filtrer et s´electionner les informations suspectes permettant une analyse d´etaill´ee par un syst`eme expert3_{. On peut aussi les utiliser directement pour la d´}

e-tection de malveillances. Mais leur apprentissage est extrˆemement d´elicat, et il est difficile de savoir quand un r´eseau est prˆet pour l’utilisation.

Les r´eseaux de neurones peuvent ˆetre exploit´es pour obtenir une mod´elisation statistique du comportement d’un utilisateur. Cependant, lorsqu’un r´eseau de neurones signale une anomalie, il n’en pr´ecise pas la cause, ce qui ne facilite pas la prise de d´ecision pour rectifier la situation. Un exemple de ce type de d´etection est IDES (Intrusion Detection Expert System) (23; 38) d´evelopp´e par le SRI (Stanford Research Institute). Il int`egre un module statistique et un syst`eme expert. Il repose sur l’hypoth`ese que le comportement d’un utilisateur reste `a peu pr`es le mˆeme au cours du temps, et que la mani`ere dont il se comporte peut ˆetre r´esum´ee en calculant diverses statistiques sur son comportement.

IDES construit ses profils par groupes d’utilisateurs cens´es avoir un comportement proche et tente de corr´eler le comportement actuel d’un utilisateur avec son comportement pass´e et le comportement pass´e du groupe. Il observe trois types de sujets : les utilisateurs, les hˆotes

2. Un r´eseau de neurones artificiels est un mod`ele de calcul dont la conception est tr`es sch´ematiquement inspir´ee du fonctionnement des neurones biologiques. Il est optimis´e par des m´ethodes d’apprentissage de type probabiliste, en particulier bay´esien.

3. Un syst`eme expert est un outil capable de reproduire les m´ecanismes cognitifs d’un expert, dans un domaine particulier. Il est d´etaill´e dans la partie contribution.

distants et les syst`emes cibles. Au total, 36 param`etres sont mesur´es : 25 pour les utilisateurs, 6 pour les hˆotes et 5 pour les syst`emes cibles (3). Toutes ces mesures font partie de ces deux cat´egories :

– mesure cat´egorique : c’est une mesure de nature discr`ete et dont les valeurs appar-tiennent `a un ensemble fini. On y retrouve par exemple les commandes invoqu´ees par un utilisateur ;

– mesure continue : c’est une fonction r´eelle. On a par exemple le nombre de lignes im-prim´ees pendant la session ou la dur´ee de la session.

Par cons´equent, IDES apporte une r´eponse aux diff´erents types d’intrusions suivant le sujet invoqu´e. Voici les types d’attaques possibles suivant Andersons (5) :

– attaquants externes : ils n’ont pas d’acc`es au mat´eriel ;

– attaquants internes : ils ont un acc`es l´egitime au syst`eme informatique pour r´ealiser une tˆache particuli`ere, mais tentent d’obtenir un acc`es `a des privil`eges qu’ils ne pos-s`edent pas normalement. Ils constituent la menace la plus importante en cas de sinistre informatique ;

– utilisateurs malfaisants : ils ont un acc`es l´egitime au syst`eme informatique et poss`edent des privil`eges importants, mais abusent de leurs privil`eges ou des ressources mises `a leurs disposition.

IDES traite chaque enregistrement d’audit quand il apparait sur le syst`eme. Pour d´etecter des comportements anormaux pendant une session, alors que tous les param`etres de la session ne sont pas encore disponibles, IDES extrapole les valeurs et les compare au profil de l’utilisateur. En guise de conclusion, bien que cette recherche montre de grandes promesses dans la d´ etec-tion des comportements anormaux des utilisateurs, des applicaetec-tions et dans l’apprentissage automatique du savoir-faire `a partir des donn´ees de formation, tout ce qu’elle peut faire est de d´etecter des comportements anormaux, ces comportements pouvant ˆetre b´enins ou mal-veillants. Malheureusement, un comportement anormal b´enin est plus fr´equent qu’un compor-tement malveillant, menant `a un taux de faux positifs important pour les r´egimes de d´etection d’anomalies. Il s’agit d’une limitation fondamentale dans cette approche.

En outre, il n’existe aucune garantie que tous les actes de malveillance soient anormaux. En effet, un pirate peut mener son attaque de telle mani`ere qu’un syst`eme de d´etection ne la consid`ere pas comme anormale (20).

Les deux techniques d´ej`a pr´esent´ees (`a base de signature et d’anomalies) se sont av´er´ees assez efficaces et sont largement utilis´ees. Cependant, elles souffrent aussi de plusieurs probl`emes.

Un syst`eme de d´etection d’intrusions `a base de signatures n´ecessite une maintenance active et continue de sa base de donn´ees des attaques (signatures). De nouvelles attaques ne sont g´en´eralement pas d´etect´ees. Une m´ethode comportementale peut quand `a elle g´en´erer une grande quantit´e de faux positifs, mˆeme si les actions observ´ees sont parfaitement l´egitimes. Dans tous les cas, face `a un comportement l´egitime, mais non planifi´e, il y a une probl´ematique qui se pose. Ces probl`emes peuvent ˆetre r´esolus de plusieurs fa¸cons sophistiqu´ees et avanc´ees. Une autre fa¸con possible de traiter ces probl`emes est d’utiliser des r`egles de d´etection. Une approche bas´ee sur une politique de s´ecurit´e d´etecte toute anomalie qui viole les r`egles d’une politique plutˆot que d’un comportement d´ej`a recens´e, ou appris et consid´er´e comme «normal» (18;19).

2.1.3 D´etection `a base de politiques de s´ecurit´e

Le premier mod`ele de syst`eme de d´etection d’intrusion param´etr´e par une politique de s´ecurit´e a ´et´e propos´e par Ko et Redmond (27). Ils sont int´eress´es aux probl`emes de violations d’une politique d’int´egrit´e par les attaques de type race-condition, litt´eralement situation de com-p´etition. Cette forme d’attaques correspond `a un probl`eme particulier de synchronisation : l’attaquant profite de l’ex´ecution concurrente et non synchronis´ee d’op´erations dont l’une au moins est «sensible» (typiquement une v´erification de contrˆole d’acc`es sur une ressource «sen-sible» suivi d’un acc`es `a cette mˆeme ressource) pour lire ou modifier des donn´ees auxquelles il n’a pas acc`es. Ko et Redmond (27) mod´elisent le syst`eme par une machine `a ´etats et la politique de s´ecurit´e par une propri´et´e de «non-interf´erence». Ils montrent ensuite que la d´etection en temps r´eel des violations de cette politique peut ˆetre r´ealis´ee par un algorithme prouv´e par un th´eor`eme de d´eroulement. Cet algorithme a ´et´e impl´ement´e au sein d’un HIDS4 sous Linux. Les exp´erimentations r´ealis´ees ont montr´e que l’IDS est alors capable de d´etecter les violations de politique d’int´egrit´e r´esultant d’une attaque de type race-condition.

Zimmermann (55; 56) a propos´e un mod`ele plus g´en´erique de d´etection param´etr´ee par une politique : le mod`ele `a flux de r´ef´erences. Ce mod`ele permet de couvrir un spectre d’attaques plus large que le mod`ele propos´e par Ko et Redmond (27). L’approche de Zimmermann permet en effet de traiter les violations de l’int´egrit´e et de la confidentialit´e, et ce quel que soit le sc´enario d’attaque utilis´e.

Une telle approche a le potentiel d’apporter des am´eliorations sensibles par rapport `a la d´ etec-tion statistique d’anomalies et `a la d´etection de sc´enarios en terme de fiabilit´e, d’exactitude et de maintenance requise. Id´ealement, la maintenance est n´ecessaire uniquement pour changer la politique sp´ecifi´ee, sans besoin de mise `a jour ou de phase d’adaptation (9). Par exemple, une politique pourrait indiquer que Telnet ne doit pas ˆetre utilis´e du tout, ou que Ftp doit ˆetre

4. HIDS : Host based IDS, signifiant «syst`eme de d´etection d’intrusions machine» sont des IDS d´edi´es `a un mat´eriel ou un syst`eme d’exploitation.

utilis´e uniquement `a certaines heures et sur des sites sp´ecifiques. Les syst`emes de d´etection devraient alors v´erifier si ces contraintes sont respect´ees et d´eclencher une alerte en cas de violation (55).

Ce type de d´etection pr´esente essentiellement deux avantages :

1. La politique de s´ecurit´e est explicitement d´efinie, ce qui n’est pas le cas avec les m´ethodes classiques. L’ad´equation de la base de signatures ou des profils `a une politique donn´ee est en effet un probl`eme d´elicat et la possibilit´e d’exprimer directement une politique est l’un des traits les plus attractifs de ces projets.

2. Un tel syst`eme peut th´eoriquement d´etecter de nouvelles attaques (on ne suppose pas la connaissance d’un sc´enario particulier). De mˆeme, la comparaison de l’activit´e du syst`eme `a une politique et non `a un profil doit r´eduire consid´erablement le taux de faux n´egatifs engendr´es par le syst`eme car un comportement inhabituel, mais l´egitime, ne doit pas ˆetre signal´e.

L’inconv´enient majeur de cette technique est que le fait d’´ecrire les r`egles de la politique de d´etection peut se r´ev´eler tr`es p´enible. En outre, si ces r`egles venaient `a ˆetre connues de l’attaquant, elles pourraient ˆetre contourn´ees.

MulVAL (37) est un outil parmi ceux qui se basent sur une analyse d’intrusions param´etr´ee suivant une politique de s´ecurit´e donn´ee. Il est d´evelopp´e par Kansas State University (37;43;

44). Son but est de g´en´erer automatiquement des graphes d’attaques `a partir d’une base de

connaissances contenant des faits et des r`egles logiques. MulVAL utilise le langage Datalog, un d´eriv´e de Prolog, pour exprimer ces faits et r`egles.

R`egles

d’interaction Environnement Prolog

scanneur OVAL hˆote 1 scanneur OVAL hˆote N Configuration r´eseaux

Politique de s´ecurit´e Violation & trace d’attaque

D´efinition OVAL Base de donn´ees

ICAT

... ...

Figure 2.2 – Architecture de MulVAL.

Les faits Datalog sont employ´es pour d´ecrire l’ensemble du syst`eme : machines, topologie r´eseau, r`egles de pare-feu, applications install´ees, vuln´erabilit´es, emplacement de l’attaquant,

etc. Ils sont ´ecrits en utilisant OVAL (Open Vulnerability and Assessment Language) (34;45) qui est un langage pour sp´ecifier les tests et fournir les r´esultats d’analyse de vuln´erabilit´es comme ce qui est d´ecrit dans la figure2.2.

Les r`egles d´ecrivent de fa¸con g´en´erique les ´etapes des attaques connues, sous forme de condi-tions logiques. MulVAL est fourni avec un ensemble de r`egles de base qui peut ˆetre ´etendu au cours du temps pour ajouter de nouvelles connaissances. MulVAL emploie aussi toutes ces informations pour d´eterminer tous les chemins d’attaques possibles depuis l’attaquant jus-qu’aux cibles. Le r´esultat est un graphe d’attaques qui est logiquement complet et exhaustif par rapport aux donn´ees fournies.

2.1.4 Conclusion

Un des inconv´enients majeurs de la d´etection par signatures d’attaques est son manque de flexibilit´e et par cons´equent sa vuln´erabilit´e aux mutations. D’une part, pour pouvoir d´efinir une signature, il faut avoir d´ej`a ´et´e confront´e `a l’attaque consid´er´ee. D’autre part, certaines de ces signatures se basent sur des caract´eristiques «volatiles» d’un outil, comme par exemple le port choisi par le pirate. Les caract´eristiques retenues pour d´efinir la signature sont donc fragiles, et les signatures extrˆemement sensibles aux mutations. Contre ce genre de probl`eme, une parade consiste `a d´efinir ce qu’est l’´etat de «compromission», c’est-`a-dire l’´etat attendu d’une machine pendant ou apr`es une attaque. On peut alors essayer de d´etecter quand la machine entre dans cet ´etat : on ne saura pas comment la machine a ´et´e attaqu´ee si l’attaque ´

etait de type inconnu, mais on se sera quand mˆeme aper¸cu que quelque chose a eu lieu. Bien sˆur, la difficult´e majeure dans cette parade est de d´efinir ce fameux ´etat de «compromission». On pourrait donc penser qu’un mod`ele comportemental serait une bonne alternative. L’ana-lyste humain d´eciderait alors lui-mˆeme si l’activit´e relev´ee est une attaque ou non tout en se basant sur une sp´ecification de la politique de s´ecurit´e adopt´ee. Ce raisonnement constitue le cœur de l’approche que nous avons mod´elis´ee.

Apr`es avoir mis en place un syst`eme de d´etection d’intrusions `a partir de traces d’ex´ecutions, il est souhaitable d’optimiser le r´esultat obtenu en limitant le nombre d’alertes affich´ees. Cette optimisation peut se faire `a travers diff´erentes techniques de r´eduction des alertes `a savoir : la corr´elation, le regroupement ou la v´erification des alertes. Un niveau de certitude peut aussi ˆ

etre associ´e aux attaques d´etect´ees afin d’optimiser l’analyse des intrusions.

2.2

Optimisation de l’analyse des intrusions

Des m´ethodes de la litt´erature peuvent contribuer `a l’optimisation du processus de d´etection d’intrusions en appliquant diff´erentes techniques de r´eduction des alertes. En effet, plusieurs alertes peuvent ˆetre li´ees `a une mˆeme attaque. La corr´elation, le regroupement et la v´

erifica-tion constituent un axe d’am´elioration prioritaire bien que ce surcoˆut soit en partie inh´erent `

a l’approche utilis´ee. D’autres techniques, permettant l’optimisation de la m´ethode d’analyse d’intrusions, peuvent ˆetre utilis´ees. Il est par exemple possible d’attribuer un niveau de cer-titude aux ´ev´enements d´etect´es par un IDS comme il est pr´esent´e par Xinming Ou (42) dans son approche. Ces deux voies d’am´elioration du syst`eme font l’objet de cette section.

2.2.1 Techniques de r´eduction des alertes

Les syst`emes de d´etection d’intrusions d´etectent un flot important d’alertes. Il devient de plus en plus difficile de reconnaˆıtre les vraies attaques noy´ees dans ce flot de donn´ees. Ainsi, il est n´ecessaire de concevoir des m´ethodes pour r´eduire ces alertes afin d’´eliminer les redondances. Il existe diff´erentes techniques qui agissent `a ce niveau. Parmi ces techniques, nous nous int´eressons `a la corr´elation, au regroupement et `a la v´erification des alertes.

Corr´elation des alertes

La plupart des syst`emes de corr´elation d’alertes fonctionnent sur des ´etats sp´ecifiques utilisant des pr´e/post-conditions qui poussent un mod`ele de corr´elation et s’appuient sur l’existence d’un mappage des alertes `a leur pr´e/post-conditions (40). Les alertes obtenues correspondent toujours `a des alertes trop ´el´ementaires. La cons´equence sera la difficult´e pour l’administrateur de s´ecurit´e de prendre la bonne d´ecision lors de la r´eception de ces alertes. Par cons´equent, une analyse compl´ementaire doit ˆetre effectu´ee. C’est l’objet de la fonction de corr´elation. Le principe de la fonction de corr´elation est de consid´erer que l’intrus veut atteindre un objectif malveillant, mais il ne peut pas g´en´eralement arriver `a ses fins par l’ex´ecution d’une seule attaque. Au lieu de cela, il effectue habituellement plusieurs attaques qui correspondent aux ´etapes d’un plan plus global d’intrusion qui lui permet d’atteindre son objectif malveillant. Il est inclus, dans le plan d’intrusion, les ´etapes pr´eliminaires que l’intrus r´ealise g´en´eralement afin de recueillir diverses informations sur la configuration du syst`eme cible d’attaque. Les syst`emes de d´etection d’intrusions classiques ne d´etectent que des attaques ´el´ementaires qui correspondent aux ´etapes de ce plan d’intrusion.

L’objectif de la fonction de corr´elation est donc de corr´eler des alertes afin de reconnaˆıtre le plan d’intrusion qui est actuellement ex´ecut´e par l’intrus (16).

Regroupement des alertes

Lors d’un regroupement d’alertes, un ensemble d’alertes similaires est regroup´e et repr´esent´e comme une seule alerte. Par exemple, des alertes ayant des adresses IP source et destination similaires, mais `a diff´erents intervalles de temps, sont regroup´ees et repr´esent´ees comme une seule alerte. L’´ecart de temps du nouveau pr´edicat sera l’´ecart ayant le premier et le dernier

intervalle de temps de l’ensemble des alertes similaires. Cette ´etape permet de r´eduire la redondance des alertes g´en´er´ees par le syst`eme de d´etection d’intrusions. Une limitation du regroupement d’alertes est qu’il ne pr´evoit pas une prise de conscience de haut niveau de la situation du r´eseau et du lien de causalit´e entre les ´ev´enements regroup´es.

Dans ce contexte, Julish (25) a propos´e une technique de forage de donn´ees5 bas´ee sur le regroupement d’alertes pour d´ecouvrir les causes profondes. Selon ses travaux, quelques di-zaines de causes repr´esentent g´en´eralement plus de 90% des alertes. En identifiant les causes profondes, il est possible de filtrer les alertes provoqu´ees par des causes b´enignes et de r´ e-duire ainsi la charge future d’alertes. Le regroupement est une bonne technique pour r´eduire l’information redondante dans les alertes.

V´erification des alertes

La v´erification d’alertes est d´efinie comme un processus de v´erification de la r´eussite des attaques, c’est-`a-dire qu’en cas d’attaque (et d’alerte correspondante soulev´ee par un syst`eme de d´etection d’intrusions), c’est le processus de v´erification d’alertes qui d´etermine si cette attaque a r´eussi ou pas (1). Il existe diff´erentes techniques qui peuvent ˆetre utilis´ees pour effectuer cette v´erification. Une des possibilit´es est de comparer la configuration de la machine de la victime (par exemple, le syst`eme d’exploitation ou la gestion des services) aux exigences d’une attaque r´eussie. Lorsque la victime n’est pas vuln´erable `a une attaque particuli`ere (car la configuration ne satisfait pas les exigences d’attaque), l’alerte peut ˆetre marqu´ee comme ayant ´echou´e. Par exemple, un certain «exploit» peut exiger que la victime ex´ecute une version vuln´erable d’un serveur Microsoft IIS, alors que, la configuration de la victime en cours d’ex´ecution est un serveur Apache sous Linux, l’«exploit» ne peut pas r´eussir.

Une importante distinction entre les diff´erents m´ecanismes de v´erification d’alertes est de savoir s’ils sont actifs ou passifs. Les m´ecanismes de v´erification actifs sont d´efinis comme des m´ecanismes qui recueillent des donn´ees de configuration ou des traces l´egales apr`es qu’une alerte ait lieu. D’autre part, les m´ecanismes passifs recueillent des donn´ees de configuration en une seule fois (ou `a intervalles r´eguliers) et des donn´ees disponibles avant l’attaque (28). Le fait de r´eduire le nombre des alertes d´eclench´ees permet de faciliter ´enorm´ement le suivi de l’´etat du syst`eme par l’administrateur de s´ecurit´e. Mais, il se trouve parfois dans la confusion de d´ecider de la s´ev´erit´e d’une alerte. Il ne peut pas qualifier la certitude de l’action effectu´ee. C’est dans ce contexte que Xinming Ou (42) a pr´esent´e une approche empirique pour la mod´elisation de l’incertitude en reproduisant le raisonnement humain dans l’interpr´etation des observations.

5. Le forage de donn´ees est une technique qui a pour objet l’extraction d’un savoir ou d’une connaissance `

2.2.2 Mod´elisation d’incertitude

Apr`es avoir ´etudi´e diff´erentes techniques de d´etection et d’analyse d’intrusions, nous d´ ecri-vons dans cette section une approche empirique de d´etection qui est inspir´ee d’observations d’attaques r´eelles afin de mod´eliser le niveau d’incertitude des observations. La qualification des actions par niveaux de certitude ajoute des informations au syst`eme (expert) pour r´eagir convenablement au comportement suspect.

L’article (42) pr´esente une conception du mod`ele de raisonnement et l’architecture de ce processus. Il est aliment´e par deux ´el´ements principaux : la correspondance d’observation et le mod`ele interne, afin d’identifier les intrusions. Nous d´etaillons d’abord ce mod`ele de raisonnement et nous d´ecrivons, par la suite, la m´ethodologie adopt´ee.

Mod`ele de raisonnement

De nos jours, plusieurs outils de d´etection d’intrusions existent sur le march´e. Ces outils d´etectent des ´ev´enements de bas niveau d’abstraction comme des paquets r´eseau, des motifs dans des fichiers logs, etc. Or, le but de l’analyse d’intrusions est la d´etection d’´ev´enements de haut niveau d’abstraction comme le fait de d´eterminer si une machine est compromise ou si elle est utilis´ee pour menacer d’autres machines. La notion d’incertitude apparaˆıt dans ce contexte pour qualifier les observations.

Les observations de bas niveau peuvent r´ev´eler des actions l´egitimes qui ne sont pas toujours des tentatives malveillantes. De ce fait, le d´efi bas´e sur l’incertitude est de pouvoir d´evelopper un mod`ele qui relit de multiples observations de bas niveau `a des conditions de haut niveau. Cela permet de sp´ecifier le niveau de confiance dans les affirmations.

Par exemple, la d´etection d’un trafic sur le r´eseau (observation de bas niveau) peut r´ev´eler une activit´e de l’attaquant sur le r´eseau (condition de haut niveau). De mˆeme, la d´etection d’un code malicieux en m´emoire du syst`eme (observation de bas niveau) peut indiquer qu’il est susceptible que la machine soit compromise par un attaquant (condition de haut niveau). Toutes ces affirmations sont associ´ees `a des degr´es d’incertitude vari´es. Le mod`ele de rai-sonnement empirique d´evelopp´e dans (42) est pr´esent´e dans ce qui suit. La correspondance d’observation trace la carte de l’observation bas niveau vers les conditions haut niveau ; le mod`ele interne capture les relations entre ces conditions de haut niveau pour alimenter le processus de raisonnement ; et les modes capturent le degr´e d’incertitude. Chacune de ces notions est d´etaill´ee dans ce qui suit.

La table 2.1 montre que le mod`ele de raisonnement utilise trois modes, p (possible), l (sus-ceptible) et c (certain), pour exprimer diff´erents niveaux de confiance : faible, moyen et haut. Ces niveaux d’incertitude sont affect´es par l’homme. L’ordre entre ces niveaux parait ´evident (p < l < c) et il n’y a pas de fourchettes de probabilit´e attribu´ees `a chaque niveau.

Table 2.1 – Modes d’incertitude.

Niveau de confiance Mode

Faible Possible : p

Moyen Susceptible : l

Haut Certain : c

Avec cette notion qualitative d’incertitude, les deux types d’assertions logiques sont introduits dans ce mod`ele de raisonnement : la correspondance d’observation et le mod`ele interne (appel´e aussi conditions internes). Obs(O) est utilis´e pour exprimer une observation O et int(F) pour indiquer une condition interne F.

A1 : obs(anormalyHighT raf ic)

p

−→ int(attackerN etActivity)

A2 : obs(netf lowBlackListF ilter(H, BlackListedIP ))−→ int(attackerN etActivity)l

A3 : obs(netf lowBlackListF ilter(H, BlackListedIP ))−→ int(compromised(H))l

A4 : obs(memoryDumpM aliciousCode(H)) l −→ int(compromised(H)) A5 : obs(memoryDumpIRCSocket(H1, H2)) l −→ int(exchangeCtlM essage(H₁, H2))

Figure 2.3 – Correspondance d’observation.

Par exemple, obs(memoryDumpMaliciousCode(ip)) est une observation dans la m´emoire de la machine ip d’un code susceptiblement malicieux alors que int(compromised(ip)) est une condition interne qui d´esigne que la machine ip est compromise.

Correspondance d’observation La figure 2.3 pr´esente la correspondance d’observation ainsi que les modes d’incertitude associ´es.

Dans A1, un trafic r´eseau anormal obs(anomalyHighTraffic) est mapp´e `a int(attackerNetActivity),

c’est-`a-dire qu’un attaquant est en train d’ex´ecuter une activit´e sur le r´eseau. Il s’agit d’un jugement de faible confiance, car un trafic anormal dans le r´eseau n’indique pas forc´ement une activit´e malveillante. Il peut ˆetre le r´esultat d’op´eration de t´el´echargement de vid´eos par exemple qui est une activit´e l´egale. C’est pour cette raison qu’on associe le mode p `a cette observation. Le mode p indique qu’il y a d’autres interpr´etations possibles pour la mˆeme observation.

A2 et A3 identifient une alerte `a travers l’analyse du flux net et la communication avec des

adresses IP malicieuses connues. Ces activit´es sont une indication d’une activit´e de l’attaquant et des machines compromises. Le mode attribu´e `a A2et A3est l car il reste d’autres possibilit´es

qui peuvent ˆetre l´egales. Dans A4, `a partir de l’analyse de la m´emoire de la machine H, on

A5 identifie une communication entre les machines H1 et H2. Ainsi, il existe un transfert

de donn´ees entre les deux machines ce qui m`ene `a dire que la machine H1 est utilis´ee pour

menacer la machine H2.

Ces affirmations de correspondances d’observation sont subjectives. Quantifier les r´esultats de d´etection d’intrusions d’une mani`ere solide reste un probl`eme difficile pour diverses raisons et il n’est pas ´evident d’avoir une classification objective de tous les ´ev´enements. Le but de cette approche est de concevoir un mod`ele flexible et l´eger dans lequel un administrateur syst`eme peut se nourrir dans ses croyances de certitude et de voir quelles cons´equences surviennent. Par exemple, l’administrateur syst`eme peut penser que le mode de A4 ou de A5 est c ce qui

est acceptable. Un avantage de cette logique est de faciliter le partage des connaissances de s´ecurit´e.

Mod`ele interne Le mod`ele de raisonnement doit exprimer les relations logiques entre les conditions de haut niveau. Ainsi, chaque connaissance est mapp´ee pour la corr´elation d’´ev´ e-nements de bas niveau.

I1f : int(compromised(H1)) f,p −→ int(probeOtherM achine(H₁, H2)) I1b : int(probeOtherM achine(H1, H2)) b,c −→ int(compromised(H₁)) I2f : int(compromised(H1)) f,p −→ int(sendExploit(H₁, H2)) I2b : int(sendExploit(H1, H2)) b,c −→ int(compromised(H₁)) I3f : int(sendExploit(H1, H2)) f,l −→ int(compromised(H₂)) I3b : int(compromised(H2)) b,p −→ int(sendExploit(H1, H2)) I4f : int(compromised(H1)), int(compromised(H2)) f,p −→ int(exchangeCtlM essage(H1, H2)) I4b1 : int(exchangeCtlM essage(H1, H2)) b,c −→ int(compromised(H1)) I4b2 : int(exchangeCtlM essage(H1, H2)) b,c −→ int(compromised(H2))

Figure 2.4 – Mod`ele interne.

Pour la repr´esentation des conditions internes dans ce mod`ele, on utilise l’op´erateur Cl m1m2

−→ C_r qui veut dire que la condition `a gauche de l’op´erateur Cl entraine celle de droite, Cr. Comme r´esultat, Cr doit avoir lieu apr`es celle `a gauche. On doit respecter l’ordre chronologique dans l’occurrence des conditions dans ce type de relations. Il y a deux modes m1 et m2 qui sont

associ´es `a la r`egle. Comme dans la correspondance d’observation, m1 sp´ecifie le niveau de

confiance et prend comme valeur p, l ou c, le mode m2 exprime la direction de l’inf´erence et

il peut ˆetre f (en avant) ou b (en arri`ere).