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

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

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

RAPPORT DE CONCEPTION UML :

RAPPORT DE CONCEPTION UML : Carlo Abi Chahine Sylvain Archenault Yves Houpert Martine Wang RAPPORT DE CONCEPTION UML : Bamboo Ch@t Projet GM4 Juin 2006 Table des matières 1 Introduction 2 2 Présentation du logiciel 3 2.1 Précisions

Plus en détail

TABLEAU DE BORD : SYSTEME D INFORMATION ET OUTIL DE PILOTAGE DE LA PERFOMANCE

TABLEAU DE BORD : SYSTEME D INFORMATION ET OUTIL DE PILOTAGE DE LA PERFOMANCE TABLEAU DE BORD : SYSTEME D INFORMATION ET OUTIL DE PILOTAGE DE LA PERFOMANCE INTRODUCTION GENERALE La situation concurrentielle des dernières années a confronté les entreprises à des problèmes économiques.

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

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

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

Architecture des ordinateurs. Optimisation : pipeline. Pipeline (I) Pipeline (II) Exemple simplifié : Instructions de type R

Architecture des ordinateurs. Optimisation : pipeline. Pipeline (I) Pipeline (II) Exemple simplifié : Instructions de type R Architecture des ordinateurs Licence Informatique - Université de Provence Jean-Marc Talbot Optimisation : pipeline jtalbot@cmi.univ-mrs.fr L3 Informatique - Université de Provence () Architecture des

Plus en détail

LES OUTILS DE LA GESTION DE PROJET

LES OUTILS DE LA GESTION DE PROJET LES OUTILS DE LA GESTION DE PROJET PROJET : «ensemble des actions à entreprendre afin de répondre à un besoin défini dans des délais fixés». Délimité dans le temps avec un début et une fin, mobilisant

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

Introduction aux systèmes d exploitation

Introduction aux systèmes d exploitation Introduction aux systèmes d exploitation Le système d exploitation est un ensemble de logiciels qui pilotent la partie matérielle d un ordinateur. Les principales ressources gérées par un système d exploitation

Plus en détail

LES NOUVEAUTES DE COST AND PROFITABILITY MANAGEMENT 8.1

LES NOUVEAUTES DE COST AND PROFITABILITY MANAGEMENT 8.1 LES NOUVEAUTES DE COST AND PROFITABILITY MANAGEMENT 8.1 SAS Cost and Profitability Management, également appelé CPM (ou C&P), est le nouveau nom de la solution SAS Activity-Based Management. Cette version

Plus en détail

les outils de la gestion de projet

les outils de la gestion de projet les outils de la gestion de projet Sommaire Objectifs de la gestion de projet Les étapes du projet Les outils de gestion de projets Paramétrage de l outil PROJET : «ensemble des actions à entreprendre

Plus en détail

Systèmes d Information Avancés (et répartis)

Systèmes d Information Avancés (et répartis) Systèmes d Information Avancés (et répartis) Université Lyon 1 MIAGE L. Médini, mars 2005 Plan des cours Protocole HTTP et programmation serveur Architectures réparties Objets distribués Introduction aux

Plus en détail

RAPPORT DU PREMIER MINI PROJET «FORUM DE CHAT» Novembre 2005

RAPPORT DU PREMIER MINI PROJET «FORUM DE CHAT» Novembre 2005 Oussama ELKACHOINDI Wajdi MEHENNI RAPPORT DU PREMIER MINI PROJET «FORUM DE CHAT» Novembre 2005 Sommaire I. Préliminaire : Notice d exécution et mode opératoire...4 II. Architecture globale de l application...5

Plus en détail

Le Petit Robert 2011 Version réseau Windows

Le Petit Robert 2011 Version réseau Windows Le Petit Robert 2011 Version réseau Windows Manuel d installation serveur et postes clients Ce document décrit la procédure d installation pour la version réseau Windows (partage de fichiers) du Petit

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

PG208, Projet n 3 : Serveur HTTP évolué

PG208, Projet n 3 : Serveur HTTP évolué PG208, Projet n 3 : Serveur HTTP évolué Bertrand LE GAL, Serge BOUTER et Clément VUCHENER Filière électronique 2 eme année - Année universitaire 2011-2012 1 Introduction 1.1 Objectif du projet L objectif

Plus en détail

La gestion de la liquidité dans TARGET2

La gestion de la liquidité dans TARGET2 La gestion de la liquidité dans TARGET2 INTRODUCTION Dans un RTGS (Real-Time Gross Settlement system), les transactions sont réglées en monnaie centrale, de façon continue, sur une base brute. Ce type

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

Cahier Technique Installation sous Terminal Server Edition. Sage P.E. Documentation technique

Cahier Technique Installation sous Terminal Server Edition. Sage P.E. Documentation technique Cahier Technique Installation sous Terminal Server Edition Sage P.E Documentation technique Sommaire I. Introduction... 3 II. Configuration du serveur... 4 1. Principe d utilisation à distance... 4 2.

Plus en détail

CAHIER DES CHARGES D IMPLANTATION

CAHIER DES CHARGES D IMPLANTATION CAHIER DES CHARGES D IMPLANTATION Tableau de diffusion du document Document : Cahier des Charges d Implantation EVRP Version 6 Etabli par DCSI Vérifié par Validé par Destinataires Pour information Création

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

SAUVEGARDE ET RESTAURATION DES METADONNEES AVEC SAS 9.3

SAUVEGARDE ET RESTAURATION DES METADONNEES AVEC SAS 9.3 SAUVEGARDE ET RESTAURATION DES METADONNEES AVEC SAS 9.3 SAS 9.3 est disponible depuis le 12 Juillet 2011. Cette nouvelle version s accompagne de son lot de nouveautés notamment au niveau du serveur de

Plus en détail

BOUYGUES TELECOM ENTREPRISES - CLOUD

BOUYGUES TELECOM ENTREPRISES - CLOUD BOUYGUES TELECOM ENTREPRISES - CLOUD PARTIE CLIENT Version 1.4. 21/06/2013 Partie client Page 1 Sommaire 1 FONCTIONS CLES DU PORTAIL 3 1.1 Pré-requis d utilisation des services Cloud 3 1.2 Principes de

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

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

User Documentation. Documentation utilisateur. version 0.2b 04-2009

User Documentation. Documentation utilisateur. version 0.2b 04-2009 User Documentation Documentation utilisateur version 0.2b 04-2009 Table des matières 3 French Version....4 English Version.22 Table des matières 4 Table des matières TABLE DES MATIERES 3 A PROPOS DE CE

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

ACTUALITÉS LANDPARK. Nouvelle version. Landpark Helpdesk. Landpark Helpdesk. Les avantages de la nouvelle version 3.9.2.

ACTUALITÉS LANDPARK. Nouvelle version. Landpark Helpdesk. Landpark Helpdesk. Les avantages de la nouvelle version 3.9.2. ACTUALITÉS LANDPARK Solutions complètes d'inventaire, de gestion de parc et de helpdesk ITIL Avril 2015 Nouvelle version Landpark Helpdesk Landpark vous associe aux meilleurs logiciels de Gestion de Parc

Plus en détail

FICHE JANVIER 2009 THÉMATIQUE. Direction de projets et programmes

FICHE JANVIER 2009 THÉMATIQUE. Direction de projets et programmes FICHE JANVIER 2009 THÉMATIQUE Direction de projets et programmes La représentation par les processus pour les projets Système d Information (SI) La modélisation de l'entreprise par les processus devient

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

EP 1 931 091 A1 (19) (11) EP 1 931 091 A1 (12) DEMANDE DE BREVET EUROPEEN. (43) Date de publication: 11.06.2008 Bulletin 2008/24

EP 1 931 091 A1 (19) (11) EP 1 931 091 A1 (12) DEMANDE DE BREVET EUROPEEN. (43) Date de publication: 11.06.2008 Bulletin 2008/24 (19) (12) DEMANDE DE BREVET EUROPEEN (11) EP 1 931 091 A1 (43) Date de publication: 11.06.2008 Bulletin 2008/24 (51) Int Cl.: H04L 12/58 (2006.01) (21) Numéro de dépôt: 07291423.7 (22) Date de dépôt: 29.11.2007

Plus en détail

Profil de protection d un logiciel d ingénierie

Profil de protection d un logiciel d ingénierie Version 1.0 moyen-terme GTCSI 11 septembre 2015 Avant-propos Dans toute la suite de ce document, l acronyme ToE (Target of Evaluation) désigne le composant qui est l objet de l évaluation. 1 Descriptif

Plus en détail

LIVRE BLANC QUALIOS MANAGER

LIVRE BLANC QUALIOS MANAGER LIVRE BLANC QUALIOS MANAGER Version 3.0 3, rue du Bois de La Champelle BP 306 54515 VANDŒUVRE CEDEX Tél. 33 (0)3 83 44 75 50 Fax. 33 (0)3 83 44 75 51 QUALIOS est une solution informatique développée par

Plus en détail

COMMENT DÉFINIR L ORIENTÉ OBJET

COMMENT DÉFINIR L ORIENTÉ OBJET COMMENT DÉFINIR L ORIENTÉ OBJET De manière superficielle, le terme «orienté objet», signifie que l on organise le logiciel comme une collection d objets dissociés comprenant à la fois une structure de

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

Gestion du parc informatique matériel et logiciel de l Ensicaen. Rapport de projet. Spécialité Informatique 2 e année. SAKHI Taoufik SIFAOUI Mohammed

Gestion du parc informatique matériel et logiciel de l Ensicaen. Rapport de projet. Spécialité Informatique 2 e année. SAKHI Taoufik SIFAOUI Mohammed 6, bd maréchal Juin F-14050 Caen cedex 4 Spécialité Informatique 2 e année Rapport de projet Gestion du parc informatique matériel et logiciel de l Ensicaen SAKHI Taoufik SIFAOUI Mohammed Suivi ENSICAEN

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

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

Mise à jour Apsynet DataCenter

Mise à jour Apsynet DataCenter Mise à jour Apsynet DataCenter Dans le cadre de sa stratégie d évolution produit, Apsynet propose à ses clients sous contrat de maintenance une mise à jour majeure annuelle. Celle-ci peut être complétée

Plus en détail

Serveur d intégration continue Jenkins et d analyse de code Sonar couplés à la forge logiciel SourceSup

Serveur d intégration continue Jenkins et d analyse de code Sonar couplés à la forge logiciel SourceSup Serveur d intégration continue Jenkins et d analyse de code Sonar couplés à la forge logiciel SourceSup Sébastien MEDARD GIP RENATER 263 avenue du Général Leclerc CS 74205 35042 Rennes Cedex Résumé L intégration

Plus en détail

ITIL V3. Exploitation des services : Les processus

ITIL V3. Exploitation des services : Les processus ITIL V3 Exploitation des services : Les processus Création : juin 2013 Mise à jour : juin 2013 A propos A propos du document Ce document de référence sur le référentiel ITIL V3 a été réalisé en se basant

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

Guide utilisateur. Sophia

Guide utilisateur. Sophia Guide utilisateur Sophia http://smarttelecom.sophia-services.fr Table des matières 1 Objectif... 2 2 Accès... 2 3 Espace utilisateur... 3 4 Gestion des appels... 4 1- Renvoi Immédiat... 4 2- Renvoi sur

Plus en détail

GUIDE DE DEMARRAGE RAPIDE 4.5. FileAudit VERSION. www.isdecisions.com

GUIDE DE DEMARRAGE RAPIDE 4.5. FileAudit VERSION. www.isdecisions.com GUIDE DE DEMARRAGE RAPIDE FileAudit 4.5 VERSION www.isdecisions.com Introduction FileAudit surveille l accès ou les tentatives d accès aux fichiers et répertoires sensibles stockés sur vos systèmes Windows.

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

DECHARGEMENT ET CHARGEMENT MASSIF DES DONNEES

DECHARGEMENT ET CHARGEMENT MASSIF DES DONNEES DECHARGEMENT ET CHARGEMENT MASSIF DES 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

Plus en détail

Plateforme de capture et d analyse de sites Web AspirWeb

Plateforme de capture et d analyse de sites Web AspirWeb Projet Java ESIAL 2A 2009-2010 Plateforme de capture et d analyse de sites Web AspirWeb 1. Contexte Ce projet de deuxième année permet d approfondir par la pratique les méthodes et techniques acquises

Plus en détail

Manuel du logiciel PrestaTest.

Manuel du logiciel PrestaTest. Manuel du logiciel. Ce document décrit les différents tests que permet le logiciel, il liste également les informations nécessaires à chacun d entre eux. Table des matières Prérequis de PrestaConnect :...2

Plus en détail

UserLock Quoi de neuf dans UserLock? Version 8.5

UserLock Quoi de neuf dans UserLock? Version 8.5 UserLock Quoi de neuf dans UserLock? Version 8.5 Table des Matières 1. UserLock Version 8... 3 1.1. Le Statut utilisateur, un nouvel indicateur de risque... 3 1.2. Des alertes en temps réel contre les

Plus en détail

ModSecurity. Cible de sécurité CSPN Version 0.96

ModSecurity. Cible de sécurité CSPN Version 0.96 Cible de sécurité CSPN Version 0.96 TABLE DES MATIERES 1 IDENTIFICATION... 3 1.1 IDENTIFICATION DE LA CIBLE DE SECURITE... 3 1.2 IDENTIFICATION DU PRODUIT... 3 2 ARGUMENTAIRE (DESCRIPTION) DU PRODUIT...

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

Projet : Plan Assurance Qualité

Projet : Plan Assurance Qualité Projet : Document : Plan Assurance Qualité 2UP_SPEC_DEV1 VERSION 1.00 Objet Ce document a pour objectif de définir la démarche d analyse et de conception objet ainsi les activités liées. Auteur Eric PAPET

Plus en détail

DUT Informatique Module Système S4 C Département Informatique 2009 / 2010. Travaux Pratiques n o 5 : Sockets Stream

DUT Informatique Module Système S4 C Département Informatique 2009 / 2010. Travaux Pratiques n o 5 : Sockets Stream iut ORSAY DUT Informatique Département Informatique 2009 / 2010 Travaux Pratiques n o 5 : Sockets Stream Nom(s) : Groupe : Date : Objectifs : manipuler les primitives relatives à la communication par sockets

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

Par le service des publications Citrix. Citrix Systems, Inc.

Par le service des publications Citrix. Citrix Systems, Inc. Licences : présentation de l architecture Par le service des publications Citrix Citrix Systems, Inc. Avis Les informations contenues dans cette publication peuvent faire l'objet de modifications sans

Plus en détail

Ch4 Interconnexion des postes dans un Lan Ethernet : protocoles des couches 3 à 7 du modèle OSI Dernière maj : lundi 2 avril 2007

Ch4 Interconnexion des postes dans un Lan Ethernet : protocoles des couches 3 à 7 du modèle OSI Dernière maj : lundi 2 avril 2007 Ch4 Interconnexion des postes dans un Lan Ethernet : protocoles des couches 3 à 7 du modèle OSI Dernière maj : lundi 2 avril 2007 I. RAPPEL : ADRESSAGE PHYSIQUE : (OSI 2)... 1 A. L ADRESSAGE DANS UN RESEAU

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

Gestion multi-stocks

Gestion multi-stocks Gestion multi-stocks Dans l architecture initiale du logiciel IDH-STOCK, 11 champs obligatoires sont constitués. Ces champs ne peuvent être supprimés. Ils constituent l ossature de base de la base de données

Plus en détail

A. Introduction. Chapitre 4. - les entités de sécurité ; - les sécurisables ; - les autorisations.

A. Introduction. Chapitre 4. - les entités de sécurité ; - les sécurisables ; - les autorisations. Chapitre 4 A. Introduction Le contrôle d'accès représente une opération importante au niveau de la gestion de la sécurité sur un serveur de bases de données. La sécurisation des données nécessite une organisation

Plus en détail

CAHIER DES CHARGES D IMPLANTATION D EvRP V3

CAHIER DES CHARGES D IMPLANTATION D EvRP V3 CAHIER DES CHARGES D IMPLANTATION D EvRP V3 Tableau de diffusion du document Document : Cahier des Charges d Implantation EVRP V3 Version 42 Etabli par Département Accompagnement des Logiciels Vérifié

Plus en détail

Notre offre Système. systemes@arrabal-is.com

Notre offre Système. systemes@arrabal-is.com systemes@arrabal-is.com Généralités Généralités des systèmes Windows Les systèmes Microsoft sont au cœur du système d information de la majorité des entreprises, si bien qu environ 90% des postes utilisateurs

Plus en détail

SERVICES RELATIFS A L EXPLOITATION DE RESEAUX DE TELECOMMUNICATIONS (Terrestres et satellitaires)

SERVICES RELATIFS A L EXPLOITATION DE RESEAUX DE TELECOMMUNICATIONS (Terrestres et satellitaires) PROBLEMATIQUE - L APPROCHE JADE Telecom L exploitation de réseaux de télécommunications implique pour les entreprises la prise en compte de différents points importants : La mise en place de personnel

Plus en détail

Concours EXTERNE d ingénieur des systèmes d information et de communication. «Session 2009»

Concours EXTERNE d ingénieur des systèmes d information et de communication. «Session 2009» Concours EXTERNE d ingénieur des systèmes d information et de communication «Session 2009» Meilleure copie "Rapport Technique" Thème : conception et développement logiciel Note : 15,75/20 Rapport technique

Plus en détail

Conception Plateforme Messagerie

Conception Plateforme Messagerie Conception Plateforme Messagerie Date du document Vendredi 19 mai 2006 Sommaire du document I. Introduction...1 II. Une vision globale du système...1 1. Le diagramme de classes UML...1 2. Détail des méthodes

Plus en détail

Environnements de Développement

Environnements de Développement Institut Supérieur des Etudes Technologiques de Mahdia Unité d Enseignement: Environnements de Développement Mme BEN ABDELJELIL HASSINE Mouna m.bnaj@yahoo.fr Développement des systèmes d Information Syllabus

Plus en détail

LE COURTAGE PRÊT AVEC OCLC 08 octobre 2013. Schéma de fonctionnement du prêt sans courtage. 4

LE COURTAGE PRÊT AVEC OCLC 08 octobre 2013. Schéma de fonctionnement du prêt sans courtage. 4 TABLE DES MATIÈRES Contexte. 2 Fonctionnement du prêt avec OCLC pour les établissements ayant plusieurs services de PEB. 2 Avec ou sans courtage.. 2 Fonctionnement du courtage.. 2 Le rôle du courtier.

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

Accès aux courriers électroniques d un employé absent

Accès aux courriers électroniques d un employé absent Accès aux courriers électroniques d un employé absent Les maîtres-mots en la matière : mesures préventives, responsabilisation, proportionnalité et transparence 1. Il convient, à ce sujet, de se référer

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

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

Encryptions, compression et partitionnement des données

Encryptions, compression et partitionnement des données Encryptions, compression et partitionnement des données Version 1.0 Grégory CASANOVA 2 Compression, encryption et partitionnement des données Sommaire 1 Introduction... 3 2 Encryption transparente des

Plus en détail

Introduction à Windows Workflow Foundation

Introduction à Windows Workflow Foundation Introduction à Windows Workflow Foundation Version 1.1 Auteur : Mathieu HOLLEBECQ Co-auteur : James RAVAILLE http://blogs.dotnet-france.com/jamesr 2 Introduction à Windows Workflow Foundation [07/01/2009]

Plus en détail

Le fichier séquentiel [fs]

Le fichier séquentiel [fs] Le fichier séquentiel [fs] Karine Zampieri, Stéphane Rivière, Béatrice Amerein-Soltner Unisciel algoprog Version 17 avril 2015 Table des matières 1 Présentation 2 2 Exploitation d un document 3 3 Primitives

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

JASPERSOFT ET LE PAYSAGE ANALYTIQUE. Jaspersoft et le paysage analytique 1

JASPERSOFT ET LE PAYSAGE ANALYTIQUE. Jaspersoft et le paysage analytique 1 JASPERSOFT ET LE PAYSAGE ANALYTIQUE Jaspersoft et le paysage analytique 1 Ce texte est un résumé du Livre Blanc complet. N hésitez pas à vous inscrire sur Jaspersoft (http://www.jaspersoft.com/fr/analyticslandscape-jaspersoft)

Plus en détail

REQUEA. v 1.0.0 PD 20 mars 2008. Mouvements d arrivée / départ de personnels Description produit

REQUEA. v 1.0.0 PD 20 mars 2008. Mouvements d arrivée / départ de personnels Description produit v 1.0.0 PD 20 mars 2008 Mouvements d arrivée / départ de personnels Description produit Fonctionnalités L application Gestion des mouvements d arrivée / départ de Requea permet la gestion collaborative

Plus en détail

La réplication sous SQL Server 2005

La réplication sous SQL Server 2005 La réplication sous SQL Server 2005 Mettre en place la réplication sur SQL Server 2005 La réplication des bases de données est une problématique classique dans les systèmes d'information. En effet, dans

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

1 Programmation Client/Serveur basée sur TCP/IP

1 Programmation Client/Serveur basée sur TCP/IP Outils Informatique pour l ingénieur TD 1 Réseau et Web IP, Client/serveur 1 Programmation Client/Serveur basée sur TCP/IP 1.1 Buts de cette réalisation Ce TP sur la programmation client/serveur a pour

Plus en détail

LES OUTILS D ALIMENTATION DU REFERENTIEL DE DB-MAIN

LES OUTILS D ALIMENTATION DU REFERENTIEL DE DB-MAIN LES OUTILS D ALIMENTATION DU REFERENTIEL DE DB-MAIN Les contenues 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

Plus en détail

PLAN CONDUITE DE PROJET

PLAN CONDUITE DE PROJET PLAN CONDUITE DE PROJET Ce guide complète le cours, il donne une marche à suivre qui peut être adaptée si vous choisissez une méthode particulière ETUDE PREALABLE ANALYSE FONCTIONNELLE ANALYSE DETAILLEE

Plus en détail

IN SYSTEM. Préconisations techniques pour Sage 100 Windows, MAC/OS, et pour Sage 100 pour SQL Server V16. Objectif :

IN SYSTEM. Préconisations techniques pour Sage 100 Windows, MAC/OS, et pour Sage 100 pour SQL Server V16. Objectif : IN SYSTEM Préconisations techniques pour Sage 100 Windows, MAC/OS, et pour Sage 100 pour SQL V16 Objectif : En synthèse des manuels de référence de Sage Ligne 100, ce document vous présente les préconisations,

Plus en détail

SAS BI DASHBOARD 4.3 : POUR LE MEILLEUR ET POUR LE FILTRE

SAS BI DASHBOARD 4.3 : POUR LE MEILLEUR ET POUR LE FILTRE SAS BI DASHBOARD 4.3 : POUR LE MEILLEUR ET POUR LE FILTRE En tant qu outils d aide à la décision, les tableaux de bord doivent répondre rapidement. Pour participer à cet effort de réactivité en termes

Plus en détail

une SOluTION basée SuR un modèle POuR PRévOIR le TRaFIc en TemPS Réel

une SOluTION basée SuR un modèle POuR PRévOIR le TRaFIc en TemPS Réel Comment anticiper le temps réel? Une solution basée sur un modèle pour prévoir le trafic en temps réel PTV Optima est la clé pour une gestion du trafic réussie. Cette solution basée sur un modèle propose

Plus en détail

MIGRATION DE DONNÉES

MIGRATION DE DONNÉ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 comme un engagement de la société REVER.

Plus en détail

Cible de sécurité CSPN

Cible de sécurité CSPN Cible de sécurité CSPN Dropbear 2012.55 Ref 12-06-037-CSPN-cible-dropbear Version 1.0 Date June 01, 2012 Quarkslab SARL 71 73 avenue des Ternes 75017 Paris France Table des matières 1 Identification 3

Plus en détail

Communiqué de Pré-Lancement. Sage CRM.com Version 5.7

Communiqué de Pré-Lancement. Sage CRM.com Version 5.7 Communiqué de Pré-Lancement Sage CRM.com Version 5.7 Nouvelle offre produit Présent sur le marché de la Gestion de la Relation Client (CRM) depuis 3 ans en France, Sage compte environ 7000 clients qui

Plus en détail

Université Paris Diderot Master 1 II. Théorie et pratique de la concurrence

Université Paris Diderot Master 1 II. Théorie et pratique de la concurrence Université Paris Diderot Master 1 II Théorie et pratique de la concurrence Partiel du 30 avril 2009 Durée : 1h30. Tous les documents sont autorisés. Le barème est indicatif. Question 1 : Soit le programme

Plus en détail

Introduction aux Bases de Données

Introduction aux Bases de Données Introduction aux Bases de Données I. Bases de données I. Bases de données Les besoins Qu est ce qu un SGBD, une BD Architecture d un SGBD Cycle de vie Plan du cours Exemples classiques d'applications BD

Plus en détail

Calatik, la vision métier et technique pour simplifier le pilotage du système d information

Calatik, la vision métier et technique pour simplifier le pilotage du système d information Calatik, la vision métier et technique pour simplifier le pilotage du système d information Le contexte : trop d outils, d écrans et de complexité Dans le domaine du pilotage du système d information,

Plus en détail

La taille du journal application de l observateur des événements de Windows doit être suffisante pour contenir tous les messages.

La taille du journal application de l observateur des événements de Windows doit être suffisante pour contenir tous les messages. Les alertes Les alertes vont être définies afin de déclencher un traitement automatique pour corriger le problème et/ou avertir un opérateur qui sera en mesure d agir rapidement afin de résoudre le problème.

Plus en détail

Mission Val de Loire 81 rue Colbert BP 4322 37043 TOURS CEDEX 1 Siret 254 503 048 00012. Cahier des charges MAINTENANCE INFORMATIQUE

Mission Val de Loire 81 rue Colbert BP 4322 37043 TOURS CEDEX 1 Siret 254 503 048 00012. Cahier des charges MAINTENANCE INFORMATIQUE Mission Val de Loire 81 rue Colbert BP 4322 37043 TOURS CEDEX 1 Siret 254 503 048 00012 Cahier des charges MAINTENANCE INFORMATIQUE Mai 2013 Table des matières Sommaire 1 Introduction... 3 1.1 Objectifs...

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

Configuration de SQL server 2005 pour la réplication

Configuration de SQL server 2005 pour la réplication Sommaire Configuration de SQL server 2005 pour la réplication 1. Présentation du besoin... 2 2. Architecture des deux sites... 2 3. Présentation du modèle de publication de réplication... 3 4. Configuration

Plus en détail

Question 1.1. Modélisation d une machine simple

Question 1.1. Modélisation d une machine simple D'apres TD ENSEEIHT Question 1. Modélisation d une machine à café Corrigé du Travaux Dirigés n 2 Ingénierie des protocoles LOTOS Question 1.1. Modélisation d une machine simple La modélisation de la machine

Plus en détail

Migration d un logiciel de gestion

Migration d un logiciel de gestion Auteur : David PERRET Publication : 01/11/2015 Toute société utilisatrice de logiciel de gestion est inéluctablement confrontée à des migrations de données. Ces migrations représentent des risques et un

Plus en détail