Vous êtes sur la page 1sur 16

Les systmes de dtection d'intrusions :

principes algorithmiques
Jacob Zimmermann et Ludovic M
Suplec, quipe SSIR
http://www.supelec-rennes.fr/rennes/si/equipe/lme/
jacob.zimmermann|ludovic.me@supelec.fr
1 Introduction
Les mthodes de dtection d'intrusions utilises l'heure actuelle reposent essentiellement sur
l'observation d'vnements et leur analyse. La collecte d'informations constitue donc la premire
tape dans tout systme de dtection d'intrusions. Il s'agit d'une part des informations fournies par le
journal systme, les journaux propres certaines applications (serveur de courrier lectronique,
etc.), mais aussi de donnes provenant de sondes installes par les outils de dtection eux-
mmes, comme des sniffers rseau ou des modules applicatifs spcifiques, permettant
d'observer l'utilisation de l'application (URL des documents lus par l'intermdiaire d'un serveur
web, etc.), des modules systme permettant de signaler l'excution de certaines oprations
particulires (modification des droits d'accs certains fichiers, etc.).
Le rle des outils de dtection d'intrusions consiste alors exploiter cette masse d'informations,
appele audit, de manire y dtecter des vnements signalant potentiellement une intrusion.
Deux approches ont t proposes ce jour dans ce but [1, 8] : l'approche comportementale
(anomaly detection) et l'approche par scnario (misuse detection ou knowledge based detection). La
premire se base sur l'hypothse que lon peut dfinir un comportement normal de l'utilisateur et
que toute dviation par rapport celui-ci est potentiellement suspecte. La seconde s'appuie sur la
connaissance des techniques employes par les attaquants : on en tire des scnarii d'attaque et on
recherche dans les traces d'audit leur ventuelle survenue.
Dans la suite de cet article, nous prsentons ces deux approches en citant les avantages et
inconvnients de chacune. Nous terminons par la prsentation dune approche alternative, qui tente
de contourner les problmes des deux approches classiques et dont le but est de dtecter des
violations de politiques de scurit.
2 Approche comportementale
La dtection d'anomalies consiste dfinir, dans une premire phase, un certain comportement
du systme, des utilisateurs, des applications, etc. considr comme normal ; dans une seconde
phase, on observe l'entit ainsi modlise et tout cart par rapport au comportement de rfrence est
signal comme tant suspect [2, 10].
Cette approche recouvre en fait deux problmes distincts : la dfinition du comportement
normal (souvent appel profil) d'une part, la spcification des critres permettant d'valuer le
comportement observ par rapport ce profil d'autre part.
Le principal investissement lors de la mise en uvre d'un dtecteur d'anomalies est la
construction du profil. Cette tape est dlicate, car le profil doit reflter la fois une certaine
politique de scurit (par exemple, il ne doit pas tre possible de dclencher un reboot du systme
via une simple requte HTTP), le fonctionnement naturel des applicatifs exploits (par exemple, un
serveur HTTP met destination d'un client distant si et seulement s'il reoit une requte de sa part)
et les habitudes ventuellement trs disparates des utilisateurs (par exemple, dans une entreprise
zro papier, un ingnieur commercial accdera trs rgulirement aux pages HTML contenant les
descriptions techniques des produits, mais probablement jamais au contrat pass avec la socit de
restauration.). Le profil peut donc contenir des rgles impratives imposes par l'administrateur
et/ou des rgles empiriques, apprises en cours de fonctionnement.
La mise en service d'un dtecteur d'anomalies est donc prcde d'une phase d'apprentissage au
cours de laquelle le profil, initialement construit uniquement partir d'une politique de scurit,
volue, afin que toute utilisation juge normale soit reconnue comme telle. Dans certains cas, cet
apprentissage continue galement aprs la mise en service : le profil volue constamment afin de
suivre au mieux l'utilisation relle du systme.
Les diffrentes approches de dtection d'anomalies se distinguent essentiellement par le choix
des entits modlises dans le profil et l'interprtation qui est faite des divergences par rapport ce
profil. Nous prsentons ici trois cas typiques : la dtection probabiliste, la dtection statistique et la
dtection par rseaux de neurones.
2.1 Approche probabiliste
Cette forme de dtection d'anomalies se montre la fois simple et efficace. Le profil correspond
une dfinition du fonctionnement-type de chaque application. tant donne une suite
d'vnements, il spcifie la probabilit de chaque vnement susceptible de se produire par la suite.
Par exemple, si un serveur HTTP excute la squence suivante :
1.connexion d'un client sur le port 80
2.rception d'une requte HTTP GET
Le profil de ce serveur peut indiquer que dans ce cas, le prochain vnement sera :
- lecture du fichier dont le nom apparat dans l'URL (probabilit 60%)
- excution du script dont le nom apparat dans l'URL (probabilit 30%)
- renvoi d'un message d'erreur HTTP 404 (probabilit 10%)
En revanche, le profil peut exiger que l'vnement rception d'une requte HTTP GET
/etc/shadow soit toujours suivi par l'vnement renvoi du message d'erreur HTTP 401 avec une
probabilit de 100%.
Ce profil constitue par dfinition la rfrence laquelle tout comportement observ doit tre
conforme pour ne pas tre considr suspect. La dfinition prcise d'une anomalie est
videmment variable en fonction des implmentations et des buts poursuivis :
- apparition d'un vnement non prvu par le profil, par exemple rception de HTTP GET suivi
de shutdown,
- apparition trop frquente d'un vnement de trs basse probabilit,
- non-apparition d'un vnement attendu,
- etc.
La construction du profil est trs simple partir de comportements observs, de mme que son
volution dynamique. Si, aprs une squence A-B-C, le profil accorde l'vnement D une
probabilit de 8% tandis qu'il se produit en pratique dans 10% des cas, le systme pourrait lever une
alerte pour signaler une violation du profil, donc une attaque potentielle. Cependant, vu le faible
cart entre la probabilit attendue et la frquence observe, il ne s'agit quasi-certainement pas d'une
intrusion, notamment si ce chiffre est stable au cours d'une longue priode. Deux ractions sont
alors possibles : laisser le systme lever les alertes ou modifier le profil et porter la probabilit
normale 10%, afin de mieux correspondre au fonctionnement rel [9].
La seconde solution rduit le taux de faux positifs (fausses alertes en labsence dattaque),
amliorant par l -mme thoriquement la qualit du dtecteur, mais elle prsente galement un
risque. Supposons par exemple qu'un attaquant cherche excuter la squence A-B-C-D de manire
trs intensive, par exemple avec une frquence de 80%. Si le profil, mme aprs modification de la
probabilit de D 10%, l'en empche, l'attaquant peut toutefois chercher atteindre
progressivement ce rgime : il pourra excuter A-B-C-D en ne dpassant que trs lgrement la
frquence autorise par le profil de manire obtenir la modification de celui-ci et ainsi de suite,
jusqu' atteindre un profil dans lequel l'excution de A-B-C-D dans 80% des cas paraisse normale.
Pour cette raison, il est ncessaire d'observer galement l'volution du profil dans le temps,
l'volution constante et rgulire de certaines rgles est le symptme de telles tentatives de
dformation du profil.
2.2 Approche statistique
Par dfinition, l'approche probabiliste repose sur des rgles explicites dfinissant le profil.
Cependant, de telles rgles ne permettent pas toujours de spcifier entirement la politique
souhaite ou d'en dceler des violations. Les attaques pouvant djouer un dtecteur probabiliste
incluent, entre autres, des dnis de service, l'exploitation de canaux cachs, l'installation de chevaux
de Troie non connus du profil, etc.
De telles attaques peuvent cependant tre prises en compte, du moins en partie, par une
approche statistique, plus exhaustive. Dans ce cas, le profil consiste en une mesure quantitative de
l'utilisation de ressources systme dans le cadre d'un fonctionnement normal. Cela inclut :
l'occupation mmoire, le taux d'utilisation des processeurs, la frquence et la localisation des accs
disque, l'intensit du trafic rseau, la frquence d'accs des services critiques du systme
(notamment l'authentification, le contrle d'accs ou le contrle de processus), etc.
Dans certains cas, le profil prend galement en compte la variation de ces mesures au cours du
temps : par exemple, un site Web d'actualits sera fortement sollicit dans la matine ainsi que le
soir, peu durant la journe et trs peu durant la nuit.
En cours de fonctionnement, les mesures observes doivent rester proches des valeurs de
refrence imposes par le profil. Dans cet exemple, un trafic rseau anormalement faible en matine
signale trs probablement une panne ou une attaque du type dni de service. De mme, une srie
trs intense de tentatives d'authentification est un symptme typique d'une recherche de mot de
passe.
La construction du profil repose essentiellement sur la mesure de ces valeurs lors de la priode
d'apprentissage. Celle-ci doit se faire en environnement contrl et sr afin d'exclure (autant que
possible) toute tentative d'attaque ce moment, qui pourrait biaiser le profil. Une fois mis en
service, le dtecteur force en ralit une utilisation du systme identique celle des conditions de
l'apprentissage. L encore, le profil peut voluer dynamiquement au cours du fonctionnement, en
l'ajustant progressivement en fonction des valeurs moyennes rellement observes. De mme que
dans le cas de la dtection probabiliste, une analyse de l'volution du profil est ncessaire.
2.3 Rseaux de neurones
Une troisime technique vise plus particulirement contrler le comportement des utilisateurs
du systme. L'objectif est de protger le systme des attaques dont ils pourraient tre les auteurs,
mais surtout de vrifier leur identit tout au long de la session. Cette approche convient donc
particulirement pour dtecter des chevaux de Troie et des attaques visant djouer
l'authentification ou des dtournements d'identit.
Le principe repose sur le fait que chaque utilisateur peut tre identifi son comportement : ses
activits, ses outils prfrs, ses habitudes de travail, mais aussi d'autres paramtres tels que la
vitesse de sa frappe au clavier, sa prfrence vis--vis de l'interface graphique ou des commandes
texte, etc. Le profil associ chaque utilisateur reflte donc ces informations dans le cadre d'une
utilisation normale, c'est--dire lgitime.
Il est possible de reprsenter efficacement ce profil par un rseau de neurones, conu pour
reconnatre des suites d'oprations caractristiques de l'utilisateur. Le rseau enregistre les
oprations de l'utilisateur durant une fentre temporelle donne, puis tente de prdire la prochaine
opration. Un chec de prdiction correspond ainsi une dviation par rapport au profil et donne
potentiellement lieu une alerte.
La fentre temporelle peut effectivement tre dfinie en temps rel (par exemple, prdire la
prochaine opration en fonction des actions de l'utilisateur au cours des 5 dernires secondes), mais
plus souvent, elle correspond en fait un certain nombre d'oprations (le rseau tente de prdire la
prochaine opration en fonction des 5 dernires). Le choix de la taille de la fentre est une
importante variable d'ajustement : une fentre plus courte limite dans les faits le champ d'action de
l'utilisateur, en limitant considrablement ses comportements possibles, ce qui tend gnrer de
frquents faux-positifs. En revanche, une fentre longue conduit automatiquement un dtecteur
moins ractif, laissant ainsi la possibilit un attaquant potentiel de "noyer" des oprations
malignes dans des sries d'actions d'apparence lgitime.
La dtection par rseaux de neurones a t largement dveloppe et teste dans les annes 80 et
90 [4], mais la plupart des projets se sont solds par des checs. Nanmoins, cette mthode fait
actuellement l'objet de nouvelles recherches, avec quelques rsultats prometteurs : par exemple, un
systme fond sur un tel rseau de neurones dtecte, selon ses auteurs, les anomalie avec un taux de
succs de 96% et un taux de faux-positifs de 7% [6]. Bien que ces valeurs correspondent aux
conditions exprimentales et non une mise en production relle, ils tmoignent d'un potentiel
certain de la mthode. Cependant, la mise en uvre reste dlicate : la construction initiale du rseau
neuronal et le choix de la taille de la fentre exigent un grand nombre de tests dans des conditions
d'exploitation relle, de mme que la longue phase d'apprentissage du rseau. En plus de cet
important investissement, l'approche prsente le risque supplmentaire qu'un utilisateur ayant des
intentions malignes long terme prsente volontairement un comportement biais au cours de ces
tapes prliminaires de manire influencer la topologie finale du rseau de neurones et gnrer un
profil sa convenance.
2.4 Conclusion sur l'approche comportementale
De manire gnrale, cette approche prsente plusieurs avantages. Le profil spcifie le
comportement normal, en revanche, il ne fait pas d'hypothse sur les anomalies qui le violent :
autrement dit, en signalant toute dviation par rapport au profil, il est possible de dtecter a priori
toute attaque qui viole ce profil, mme dans le cas o cette attaque n'tait pas connue au moment de
la construction du profil. Cette capacit dtecter de nouvelles attaques constitue la principale
force de la dtection d'anomalies.
En outre, une fois un profil au point, le systme ne ncessite qu'une maintenance minimale, si
l'on considre a priori que l'volution de l'usage normal, c'est--dire lgal, reste faible.
Cependant, l'approche comportementale souffre de quelques dfauts intrinsques :
- les donnes utilises en apprentissage doivent tre exemptes d'attaques,
- en cas de modifications subites de l'environnement de l'entit modlise, cette entit changera
sans doute brutalement de comportement. Des alarmes seront donc leves. Pour autant, ce n'est
peut-tre qu'une raction normale la modification de l'environnement,
- enfin, un utilisateur malicieux peut habituer le systme (soit pendant la phase d'apprentissage,
soit en exploitation si l'apprentissage est continu) des actions malveillantes, qui ne donneront
donc plus lieu des alertes.
3 Approche par scnario
Le problme de la dtection d'intrusions est galement couramment approch d'une faon
radicalement diffrente, en visant dtecter des signes de scnarii d'attaques connues. Le principe
commun toutes les techniques de cette classe consiste utiliser une base de donnes, contenant
des spcifications de scnarii d'attaques (on parle de signatures d'attaque et de base de signatures).
Le dtecteur d'intrusions confronte le comportement observ du systme cette base et lve une
alerte si ce comportement correspond l'une des signatures.
Nous prsentons dans la suite deux techniques qui rpondent cet objectif: le pattern matching
et la dtection par infrence.
3.1 Pattern matching
Le pattern matching est la forme la plus simple de dtection de signatures. Dans ce cas, les
suites d'oprations enregistres dans l'audit sont considres comme un langage, dont la base de
signatures constitue un sous-ensemble dfini par un ensemble de patterns. La dtection d'intrusions
s'apparente ds lors au problme classique de reconnaissance de langage ; le cur du dtecteur
d'intrusions implmente un certain modle de reconnaissance de langage (machine de Turing,
automate tats, rseau de Petri, etc.) dont dpend directement la classe des attaques susceptibles
d'tre dtectes [11].
Cependant, un modle de dtection dans lequel les transitions dtats correspondraient
directement aux oprations effectues et consignes dans l'audit aboutirait immdiatement une
explosion combinatoire, tant donn le nombre astronomique des tats possibles d'un systme
informatique, mme de taille modeste. Pour cette raison, les transitions sont munies de gardes : il
s'agit de fonctions boolennes de l'tat du systme qui permettent la fois de simplifier la
spcification des patterns et rduire dramatiquement l'espace d'exploration du dtecteur.
Considrons par exemple une vulnrabilit bien connue des systmes Unix : l'excution d'un
interprteur de commandes muni du bit suid, qui permet un utilisateur malveillant d'acqurir des
droits illgitimes. Le principe de l'attaque peut se rsumer ainsi :
1. l'utilisateur user1 cre une copie de /bin/sh par exemple dans /home/user1/mysh.
2. il trouve un moyen (cheval de Troie, dtournement d'identit, social-engineering, etc.) de donner
cette copie une autre identit user2 et armer son bit suid.
3. il lui suffit dsormais d'excuter /home/user1/mysh pour lancer des oprations illgales.
En utilisant la notation conventionnelle des expressions rgulires et l'aide des gardes, un
pattern dcrivant cette attaque peut s'crire :
cp(/bin/sh,A)
uid(A)=U
.* exec(A)
uid(A)? U ? suid(A)=true
En tant que tel, ce mcanisme de dtection reste trs fiable, le pattern matching tant une
mthode dterministe et exacte. La principale difficult provient en revanche de la construction des
patterns eux-mmes, qui doivent rponde aux critres contradictoires d'tre la fois suffisamment
prcis pour discriminer un grand nombre de cas et viter de gnrer des faux positifs, et rester
suffisamment gnriques pour dtecter diffrentes variantes de la mme attaque.
Dans lexemple trs simple propos ci-dessus, le pattern propos n'met aucune hypothse
quant aux oprations entranant la modification du propritaire de la copie A et du bit suid : ainsi,
toute forme d'attaque aboutissant l'excution d'un shell avec un bit suid arm et appartenant un
autre utilisateur sera dtecte. En revanche, on suppose ici que l'attaquant est l'auteur de la copie A.
S'il ne fait qu'armer le bit suid sans modifier le propritaire de A, l'excution d'un tel shell n'est en
rien illgale pour lui, mais constitue une intrusion pour tout autre utilisateur. Ce cas n'est pas pris en
compte par ce pattern, donnant ainsi lieu un faux ngatif (absence dalerte en prsence dattaque).
3.2 Dtection par infrence
Le pattern matching seul reste une technique rigide et difficile exploiter grande chelle. C'est
pourquoi de nombreux dtecteurs de scnarii le compltent par un algorithme d'infrence
probabiliste, fond sur le principe de l'infrence de Bayes [7]. Dans ce modle, les attaques connues
constituent des hypothses, pouvant expliquer les faits observs. On considre qu'une attaque
donne se traduit par des symptmes, pouvant apparatre sous forme d'vnements dans l'audit,
mais aussi de donnes statistiques comme dans le cas de la dtection d'anomalies (occupation
mmoire, charge CPU, etc.). tant donn un ensemble de symptmes, l'infrence baysienne permet
de calculer la probabilit de chaque scnario d'attaque connu. Lorsqu'un scnario affiche une
probabilit leve, une alerte est leve.
La rgle d'infrence de Bayes peut s'noncer de manire simplifie ainsi :
p(A|S) = p(A)*p(S|A)*a
Dans cette notation, p(X|Y) dsigne la probabilit de X tant donn Y. Ainsi, si S est un
symptme et A une attaque particulire, p(S|A) reprsente la probabilit que l'attaque A fasse
apparatre le symptme S. p(A) est la probabilit gnrale de l'occurrence de l'attaque A. tant
donn que p(A) aussi bien que p(S|A) sont des donnes empiriques, connues et fournies par la base
d'attaques, on peut aisment calculer p(A|S), la probabilit de l'existence de l'attaque A tant donn
le symptme S (a reprsente ici une simple constante de normalisation des probabilits).
Contrairement cet exemple, il est trs rare en pratique que S reprsente directement un
symptme et A une attaque. La vritable signification de ces paramtres est respectivement
l'information courante (c'est--dire une hypothse) et une nouvelle information (un lment
venant confirmer ou dmentir cette hypothse). Un dtecteur d'intrusions infrence baysienne
construit donc rcursivement un arbre de dcision, selon la rgle d'infrence :
p(A
n+1
) = p(A
n
|S
n
)=p(A
n
)*p(S
n
|A
n
)*a
Les donnes de l'algorithme, c'est--dire la base des attaques, contient l'ensemble des hypothses
A
i
, dont certaines dsignent des attaques connues, ainsi que les probabilits p(A
i
) et p(A
i
|S
j
).
L'information initiale, S
0
, correspond un premier symptme observ (par exemple par pattern
matching), permettant d'affecter une certaine probabilit chacune des hypothses possibles.
L'arrive de chaque nouvel lment S
i
modifie ainsi ces probabilits, donnant lieu un nouveau
noeud de l'arbre. Dans le cas d'une intrusion connue, l'algorithme gnrera finalement un noeud
accordant une probabilit leve une certaine hypothse A
q
, qui est dfinie comme tant cette
attaque.
Cette mthode prsente l'avantage de minimiser en principe le risque qu'un attaquant puisse
exploiter sa connaissance de la base des attaques pour passer inaperu. Chaque lment observ
dans l'audit est confront diffrentes hypothses et un scnario d'attaque est dfini comme la
prsence combine d'un ensemble de symptmes et non comme une squence particulire
d'vnements. Llaboration d'un scnario non dtectable ncessite la construction d'une srie
d'oprations ralisant l'attaque voulue, mais dans laquelle rien ne confirme rellement aucune des
hypothses, ce qui est trs difficile dans le cas d'une base d'attaques non-triviale. Seules les attaques
rellement inconnues dans la base ne seront pas dtectes. De plus, si la dtection de vritables
nouvelles attaques est videmment exclue, le principe d'infrence permet nanmoins de dtecter
nombre de variantes d'une attaque donne, y compris de nouvelles variantes, et se montre
performant notamment dans le cas o l'attaquant cherche "noyer" son attaque dans du bruit, en
gnrant un grand nombre d'oprations anodines.
En pratique, l'efficacit de cette approche dpend naturellement principalement de la qualit de
la base d'attaques, c'est--dire : exhaustivit des symptmes dfinis, pertinence des hypothses
formules et ralisme des probabilits associes ces hypothses.
La construction de la base ncessite ainsi la fois un important travail d'expert (formulation des
hypothses) et une tude statistique de cas rels (calcul des probabilits).
3.3 Conclusion sur l'approche par scnario
Contrairement un systme de dtection d'anomalies, ce type de dtecteur d'intrusions ncessite
une maintenance active : puisque par nature il ne peut dtecter que les attaques dont les signatures
sont dans sa base, cette base doit tre rgulirement (sans doute quotidiennement) mise jour en
fonction de la dcouverte de nouvelles attaques. Aucune nouvelle attaque ne peut par dfinition tre
dtecte, ce qui implique un taux plus lev de faux ngatifs. Le problme se pose essentiellement
pour les attaques trs rcentes, dont les signatures n'ont pas encore pu tre incluses dans la base. Il y
a donc un besoin permanent de veille technologique et de maintenance, ce qui engendrent un cot
global d'utilisation lev.
La construction de cette base reprsente ainsi un problme part entire et un systme de
dtection d'intrusions de ce type doit s'accompagner d'outils efficaces de maintenance de la base. A
cette fin, diffrents langages de description d'attaques ont t proposs [AdeLe], poursuivant un
double objectif :
- une grande expressivit : le langage doit permettre de dcrire de manire simple, concise et
prcise un grand nombre d'attaques diffrentes.
- facilit d'implmentation : pour tre utilisable, le langage doit pouvoir tre compil efficacement
pour le systme de dtection d'intrusions utilis.
Malheureusement, aucun langage ne fait pour le moment lunanimit ; aucun langage ne sest
donc impos comme standard de fait, ce qui limite lutilit des signatures dcrites dans un langage
donn, qui ne peuvent tre comprises que par le dtecteur correspondant.
De manire gnrale, les dtecteurs de scnarii se montrent fiables pour signaler les attaques
rfrences dans la base. Thoriquement, leur taux de faux positifs devrait rester trs faible, car par
dfinition une alerte n'est leve que dans le cas o la signature d'une attaque est observer.
Cependant, pour des raisons de performance, les signatures sont souvent trop simples. Peuvent donc
leur correspondent des actions tout a fait lgitimes. Le taux de faux positif reste donc lev avec les
outils existant aujourd'hui.
De plus, une ventuelle connaissance de la base de signatures (particulirement dans le cas des
patterns) permet en principe l'attaquant de construire prcisment un scnario non dtectable.
Cela ne fait que renforcer encore l'exigence de maintenir rgulirement la base.
Ce type de dtecteur reste assez faciles mettre en uvre, ne ncessitant pas de phase
d'apprentissage (ce qui limine le risque de sur-apprentissage ou de dformation volontaire du
profil).
4 Une alternative possible
Une alternative possible aux approches classiques prsentes ci-dessus consiste construire des
systmes de dtection d'intrusions capable de dtecter des violations de politiques de scurit. A la
place d'une base de scnarii d'attaque ou de profils empiriques, on souhaite utiliser une spcification
de politique de scurit, dont le systme devra dtecter automatiquement les violations. La politique
de scurit peut tre dfinie par la liste des actions autorises (toutes les autres actions tant
interdites) ou par la liste des actions interdites (toutes les autres actions tant autorises).
Potentiellement, cette voie prsente un double avantage :
- la politique de scurit est explicitement dfinie, ce qui n'est pas le cas avec les mthodes
classiques. L'adquation de la base de scnarii ou des profils une politique donne est en effet
un problme dlicat et la possibilit d'exprimer directement une politique est l'un des traits les
plus attractifs de ces projets ;
- l'audit observ tant dsormais compar une politique et non une base de scnarii, un tel
systme peut thoriquement dtecter de nouvelles attaques (on ne suppose pas la connaissance
d'un scnario particulier). De mme, la comparaison de l'audit une politique et non un profil
doit rduire considrablement le taux de faux ngatifs engendrs par le systme car un
comportement inhabituel, mais lgitime, ne doit pas tre signal.
Nous prsentons ici, titre dexemple, une approche de dtection dans laquelle la notion de
violation de politique de scurit est exprime sous fourme d'un prdicat logique facilement
vrifiable tant donn un audit [5].
Les approches prsentes aux paragraphes 2 et 3 sont rendues ncessaires par le fait que les
mcanismes de contrle d'accs et d'authentification, implments dans les systmes informatiques
utiliss, ne suffisent pas assurer la confidentialit et l'intgrit requises. Parmi les failles
existantes, on peut noter en particulier :
- la faiblesse des systmes de contrle d'accs (essentiellement du contrle d'accs
discrtionnaire),
- les dfauts de conception (par ex. la transmission de mots de passe en clair),
- les vulnrabilits lies au non-dterminisme de l'excution (race conditions),
- les effets de bord difficilement prvisibles,
- etc.
Ces problmes peuvent thoriquement tre rsolus en utilisant des modles de contrle de flux
d'informations. Cependant, de tels modles ne peuvent pas tre universellement appliqus grande
chelle, car ils supposent soit une connaissance prcise du comportement du systme (ce qui est
exclu en pratique), soit une analyse de trs fine granularit, prenant en compte les oprations
atomiques de chaque programme.
Il est possible de simplifier le problme au moyen de deux hypothses :
1. les proprits d'intgrit et de confidentialit doivent tre assures au niveau de l'accs aux
objets du systme,
2. la politique de scurit consiste en la dfinition des oprations interdites, toute autre action
est par dfinition considre comme tant lgale.
On sintresse aux attaques violant les objectifs d'intgrit et de confidentialit du systme. En
termes de contrle de flux d'informations, ces attaques correspondent des transferts illgaux
d'informations d'un domaine vers un autre. Si, comme dcrit ci-dessus, il n'est pas possible de
mettre en uvre un mcanisme global de contrle de flux d'informations, l'objectif est de contrler
l'accs l'information (c--d l'accs un du objet systme), selon la premire hypothse. Dans ce
cas, une intrusion correspond l'accs un objet ralis dans un contexte dans lequel la capacit
d'effectuer cet accs ne devrait pas exister.
De faon gnrale, l'approche consiste associer des droits particuliers des scnarii d'excution
logique (c'est--dire des squences d'oprations causalement lies) plutt qu' des identits de
sujet, comme dans le cas du contrle d'accs discrtionnaire standard. Les droits dtenus par un
sujet particulier voluent ainsi dynamiquement au cours de l'excution, on considre qu'une
intrusion se produit lorsqu'un ensemble de droits permet d'excuter une opration interdite par la
politique de scurit.
Nous reprsentons la possibilit d'excuter une action atomique particulire sur un objet donn par
une rfrence. Chaque opration requiert ainsi un ensemble de rfrences pour tre autorise. Dans
le cas le plus simple, une rfrence quivaut une capacit systme (nous utilisons ici le terme de
capacit en tant qu'abstraction. Dans un systme rel, la dfinition complte d'un vecteur de
capacits associ un processus est complexe et comprend ses capacits au sens du systme (par
ex. dans la norme POSIX, la possibilit de changer la priorit du processus), son identit et les
permissions associes, les permissions supplmentaires dfinies par des ACLs, l'tat de ses
entres/sorties, etc.). Par exemple une opration close(fd) ncessite une unique rfrence
permettant de fermer fd. D'autres oprations plus complexes ncessitent plusieurs rfrences : par
exemple, read(fd, buffer, size) ncessite une rfrence permettant de lire fd et une
permettant d'crire dans l'objet buffer. De mme, open(/etc/shadow, READ)requiert
videmment une rfrence permettant de lire /etc/shadow en lecture, mais aussi une rfrence
permettant d'accder au rpertoire /etc, une rfrence pour lire son contenu, idem pour le
rpertoire racine et ainsi de suite.
Un ensemble de rfrences dfinit ainsi un vecteur de capacits permettant d'excuter une ou
plusieurs oprations, cependant les rfrences diffrent des capacits traditionnelles car leur
dfinition n'est pas lie l'excution d'un processus mais l'existence d'un objet. Chaque rfrence
correspond un certain objet et elle existe si et seulement cet objet existe. L'ensemble des
rfrences dfinies pour un objet donn constitue l'interface de cet objet.
Les oprations de cration et destruction d'objets impliquent donc la cration et la destruction des
rfrences. Ainsi, l'excution de l'opration fd=open(file.dat, READ) cre l'objet
descripteur d'entre/sortie fd et un ensemble de rfrences sur cet objet, dont une rfrence pour
lire sur ce descripteur et une rfrence pour le fermer. De mme, l'opration close(fd) a pour
effet de dtruire l'objet fd et toutes les rfrences qui s'y rapportent.
Pour chaque objet du systme, la cration et la destruction de l'objet, les accs successifs son tat
et la modification de celui-ci impliquent une relation de dpendence causale entre les oprations
correspondantes. Considrant que toute action du systme peut tre dcrite comme une opration
sur un certain objet, les rfrences existant lors de l'excution d'une opration O1 (et les rfrences
ventuellement cres par celle-ci) existent donc par dfinition lors de l'excution d'une opration
O2 qui suit causalement 01. Autrement dit, chaque opration hrite des rfrences existant ou
produites par l'opration qui la prcde dans l'ordre causal. De cette faon, un ensemble de droits,
c'est--dire le vecteur de capacits dfini par un ensemble de rfrences, reste consistant tout le long
d'une squence d'oprations causalement dpendantes.
Si l'on suppose que l'implmentation du systme informatique est correcte dans le sens o il est
effectivement impossible d'excuter une opration priori interdite, une attaque consistera en une
suite d'oprations dont chacune est lgale considre sparment, mais dont l'effet combin viole la
politique de scurit. Par exemple, une politique stipule que :
- Chaque utilisateur peut changer son mot de passe, ce qui implique la lecture et l'criture de
/etc/shadow,
- Chaque utilisateur dispose d'un accs illimit aux fichiers dont il est le propritaire.
Dans les systmes usuels, l'accs /etc/shadow se fait gnralement par l'intermdiaire de
programmes privilgis, afin de le restreindre aux seuls besoins d'authentification et de changement
de mots de passe. Toutefois, en exploitant par exemple des effets de bord ou des dbordements de
pile, un attaquant peut potentiellement dtourner l'excution de tels programmes afin de copier le
contenu de /etc/shadow dans un fichier personnel. On peut remarquer que dans un tel cas,
l'criture de ce fichier est une consquence causale de la lecture de /etc/shadow et l'attaque
consiste alors en l'effet combin de deux oprations priori lgales.
Dans le but de dtecter ce type d'attaques, chaque rfrence fait partie d'un groupe de rfrences.
Par dfinition, une opration n'est lgale que si toutes les rfrences requises existent dans un mme
groupe. En revanche, une opration rendue possible en utilisant des rfrences appartenant
plusieurs groupes diffrents est illgale. La dfinition des groupes dpend directement de la
politique de scurit, car chaque groupe reprsente un ensemble d'oprations dont la combinaison
ne prsente pas de risque. Dans l'exemple trs simple ci-dessus, un premier groupe contient par
exemple uniquement les rfrences permettant d'excuter la commande passwd, lire sur la console
(pour la saisie du nouveau mot de passe) et modifier le contenu de /etc/shadow. De mme, un
autre groupe autorise l'accs aux fichiers personnels dans le rpertoire /home/user. En revanche,
toute tentative d'aboutir une copie de /etc/shadow dans /home/user impliquera
ncessairement une opration utilisant simultanment des rfrences de ces deux groupes, ce qui est
symptme d'une intrusion.
On le voit, cette approche ne fait aucune hypothse en ce qui concerne le scnario menant une
opration illgale. Une tentative de cumuler illgalement les effets de plusieurs oprations lgales
aboutira une opration utilisant les rfrences de diffrents groupes de rfrences, quelle que soit
la squence prcdente des oprations permettant de constituer ces groupes. De nouvelles attaques
peuvent ainsi tre dtectes. En revanche, ce modle ne peut dtecter que des attaques reposant
effectivement sur un accs illgal aux objets.
Cette approche convient donc pour la dtection des violations de la politique de contrle d'accs
mais n'est pas mme de dtecter des violations d'une vritable politique de contrle de flux
d'informations. Sous cette rserve, le modle est facilement implmentable car il repose uniquement
sur le contrle des oprations systme excutes et fournit un mcanisme de dtection d'intrusions
lors de l'excution.
5 Conclusion
Nous avons prsent dans cet article les principes des algorithmes qui rsident au cur des
systmes de dtection dintrusions. Ces algorithmes suivent lune ou lautre des deux approches
classiques : lapproche comportementale et lapproche par scnario. Nous avons vu que chaque
approche prsente ses avantages et ses inconvnients. Pour contourner ces inconvnients, diverses
voies de recherche sont aujourdhui explores. Parmi celles-ci nous parat entre autres prometteuse
celle qui vise proposer des systmes capables de dtecter automatiquement les violations de la
politique de scurit que lon souhaite mettre en place sur le systme dinformation. Nous avons
donc prsent une telle approche. Dautres voies de recherche nous paraissent galement
intressantes (comme la coopration inter-IDS et la corrlation dalertes), mais ne sont pas
prsentes ici.
6 Rfrences
[1] Aurobindo Sundaram. An intrusion to Intrusion Detection. ACM Crossroads Student Magazine,
http://www.acm.org/crossroads/xrds2-4/intrus.html
[2] Dorothy E. Denning. An intrusion-detection model. IEEE Transactions on Software
Engineering 13(2):222-232, Fvrier 1987.
[3] Calvin Ko & Timothy Redmond. Noninterference and Intrusion Detection. Proccedings of the
IEEE Symposium on Security and Privacy, 2002
[4] H. Debar, M. Becker and D. Siboni. A Neural Network Component for an Intrusion Detection
System. Proceedings of the IEEE Symposium of Research in Computer Security and Privacy. 1992.
[5] Jacob Zimmermann, Ludovic M, Christophe Bidan. Introducing reference flow control for
detecting intrusion symptoms at the OS level. RAID 2002
[6] Jake Ryan, Meng-Jang Lin & Risto Miikkulainen. Intrusion Detection with Neural Networks.
Advances in Neural Information Processing Systems, The MIT Press, 1998
[7] D. Bulatovic, D. Valesevic, A distributed intrusion detection system based on Bayesian alarm
networks. Proceedings of the Secure Networking CQRE[Secure] ' 99 Conference<, Dsseldorf,
Novembre/Dcembre, 1999
[8] H. Debar, M. Dacier, A. Wespi. Towards a taxonomy of intrusion-detection systems. Computer
Networks, No. 31, 1999.
[9] Terran Lane and Carla E. Brodley. Temporal Sequence Learning and Data Reduction for
Anomaly Detection. Proceedings of the Fifth ACM Conference on Computer and Communications
Security, pages 150-158, 1998.
[10] G. E. Liepins and H. S. Vaccaro. Anomaly detection: Purpose and framework. Proceedings of
the 12th National Computer Security Conference, pages 495-504, Octobre 1989.
[11] Sandeep Kumar & Eugene H. Spafford. A Pattern Matching Model for Misuse Intrusion
Detection. Proceedings of the 17th National Computer Security Conference, pages 11-21, 1994

Vous aimerez peut-être aussi