Les sondes de détection d’intrusion constituent le complément du firewall. Elles permettent d’analyser les actions ou les flux pour y détecter une tentative d’intrusion. Ces sondes remontent un certain nombre d’alertes de sécurité. Compte tenu de la multiplication des offres, la mise en place de sondes de détection d’intrusion s’accompagne souvent de la mise en place d’hyperviseurs de sécurité, véritables nœuds focaux de remontée de l’information.
Pour classer les systèmes de détection d'intrusions, on peut se baser sur plusieurs variables. La principale différence retenue est l'approche utilisée, qui peut être soit comportementale, soit par scénarios.
Dans les traces d'audit, on peut chercher deux choses différentes. La première correspond à l'approche comportementale, c'est-à-dire qu'on va chercher à savoir si un utilisateur a eu un comportement déviant par rapport à ses habitudes. Ceci signifierait qu'il essaye d'effectuer des opérations qu'il n'a pas l'habitude de faire. On peut en déduire, soit que c'est quelqu'un d'autre qui a pris sa place, soit que lui même essaye d'attaquer le système en abusant de ses droits. Dans les deux cas, il y a intrusion.
La deuxième chose que l'on peut chercher dans les traces d'audit est une signature d'attaque. Cela correspond à l'approche par scénarios. Les attaques connues sont répertoriées et les actions indispensables de cette attaque forment sa signature. On compare ensuite les actions effectuées sur le système avec ces signatures d'attaques. Si on retrouve une signature d'attaque dans les actions d'un utilisateur, on peut en déduire qu'il tente d'attaquer le système par cette méthode.
Plusieurs méthodes différentes peuvent être mises en oeuvre pour détecter le comportement déviant d'un individu par rapport à un comportement antérieur considéré comme normal par le système. La méthode statistique se base sur un profil du comportement normal de l'utilisateur au vu de plusieurs variables aléatoires. Lors de l'analyse, on calcule un taux de déviation entre le comportement courant et le comportement passé. Si ce taux dépasse un certain seuil, le système déclare qu'il est attaqué. Les systèmes experts, eux, visent à représenter le profil d'un individu par une base de règles créée en fonction de ses précédentes activités et recherchent un comportement déviant par rapport à ces règles. Une autre méthode consiste à prédire la prochaine commande de l'utilisateur avec une certaine probabilité. Les IDS utilisent la technique dite « des réseaux de neurones » pour apprendre les comportements normaux des utilisateurs ou encore l'utilisation de la méthode dîte "d'immunologie" se basant sur le comportement normal du système et non des utilisateurs.
De même que pour l'approche comportementale, plusieurs méthodes peuvent être utilisées pour gérer les signatures d'attaques. Les systèmes experts les représentent sous forme de règles. La méthode dite du « Pattern Matching » (reconnaissance de forme) représente les signatures d'attaques comme des suites de lettres d'un alphabet, chaque lettre correspondant à un évènement. Les algorithmes génétiques sont également utilisés pour analyser efficacement les traces d'audit. Les signatures d'attaques peuvent être également vues comme une séquence de changements d'états du système. La simple analyse de séquences de commandes a été rapidement abandonnée car elle ne permettait pas la détection d'attaques complexes. Pour l'approche par scénarios, le poids donné à chaque entité (audit, base de signatures d'attaques et mécanisme d'analyse) et la façon dont elles sont mises en relation est décisif pour obtenir un système de détection efficace.
Chacune des deux approches a ses avantages et ses inconvénients, et les systèmes de détection d'intrusions implémentent généralement ces deux aspects. Avec l'approche comportementale, on a la possibilité de détecter une intrusion par une attaque inconnue jusqu'alors. Par contre, le choix des paramètres est délicat, ce système de mesures n'est pas prouvé exact, et on obtient beaucoup de faux positifs, c'est-à-dire que le système croit être attaqué alors qu'il ne l'est pas. Qui plus est, un utilisateur peut apprendre à la machine le comportement qu'il souhaite, notamment un comportement totalement anarchique ou encore changer lentement de comportement. Avec l'approche par scénarios, on peut prendre en compte les comportements exacts des attaquants potentiels. Les inconvénients sont dans la base de règles qui doit être bien construite et les performances qui sont limitées par l'esprit humain qui les a conçues.
Il est important de noter que l'approche par scénarios ne permet pas de détecter une attaque inconnue jusque là.
Si la classification la plus utilisée est celle de l'approche comportementale et de l'approche par scénarios, il est possible de classer les systèmes de détection d'intrusions en fonction d'autres paramètres. On peut classer les systèmes en fonction de la réponse qu'il apporte à l'intrusion qu'ils ont détectée. Certains systèmes se contentent d'émettre une alarme à l'administrateur (réponse passive) tandis que d'autres essayent de contrer l'attaque en cours (réponse active). Il y a pour l'instant deux principaux mécanismes de réponse implémentés : les alarmes qui permettent de prévenir rapidement l'administrateur et le filtrage des paquets venant de l'attaquant.
Les systèmes peuvent également être classés en fonction de la provenance de leurs données d'audit, selon qu'elles viennent du système, des applications ou des paquets du réseau. Certains systèmes surveillent en permanence le système d'informations tandis que d'autres se contentent d'une analyse périodique.
On peut également envisager de se baser sur d'autres paramètres comme le délai de détection, c'est-à-dire si le système détecte les intrusions en temps réel ou non, sa capacité de traiter les données de façon distribuée, sa capacité à répondre aux attaques sur lui-même ou encore son degré d'interopérabilité avec d'autres systèmes de détection d'intrusions.
Le premier système de détection d'intrusions a été proposé en 1980 par James ANDERSON. Il en existe maintenant beaucoup d'autres, commerciaux ou non. La majorité de ses systèmes se basent sur les deux approches, comportementale et par scénarios.
Stefan AXELSSON donne un modèle d'architecture de base pour un système de détection d'intrusions. Du système surveillé, un module s'occupe de la collecte d'informations d'audit, ces données étant stockées quelque part. Le module de traitement des données interagit avec ces données de l'audit et les données en cours de traitement, ainsi qu'avec les données de référence (signatures, profils) et de configuration entrées par l'administrateur du système de sécurité. En cas de détection, le module de traitement remonte une alarme vers l'administrateur du système de sécurité ou vers un module. Une réponse sera ensuite apportée sur le système surveillé par l'entité alertée.
Les imperfections de ce type de systèmes monolithiques et même des systèmes de détection d'intrusions en général sont à prendre en compte. Un certain nombre de techniques ont été développées pour les systèmes de détection d'intrusions. La plupart analysent des évènements au niveau local et se contentent de remonter une alarme sans agir. Ils détectent de plus les activités dangereuses d'un utilisateur sans se préoccuper du code dangereux.
Dans la plupart des cas, les systèmes de détection d'intrusions sont faits d'un seul bloc ou module qui se charge de toute l'analyse. Ce système monolithique demande qu'on lui fournisse beaucoup de données d'audit, ce qui utilise beaucoup de ressources de la machine surveillée. L'aspect monolithique pose également des problèmes de mises à jour et constitue un point d'attaque unique pour ceux qui veulent s'introduire dans le système d'informations.
D'autres imperfections plus générales sont relevables dans les systèmes de détection d'intrusions actuels :
- même en implémentant les deux types d'approches, certaines attaques sont indécelables et les systèmes de détection sont eux-mêmes attaquables. Les approches comportementales et par scénarios ont elles-mêmes leurs limites ;
- les groupes de travail sur ce sujet sont relativement fermés et il n'y a pas de méthodologie générique de construction. Aucun standard n'a pour l'instant vu le jour dans ce domaine.
- les mises à jour de profils, de signatures d'attaques ou de façon de spécifier des règles sont généralement difficiles. De plus, les systèmes de détection d'intrusions demandent de plus en plus de compétences d’administration.
- les systèmes de détection sont généralement écrits pour un seul environnement et ne s'adaptent pas au système surveillé alors que les systèmes d'informations sont, la plupart du temps, hétérogènes et utilisés de plusieurs façons différentes.
- Aucune donnée n'a été pour l'instant publiée pour quantifier la performance d'un système de détection d'intrusions. De plus, pour tester ces systèmes, les attaques sont de plus en plus difficiles à simuler.
Il est important de noter qu’un système de détection d'intrusions vise à augmenter la fiabilité d'un réseau et en devient donc un composant critique. Un système de détection d'intrusions, quelque soit son architecture, doit répondre aux contraintes suivantes :
- être capable de fonctionner en permanence sans superviseur humain ;
- être tolérant aux fautes et résister aux attaques ;
- utiliser un minimum de ressources du système surveillé ;
- détecter les déviations par rapport à un comportement normal ;
- être facilement adaptable à un réseau spécifique ;
- s'adapter aux changements avec le temps ;
- être difficile à tromper.
Les conditions à appliquer aux systèmes de détection d'intrusions peuvent être classées en deux parties :
- les conditions fonctionnelles, c'est-à-dire ce que le système de détection se doit de faire ;
- les conditions de performances, c'est-à-dire comment il se doit de le faire.
Un système de détection d'intrusions se doit de présenter les caractéristiques suivantes :
- être en mesure d’effectuer une surveillance permanente et d'émettre une alarme en cas de détection ;
- fournir suffisamment d'informations pour réparer le système et déterminer l'étendu des dommages et la responsabilité de l'intrus.
- être modulable et configurable pour s'adapter aux plates-formes et aux architectures réseaux.
- être en mesure d’assurer sa propre défense, comme supporter que tout ou partie du système soit hors service.
- avoir un faible taux de faux positifs.
- être en mesure de tirer les leçons de son expérience et être fréquemment mis à jour avec de nouvelles signatures d'attaques.
- être en mesure de gérer les informations apportées par chacune des différentes machines et discuter avec chacune d'entre elles.
- être capable d'apporter une réponse automatique en cas d’attaques, même coordonnées ou distribuées.
- être en mesure de travailler avec d'autres outils, et notamment ceux de diagnostic de sécurité du système.
- être en mesure de retrouver les premiers évènements de corruption pour réparer correctement le système d'informations.
- ne pas créer de vulnérabilités supplémentaires.
- surveiller l'administrateur système.