ACES. Livrable 6.1. Spécifications Détaillées du Gestionnaire de Corrélation

Dimension: px
Commencer à balayer dès la page:

Download "ACES. Livrable 6.1. Spécifications Détaillées du Gestionnaire de Corrélation"

Transcription

1 ACES Livrable 6.1 Spécifications Détaillées du Gestionnaire de Corrélation

2 Résumé L objectif du sous-projet 6 est de réaliser des composants de corrélation d alertes, dont la fonction est d améliorer le diagnostic porté par les alertes émanant de sondes de détection d intrusions. Ce livrable spécifie les mécanismes de corrélation que nous proposons. Leur mise en œuvre est l objet du second livrable de ce sous-projet. Le raisonnement effectué par ces processus de corrélation d alertes s appuie sur les connaissances disponibles concernant 1) le contexte local et global dans lequel les attaques ont lieu, 2) sur les caractéristiques intrinsèques de ces attaques et 3) sur la configuration des sondes qui les détectent. Les mécanismes de collecte des connaissances contextuelles locales et globales sont l objet des sous projets 3 et 4, respectivement ; le sous-projet 5 traite de la configuration des sondes. Le sous projet 2 décrit le modèle M4D4, qui définit formellement l ensemble des concepts et relations qui constitue le domaine des connaissances nécessaires pour raisonner sur les alertes. Le sous-projet 6 décrit pour sa part les mécanismes de raisonnement mis en œuvre pour manipuler ces connaissances afin d améliorer le contenu sémantique des alertes. Il s appuie donc sur le modèle de données M4D4. Ce livrable détaille le fonctionnement interne de certains composants identifiés dans l architecture fonctionnelle des flots de contrôle et de données (livrable du sous-projet 1). Il explicite comment les scénarios d attaques présentés dans ce livrable sont traités par les mécanismes de corrélation.

3 Table des matières 1 Introduction Problématique Corrélation d alertes Contributions Gestionnaire de corrélation Caractéristiques du gestionnaire de corrélation Traitement en ligne vs hors ligne Traitement en série vs parallèle Communication des résultats de la corrélation Spécifications du gestionnaire de corrélation Composants du gestionnaire de corrélation Interface avec M4D Connexion avec Prélude Architecture logique de la plateforme Corrélation mono-événementielle Corrélation avec les vulnérabilités Corrélation avec des rapports de vulnérabilité Corrélation avec des configurations logicielles Reconnaissance de faux positifs Traitement d alertes redondantes Corrélation avec le contexte global Traitements préventifs Corrélation avec des alertes émanant d autres équipements Analyses complémentaires Corrélation multi-événementielle Introduction au langage ADeLe Notion de filtre d événements Opérateurs de corrélation Opérateur Sequence Opérateur NonOrdered Opérateur OneAmong Opérateur Without Opérateur Repeat Corrélation contextuelle Algorithme de corrélation Présentation de GNG Architecture Notions d automate et de plan Traitement des opérateurs de contrainte temporelle Travaux connexes

4 Chapitre 1 Introduction 1.1 Problématique Les outils de détection d intrusions actuels génèrent un volume important d alertes dont le contenu sémantique est souvent pauvre. L excès d alertes provient essentiellement de la présence de fausses alertes ou d alertes non pertinentes (indifféremment désignées faux positifs dans la suite). Selon les études, le taux de faux positifs varie de 40 à 90% du nombre global d alertes. Au problème de faux positifs s ajoutent différents facteurs de multiplication d alertes, parmi lesquels la récurrence et la redondance. Les alertes redondantes proviennent de la détection d un même événement (intrusif ou non) par plusieurs sondes. Le problème de redondance est particulièrement sensible avec les sondes de détection réseau, car il est généralement nécessaire de déployer ce type de sonde sur plusieurs segments du réseau pour obtenir une couverture maximale de détection. En fonction du chemin suivi par les paquets réseau depuis la source d une attaque jusqu à sa cible, plusieurs sondes sont donc susceptibles de détecter une même attaque. Les alertes récurrentes sont souvent aussi des faux positifs. En effet, la probabilité d occurrence de phénomènes normaux (ou bénins) étant largement supérieure à celles des phénomènes réellement intrusifs, si ces phénomènes donnent lieu à des alertes, alors ces alertes sont récurrentes. En tout état de cause, la résolution de l excès global d alertes passe avant tout par l identification des faux positifs. Le problème de sémantique des alertes inclut l évaluation simpliste de la criticité des incidents et la désignation peu explicite des attaques et des protagonistes (victimes et attaquants) par les sondes de détection. Par exemple, la sévérité affichée n est généralement fonction que des dommages potentiels maximaux de la faille exploitée, mais ne prend pas en compte les caractéristiques propres à l attaque et la vulnérabilité de la victime. Enfin, en dépit de l excès d alertes, certaines attaques demeurent non détectées. L amélioration de la complétude de la détection requiert une multiplications de sondes hétérogènes, afin non seulement d accroître la couverture de surveillance, mais aussi de bénéficier de techniques de détections complémentaires ; la multiplication des sondes engendre mécaniquement un accroissement du nombre d alertes, ce qui renforce la nécessité d une analyse complémentaire des alertes en aval de leur production par les sondes de détection d attaques. Le débit d alertes est incompatible avec le temps nécessaire à leur analyse par un exploitant humain. C est pourquoi cette analyse doit être en partie automatisée. 1.2 Corrélation d alertes La corrélation d alertes a pour objectif de faire coopérer les sondes de détection d intrusions, afin d améliorer le taux de détection et de réduire le volume global d alertes, tout en enrichissant leur contenu sémantique. Plusieurs approches de corrélation ont été proposées dans la littérature. Nous ne les énumérons pas dans le présent document, mais nous présentons leur caractéristiques principales. On distingue généralement trois catégories de techniques de corrélation d alertes dans le domaine de la détection d intrusions : 2

5 Corrélation implicite : La corrélation implicite consiste à effectuer des regroupements d alertes sur la base de critères de similarité. L objectif principal de ce type d approche est de synthétiser le volume d information présenté à l opérateur pour lui faciliter la tâche d analyse, en lui permettant de se focaliser sur les incidents prioritaires. Différents termes sont associés à ce type de corrélation, parmi lesquels la fusion, l agrégation ou le clustering d alertes. La fonction prioritaire de ce type d approche n est donc pas tant le diagnostic ou l enrichissement sémantique que la diminution du nombre d alertes. Ces techniques sont néanmoins tout à fait pertinentes. Corrélation explicite : À l instar des méthodes de détection d intrusions par signatures d attaques, la corrélation explicite consiste à confronter le flot d alertes à des scénarios d intrusions spécifiés explicitement (d où leur nom) dans un langage donné. Ces scénarios sont constitués de filtres sur les alertes, liés entre eux par des contraintes logicotemporelles (et, ou, puis, etc.). Lorsque l ensemble des contraintes exprimées dans un scénario sont vérifiées par une séquence d alertes en entrée, une alerte de haut niveau est émise et reliée à l ensemble des alertes ayant participé à l instanciation du scénario. Ces scénarios sont généralement compilés sous la forme d automates à états finis, dont les états correspondent aux étapes du scénario et les transitions sont conditionnées par la correspondance des alertes avec les filtres et le respect des contraintes logico-temporelles. Les scénarios peuvent être utilisés pour reconnaître des phénomènes d attaques impliquant plusieurs alertes et dont le déroulement est déterministe (par exemple la propagation d un ver), ou bien des phénomènes bénins dont l identification requiert plusieurs événements. Ces scénarios peuvent aussi modéliser les différentes étapes d une stratégie d intrusion complexe. Il faut cependant noter que cette dernière utilisation est peu réaliste car l élaboration anticipée des stratégies d attaque sous la forme de scénarios est quasi-impossible du fait du nombre de variantes possibles. Corrélation semi-explicite : La corrélation semi-explicite part du principe que les stratégies d intrusions d un attaquant sont constituées d étapes logiquement liées entre elles et contribuent à l accomplissement d un objectif précis. Ce type de corrélation consiste donc à détecter des correspondances entre les pré-requis (ou pré-conditions d attaques et les conséquences (ou post-conditions) d attaques antérieures. Le résultat de ces techniques de corrélation se présente généralement sous la forme d un graphe d attaque, dont les nœuds sont les attaques référencées dans les alertes et les liens correspondent aux similitudes trouvées entre les pré-conditions et les post-conditions. Si le principe de ce type de corrélation est séduisant, sa mise en pratique est plus problématique. Tout d abord, la corrélation semi-explicite suppose l existance des pré-requis et post-conditions associés à chaque type d attaque, ce qui n est pas le cas actuellement et peu vraisemblable dans l avenir, compte tenu de la difficulté d identifier et de formaliser ces caractéristiques. Ensuite, la corrélation explicite est inadaptée aux flots d alertes rencontrés en environnement opérationel, car la proportion majoritaire de faux positifs conduit ce type d approche à construire des plans inutiles. Enfin, la complexité des mécanismes mis en jeu est incompatible avec le volume d alertes à traiter. D autres approches, difficilement classables, proposent d apporter des solutions pratiques à des problèmes spécifiques des sondes de détection d intrusions. Par exemple, Pietraseck propose de modéliser les phénomènes qui sont réputés pour engendrer des faux positifs dans les réseaux. Les alertes sont alors comparées à ces modèles et en cas de correspondance, la sévérité associée aux alertes est diminuée. Dans la grande majorité des cas, les mécanismes de corrélation proposés dans la littérature partagent une propriété, à savoir l utilisation de données liées au contexte surveillé et des connaissances sur les caractéristiques des attaques. C est pour cette raison que nous avons proposé le modèle M4D4 (c.f. livrables du sous projet 2), qui fédère les informations qui sont nécessaires à la corrélation d alertes. L objectif de ce sous projet est de mettre en œuvre des mécanismes de corrélation qui exploitent les données modélisées. 1.3 Contributions Comme l illustre l état de l art de la corrélation d alertes, la notion de corrélation d alertes recouvre des notions très différentes ; les objectifs poursuivis par les mécanismes de corrélation proposés dans la littérature sont différents, ainsi que les techniques utilisées pour les mettre en œuvre. Pour autant, il est possible de dégager un ensemble de fonctions 3

6 élémentaires partagées par la majorité des mécanismes de corrélation, parmi lesquels la réception, la production, la modification des alertes et l accès aux informations contextuelles. Une première contribution réside dans la conception d une plate-forme générique remplissant ces fonctions élémentaires, sur laquelle des modules de corrélation peuvent se greffer pour effectuer leur traitement. Le gestionnaire de corrélation est cette plate-forme générique, décrit en section 2. Les différents traitements de corrélation sont implémentés sous la forme de processus indépendants. On distingue généralement deux catégories de traitements de corrélation, qualifiés de mono- ou multi-événementiels. En référence au livrable 1.1, les traitements de corrélation mono-événementiels sont notés F 1. Le traitement d un processus F 1 est dit mono-événementiel s il porte sur une seule alerte, indépendamment des alertes reçues antérieurement et ultérieurement. Un module F 1 est donc sans état. Les traitements portent sur le contenu de l alerte et peuvent exploiter des informations externes par interrogation du contexte local et global. Le cas échéant, les informations contextuelles utilisées peuvent être des événements ou alertes présents dans la base de connaissances M4D4. Par exemple, un module F 1 dont l objectif est de déterminer la vulnérabilité d un hôte vis-à-vis d une attaque peut interroger le contexte pour savoir s il existe un rapport de vulnérabilité (qui est un type d événement particulier) relatif à l hôte en question. Les performances attendues des modules F 1 sont élevées. Les traitements multi-événementiels sont notés F n. Un processus de corrélation est qualifié de multi-événementiel si son traitement porte sur une séquence d alertes. Un module F n possède donc un état, qui est modifié au fur et à mesure de la réception des alertes. Cet état peut par exemple correspondre à l évolution d un plan dans le cas d un système de corrélation explicite, ou bien à la mise à jour d un groupe d alertes dans le cas d un système de corrélation implicite. Il est important de distinguer les systèmes de corrélation mono-événementiels utilisant des informations qui correspondent à des alertes reçues antérieurement, des systèmes de corrélation multi-événementiels. Les premiers interrogent le contexte pour prendre une décision (mode pull), tandis que les second adaptent leur état en fonction de la réception des alertes (mode push). Les deux autres contributions du projet résident dans la conception de modules de corrélation mono-événementiel et d un module multi-événementiel. Les premiers sont présentés en section 3 et le second en section 4. Le module de corrélation multi-événementiel enrichit un système existant baptisé GnG, issu de travaux antérieurs menés au sein de Supélec. L ensemble de ces modules exploite les informations disponibles dans une base de connaissances M4D4, c est-à-dire des informations concernant le contexte local et global, les attaques, les vulnérabilités, la configuration des sondes et les alertes reçues préalablement. 4

7 Chapitre 2 Gestionnaire de corrélation Dans cette section, nous spécifions le fonctionnement du gestionnaire de corrélation. Le gestionnaire de corrélation est responsable de l ensemble des services élémentaires rendus aux modules de corrélation, c est-à-dire la réception des alertes issues des sondes, la persistance des alertes, le transfert des alertes aux modules de corrélation et l accès aux données contextuelles. Nous nous focalisons donc ici sur les éléments génériques qui permettent de corréler des alertes. Le principe de fonctionnement des systèmes de corrélation est spécifié dans les sections 3 et 4. Les fonctions de réception et de persistance d alertes sont assurées par un outil existant, Prélude. Nous explicitons la manière dont le gestionnaire de corrélation s interface avec Prélude à la fin de ce chapitre. La figure 2.1 illustre l architecture globale du système de corrélation, dans laquelle le gestionnaire de corrélation joue un rôle central. Le gestionnaire de corrélation reçoit des alertes issues des sondes de détection d intrusions (via le gestionnaire d alertes de Prélude) et transmet leurs références aux différents modules de corrélation après les avoir stockées dans une mémoire cache. Le gestionnaire de corrélation reçoit les alertes produites par les modules de corrélation est relaye leurs requêtes à destination du contexte local (Q CL ) et global (Q CG ), c-à-d. M4D4. Les différents composants évoqués ci-dessus sont détaillés dans la seconde section de cette partie. Dans la première section, nous présentons et justifions certaines caractéristiques du gestionnaire de corrélation. La dernière section fournit le schéma d architecture complet de la plateforme ACES, qui illustre les interactions entre les différents composants identifiés et précise comment ils se positionnent vis-à-vis de l architecture fonctionnelle proposée dans le livrable 1.1 et des sous projets de ACES. 2.1 Caractéristiques du gestionnaire de corrélation Traitement en ligne vs hors ligne D une manière générale, les alertes peuvent être traitées en ligne ou hors ligne par les modules de corrélation. Le traitement en ligne suppose que le traitement d un module de corrélation est déclenché par la réception d une alerte (c-à-d. au fil de l eau ). Le traitement hors ligne suppose que le traitement d un module de corrélation est déclenché autrement que par la réception d une alerte, le plus souvent par une horloge, ce qui suppose que ces modules interrogent régulièrement la base où les alertes précédemment reçues ont été stockées. Le mode de fonctionnement par défaut adopté dans le gestionnaire de corrélation est orienté en ligne : le gestionnaire de corrélation diffuse les références des alertes aux modules de corrélation, pour que ces derniers puissent les traiter en temps réel. Ceci permet notamment de garantir une meilleure réactivité dans les traitement de corrélation. Néanmoins, rien n empêche un module de corrélation de mémoriser localement des alertes qu il reçoit dynamiquement, pour déclencher régulièrement un traitement sur cet ensemble d alertes mémorisé. Par exemple, un module de corrélation statistique qui a besoin de compter des alertes peut mettre à jour les compteurs au fur et à mesure de la réception des alertes et exécuter périodiquement les traitements statistiques. Bien entendu, un module de corrélation en ligne ne peut pas exploiter une information qui serait obtenue après 5

8 Cache d'alertes Module de Corrélation alertes Gestionnaire de Corrélation Module de Corrélation Q_CL Q_CG Gestionnaire de contexte Module de Corrélation Base d'alertes Informations contextuelles FIG. 2.1 Architecture globale du système de corrélation la réception d une alerte. En revanche, il est envisageable que la réception d une alerte par un module de corrélation déclenche de manière synchrone un traitement spécifique ayant pour objectif d obtenir une information nécessaire au module de corrélation. Par exemple, si une attaque exploite vulnérabilité, un module de corrélation en ligne ne peut pas vérifier s il existe un rapport de vulnérabilité plus récent que l alerte établissant la vulnérabilité de la victime ; en revanche, un module de corrélation peut déclencher un audit de vulnérabilité contre la victime pour savoir si cette dernière est affectée ou non Traitement en série vs parallèle Nous distinguons deux types d envoi des alertes par les modules de corrélation par le gestionnaire de corrélation : l envoi en série et l envoi en parallèle. Traitement en parallèle : Un traitement en parallèle consiste pour le gestionnaire de corrélation à envoyer simultanément chaque alerte à l ensemble des module de corrélation. Un traitement en parallèle garantit ainsi que chaque module de corrélation reçoit effectivement chaque alerte originale, ce qui facilite les traitements concurrents (i.e. des traitements différents sur une même alerte). En revanche, le traitement en parallèle complexifie les traitements coopératifs, dans lesquels un ordre dans les traitements entre module de corrélation est souhaité. Enfin, par définition, un traitement strictement parallèle ne permet pas à un module de corrélation de faire de la rétention d alertes (c.f. ci-dessous), ce qui peut s avérer nécessaire compte tenu de la récurrence de certaines alertes. Traitement en série : Le traitement en série correspond à un chaînage des modules de corrélation. Le gestionnaire de corrélation transmet chaque alerte au premier module de corrélation de la chaîne, qui la transmet à son tour au module de corrélation suivant, une fois son traitement terminé ou annulé. En cas d échec, l alerte est transmise inchangée au processus suivant ; en cas de succès, l alerte initiale peut être modifiée ou subsumée par une méta-alerte. Notons que le 6

9 traitement d un module de corrélation peut être long et engendrer un blocage de l ensemble de la chaîne de traitement de corrélation si un tel module se trouve en série. Un traitement en série peut ou non dénoter un ordre logique dans les traitements effectués par les modules de corrélation, mais un ordonnancement volontaire de traitements de corrélation impose de pouvoir chaîner les modules de corrélation. Dans l architecture fonctionnelle de la plate-forme, un ordre est suggéré, qui consiste à exécuter les traitements mono-événementiels avant les traitements multi-événementiels. En résumé, les traitements en série permettent d ordonner les traitements de corrélation et effectuer de la rétention d alertes ; les traitements en parallèle garantissent la remise des alertes à un ensemble de modules de corrélation et limite les problèmes liés à un blocage d un module. On constate donc que ces deux types de traitements doivent être implantés au niveau du gestionnaire de corrélation. Dans un traitement en série, une communication par création d alerte impose à chaque module de corrélation soit de transmettre au processus suivant la méta-alerte et l alerte initiale, soit de ne transmettre que la méta-alerte, en laissant le soin au processus suivant de rapatrier le contenu de l alerte initiale de la base de connaissance (ce qui suppose que les alertes ont été systématiquement stockées en base avant leur traitement par les modules de corrélation). En effet, le format IDMEF ne permet pas d encapsuler des alertes ; une méta-alerte ne peut que contenir des références à des alertes. La première solution n est pas satisfaisante car l ordre dans lequel une méta-alerte et l alerte subsumée doivent être transmises est discutable : si l alerte est transmise avant la méta alerte, le module de corrélation suivant ne sait pas encore que cette alerte est déjà subsumée au moment du traitement ; si la méta-alerte est transmise avant l alerte, le module de corrélation doit consommer les alertes sur sa file d attente pour trouver l alerte en question (qui ne se trouve pas nécessairement juste après la méta-alerte). Nous optons donc pour la seconde solution, qui consiste pour un module de corrélation à rapatrier les caractéristiques d une alerte dont il trouve la référence dans une méta-alerte. Plus généralement, comme nous l avons évoqué en introduction, le gestionnaire de corrélation ne transmet que les références des alertes aux modules de corrélation, pas leur contenu. Tout accès au contenu d une alerte par un module de corrélation passe donc nécessairement par une requête au gestionnaire de corrélation. Afin d éviter que chaque accès se traduise par un accès à la base de données relationnelle où sont stockées l ensemble des alertes ce qui serait prohibitif du point de vue des performances, le gestionnaire de corrélation maintient à jour un cache où sont stockées les alertes les plus récentes ou les plus fréquemment accédées (c.f. Figure 2.1) Communication des résultats de la corrélation Nous nous intéressons ici à la manière dont un module de corrélation peut informer un opérateur de sécurité (c-à-d un exploitant humain) ou un autre module de corrélation du résultat de son traitement. Nous distinguons trois méthodes possibles : la création d une nouvelle alerte, la modification de l alerte et la notification annexe. Création d une alerte Pour un module de corrélation, une manière d informer son environnement du résultat de son traitement peut être de générer une nouvelle alerte. Les alertes créées par les modules de corrélation sont souvent appelées dans la littérature méta-alertes ou hyper-alertes, du fait de leur caractère haut niveau ; nous opterons pour le premier qualificatif dans la suite de ce document. La création d une méta-alerte par un module de corrélation s accompagne généralement de la création d une relation (dite de subsomption ou d inclusion) entre cette méta-alerte et la ou les alertes qui ont contribué à la sa création. Par exemple, un procédé de clustering d alertes peut lier les alertes élémentaires à la méta-alerte qui caractérise le cluster d alertes similaires. Dans le format IDMEF, une méta-alerte est une instance de la classe CorrelationAlert, qui hérite de la classe Alert. Il est important de noter qu une classe CorrelationAlert n encapsule pas le contenu des alertes qu elle subsume ; elle contient uniquement les références de ces alertes (c-à-d, leurs identifiants). Nous verrons par la suite que cette propriété a un répercussion sur le traitement en série ou en parallèle des alertes par les modules de corrélation. Modification d alertes Pour un module de corrélation d alertes, une seconde manière (complémentaire de la précédente) d informer son environnement du résultat de son traitement peut être de modifier le contenu d une alerte 7

10 existante. Dans la perspective de traitements concurrents sur les alertes, toute modification d une alerte est problématique. En effet, une alerte qui n est initialement pas candidate pour un système de corrélation, peut le devenir ultérieurement suite à une modification par un autre module de corrélation. La modification d une alerte par un module de corrélation implique donc éventuellement la ré-émission de cette alerte aux autres modules de corrélation, ce qui peut avoir des répercussions négatives sur les performances du système. De plus, les modules de corrélation qui se voient réadresser des alertes modifiées doivent être capables d identifier cette alerte comme ayant déjà été traitée, afin de ne pas réitérer un raisonnement déjà effectué. Nous pouvons distinguer quatre types de modifications : Modification d attribut existant : La modification de la valeur d un attribut d alerte existant est une fonctionnalité discutable. En effet, au cours du traitement d une alerte par un module de corrélation, toute modification externe de la valeur d un attribut de cette alerte (typiquement par un système de corrélation concurrent) peut engendrer une inconsistance dans le raisonnement du module de corrélation. De plus, la perte d information que constitue une modification est peu souhaitable dans un contexte de sécurité. Nous excluons donc la modification d attributs existants d une alerte par un module de corrélation. Suppression d attribut : Ce cas est similaire au précédent ; nous l excluons donc aussi. Ajout d attribut : L ajout d un attribut à une alerte par un module de corrélation est vraisemblablement une fonctionnalité incontournable pour permettre d enrichissement du contenu des alertes sans nécessairement passer par la création d une méta-alerte. Suppression d alertes : La suppression d alertes peut être perçue de deux façons différentes : Suppression complète : l alerte est éliminée (filtrée) par le module de corrélation et n est pas mise à disposition de l opérateur. Comme la suppression et la modification d attributs, la suppression d alertes est discutable dans un contexte sécuritaire. Rétention d alerte : la rétention d alerte consiste pour un module de corrélation à ne pas transférer une alerte aux autres modules de corrélation. En ce sens, la rétention d alerte peut être perçue comme une suppression d alerte, à ceci près que l alerte d origine est préalablement stockée et mise à disposition de l opérateur. Bien entendu, la rétention d alerte implique un traitement en série des alertes. Afin de prendre en compte la modification des alertes, nous supposons que l ensemble des modules de corrélation partagent une mémoire où sont stockées les alertes. C est le cache d alerte qui joue ce rôle (c.f. Figure 2.1). Toute modification d alerte passe par une requête au gestionnaire de corrélation, qui garantit que deux modifications concurrentes sur la même alerte n ont pas lieu simultanément par deux modules de corrélation distincts. Une alerte absente du cache est rapatriée de la base de données d alertes par le gestionnaire de corrélation. Notification annexe : Une troisième alternative permettant à un module de corrélation d informer son environnement du résultat de son traitement peut consister à associer une description du résultat à l alerte IDMEF, sous la forme d une annexe. Les triplets (A,V,R) évoqués dans le livrable 1.1 sont des exemples de messages annexes. L intégration des résultats de différents modules de corrélation concernant une même alerte peut alors être sous la responsabilité d un module spécifique, ayant une fonction d arbitrage sur des résultats de corrélation éventuellement antagonistes. Cette fonction d arbitrage peut être assurée par le module Dec de l architecture fonctionnelle. On notera que les annexes peuvent éventuellement être stockées en tant que données additionnelles (AdditionalData) des alertes plutôt qu en tant que messages externes. Il faut noter que cette solution nécessite la modification du contenu des alertes par ajout d attributs. Cette solution est pratique car elle n impose aucune modification des implémentations existantes de bus d alertes utilisant IDMEF (c.f. section Prélude ci-après). Néanmoins, cette solution est peu élégante car la structure (type, valeur) des données additionnelles n est pas suffisamment expressive pour distinguer les résultats de différents modules de corrélation sur une même alerte. 2.2 Spécifications du gestionnaire de corrélation Nous détaillons dans cette section le fonctionnement du gestionnaire d alertes et ses composants périphériques. Dans un second temps, nous montrons comment ce gestionnaire de corrélation s interface avec une plate-forme de gestion d alertes existante, Prelude. 8

11 2.2.1 Composants du gestionnaire de corrélation Le gestionnaire de corrélation est constitué d un ensemble de briques de base : un gestionnaire, chargé notamment de recevoir les alertes issues des sondes, de les mettre en cache et de les transmettre aux différents modules de corrélation, par l intermédiaire de canaux d alertes et de répartiteurs d alertes. Ces différents composants sont décrits dans la suite. Cache d alertes Le cache d alerte est une mémoire partagée par l ensemble des composants de corrélation, qui permet de stocker les alertes les plus récentes ou accédées fréquemment. Tout accès en lecture ou en écriture aux alertes contenues dans le cache passe par le gestionnaire de corrélation, qui garantit que l accès se fait en exclusion mutuelle. Les modifications apportées aux alertes se font exclusivement dans le cache. Une alerte absente du cache d alerte est rapatriée complètement par le gestionnaire de corrélation. Un processus exécuté en arrière plan est chargé de scruter le contenu du cache, de répercuter les modifications apportées aux alertes au niveau de la base de données relationnelle et de maintenir la taille du cache en dessous d un seuil fixé. Canal d alertes Un canal d alertes est une file d attente de type FIFO alimentée par un producteur d alertes (un module de corrélation, un répartiteur d alertes ou un analyseur), où les alertes sont stockées en attente d être consommées par un module de corrélation pour être analysées, ou bien par un répartiteur d alertes pour être diffusées à d autres modules de corrélation. Les objets stockés dans un canal d alertes sont en réalité des références d alertes (c-à-d. leurs identifiants) qui sont utilisés par les modules de corrélation pour accéder au contenu des alertes, qui est stocké au niveau du gestionnaire de corrélation. Répartiteur d alertes Les répartiteurs d alertes sont destinés au traitement en parallèle des alertes par des modules de corrélation. Un répartiteur d alertes est constitué d un canal d entrée et de un ou plusieurs canaux de sortie. Un répartiteur d alertes consomme les alertes disponibles sur son canal d entrée et les diffuse systématiquement sur chaque canal de sortie, de manière asynchrone. Module de corrélation Un module de corrélation implémente un traitement d alerte particulier, tel que ceux décrits dans les sections 3 et 4. Un module de corrélation possède un canal d entrée et un canal de sortie d alertes. Deux modules de corrélation peuvent donc être agencés en série, si le canal de sortie de l un coïncide avec le canal d entrée du module de corrélation suivant. L agencement en parallèle de plusieurs modules de corrélation passe par l utilisation d un répartiteur d alertes (c.f. figures 2.2 et 2.3). La logique de traitement d alertes doit se faire explicitement, en associant entre eux elles les entrées et les sorties des modules de corrélation. Le cas échéant, cet agencement pourra être paramétré dans un fichier de configuration plutôt que codé en dur dans l application du gestionnaire de corrélation. Le traitement d un module de corrélation est synchrone : une alerte n est consommée que lorsque le traitement portant sur l alerte précédente est terminé. Un module de corrélation est implémenté sous la forme d un processus léger, synchronisé sur ses canaux d entrée et de sortie : un module de corrélation dont le canal d entrée est vide est mis en sommeil jusqu à ce qu une nouvelle alerte soit mise à disposition, ce qui provoque son réveil. Un module de corrélation peut aussi être mis en sommeil si son canal de sortie est plein. On notera que le blocage d un module peut engendrer un blocage en chaîne des modules de corrélation qui le précèdent. Si le traitement effectué le permet, plusieurs instances d un même module de corrélation peuvent être exécutées en parallèle au sein d un même module, pour accélérer le traitement des alertes. Toute émission d alerte par un module de corrélation se fait par un appel explicite à la méthode de dépôt d alerte du canal de sortie. Par conséquent, le transfert d une alerte non modifiée par un module de corrélation se fait de manière explicite. 9

12 MaCo : Manager de Corrélation MoCo : Module de Corrélation Canal d'alertes MaCo MoCo MoCo MoCo FIG. 2.2 Agencement en série des modules de corrélation MaCo : Manager de Corrélation MoCo : Module de Corrélation RepAl : Répétiteur d'alerte Canal d'alertes MoCo MaCo MoCo RepAl MoCo MoCo MoCo FIG. 2.3 Agencement en parallèle et série des modules de corrélation Les différents modes de notification du résultat du traitement d un module de corrélation sont mis en œuvre des manières suivantes : La notification par création d alerte se fait simplement par la création d une nouvelle alerte, suivi de son dépôt sur le canal de sortie. La modification du contenu d une alerte existante est déléguée au gestionnaire de corrélation, au niveau duquel est stocké le contenu des alertes. Un module de corrélation souhaitant modifier une alerte invoque donc les méthodes idoines au niveau du serveur. Chaque modification d alerte se fait en exclusion mutuelle : à un instant donné, un seul module de corrélation peut modifier le contenu d une alerte. En revanche, plusieurs modifications simultanées peuvent être effectuées par des modules de corrélation différents, à condition que ces modifications portent sur des alertes distinctes. Les éventuels modules de corrélation désirant apporter des modifications de manière concurrente sur une même alerte sont mis en attente au niveau de l alerte, jusqu à ce que le module courant ait terminé sa modification. Rappelons que seules les modifications par ajout d attributs sont retenues dans ce projet. L ajout d une nouvelle alerte en tant que fille d une méta-alerte existante fait partie des modifications d alertes possibles. On veillera à ce que ce système de modification d alerte ne provoque pas d interblocage entre deux modules de corrélation étant mis mutuellement en sommeil sur deux alertes. La rétention d alerte par un module de corrélation se fait simplement par un chaînage en série et la non-transmission d une alerte sur le canal de sortie. Le canal de sortie d un module de corrélation peut être connecté à n importe quel autre canal d entrée existant, selon que les méta-alertes produites par le module de corrélation doivent être mises à disposition des autres modules de corrélation ou non : Le canal de sortie d un module de corrélation peut être relié au canal d entrée du gestionnaire de corrélation, qui diffusera naturellement la nouvelle alerte aux autres modules de corrélation. Pour éviter des boucles infinies de traitement d alertes consommées et produites par un même module, on suppose que les modules de corrélation sont équipés de filtres permettant de ne pas traiter les alertes dont l identité du producteur correspond à celle du 10

13 module. Le canal de sortie d un module de corrélation peut être relié au canal d entrée d un autre module de corrélation ou d un répartiteur d alertes situé en aval. Éventuellement, le canal de sortie d un module de corrélation peut-être un relié à un trou noir, si ce module de corrélation ne produit aucune méta-alerte et se contente de modifier le contenu d alertes existantes. Dans tous les cas, on suppose que toute nouvelle méta-alerte créée par un module de corrélation est systématiquement mémorisée au niveau du gestionnaire de corrélation. On notera que la question de l enchaînement des modules de corrélation n est pas triviale, ou du moins peut être litigieuse. Par exemple, considérons un phénomène dans lequel des alertes fortement récurrentes sont reçues par le gestionnaire de corrélation, avertissant d occurrences d attaques exploitant une vulnérabilité référencée. Le caractère récurrent des alertes fait qu un module d agrégation d alertes est tout indiqué. L exploitation de la vulnérabilité impose une vérification du succès de l attaque. Les deux ordres de traitement se justifient : la vérification du succès de l attaque peut porter sur une méta-alerte qui synthétise chacune des alertes individuelle et présente l avantage de limiter le nombre de vérifications de vulnérabilité. L agrégation peut aussi s appliquer sur des alertes pour lesquelles le diagnostic de succès a été effectué de manière individuelle. Cet ordre impose un surcoût de traitement, mais permet éventuellement de distinguer deux groupes d alertes distincts : celui englobant les alertes pour lesquelles le diagnostic est positif et celui pour lequel les diagnostics sont négatifs (suite au patch d une machine, par exemple). L idéal serait d automatiser le choix de l ordre des traitements. Nous n abordons pas ce problème dans le cadre du projet ACES. Le choix de l ordre du traitement des alertes est laissé à l administrateur du système de corrélation. Gestionnaire de corrélation Le gestionnaire de corrélation reçoit les alertes IDMEF de l ensemble des sondes, mémorise leur contenu localement et transmet leurs références aux modules de corrélation. Le gestionnaire de corrélation est donc constitué d un canal d entrée et d un canal de sortie d alertes. Les alertes reçues par le manager de corrélation ne sont pas directement stockées en base de données ; elles sont mémorisées dans l espace d adressage du processus, pour permettre un accès rapide au contenu des alertes par les modules de corrélation, à partir de leur identifiant. Un processus exécuté en arrière-plan est chargé du stockage en base des alertes, lorsque le volume d alertes stockées en mémoire excède un seuil donné, qui dépend de la quantité de mémoire vive disponible. Le gestionnaire de corrélation sert d interface pour l accès au contenu de n importe quelle alerte : si un module de corrélation demande d accéder au contenu d une alerte qui n est plus présente en mémoire vive, le gestionnaire de corrélation recharge l alerte en mémoire vive à partir de la base de données où l ensemble des alertes sont stockées. Du point de vue d un module de corrélation, l accès au contenu d une alerte est donc transparent. Le gestionnaire de corrélation fait enfin fonction d interface pour le traitement des requêtes en rapport avec le contexte global et local : il reçoit les requêtes émanant des modules de corrélation sous la forme de prédicats du premier ordre, délègue le traitement aux composants Q CL et Q CG, et transmet la réponse au module demandeur. La figure 2.4 représente le diagramme de classes simplifié de ces différents composants Interface avec M4D4 M4D4 est un modèle de données qui fédère les concepts et relations nécessaires au raisonnements sur les alertes effectués par les modules de corrélation. Ce modèle de données contextuelles est décrit dans le livrable 2.2 du projet. Les interactions entre les modules de corrélation et le contexte est géré par un composant particulier du gestionnaire de corrélation, le gestionnaire de contexte. Le gestionnaire de contexte communique avec le contexte global (Q C G), le contexte local (Q C L), ainsi qu avec les bases d informations relatives aux attaques, aux vulnérabilités et à la configuration des sondes (c.f. Figure 2.1 et livrable 1.1). Les bases de données contextuelles utilisées dans le cadre de ACES possèdent leur propre schémas de données. M4D4 peut être perçu comme un langage de description unificateur des informations manipulées par les modules de corrélation. Ce langage constitue une couche d abstraction qui affranchit les modules de corrélation de la connaissance des structures de données spécifiques utilisées par les systèmes de collecte d informations contextuelles. Le rôle du 11

14 Correlation Node output channel Alert Hub input channel input channel 1 Correlation Manager Correlation Module 1 output channels 1 n Alert Channel 1 Alert FIFO 1 Alert Cache n Alert FIG. 2.4 Diagramme de classes gestionnaire de corrélation est donc de traduire des requêtes exprimées en M4D4 en requêtes compatibles avec les schémas de données utilisées par les bases d informations concrètes. Le modèle M4D4 utilise le formalisme de la logique du premier ordre. Les requêtes d interrogation du contexte par le modules de corrélation ont donc naturellement la forme d un but à la Prolog. Le gestionnaire de contexte a comme objectifs : de recevoir les requêtes des modules de corrélation, de traduire ces requêtes dans le langage de requêtes de la base de données cible (en l occurrence SQL), d unifier les variables libres de ce but avec les faits disponibles dans différentes bases de données, de fournir le résultat au module de corrélation qui le demande, sous la forme d une liste de n-uplets ((X 1,V 1 ),...,(X n,v n )), où X i représente le nom d un variable libre et V i une valeur de cette variable. Une requête peut être par exemple : nodeaddress(x, ),hosts(x,y ),so ftware(y,z,, os, ),Z debian Le langage permet d exprimer des contraintes sur les variables grâce aux opérateurs ==,! =, <, <=, >, >= et pour la comparaison à une expression régulière. Les prédicats portant sur M4D4 sont paramétrables (ici nodeaddress, hosts, so f tware), ainsi que leur relation avec les tables de la base de données interrogée. La reconnaissance des prédicats M4D4 et l accès au tables de la base M4D4 repose sur : le paramétrage du gestionnaire de contexte par la définition des prédicats ; la définition de vues équivalentes à ces prédicats sur les tables des bases concrètes (nom de vues identiques aux noms de prédicats, noms de champs identiques aux noms d arguments) ; il s agit de reporter l optimisation de l exécution des requêtes sur le moteur de la base de données ; Il est envisageable de déduire automatiquement ces vues à partir des prédicats visés, du schéma de la base de données et de la correspondance entre les champs de prédicats et les champs des tables (les tables et leurs clés étrangères permettant de constituer un graphe, les jointures correspondent à un chemin dans ce graphe). L algorithme de principe du gestionnaire de contexte est le suivant : Analyse du but par un analyseur récursif descendant, permettant de constituer une liste des arbres abstraits des prédicats M4D4, une liste des contraintes sur les variables et une table des variables avec la liste des références 12

15 par les prédicats M4D4 ; Vérification de l appartenance de la liste des variables sur laquelle projeter les tuples à la liste des variables du but ; Génération de la requête SQL Connexion avec Prélude Nous détaillons ici comment le gestionnaire de corrélation décrit précédemment s interface avec l outil Prélude. Présentation de Prélude Prélude 1 est un système de gestion d événements de sécurité (SEMP, Security Event Management Product) opensource. Prélude est constitué de trois types de composants : des sondes, un gestionnaire d alertes prelude-manager et une console d alertes (prewikka). Ces composants sont basés sur une bibliothèque commune (libprelude) et remplissent les différentes fonctions attendues d un SEMP : Bus d alertes : Le manager Prelude remplit la fonction de bus d événements. Un mécanisme d abonnement permet à des composants de se connecter au manager pour émettre et/ou recevoir des alertes. Conformément à l architecture des IDS définie par le groupe de travail IDWG (Intrusion Detection Working Group) de l IETF, les sondes sont des producteurs d alertes et les composant de corrélation sont des consommateurs et producteurs de nouvelles alertes, qui résultent de la corrélation des alertes entre elles et/ou avec des informations contextuelles. Deux managers d alertes peuvent être connectés entre eux, ce qui permet de construire une hiérarchie de managers. Le manager Prélude gère les files d attentes d alertes qu il reçoit sur son interface d entrée. Les alertes échangées entre les composants sont formattées en IDMEF. Le bus d alertes possède en outre des propriétés souhaitables de sûreté de fonctionnement. Par exemple, le canal d alertes est chiffré et requiert de la part des composants une authentification mutuelle. Des mécanismes de reprise sur panne garantissent pour leur part l absence de perte d alertes, en cas de coupure de connexion entre les composants. Persistance des alertes : Le manager Prelude est responsable de la persistance des alertes reçues des différents abonnés. Le stockage s effectue dans une base de donnée dont le schéma relationnel est calqué sur le format IDMEF. Alternativement, le stockage peut s effectuer dans un fichier à plat, dans le format IDMEF ou CSV (Comma Separated Variable). Nous optons ici pour le stockage en base de données, pour permettre aux composant M4D4 d interroger les bases de données d alertes. Présentation des alertes d alertes. Prélude inclut un composant de visualisation d alertes basé sur la base de données On notera enfin que l utilisation du standard IDMEF et l API offerte par la bibliothèque Prélude facilitent considérablement l intégration de nouvelles source d alertes. Certaines sondes sont dores et déjà compatibles avec Prelude, notamment Snort, que nous utilisons dans le cadre de ACES comme sonde de détection d intrusions réseau. Connexion du gestionnaire de corrélation avec Prélude Des fonctions de corrélation sont actuellement en cours de conception dans le projet Prélude. Il est prévu que différents plugins de corrélation puissent se connecter à un gestionnaire d alerte, mais l implémentation semble encore peu mature et n offre pas la souplesse nécessaire au différents types de traitements de corrélation envisagés. C est pour cette raison que nous préférons concevoir notre propre gestionnaire de corrélation et contribuer ainsi au développement de Prélude

16 Le gestionnaire de corrélation de la plateforme ACES est simplement implémenté sous la forme d un processus abonné à un gestionnaire d alertes Prélude. Le gestionnaire d alerte reçoit l ensemble des alertes issues des sondes, les stocke dans une base de données relationnelle et les transmet au gestionnaire de corrélation. En référence à l architecture fonctionnelle des flots de données et de contrôle (c.f. Figure 2.5), nous suggérons que les messages en mode push soient formattés en IDMEF par les sondes, puis envoyés à un manager Prélude, qui le transmet au gestionnaire de corrélation. 2.3 Architecture logique de la plateforme Les figures 2.5 et 2.6 illustrent toutes les deux les relations entre les différents composants de la plateforme ACES constituée des composants de corrélation, de la base de connaissance et des différents systèmes chargés d alimenter cette base de connaissance avec des informations relatives au contexte, aux attaques et à la configuration des sondes. Elle représente aussi l intégration de Prélude au sein de cette plateforme. La première figure met en évidence les composants de l architecture fonctionnelle des flots de données et de contrôle identifiés dans le livrable 1.1. On notera que la division F 1 /F n des différents types de modules de corrélation et l agencement des modules sont arbitraires et ont uniquement un but illustratif. La seconde figure montre pour sa part les sous projets dans lesquels ces composants sont développés. Module de Corrélation (MoCo) Configuration des sondes IDS IDS Sondes Alertes Gestionnaire d'alertes Prelude Alertes Events & Alerts Gestionnaire de Corrélation (MaCo) Module de Corrélation (MoCo) RepAl Module de Corrélation (MoCo) Module de Corrélation (MoCo) F1 FN Base de faits et règles M4D4 Q_CL et Q_CG Contexte Global Topologie Cartographie Attaques & Vulnérabilités Honeypots Sondes Passives DNA OSVDB OVAL CG CL FIG. 2.5 Gestionnaire de corrélation v-à-v de l architecture fonctionnelle 14

17 Module de Corrélation (MoCo) IDS IDS Sondes Alertes Gestionnaire d'alertes Prelude Gestionnaire de Corrélation (MaCo) Module de Corrélation (MoCo) RepAl Module de Corrélation (MoCo) Configuration des sondes SP5 Alertes Events & Alerts Module de Corrélation (MoCo) Base de faits et règles M4D4 SP2 SP6 Contexte Global Topologie Cartographie Attaques & Vulnérabilités Honeypots Sondes Passives DNA OSVDB OVAL SP4 SP3 SP2 FIG. 2.6 Gestionnaire de corrélation v-à-v des WP 15

18 Chapitre 3 Corrélation mono-événementielle 3.1 Corrélation avec les vulnérabilités L objectif de ce type de corrélation consiste à évaluer le succès d une attaque exploitant une vulnérabilité en vérifiant si la vulnérabilité exploitée est effectivement présente sur la victime. Deux techniques complémentaires peuvent être envisagées pour y parvenir, que nous présentons dans la suite de cette section Corrélation avec des rapports de vulnérabilité Principe La première technique de corrélation avec les vulnérabilité consiste simplement à exploiter les rapports d audits fournis par des scanners de vulnérabilités. Ce schéma de corrélation est probablement l un des premiers à avoir été proposés dans la littérature. À la réception d une alerte faisant référence à une attaque exploitant une vulnérabilité identifiée V contre un hôte H, ce schéma de corrélation consiste à vérifier si il existe un rapport de vulnérabilité ayant été reçu par le passé, faisant état de la présence de V sur H. Dans l affirmative (et à condition que le rapport ne soit pas obsolète), la sévérité de l alerte peut être augmentée ; dans la négative, celle-ci peut être diminuée. La question de l actualité des rapports de vulnérabilité est cruciale, mais nous ne l abordons pas dans ce document car la gestion de l obsolescence des rapports est une problématique propre aux sondes. Ce schéma de corrélation repose sur une identification commune des vulnérabilités par les sondes de détection d intrusion, d une part, et par les scanners de vulnérabilité, d autre part. Différents systèmes de nommage peuvent être utilisés à cet effet, notamment CVE, BugTraq, Nessus. Schéma de corrélation Étant donnés un hôte h et une classe d attaque k présents dans une alerte, la formule suivante traduit la requête existe-t-il une vulnérabilité V exploitée par k qui a été détectée sur h et rapportée dans un rapport de vulnérabilité? : exploits(k,v ) report(r, h,v ) Une réponse positive à cette requête (c-à-d une instanciation de V et R) indique que le rapport d audit R établit que h est affecté par la vulnérabilité V exploitée par l attaque k. Une réponse négative peut indiquer soit que la vulnérabilité est absente, soit que l information n est pas disponible (auquel cas aucune conclusion définitive sur la vulnérabilité de la victime ne peut être tirée). Pour distinguer ces deux possibilités, il est possible d interroger le contexte pour savoir s il existe un scanner de vulnérabilité configuré pour tester la présence de V sur h : monitors(s,v,h) message(r,s) report(r,h, ) 16

19 où S symbolise l identifiant de scanner à l origine d un message R, qui est aussi un rapport de vulnérabilité relatif à h (v représente ici une instanciation de V précédemment évoqué). Une réponse positive à cette requête signifie que le scanner est effectivement configuré pour effectuer des audits périodiques pour tester la présence de V sur h et qu au moins un audit de h a déjà été effectué (indiqué par la présence d un rapport R). Cette dernière condition doit être vérifiée, sinon le système de corrélation pourrait conclure qu une victime est immunisée (car un scanner est correctement configuré), alors qu en réalité aucun audit n a encore été effectué. On suppose donc tout audit de vulnérabilité déclenche au moins un message message(r, S) permettant de connaître la date du dernier audit. Pour distinguer l absence de connaissance sur l état de vulnérabilité de la victime de son immunité, le contexte local pourrait aussi mémoriser des faits traduisant l absence de vulnérabilité (i.e. report(r,v, h)). Cependant, les systèmes d audit ne fournissent généralement que les présences de vulnérabilité. Résultat de la corrélation L annonce du résultat de la corrélation se fera par la construction d une méta-alerte subsumant l alerte originale. Le contenu de la méta-alerte est le même que l alerte originale, à l exception des champs de la classe IDMEF Impact suivants : Severity = 3 si la victime est vulnérable, 1 sinon. Completion = 1 si la victime est vulnérable, 0 sinon. Le champ name de la CorrelationAlert est un champ libre qui précise la raison de la corrélation ; dans le cas présent, les chaînes suivantes seront utilisées : Tested vulnerable victim pour une victime vulnérable et Tested and immune victim pour une victime non vulnérable. L absence d information relative à la vulnérabilité de la victime ne donne pas lieu à la création de méta-alerte Corrélation avec des configurations logicielles Le schéma de corrélation précédent suppose l existence de rapports de vulnérabilités pour évaluer le succès des attaques. Cependant, les rapports ne sont pas toujours disponibles dans les réseaux. En effet, ces derniers peuvent avoir des effets de bord peu souhaitables sur l environnement surveillé. Nous présentons ici un schéma de corrélation alternatif, dont l objectif est le même que le précédent, mais qui n utilise pas de rapports de vulnérabilités. Principe Les vulnérabilités sont des failles introduites involontairement au cours l ensemble des phases de conception d un logiciel (spécification, conception, configuration). Les vulnérabilités connues sont donc généralement associées à une ou plusieurs configurations logicielles. Une configuration logicielle est un ensemble de logiciels dont la présence conjuguée sur une machine provoque la faille. Par exemple, la présence d une version spécifique d un serveur applicatif sur un système d exploitation précis peut constituer une configuration vulnérable. L objectif de la corrélation avec des configurations logicielles est d évaluer le succès d une attaque en comparant les configurations d une vulnérabilité exploitée par une attaque avec la configuration effective de la victime de l attaque. Cette comparaison se base sur les logiciels affectés par une configuration, d une part, et sur ceux effectivement hébergés par les hôtes du réseau, d autre part. Le principe de la corrélation consiste à accroître le niveau de sévérité d une attaque exploitant une vulnérabilité affectant des logiciels hébergés par la victime. Cependant, statuer sur le succès d une attaque sur la base d une correspondance entre les logiciels affectés par une vulnérabilité et ceux hébergés par la machine nécessite un niveau de détail extrêmement fin dans les observations fournies par les outils de collecte de la cartographie et les bases de vulnérabilité. En effet, une vulnérabilité affecte généralement une version très spécifique d un logiciel ou d un système d exploitation. Les systèmes de cartographie ne sont généralement pas capables de fournir ce niveau de détail. Nous serions donc contraints d effectuer des comparaisons grossières entre les configurations affectées et celles observées sur les hôtes. Le diagnostic de succès de l attaque serait donc très incertain : même en cas de correspondance entre 17

20 les logiciels affectés et ceux hébergés par un hôte, le système de corrélation ne pourrait que supposer le succès de l attaque, sans le garantir. Par conséquent, en pratique, nous raisonnerons à l inverse, en diminuant le niveau de sévérité d une attaque dont la vulnérabilité affecte des logiciels absents de la victime. Par exemple, savoir qu une victime héberge un système d exploitation Linux suffit à diagnostiquer l échec d une attaque exploitant la vulnérabilité CAN , qui correspond au ver Blaster. A contrario, diagnostiquer le succès de cette attaque nécessite d avoir des informations beaucoup plus détaillées (numéro de version ou de patch) sur la victime, si celle-ci héberge Windows. L échec de la corrélation traduit alors le fait que la victime est potentiellement vulnérable. En plus des difficultés techniques liées à l identification précise des logiciels hébergés par les hôtes du réseau, se pose le problème de la dénomination de ces logiciels par les outils de collecte de la cartographie d une part, et les bases de vulnérabilités d autre part. Il n existe à l heure actuelle aucune convention de nommage des logiciels. Par conséquent, les différentes dénominations utilisés dans les systèmes sont non seulement rarement compatibles entre elles, mais sont en plus souvent entachées d incertitudes, voire d erreurs, et manquent de cohérence. Par exemple, un système peut nommer une version de Windows Windows 2000, alors qu un autre le nommera Win2k. Un prérequis à toute tentative de raisonnement sur le succès des attaques à partir des vulnérabilités consiste donc à construire un référentiel unique des identifiants de logiciels. Nous ne détaillons pas ici la construction de ce référentiel de nommage, qui est décrit dans le livrable 3.1 et nous supposons que l ensemble des noms de logiciels sont normalisés. Schéma de corrélation Comme évoqué précédemment, une vulnérabilité n affecte généralement un seul logiciel, mais au moins une configuration, une configuration étant un ensemble de logiciel dont la présence conjuguée est nécessaire pour qu un hôte soit affecté. Étant donnés un hôte H et une vulnérabilité V présents dans une alerte, le système de corrélation estimera qu un hôte n est pas vulnérable si la condition suivante est satisfaite : où est défini de la manière suivante : vulnerability(v ) node(h) C.a f f ects(v,c) ( S V.takespartin(S V,C) ( S H.hosts(H,S H ) S V S H )) S 1 S 2 S 1 S 2 S 1 S 2 S 1.type S 2.type S 1.type = S 2.type S 1.name S 2.name S 1.type = S 2.type S 1.name = S 2.name S 1.version S 2.version S.name, S.type et S.version désignent respectivement le nom, le type et la version d un logiciel. On suppose que la relation est définie sur l ensemble des versions de logiciels. Cette règle dit qu un hôte H n est pas affecté par la vulnérabilité V si chaque ( C...) configuration vulnérable C inclut au moins un logiciel S V qui ne correspond ( ) à aucun ( S H ) des logiciels S N effectivement hébergés (hosts(...)) par H. Dans le cas contraire, la victime est peut-être vulnérable. Comme dans le cas de la corrélation avec des rapports de vulnérabilité, on distinguera plusieurs cas : La règle précédente est satisfaite, ce qui signifie que la victime n est pas vulnérable, donc que l attaque est un échec. La règle précédente n est pas satisfaite, ce qui signifie : Soit qu au moins une configuration vulnérable correspond à la configuration de l hôte, auquel cas l attaque est peut-être un succès. Soit que la configuration de la victime est inconnue. Aucune conclusion ne peut alors être tirée sur le succès de l attaque. On supposera que la configuration d un hôte est inconnue si aucune information cartographique n est disponible à son sujet. 18

Page 1 2 La présente invention concerne le domaine des architectures informatiques, et en particulier un procédé pour le développement d applications destiné à un fonctionnement en réseau, par exemple

Plus en détail

Présentation. Logistique. Résumé de la 1e Partie. Mise en place du système

Présentation. Logistique. Résumé de la 1e Partie. Mise en place du système Présentation Diapo01 Je m appelle Michel Canneddu. Je développe avec 4D depuis 1987 et j exerce en tant qu indépendant depuis 1990. Avant de commencer, je tiens à remercier mes parrains Jean-Pierre MILLIET,

Plus en détail

Les principaux domaines de l informatique

Les principaux domaines de l informatique Les principaux domaines de l informatique... abordés dans le cadre de ce cours: La Programmation Les Systèmes d Exploitation Les Systèmes d Information La Conception d Interfaces Le Calcul Scientifique

Plus en détail

White Paper - Livre Blanc

White Paper - Livre Blanc White Paper - Livre Blanc Développement d applications de supervision des systèmes d information Avec LoriotPro Vous disposez d un environnement informatique hétérogène et vous souhaitez à partir d une

Plus en détail

Architecture des calculateurs

Architecture des calculateurs Chapitre 1 Architecture des calculateurs 1.1 Introduction Ce paragraphe n a pas la prétention de présenter un cours d informatique. D une manière générale, seuls les caractéristiques architecturales qui

Plus en détail

IPS : Corrélation de vulnérabilités et Prévention des menaces

IPS : Corrélation de vulnérabilités et Prévention des menaces IPS : Corrélation de vulnérabilités et Prévention des menaces SIM+IPS opensource David Bizeul & Alexis Caurette C O N N E C T I N G B U S I N E S S & T E C H N O L O G Y Définitions SIM : Security Information

Plus en détail

L approche Bases de données

L approche Bases de données L approche Bases de données Cours: BD. Avancées Année: 2005/2006 Par: Dr B. Belattar (Univ. Batna Algérie) I- : Mise à niveau 1 Cours: BDD. Année: 2013/2014 Ens. S. MEDILEH (Univ. El-Oued) L approche Base

Plus en détail

et les Systèmes Multidimensionnels

et les Systèmes Multidimensionnels Le Data Warehouse et les Systèmes Multidimensionnels 1 1. Définition d un Datawarehouse (DW) Le Datawarehouse est une collection de données orientées sujet, intégrées, non volatiles et historisées, organisées

Plus en détail

basée sur le cours de Bertrand Legal, maître de conférences à l ENSEIRB www.enseirb.fr/~legal Olivier Augereau Formation UML

basée sur le cours de Bertrand Legal, maître de conférences à l ENSEIRB www.enseirb.fr/~legal Olivier Augereau Formation UML basée sur le cours de Bertrand Legal, maître de conférences à l ENSEIRB www.enseirb.fr/~legal Olivier Augereau Formation UML http://olivier-augereau.com Sommaire Introduction I) Les bases II) Les diagrammes

Plus en détail

Analyse abstraite de missions sous PILOT

Analyse abstraite de missions sous PILOT Analyse abstraite de missions sous PILOT Damien Massé EA 3883, Université de Bretagne Occidentale, Brest damien.masse@univ-brest.fr Résumé Nous étudions la possibilité de réaliser un analyseur par interprétation

Plus en détail

MEGA TeamWork. Guide d utilisation

MEGA TeamWork. Guide d utilisation MEGA TeamWork Guide d utilisation MEGA HOPEX V1R1 1ère édition (juillet 2013) Les informations contenues dans ce document pourront faire l objet de modifications sans préavis et ne sauraient en aucune

Plus en détail

Exécution des applications réparties

Exécution des applications réparties Exécution des applications réparties Programmation des Applications Réparties Olivier Flauzac URCA Master STIC-Informatique première année Olivier Flauzac (URCA) PAR : Exécution des applications réparties

Plus en détail

Projet ROSES Programme MDCO Edition 2007. Livrable no D1.2 Architecture d un Système ROSES centralisé

Projet ROSES Programme MDCO Edition 2007. Livrable no D1.2 Architecture d un Système ROSES centralisé Projet ROSES Programme MDCO Edition 2007 Livrable no D1.2 Architecture d un Système ROSES centralisé Identification Acronyme du projet Numéro d'identification de l'acte attributif ROSES ANR-07-MDCO-011-01

Plus en détail

Mémoire virtuelle. Généralités

Mémoire virtuelle. Généralités Mémoire virtuelle Généralités La pagination pure - Conversion d adresses virtuelles en adresses physiques - Table des pages à plusieurs niveau et table inversée - Algorithmes de remplacement de page -

Plus en détail

Exemple de développement d une application

Exemple de développement d une application Exemple de développement d une application Département Informatique TELECOM SudParis 1ère année Dépt INF 2009/2010 Table des matières Exemple de développement d une application Département Informatique,,

Plus en détail

Guillaume SOLDERA (B guillaume.soldera@serli.fr) SERLI Informatique Bull OW2 Consortium. Comparatif Choco/Drools dans le cadre du projet JASMINe

Guillaume SOLDERA (B guillaume.soldera@serli.fr) SERLI Informatique Bull OW2 Consortium. Comparatif Choco/Drools dans le cadre du projet JASMINe Guillaume SOLDERA (B guillaume.soldera@serli.fr) SERLI Informatique Bull OW2 Consortium dans le cadre du projet JASMINe Avril 2008 Table des matières 1 Introduction 3 1.1 Rappel sur JASMINe.......................................

Plus en détail

Machine de Turing. Informatique II Algorithmique 1

Machine de Turing. Informatique II Algorithmique 1 Machine de Turing Nous avons vu qu un programme peut être considéré comme la décomposition de la tâche à réaliser en une séquence d instructions élémentaires (manipulant des données élémentaires) compréhensibles

Plus en détail

PROBLÉMATIQUE D INTERCONNEXION DES RÉSEAUX IP

PROBLÉMATIQUE D INTERCONNEXION DES RÉSEAUX IP PREMIER MINISTRE Secrétariat général de la défense nationale Direction centrale de la sécurité des systèmes d information Sous-direction scientifique et technique Laboratoire Technologies de l Information

Plus en détail

Chapitre 1 : Introduction aux Systèmes de Gestion de Bases de Données (Eléments de base)

Chapitre 1 : Introduction aux Systèmes de Gestion de Bases de Données (Eléments de base) Chapitre 1 : Introduction aux Systèmes de Gestion de Bases de Données (Eléments de base) 1. Généralités sur l'information et sur sa Représentation 1.1 Informations et données : a. Au sen de la vie : C

Plus en détail

PRODUCTION DE JEUX DE DONNÉES ANONYMISÉES

PRODUCTION DE JEUX DE DONNÉES ANONYMISÉES PRODUCTION DE JEUX DE DONNÉES ANONYMISÉES Les contenus de ce document sont la propriété exclusive de la société REVER. Ils ne sont transmis qu à titre d information et ne peuvent en aucun cas être considérés

Plus en détail

Créer et partager des fichiers

Créer et partager des fichiers Créer et partager des fichiers Le rôle Services de fichiers... 246 Les autorisations de fichiers NTFS... 255 Recherche de comptes d utilisateurs et d ordinateurs dans Active Directory... 262 Délégation

Plus en détail

MEGA Administration-Supervisor. Guide de l administrateur

MEGA Administration-Supervisor. Guide de l administrateur MEGA Administration-Supervisor Guide de l administrateur MEGA 2009 SP4 1ère édition (juin 2010) Les informations contenues dans ce document pourront faire l objet de modifications sans préavis et ne sauraient

Plus en détail

Objectifs. Maîtriser. Pratiquer

Objectifs. Maîtriser. Pratiquer 1 Bases de Données Objectifs Maîtriser les concepts d un SGBD relationnel Les modèles de représentations de données Les modèles de représentations de données La conception d une base de données Pratiquer

Plus en détail

SECURIDAY 2013 Cyber War

SECURIDAY 2013 Cyber War Club de la Sécurité Informatique à l INSAT Dans le cadre de la 3ème édition de la journée nationale de la sécurité informatique SECURIDAY 2013 Cyber War SECURINETS Présente Formateurs: 1. Trabelsi NAJET

Plus en détail

DATASET / NETREPORT, propose une offre complète de solutions dans les domaines suivants:

DATASET / NETREPORT, propose une offre complète de solutions dans les domaines suivants: Présentation Société DATASET / NETREPORT, propose une offre complète de solutions dans les domaines suivants: Outils d aide à la décision Gamme DATASET Solutions de gestion temps réel du système d information

Plus en détail

SOA et Services Web. 23 octobre 2011. SOA: Concepts de base

SOA et Services Web. 23 octobre 2011. SOA: Concepts de base SOA et Services Web 23 octobre 2011 1 SOA: Concepts de base 2 Du client serveur à la SOA N est Nest pas une démarche entièrement nouvelle: années 1990 avec les solutions C/S Besoins d ouverture et d interopérabilité

Plus en détail

MEGA Administration-Supervisor. Guide de l administrateur

MEGA Administration-Supervisor. Guide de l administrateur MEGA Administration-Supervisor Guide de l administrateur MEGA HOPEX V1R2-V1R3 10ème édition (novembre 2015) Les informations contenues dans ce document pourront faire l objet de modifications sans préavis

Plus en détail

MEGA TeamWork. Guide d utilisation

MEGA TeamWork. Guide d utilisation MEGA TeamWork Guide d utilisation MEGA 2009 SP4 1ère édition (juin 2010) Les informations contenues dans ce document pourront faire l objet de modifications sans préavis et ne sauraient en aucune manière

Plus en détail

MASTER SIS PRO : logique et sécurité DÉTECTION D INTRUSIONS. Odile PAPINI, LSIS. Université de Toulon et du Var. papini@univ-tln.

MASTER SIS PRO : logique et sécurité DÉTECTION D INTRUSIONS. Odile PAPINI, LSIS. Université de Toulon et du Var. papini@univ-tln. MASTER SIS PRO : logique et sécurité DÉTECTION D INTRUSIONS Odile PAPINI, LSIS. Université de Toulon et du Var. papini@univ-tln.fr Plan Introduction Généralités sur les systèmes de détection d intrusion

Plus en détail

CAHIER DES SPECIFICATIONS FONCTIONNELLES

CAHIER DES SPECIFICATIONS FONCTIONNELLES 2010/2011 INSTITUT SUP GALILEE CAHIER DES SPECIFICATIONS FONCTIONNELLES IHM XML O.N.E.R.A. Institut Sup Galilée O.N.E.R.A. Page 2 Sommaire I. Description du sujet... 4 II. Outils utilisés... 4 III. Description

Plus en détail

D une part, elles ne peuvent faire table rase de la richesse contenue dans leur système d information.

D une part, elles ne peuvent faire table rase de la richesse contenue dans leur système d information. PACBASE «Interrogez le passé, il répondra présent.». Le Module e-business Les entreprises doivent aujourd hui relever un triple défi. D une part, elles ne peuvent faire table rase de la richesse contenue

Plus en détail

GESTION DU RÉSEAU DANS LES ENVIRONNEMENTS DISTRIBUÉS. Défis et Opportunités pour l Entreprise

GESTION DU RÉSEAU DANS LES ENVIRONNEMENTS DISTRIBUÉS. Défis et Opportunités pour l Entreprise GESTION DU RÉSEAU DANS LES ENVIRONNEMENTS DISTRIBUÉS Défis et Opportunités pour l Entreprise I. INTRODUCTION Le développement des réseaux ne se limite pas à leur taille et à leurs capacités, il concerne

Plus en détail

GPA 789 : Analyse et Conception Orientées Objet. ETS Mickaël Gardoni Bureau A 3588 tel 84 11. Mise en Œuvre UML version du 24 avril 2009

GPA 789 : Analyse et Conception Orientées Objet. ETS Mickaël Gardoni Bureau A 3588 tel 84 11. Mise en Œuvre UML version du 24 avril 2009 GPA 789 : Analyse et Conception Orientées Objet ETS Mickaël Gardoni Bureau A 3588 tel 84 11 Mise en œuvre UML 1/ 25 Introduction Mise en œuvre d UML UML n est pas une méthode 2/ 25 1 UML n est qu un langage

Plus en détail

Résumé CONCEPTEUR, INTEGRATEUR, OPERATEUR DE SYSTEMES CRITIQUES

Résumé CONCEPTEUR, INTEGRATEUR, OPERATEUR DE SYSTEMES CRITIQUES Aristote ----- Cloud Interopérabilité Retour d'expérience L A F O R C E D E L I N N O V A T I O N Résumé Les systèmes d'information logistique (SIL) sont des outils qui amènent des gains de productivité

Plus en détail

Sensibilisation à la sécurité informatique

Sensibilisation à la sécurité informatique Sensibilisation à la sécurité informatique Michel Salomon IUT de Belfort-Montbéliard Département d informatique Michel Salomon Sécurité 1 / 25 Sensibilisation à la sécurité informatique Généralités et

Plus en détail

Introduction pratique au Développement orienté Modèle Pierre Parrend, Mars 2005

Introduction pratique au Développement orienté Modèle Pierre Parrend, Mars 2005 MDA : Un Tutoriel Introduction pratique au Développement orienté Modèle Pierre Parrend, Mars 2005 1 Sommaire Table des matières 1 Sommaire 1 2 Introduction 2 2.1 A qui s adresse ce tutoriel......................

Plus en détail

Retour d expérience sur Prelude

Retour d expérience sur Prelude Retour d expérience sur Prelude OSSIR Paris / Mathieu Mauger Consultant Sécurité (Mathieu.Mauger@intrinsec.com) Guillaume Lopes Consultant Sécurité (Guillaume.Lopes@Intrinsec.com) @Intrinsec_Secu 1 Plan

Plus en détail

Déploiement adaptatif des composants dans les sessions collaboratives

Déploiement adaptatif des composants dans les sessions collaboratives NOuvelles TEchnologies de la REpartition NOTERE 2005 Déploiement adaptatif des composants dans les sessions collaboratives Emir HAMMAMI, Thierry VILLEMUR {ehammami, villemur}@laas.fr LAAS-CNRS 7, avenue

Plus en détail

WEA Un Gérant d'objets Persistants pour des environnements distribués

WEA Un Gérant d'objets Persistants pour des environnements distribués Thèse de Doctorat de l'université P & M Curie WEA Un Gérant d'objets Persistants pour des environnements distribués Didier Donsez Université Pierre et Marie Curie Paris VI Laboratoire de Méthodologie et

Plus en détail

données en connaissance et en actions?

données en connaissance et en actions? 1 Partie 2 : Présentation de la plateforme SPSS Modeler : Comment transformer vos données en connaissance et en actions? SPSS Modeler : l atelier de data mining Large gamme de techniques d analyse (algorithmes)

Plus en détail

Résumé du chapitre 3 Synchronisation entre processus : de producteur/consommateur aux sémaphores

Résumé du chapitre 3 Synchronisation entre processus : de producteur/consommateur aux sémaphores Résumé du chapitre 3 Synchronisation entre processus : de producteur/consommateur aux sémaphores Jacques Mossière 22 septembre 2008 1 Introduction Nous étudions dans ce chapitre la réalisation des processus

Plus en détail

Architecture Logicielle

Architecture Logicielle Architecture Logicielle Chapitre 3: UML pour la description et la documentation d une architecture logicielle Année universitaire 2013/2014 Semestre 1 Rappel L architecture d un programme ou d un système

Plus en détail

LES RÉSEAUX INFORMATIQUES

LES RÉSEAUX INFORMATIQUES LES RÉSEAUX INFORMATIQUES Lorraine Le développement d Internet et de la messagerie électronique dans les entreprises a été, ces dernières années, le principal moteur de la mise en place de réseau informatique

Plus en détail

LES OUTILS DU TRAVAIL COLLABORATIF

LES OUTILS DU TRAVAIL COLLABORATIF LES OUTILS DU TRAVAIL COLLABORATIF Lorraine L expression «travail collaboratif» peut se définir comme «l utilisation de ressources informatiques dans le contexte d un projet réalisé par les membres d un

Plus en détail

82 -FRONTAL DE FLUX : PRESENTATION GENERALE TIERS PAYANT OPTIQUE

82 -FRONTAL DE FLUX : PRESENTATION GENERALE TIERS PAYANT OPTIQUE 82 -FRONTAL DE FLUX : PRESENTATION GENERALE TIERS PAYANT OPTIQUE G.I.E. SINTIA 42 rue de Clichy - 75009 Paris Standard 01 45 96 12 12 - Fax 01 45 96 11 58 http://www.sintia.fr OBJET Objectif résumé du

Plus en détail

Media Streaming avec Windows 7

Media Streaming avec Windows 7 Media Streaming avec Windows 7 Après avoir parlé des nouvelles possibilités réseaux de Windows, notamment des «Homegroups», pardon, des «groupes résidentiels, voyons comment ont été intégrées les possibilités

Plus en détail

2. MAQUETTAGE DES SOLUTIONS CONSTRUCTIVES. 2.2 Architecture fonctionnelle d un système communicant. http://robert.cireddu.free.

2. MAQUETTAGE DES SOLUTIONS CONSTRUCTIVES. 2.2 Architecture fonctionnelle d un système communicant. http://robert.cireddu.free. 2. MAQUETTAGE DES SOLUTIONS CONSTRUCTIVES 2.2 Architecture fonctionnelle d un système communicant Page:1/11 http://robert.cireddu.free.fr/sin LES DÉFENSES Objectifs du COURS : Ce cours traitera essentiellement

Plus en détail

L audit de sécurité des réseaux Windows avec WinReporter

L audit de sécurité des réseaux Windows avec WinReporter White Paper L audit de sécurité des réseaux Windows avec WinReporter Ce document présente comment les administrateurs réseaux et système peuvent tirer le meilleur parti de WinReporter, édité par IS Decisions,

Plus en détail

Nom de l application

Nom de l application Ministère de l Enseignement Supérieur et de la Recherche Scientifique Direction Générale des Etudes Technologiques Institut Supérieur des Etudes Technologiques de Gafsa Département Technologies de l Informatique

Plus en détail

La sécurité informatique

La sécurité informatique 1 La sécurité informatique 2 Sécurité des systèmes d information Yves Denneulin (ISI) et Sébastien Viardot(SIF) Cadre du cours Informatique civile (avec différences si publiques) Technologies répandues

Plus en détail

Détection d intrusions : corrélation d alertes

Détection d intrusions : corrélation d alertes SYNTHÈSE Détection d intrusions : corrélation d alertes Hervé Debar 1 Benjamin Morin 1 Frédéric Cuppens 2,4 Fabien Autrel 2 Ludovic Mé 3 Bernard Vivinis 3 Salem Benferhat 4 Mireille Ducassé 5 Rodolphe

Plus en détail

Spring IDE. Mise en œuvre. Eclipse

Spring IDE. Mise en œuvre. Eclipse A Spring IDE Bien que Spring mette à disposition d intéressants mécanismes afin d améliorer l architecture des applications Java EE en se fondant sur l injection de dépendances et la programmation orientée

Plus en détail

CHAPITRE 3 : INTERVENTIONS SUR INCIDENTS

CHAPITRE 3 : INTERVENTIONS SUR INCIDENTS CHAPITRE 3 : INTERVENTIONS SUR INCIDENTS CINQ RECOMMANDATIONS ESSENTIELLES 1 CINQ RECOMMANDATIONS ESSENTIELLES CINQ RECOMMANDATIONS ESSENTIELLES BASÉES SUR UNE ANALYSE DES INCIDENTS OBSERVÉS En 2014, le

Plus en détail

Besoin de concevoir des systèmes massivement répartis. Comment tester le système? Solution. Évaluation de systèmes répartis à large échelle

Besoin de concevoir des systèmes massivement répartis. Comment tester le système? Solution. Évaluation de systèmes répartis à large échelle Besoin de concevoir des systèmes massivement répartis. Évaluation de systèmes répartis à large échelle Sergey Legtchenko Motivation : LIP6-INRIA Tolérance aux pannes Stockage de données critiques Coût

Plus en détail

LIVRE BLANC Accès ininterrompu à des

LIVRE BLANC Accès ininterrompu à des LIVRE BLANC LIVRE BLANC Accès ininterrompu à des volumes de cluster partagés à mise en miroir synchrone sur des sites métropolitains actifs La prise en charge des clusters de basculement sous Windows Server

Plus en détail

Types d applications pour la persistance. Outils de développement. Base de données préexistante? 3 modèles. Variantes avec passerelles

Types d applications pour la persistance. Outils de développement. Base de données préexistante? 3 modèles. Variantes avec passerelles Types d applications pour la persistance Université de Nice Sophia-Antipolis Version 0.9 28/8/07 Richard Grin Toutes les applications n ont pas une complexité qui nécessite une architecture n- tiers Ce

Plus en détail

1 La visualisation des logs au CNES

1 La visualisation des logs au CNES 1 La visualisation des logs au CNES 1.1 Historique Depuis près de 2 ans maintenant, le CNES a mis en place une «cellule d analyse de logs». Son rôle est multiple : Cette cellule est chargée d analyser

Plus en détail

Description des prestations

Description des prestations Description des prestations Envoi, réception et archivage d e-factures Valable à partir du 01. 01.2015 Table des matières 1. Principes 3 1.1 Définitions 3 1.2 Canaux de communication 3 1.3 Moyens d identification

Plus en détail

Sciences de Gestion Spécialité : SYSTÈMES D INFORMATION DE GESTION

Sciences de Gestion Spécialité : SYSTÈMES D INFORMATION DE GESTION Sciences de Gestion Spécialité : SYSTÈMES D INFORMATION DE GESTION Classe de terminale de la série Sciences et Technologie du Management et de la Gestion Préambule Présentation Les technologies de l information

Plus en détail

RETRO-INGENIERIE DES BASES DE DONNEES

RETRO-INGENIERIE DES BASES DE DONNEES RETRO-INGENIERIE DES BASES DE DONNEES Les contenus de ce document sont la propriété exclusive de la société REVER. Ils ne sont transmis qu à titre d information et ne peuvent en aucun cas être considérés

Plus en détail

LES FONCTIONS DE SURVEILLANCE DES FICHIERS

LES FONCTIONS DE SURVEILLANCE DES FICHIERS SYSLOG and APPLICATION LOGS Knowledge Module for PATROL - Data Sheet Version 1.5 Développé par http://www.axivia.com/ PRESENTATION DU PRODUIT SYSLOG and APPLICATION LOGS Knowledge Module for PATROL est

Plus en détail

Université de Bangui. Modélisons en UML

Université de Bangui. Modélisons en UML Université de Bangui CRM Modélisons en UML Ce cours a été possible grâce à l initiative d Apollinaire MOLAYE qui m a contacté pour vous faire bénéficier de mes connaissances en nouvelles technologies et

Plus en détail

REFERENTIEL DU CQPM. TITRE DU CQPM : Préventeur (trice) en cybersécurité des systèmes d information

REFERENTIEL DU CQPM. TITRE DU CQPM : Préventeur (trice) en cybersécurité des systèmes d information COMMISION PARITAIRE NATIONALE DE L EMPLOI DE LE METALLURGIE Qualification : Catégorie : D Dernière modification : 02/04/2015 REFERENTIEL DU CQPM TITRE DU CQPM : Préventeur (trice) en cybersécurité des

Plus en détail

Le modèle de données relationnel

Le modèle de données relationnel Le modèle de données relationnel 1. Le modèle relationnel 1.1. Présentation Le modèle relationnel représente la base de données comme un ensemble de tables, sans préjuger de la façon dont les informations

Plus en détail

Solutions SAP Crystal

Solutions SAP Crystal Solutions SAP Crystal Solutions SAP Crystal NOUVEAUTÉS 2011 SOMMAIRE ^ 4 Nouveautés de SAP Crystal Server 2011 4 Exploration contextuelle des données 5 Expérience utilisateur attrayante 5 Panneau d interrogation

Plus en détail

INTERSYSTEMS CACHÉ COMME ALTERNATIVE AUX BASES DE DONNÉES RÉSIDENTES EN MÉMOIRE

INTERSYSTEMS CACHÉ COMME ALTERNATIVE AUX BASES DE DONNÉES RÉSIDENTES EN MÉMOIRE I N T E RS Y S T E M S INTERSYSTEMS CACHÉ COMME ALTERNATIVE AUX BASES DE DONNÉES RÉSIDENTES EN MÉMOIRE David Kaaret InterSystems Corporation INTERSySTEMS CAChé CoMME ALTERNATIvE AUx BASES de données RéSIdENTES

Plus en détail

Elles énumèrent les connaissances qui doivent être acquises par les élèves à l issue de la classe terminale.

Elles énumèrent les connaissances qui doivent être acquises par les élèves à l issue de la classe terminale. Annexe 5 SCIENCES DE GESTION - CLASSE TERMINALE SPÉCIALITÉ : SYSTÈMES D INFORMATION DE GESTION Présentation Les technologies de l information et de la communication contribuent à la construction d'une

Plus en détail

LA GESTION DE FICHIERS

LA GESTION DE FICHIERS CHAPITRE 6 : LA GESTION DE FICHIERS Objectifs spécifiques Connaître la notion de fichier, ses caractéristiques Connaître la notion de répertoires et partitions Connaître les différentes stratégies d allocation

Plus en détail

Service combinators for farming virtual machines

Service combinators for farming virtual machines Master d Informatique Fondamentale École Normale Supérieure de Lyon Sémantique du parallélisme Chantal Keller Service combinators for farming virtual machines K. Bhargavan, A. D. Gordon, I. Narasamdya

Plus en détail

Conception de la base de données

Conception de la base de données Rapport T.E.R HLIN405 Conception de la base de données des projets de licence deuxième et troisième année Réalisé par Achraf Tajani Cvete Maceski Mohamed Bareche Sous l encadrement de Christian Retoré

Plus en détail

Sécurisation du DNS : les extensions DNSsec

Sécurisation du DNS : les extensions DNSsec Sécurisation du DNS : les extensions DNSsec Bertrand Leonard, AFNIC/projet IDsA Sécurisation du DNS: les extensions DNSsec JRES, 19/11/03 1 Historique Jusqu en 1984 : réseau restreint militaire/universitaire/recherche

Plus en détail

Chapitre 7. Approfondir les connaissances

Chapitre 7. Approfondir les connaissances Chapitre 7 Approfondir les connaissances Déroulement du cours 1 : Le rôle du Designer d Univers 2 : Créer un Univers avec l Assistant 3 : Créer un Univers étape par étape 4 : Enrichir un Univers 5 : Création

Plus en détail

itop : la solution ITSM Open Source

itop : la solution ITSM Open Source itop : la solution ITSM Open Source itop est un portail web multi-clients conçu pour les fournisseurs de services et les entreprises. Simple et facile d utilisation il permet de gérer dans une CMDB flexible

Plus en détail

CONNECT. Mode d emploi. Android

CONNECT. Mode d emploi. Android CONNECT Mode d emploi Android fr Table des matières 1 Qu est-ce que JURA Connect?... 3 2 Premiers pas...4 3 Assistant de configuration... 5 Bienvenue dans l assistant de configuration!... 6 Insérer Smart

Plus en détail

et dépannage de PC Configuration Sophie Lange Guide de formation avec exercices pratiques Préparation à la certification A+

et dépannage de PC Configuration Sophie Lange Guide de formation avec exercices pratiques Préparation à la certification A+ Guide de formation avec exercices pratiques Configuration et dépannage de PC Préparation à la certification A+ Sophie Lange Troisième édition : couvre Windows 2000, Windows XP et Windows Vista Les Guides

Plus en détail

DOCUMENTATION DU COMPAGNON ASP

DOCUMENTATION DU COMPAGNON ASP DOCUMENTATION DU COMPAGNON ASP MANUEL UTILISATEUR VERSION 1.0 / SEPTEMBRE 2011 Rédacteur Gilles Mankowski 19/09/2011 Chapitre : Pre requis CONTENU Pre requis... 3 Introduction... 3 Comment fonctionne l'asp?...

Plus en détail

Chacun est conscient qu il sera souvent nécessaire de mobiliser les notions abordées en première et, parfois, de les reprendre.

Chacun est conscient qu il sera souvent nécessaire de mobiliser les notions abordées en première et, parfois, de les reprendre. UE Atelier B Deux groupes de stagiaires ont suivi les exposés sur les séquences pédagogiques. Les échanges ont principalement porté sur les apports notionnels (quelles notions aborder), le bornage (jusqu

Plus en détail

Systèmes d information

Systèmes d information 11 Systèmes Cette famille rassemble des métiers dont la finalité est de concevoir, développer, exploiter et entretenir des solutions (logicielles et matérielles) répondant aux besoins collectifs et individuels

Plus en détail

Les formations. Développeur Logiciel. ENI Ecole Informatique

Les formations. Développeur Logiciel. ENI Ecole Informatique page 1/8 Titre professionnel : Inscrit au RNCP de Niveau III (Bac + 2) (J.O. du 19/02/13) 24 semaines + 8 semaines de stage (uniquement en formation continue) Développer une application orientée objet

Plus en détail

Solutions de gestion de la sécurité Livre blanc

Solutions de gestion de la sécurité Livre blanc Solutions de gestion de la sécurité Livre blanc L intégration de la gestion des identités et des accès avec l authentification unique Objectif : Renforcer la politique de sécurité et améliorer la productivité

Plus en détail

Les systèmes RAID Architecture des ordinateurs

Les systèmes RAID Architecture des ordinateurs METAIS Cédric 2 ème année Informatique et réseaux Les systèmes RAID Architecture des ordinateurs Cédric METAIS ISMRa - 1 - LES DIFFERENTS SYSTEMES RAID SOMMAIRE INTRODUCTION I LES DIFFERENTS RAID I.1 Le

Plus en détail

Plan. Cours 4 : Méthodes d accès aux données. Architecture système. Objectifs des SGBD (rappel)

Plan. Cours 4 : Méthodes d accès aux données. Architecture système. Objectifs des SGBD (rappel) UPMC - UFR 99 Licence d informatique 205/206 Module 3I009 Cours 4 : Méthodes d accès aux données Plan Fonctions et structure des SGBD Structures physiques Stockage des données Organisation de fichiers

Plus en détail

PROGRAMME DU CONCOURS DE RÉDACTEUR INFORMATICIEN

PROGRAMME DU CONCOURS DE RÉDACTEUR INFORMATICIEN PROGRAMME DU CONCOURS DE RÉDACTEUR INFORMATICIEN 1. DÉVELOPPEMENT D'APPLICATION (CONCEPTEUR ANALYSTE) 1.1 ARCHITECTURE MATÉRIELLE DU SYSTÈME INFORMATIQUE 1.1.1 Architecture d'un ordinateur Processeur,

Plus en détail

FICHE PRODUIT COREYE CACHE Architecture technique En bref Plateforme Clients Web Coreye Cache applicative Références Principe de fonctionnement

FICHE PRODUIT COREYE CACHE Architecture technique En bref Plateforme Clients Web Coreye Cache applicative Références Principe de fonctionnement COREYE CACHE Solution d absorption de charge pour une disponibilité et une performance optimales des applications Web En bref Architecture technique La plateforme Coreye Cache délivre la majeure partie

Plus en détail

Release Notes POM v5

Release Notes POM v5 Release Notes POM v5 POM Monitoring http://www.pom-monitoring.com Ce document est strictement réservé à l usage de la société POM Monitoring. Il ne peut être diffusé ou transféré sans l autorisation écrite

Plus en détail

Bases de données Cours 1 : Généralités sur les bases de données

Bases de données Cours 1 : Généralités sur les bases de données Cours 1 : Généralités sur les bases de données POLYTECH Université d Aix-Marseille odile.papini@univ-amu.fr http://odile.papini.perso.esil.univmed.fr/sources/bd.html Plan du cours 1 1 Qu est ce qu une

Plus en détail

AADL. un langage pour la modélisation et la génération d applications. Thomas Vergnaud, thomas.vergnaud@enst.fr

AADL. un langage pour la modélisation et la génération d applications. Thomas Vergnaud, thomas.vergnaud@enst.fr AADL un langage pour la modélisation et la génération d applications, thomas.vergnaud@enst.fr Les langages de description d architecture la conception des systèmes devient complexe difficulté de compréhension

Plus en détail

Conception des systèmes répartis

Conception des systèmes répartis Conception des systèmes répartis Principes et concepts Gérard Padiou Département Informatique et Mathématiques appliquées ENSEEIHT Octobre 2012 Gérard Padiou Conception des systèmes répartis 1 / 37 plan

Plus en détail

Présentation SERVEUR EN CLUSTER. Clinkast 4 Avenue du Général de Gaulle F 92360 Meudon (+33) 6 20 44 86 95 (+33) 1 46 30 24 13

Présentation SERVEUR EN CLUSTER. Clinkast 4 Avenue du Général de Gaulle F 92360 Meudon (+33) 6 20 44 86 95 (+33) 1 46 30 24 13 Présentation SERVEUR D APPLICATIONS EN CLUSTER Description Un cluster est un ensemble d instances de serveurs d applications combinant haute disponibilité et forte évolutivité. Contrairement à un système

Plus en détail

MSP Center Plus. Vue du Produit

MSP Center Plus. Vue du Produit MSP Center Plus Vue du Produit Agenda A propos de MSP Center Plus Architecture de MSP Center Plus Architecture Central basée sur les Probes Architecture Centrale basée sur l Agent Fonctionnalités démo

Plus en détail

Exceed 8.0. Nouvelles fonctionnalités

Exceed 8.0. Nouvelles fonctionnalités Exceed 8.0 Nouvelles fonctionnalités Copyright Hummingbird 2002 Page 1 of 9 Sommaire Sommaire... 2 Généralités... 3 Conformité à la section 508 de la Rehabilitation Act des Etats-Unis... 3 Certification

Plus en détail

Le premier objectif de Quickser est donc de proposer une solution avant tout source d économies et ce dans plusieurs domaines.

Le premier objectif de Quickser est donc de proposer une solution avant tout source d économies et ce dans plusieurs domaines. Quickser a été conçu dès que la version 7 de DB2/UDB annonçait la disponibilité d un dispositif majeur RTS (Real time statistic). En effet, les conséquences de la mise en œuvre de ce dispositif permettaient

Plus en détail

Supervision de la sécurits. curité et gestion du risque

Supervision de la sécurits. curité et gestion du risque Supervision de la sécurits curité et gestion du risque Plan de la présentation 1. La tendance en matière de SSI 2. Les enjeux de la supervision de la sécurits curité 3. La solution EAS La tendance Menace

Plus en détail

Conception des bases de données : Modèle Entité-Association

Conception des bases de données : Modèle Entité-Association Conception des bases de données : Modèle Entité-Association La modélisation d un problème, c est-à-dire le passage du monde réel à sa représentation informatique, se définit en plusieurs étapes pour parvenir

Plus en détail

IBM Tivoli Monitoring

IBM Tivoli Monitoring Surveiller et gérer les ressources vitales et les mesures sur diverses plates-formes à partir d une seule console IBM Tivoli Monitoring Points forts Surveille de manière proactive Aide à réduire les coûts

Plus en détail

Les formations. Développeur Logiciel. ENI Ecole Informatique

Les formations. Développeur Logiciel. ENI Ecole Informatique page 1/5 Titre professionnel : Reconnu par l Etat de niveau III (Bac), inscrit au RNCP (arrêté du 12/10/07, J.O. n 246 du 23/10/07) (32 semaines) Unité 1 : Structurer une application 6 semaines Module

Plus en détail

Cible de sécurité CSPN

Cible de sécurité CSPN Cible de sécurité CSPN ClearBUS Application cliente pour la communication sécurisée Version 1.12 Le 25/11/2011 Identifiant : CBUS-CS-1.12-20111125 contact@clearbus.fr tel : +33(0)485.029.634 Version 1.12

Plus en détail

Techniques et outils de test pour les logiciels réactifs synchrones

Techniques et outils de test pour les logiciels réactifs synchrones Journées Systèmes et Logiciels Critiques Institut IMAG ; 14-16 nombre 2000 Techniques et outils de test pour les logiciels réactifs synchrones Farid Ouabdesselam 1 Méthodes de test : classification générale

Plus en détail

Le langage UML : Les diagrammes de séquence. Lydie du Bousquet Lydie.du-bousquet@imag.fr

Le langage UML : Les diagrammes de séquence. Lydie du Bousquet Lydie.du-bousquet@imag.fr Le langage UML : Les diagrammes de séquence Lydie du Bousquet Lydie.du-bousquet@imag.fr 1 Modélisation des interactions Les objets d un système ont un comportement Ils interagissent entre eux Dynamique

Plus en détail