Soutenance mémoire
Enjeux de sécurité des applications distribuées
En tant qu’utilisateur, nous sommes de plus en plus concernés par les applications de stockage et partage de documents, de commerce électronique, de banque en ligne, de jeux en ligne, etc. Via nos ordinateurs, tablettes et smartphones, nous interagissons régulièrement avec des serveurs, des bases de données et des logiciels applicatifs mis à notre disposition. L’essor de l’internet des objets renforce encore notre immersion dans un monde numérique dématérialisé. Les traitements que nous déclenchons ou avec lesquels nous interagissons impliquent une coopération entre des calculateurs distants. Dans ces systèmes distribués parfois large échelle et parfois extrêmement complexes, les problématiques de sécurité ne peuvent pas être négligées. Elles sont désormais prises en compte dès les phases de conception et développement. Mais, malgré tout les efforts de prévention, il est difficile d’assurer que l’exécution d’une application résistera à toute sorte d’actions malveillantes. Des vulnérabilités (identifiées ou pas) au niveau du logiciel ou du matériel peuvent être exploitées par un attaquant. Des applications sensibles telles que le commerce électronique ou les systèmes de fichiers qui s’exécutent désormais sur des systèmes distribués à grande échelle sont donc potentiellement vulnérables. Elles constituent des cibles privilégiées pour les attaquants susceptibles d’utiliser le service à mauvais escient, de voler des informations, de compromettre la disponibilité du service ou l’intégrité des données. Une seconde ligne de défense est nécessaire pour contrer les attaquants qui réussissent (ou sont sur le point de réussir) à corrompre un système d’information. L’objectif est d’identifier qu’une intrusion est en cours (ou vient de réussir) afin de lever une alerte et de permettre aux administrateurs de prendre des contremesures pour protéger le système ou limiter les dommages causés.
La détection d’anomalies comme cadre d’études
L’approche habituelle pour détecter les comportements incorrects dans les systèmes distribués consiste à surveiller chaque processus (ou chaque élément du réseau de communication) avec un système de détection d’intrusion, en anglais : IDS (Intrusion Detection System). Un IDS observe des activités locales et génère des informations sur ce qu’il observe (occurrences d’actions particulières) ou sur ce qu’il interprète comme un comportement localement suspect (alertes bas niveau). Tout ces événements générés localement par les différents IDS sont estampillés grâce à une horloge globale et envoyés à un moteur de corrélation central. Ce moteur ordonne tous les événements en utilisant leurs horodatages et analyse la séquence ainsi obtenue afin de détecter des motifs prédéfinis correspondant à des scénarios d’attaque [LHT18]. Cette approche, qui est connue sous le nom d’approche par scénarios (ou approche par signatures), ne peut détecter que des attaques connues, pour lesquelles une «signature» d’événements a pu être spécifiée. De plus, une horloge globale est nécessaire pour construire l’ordre total sur tous les événements, ce qui peut être impossible notamment dans le cas de grandes applications distribuées.
L’étude réalisée durant cette thèse s’est focalisée sur une approche alternative : la détection d’anomalies. Les systèmes de détection d’intrusion destinés à détecter des anomalies recherchent des écarts par rapport à un modèle de référence du comportement normal ; tout écart est interprété (à tort ou à raison) comme une conséquence observable d’une attaque. Aucune connaissance préalable des attaques possibles n’est requise. Par contre, il est nécessaire d’avoir un modèle permettant d’identifier quels sont les comportements normaux de l’application. A moins de disposer d’une spécification du comportement normal de l’application (ce qui est malheureusement assez rare), il faut inférer cette connaissance durant une phase dite de construction du modèle. Une solution consiste à exécuter l’application à plusieurs reprises dans un environnement sécurisé (sans attaquant) afin de collecter de l’information sur ses différents comportements normaux. La connaissance acquise durant cet apprentissage n’est que partielle puisqu’il est souvent impossible de découvrir l’ensemble des comportements autorisés durant un nombre fini d’exécutions. Le modèle construit identifie des contraintes sur l’enchaînement des événements durant une exécution normale. Son rôle est de permettre d’identifier si une séquence d’événements est valide ou ne l’est pas.
Différentes représentations (sous la forme d’un automate, sous la forme d’une liste d’invariants,…) peuvent être utilisées. Le modèle peut se fonder sur une seule représentation ou au contraire être composé de plusieurs sous-modèles distincts. Il peut refléter fidèlement ce qui a été appris durant l’apprentissage et n’accepter que les comportements appris. Mais, dans ce cas, tout comportement normal non appris est susceptible d’être ensuite rejeté par l’outil de détection car il ne sera pas nécessairement reconnu comme valide par le modèle. Pour éviter cela, des techniques dite de généralisation transforment le modèle (souvent en le réduisant) pour qu’il soit moins restrictif et accepte également des comportements non appris. Une technique de généralisation est donc indispensable pour réduire le nombre de faux positifs (alertes générées sans raison). Mais, parmi les comportements non appris qu’une technique de généralisation permet d’autoriser, certains peuvent être des comportements symptomatiques d’une attaque : une technique de généralisation qui vise à réduire le nombre de faux positif peut donc aussi potentiellement engendrer des faux négatif (une attaque réelle ne sera pas détectée). En matière de modélisation des comportements normaux, il existe donc un vaste panel de solutions possibles et seules quelques unes ont été proposées et évaluées à ce jour.
Une fois construit, le modèle peut être utilisé par le mécanisme de détection d’intrusion. Ce mécanisme est en charge de surveiller l’application qui s’exécute désormais dans un environnement non sécurisé. Durant cette phase dite de détection, les informations collectées sont exploitées pour déterminer si l’exécution est conforme ou pas au modèle de l’application. En cas de divergence, une alerte est levée.
Détection d’intrusion dans les applications distribuées
Les approches de détection d’intrusion
La détection d’intrusion est une problématique de sécurité qui a commencé à faire l’objet de nombreux travaux dans les années 1980 [Den87] avec l’apparition à cette époque de plusieurs prototypes [Sma88, LJ88]. En 1999, Debar [DDW99] propose une taxonomie des systèmes de détection d’intrusion (IDS, Intrusion Detection System) qui est reprise ici pour structurer la rédaction de cette partie. La sécurisation d’un système d’information commence par la définition d’une politique de sécurité des systèmes d’information (PSSI) [ANS04]. Cette dernière constitue le principal document de référence en matière de SSI d’un organisme. Elle a pour objectif d’identifier les différents éléments à protéger (matériel, immatériel, informations relatives aux personnes) à l’aide d’une analyse de risque et de définir les moyens techniques ou organisationnels pour mettre en œuvre cette politique de sécurité. Les systèmes de détection d’intrusion (IDS) visent à identifier des attaques qui sont des violations de la politique de sécurité du système d’information. Un IDS est un mécanisme destiné à identifier des activités suspectes ou anormales. Pour cela, il surveille dynamiquement les actions réalisées sur l’environnement ciblé. Son rôle ne se cantonne pas à observer. Il analyse les informations collectées afin de décider si ces actions relèvent d’une attaque ou si elles correspondent à une utilisation légitime de l’environnement. Un IDS peut être classifié à l’aide de certaines de ses caractéristiques fonctionnelles :
— Le comportement de l’IDS lors de la détection : l’IDS peut soit seulement lever des alertes soit également réagir à celles-ci (IPS, intrusion prevention system) ;
— La méthode de détection utilisée par l’IDS ;
— Les sources de données que l’IDS collecte.
La méthode de détection
La méthode de détection correspond à l’approche choisie par l’IDS pour traiter l’information collectée à propos des actions observées. L’approche choisie peut être soit une approche par signature soit une approche comportementale. Lorsqu’un IDS utilise la connaissance des attaques auxquelles le système est exposé, il utilise une approche par signature. Quand il cherche à identifier les déviations par rapport à un modèle de comportement normal du système, il utilise une approche par comportement. Ces deux approches sont complémentaires. L’approche par signature utilise des connaissances préalablement acquises concernant des attaques spécifiques et des vulnérabilités du système. Dans cette approche, un IDS détient des informations à propos des vulnérabilités du système et essaye d’identifier les tentatives d’exploitation de celles-ci. Quand une de ces tentatives est détectée, une alerte est levée. Autrement dit, toute action non reconnue comme une attaque est considérée comme saine. Ce type d’approche permet d’avoir une vision détaillée des attaques qui ont eu lieu. Cependant, la détection par ce type d’approche ne considère pas la détection d’attaques inconnues. D’autre part, il est nécessaire de collecter des informations sur le fonctionnement du système et de décrire les vulnérabilités de celui-ci.
L’approche comportementale considère qu’une intrusion peut être détectée en observant une déviation du comportement normal. Le modèle de comportement normal est extrait des informations de référence collectées par différents moyens. Ce modèle est ensuite comparé aux activités en cours. Si une déviation est observée, une alerte est générée. Autrement dit, tout ce qui ne correspond pas au modèle préalablement construit est considéré comme une attaque. Un IDS utilisant ce type d’approche va permettre de détecter des attaques nouvelles et non connues sans avoir besoin de mettre régulièrement à jour le modèle. Cependant, dans le cas où le comportement normal du système évolue (à la suite par exemple d’une évolution d’un de ses composants), le modèle doit impérativement être mis à jour puisqu’il fait explicitement référence aux actions normales des différents composants (un appel système, un appel de fonction, l’exécution d’une instruction particulière, …). En l’absence d’information précise sur le système ou l’application, des comportements normaux peuvent être identifiés en observant le déroulement du calcul durant plusieurs exécutions successives. La construction d’un modèle de comportement normal nécessite qu’aucune attaque n’ait lieu pendant cette phase d’apprentissage .
|
Table des matières
1 Introduction
1.1 Enjeux de sécurité des applications distribuées
1.2 La détection d’anomalies comme cadre d’études
1.3 Objectifs de la thèse et contributions
1.4 Organisation du document
2 État de l’art
2.1 Détection d’intrusion dans les applications distribuées
2.1.1 Les approches de détection d’intrusion
2.1.1.1 La méthode de détection
2.1.1.2 Les sources de données
2.1.2 La corrélation d’alertes
2.1.3 Des approches comportementales parfois éloignées
2.2 Quelques notions relatives aux applications distribuées
2.3 Apprentissage d’un modèle de comportement
2.3.1 Contexte
2.3.2 Inférence d’automates
2.3.3 Inférence d’invariants
2.3.3.1 Logique temporelle
2.3.3.2 Simplification des propriétés
2.3.3.3 Inférence automatique de propriétés
2.3.3.4 Inférence de propriétés pour les applications réparties
2.4 Conformité d’un modèle avec les comportements réels
2.4.1 Complétude du modèle
2.4.2 Précision du modèle
2.5 Conclusion
3 Une première approche pour la construction d’un modèle à partir de traces
3.1 Présentation Générale
3.2 Inférence d’un modèle intermédiaire à partir d’une seule trace
3.2.1 Construction du treillis des états globaux cohérents
3.2.2 Inférence d’automates
3.2.3 Inférence d’invariants
3.2.3.1 Evénements minimaux et événements maximaux
3.2.3.2 Nouvelles formulations des classes d’invariants
3.2.3.3 Coordonnées des états du treillis et relation de dépendance causale
3.2.3.4 Calcul des ensembles minimaux et maximaux
3.2.3.5 Inférence des invariants
3.3 Fusion de modèles intermédiaires et généralisation
3.3.1 Fusion d’automates et généralisation
3.3.2 Fusion d’invariants
3.4 Détection
3.5 Conclusion
4 Passage à l’échelle
4.1 Problèmes de passage à l’échelle
4.1.1 La croissance exponentielle du treillis
4.1.2 La généralisation d’automates de grande taille
4.2 Calcul d’un sous ensemble du treillis
4.3 Fusion et généralisation itérative
4.4 Conclusion
5 Évaluation
6 Conclusion
